Witam. Szukam odpowiedzi na to pytanie jednak nie mogę znaleźć nic, co by mnie oświeciło. Chciałbym skierować to pytanie do osób doświadczonych, którzy pracowali już nad aplikacjami komercyjnymi i mieli w nich taki problem.
Otóż zastanawiam się na jakiej zasadzie działają aplikacje, które mają kilku klientów. Przykładowo: napisałem jakiś prosty system, który chciałbym sprzedawać dla wielu firm (czysto teoretycznie). Każda firma wykupuje podstawową wersję + wybiera sobie moduły.
Jak to jest z tymi modułami? Czy dla każdego klienta tworzy się oddzielny VPS, stawia się od nowa aplikacje i ją dostosowywuje, wgrywa jakiś folder z modułem? W takim przypadku przy aktualizacji i zmianach na każdym VPS musiałbym aktualizować kod.
Czy jest na to jakieś rozwiązanie? Jakaś technika, wzorzec projektowy?
Drugie pytanie to baza danych, choć z tym trochę znalazłem na forach, jednak zdania tam są podzielone. Jedna dla wielu czy kilka? Jeśli jedna - działa to na zasadzie : każda tabela ma kolumnę z np. "idFirmy" i potem po tej kolumnie wszystko filtrujemy? Tyle że w takim wypadku np.: jeden klient będzie miał w tabeli 100 tyś/ milion rekordów * kilka/kilkanaście firm, czy to jest dobre rozwiązanie?
Z drugiej strony każdy klient z jedną bazą danych, ale tu dochodzi do problemu edycji - zmiany w każdej bazie przy aktualizacjach.
Przepraszam jeśli powtórzyłem temat, niestety nic nie znalazłem. Nie jestem także bardzo doświadczony, trochę koduje, ale brak mi porady ekspertów
Dziękuję z góry za każdą pomoc

Co do modułów to możesz je wszystkie mieć na serwerze i włączać je w konfiguracji dla danego klienta. Jeśli są to jakieś zewnętrzne moduły, które klient może wgrać, to uploadujesz je do folderów per klient - każdy ma swój.

Co do bazy - to zależy :-) Jeśli aplikacja jest mała, danych nie ma za dużo to możesz spokojnie to trzymać w jednej dodając wszędzie identyfikator klienta. Jeśli jest większa, więcej danych to osobna baza będzie lepszym rozwiązaniem. Kwestia aktualizacji jest moim zdaniem pomijalna - bo to obojętne czy skrypt uruchomisz dla jednej wielkiej bazy czy dla wielu mniejszych. Mniejsze nawet możesz podzielić czasowo, uruchomić w kilku procesach i finalnie wyjdzie nawet szybciej (no i aktualizacja u jednego klienta nie spowalnia pracy pozostałych).

Co do podziału klient - nowy VPS to też ma sens. Ale jak wyżej - wszystko zależy od przypadku. Jeśli np w aplikacji masz różne plany, z różnymi parametrami wydajnościowymi, albo klient płaci za faktyczne zużycie to może się bardziej opłacać (czy tez być sprawiedliwiej) rozdzielać klientów na osobne maszyny. Wtedy działania jednego klienta nie wpływają w ogóle na innych. Wszystkie działania administracyjne mogą być odseparowane, jeden klient nie nadużyje zasobów przydzielonych dla innego klienta. Jedynie tutaj proponowałbym pójść w stronę kontenerów niż osobnych VPSów - będzie wygodniej i raczej taniej.

Miałem okazję pracować w kilku modelach rozwiązujących Twój problem. Poniżej znajdziesz zestawienie wad i zalet każdego z nich. Zestawienie to jest bardzo ogólne, więc zanim zdecydujesz się na jakiś model, poszukaj więcej szczegółów. Co więcej, nie są to wszystkie możliwości, np. pominąłem tutaj kontenery, które mogłyby pomóc rozwiązać niektóre problemy. Tak jak pisał vokiel - wszystko zależy od tego, co potrzebujesz.

1. Wszytko w jednym worze.

