Jak stworzyć aplikację SaaS w Pythonie i Django

Oprogramowanie jako usługa to tylko słowo marketingowe, technicznie nie różni się od serwera, który jest dostępny przez internet. Więc pytanie 3 nie ma sensu. Pozostaje nam pytanie 1 i 2:

1. Co masz na myśli mówiąc "aplikacja" w tym kontekście? Twoja aplikacja webowa (zbudowana z Pythona i Django) może mieć wiele aplikacji Django (komponentów, które składają się na aplikację webową), ale myślę, że nie o to ci chodzi. Możesz zbudować swoją stronę w Pythonie / Django i mieć różne opcje dostosowywania w zależności od tego, który użytkownik (klient) jest zalogowany. Na przykład klient premium może mieć włączone kilka zaawansowanych opcji, ale nadal jest częścią tej samej bazy kodowej. Po prostu niektóre opcje (przyciski / kontrolki itp.) nie są wyświetlane dla niektórych klientów

2. Django ma mnóstwo narzędzi do zarządzania użytkownikami, uprawnieniami i grupami. Możesz nadać każdemu użytkownikowi (każdemu klientowi) różne uprawnienia i te uprawnienia określają, co może zrobić. Dostęp do bazy danych powinien być zarządzane przez Twoją aplikację internetową. Na przykład kod określa, jakie informacje mają być wyświetlane na stronie internetowej (w zależności od tego, który klient jest zalogowany), a ten kod pobiera informacje z bazy danych. W zależności od skali, do której dążysz, możesz również określić, z której bazy danych mają być używane do pobierania informacji.

Bardzo podstawowy, elementarny przykład tego, jak byś to zrobił.

Załóżmy, że masz prostą aplikację zaprojektowaną do rozwiązania konkretnego przypadku biznesowego. Na przykład utworzyłeś aplikację do obsługi rezerwacji pokoju w biurze.

Aby "przekonwertować" tę aplikację na usługę , musisz ją skonfigurować tak, aby większość części aplikacji specyficznych dla Użytkownika była parametryczna(można ją "zmontować" - z braku lepszego słowa).

Tak wyglądałby front end nawrócony. Możesz utworzyć zmienne do przechowywania logo, nagłówek, zwiastun, schemat kolorów dla aplikacji; pozwalając każdemu użytkownikowi dostosować swoje wystąpienie.

Do tej pory, Twoja aplikacja jest w stanie dostosować się do przodu. Nadal korzysta z tej samej bazy danych, która została zaprojektowana w pierwszej fazie.

Teraz pojawia się kwestia pokazania tylko tych pól, które są istotne dla konkretnego użytkownika. Będzie to parametryzacja bazy danych. Możesz więc dodać kolumnę, która identyfikuje każdy wiersz jako należący do konkretnego użytkownika; następnie utwórz widoki lub procedury składowane, które filtrują rekordy na podstawie zalogowanego użytkownika.

Teraz aplikacja może być "wypożyczona"; ponieważ jesteś w stanie dostosować instancję w oparciu o użytkownika.

To po prostu robi się większy stąd-w zależności od skali, typu i zamierzonego dostosowania aplikacji. Możesz zdecydować, że Twoja aplikacja działa lepiej, gdy każdy użytkownik ma własną dedykowaną bazę danych zamiast procedury składowanej + widok combo.

Możesz zdecydować, że dla niektórych typów użytkowników (lub" pakietów") potrzebujesz dedykowanej instancji uruchomionej aplikacji. Tak więc dla użytkowników "premium" lub "ultra" chcesz mieć uruchomiony własny dedykowany system.

Jeśli Twoja aplikacja wymaga dużej ilości miejsca-możesz zdecydować się na oddzielną opłatę za przechowywanie.

Najważniejsze jest to, że nie ma to nic wspólnego z używanym językiem. To bardziej problem architektury i projektowania.

Mam post na blogu opisujący moją propozycję, jak zrobić aplikację sieciową SAAS dla wielu dzierżawców za pomocą Django. Multi-tenancy oznacza tutaj, że gdy użytkownik rejestruje się, ma swoją sub-domenę. Podsumowanie:

• wszyscy dzierżawcy mają jedną bazę danych, ale każdy z nich ma własne schematy. Wyobraź sobie, że masz stronę internetową abc.com i ktoś zarejestrowałxyz , aby uzyskać dostęp do swojej strony przez xyz.abc.com , wtedy dla lokatora xyz masz oddzielny schemat zawierający wszystkie tabele w ten sposób hermetyzujące dane związane tylko z xyz dzierżawcą. Istnieją inne sposoby, jak posiadanie jednej bazy danych i jednego schematu dla wszystkich lub posiadanie nawet oddzielnych baz danych. Ale podejście Schematy jest najlepszy kompromis. Dokumentacja biblioteki django-tenants zawiera bardziej szczegółowe informacje, jeśli jesteś zainteresowany
• Użyj biblioteki django-tenants do abstrakcji pracy z lokatorami. Kiedy ktoś uzyskuje dostęp xyz.abc.com , potrzebujesz aby wiedzieć, że xyz jest dzierżawcą i że należy użyć schematu xyz . biblioteka django-tenants robi to za ciebie, więc przy każdym żądaniu możesz uzyskać obiekt tenant po prostu wykonując current_tenant = request.tenant
• należy odróżnić tabele współdzielone od tabel specyficznych dla dzierżawców. Na przykład, posiadanie tabeli z listą zleceń jest specyficzne dla najemcy. Każdy najemca może mieć własną bazę danych zawierającą wszystkie zamówienia. Tabela powinna znajdować się wewnątrz schematu xyz. Na w tym samym czasie będziesz miał kilka podstawowych tabel Django, takich jak user . Dane mogą być udostępniane, na przykład, aby uniemożliwić dwóm użytkownikom rejestrowanie się za pomocą tego samego adresu e-mail.
• musisz skonfigurować swój DNS, aby przechwytywał wyrażenie wieloznaczne *. abc.com , dla którego możesz dodać a rekord wewnątrz Twojego cPanelu z *.abc.com linkującym do IP Twojego serwera