Aplikacja/serwer i baza danych są dzielone między wszystkich klientów.

Zalety:
- wszystko masz w jednym miejscu
- aktualizuję robisz na raz dla wszystkich klientów
- nie musisz tworzyć dodatkowych narzędzi do zarządzania

Wady:
- wszystko masz w jednym miejscu
- jeden klient jest w stanie położyć aplikację i nikt nie będzie w stanie jej używać
- aktualizacje są wypuszczane dla wszystkich klientów
- baza danych oraz aplikacja będą bardziej skomplikowane, ponieważ wszędzie musisz wstawić id klienta
- jeden mały błąd i dane jednego klienta mogą wyświetlić się innemu klientowi
- brak możliwości wersjonowania (wszyscy klienci są na tej samej wersji)

2. Wspólna aplikacja/serwer, niezależne bazy danych.

Aplikacja siedzi na jednym serwerze i jest wspólna dla wszystkich klientów, każdy klient ma dedykowaną bazę danych.

Zalety:
- separacja danych (bardzo niskie prawdopodobieństwo pokazania danych jednego klienta innemu klientowi)
- aplikację/serwer aktualizujesz na raz dla wszystkich klientów
- każdy klient może mieć inną wersję bazy danych (w zależności od wersji aplikacji)

Wady:
- będziesz potrzebował dodatkowego oprogramowania do zarządzania wersjami aplikacji/bazy danych
- każda baza danych musi być aktualizowana osobno
- jeden klient jest w stanie położyć aplikację i nikt nie będzie w stanie jej używać

3. Każdy klient ma osobny serwer i bazę danych.

Zalety:
- separacja danych (niskie prawdopodobieństwo pokazania danych jednego klienta innemu klientowi)
- każdy klient może być na innej wersji aplikacji/bazy danych
- nie ma możliwości aby jeden klient położył aplikację innym klientom

Wady:
- bardzo łatwo o bałagan
- będziesz potrzebował dodatkowego oprogramowania do zarządzania serwerami, wersjami aplikacji i bazy danych
- wysoka cena

4. "Rozproszona" aplikacja i oddzielne bazy danych.

Zalety:
- kod dla każdego klienta siedzi na jednym serwerze (może być w osobnych folderach lub linkować do konkretnych wersji - np. do tagu lub commit hash). Ten punkt można wykorzystać we wszystkich poprzednich modelach.
- aplikacja służy tylko do wyświetlenia danych, nie robi żadnych obliczeń (innymi słowy jest szybka)
- wszystkie operacje wykonywane są w tle, najlepiej na dedykowanym serwerze/serwerach lub w chmurze (kolejki, pubsub, websockets, itp.)
- nie ma możliwości aby jeden klient położył aplikację innym klientom

Wady:
- będziesz potrzebował dodatkowego oprogramowania do zarządzania wersjami aplikacji i bazy
- projekt będzie bardziej skomplikowanych i będzie wymagał więcej uwagi (dużo logowania i monitorowania)
- koszt może być wysoki (zależy od dodatkowych produktów)

5. Serverless

Zalety:
- każdy klient ma własną infrastrukturę
- nie ma możliwości pomieszania danych (no dobra, jest, ale bardzo mała)
- nie ma możliwości aby jeden klient położył aplikację innym klientom
- niski koszt początkowy
- nie trzeba zarządzać serwerami
- aktualizacje możesz robić per klient

Wady:
- będziesz potrzebował dodatkowego oprogramowania do zarządzania wersjami aplikacji i bazy
- będziesz potrzebował narzędzi typu Infrastructure as Code (terraform, CloudFormation, itp.) do zarządzania infrastrukturą
- koszt może bardzo szybko wzrosnąć

Drobna uwaga do punktu 2

No nie do konca, skoro kazdy klient bedzie mial te sama wersje aplikacji a nie rozna jak napisales w tym zdaniu

Musiałem myśleć o punkcie 4, gdy to pisałem. Nic nie stoi na przeszkodzie, aby każdy klient miał własny katalog na serwerze (tak jak w punkcie 4).