Comment créer une application SaaS avec Python et Django

le Logiciel en tant que Service est un vain mot, c'est techniquement pas différent d'un serveur qui est accessible sur internet. Donc la question 3 n'a pas de sens. Cela nous laisse avec les questions 1 et 2:

1. Que voulez vous dire par 'app' dans ce contexte? Votre application web (construite avec Python et Django) peut avoir plusieurs applications Django (composants qui composent l'application web) mais je pense que ce n'est pas ce que vous voulez dire. Vous pouvez construire votre site Web en Python / Django et ont différentes options de personnalisation en fonction de l'utilisateur (client) est connecté. Par exemple, un client premium peut avoir plusieurs options avancées activées, mais il fait toujours partie de la même base de codes. C'est juste que certaines options (boutons/commandes, etc) ne sont pas affichées pour certains clients

2. Django dispose de nombreux outils pour la gestion des utilisateurs, des permissions et des groupes. Vous pouvez donner à chaque utilisateur (chaque client) des permissions différentes et ces permissions déterminent ce qu'ils peuvent faire. L'accès à la base de données doit être géré par votre application web. Par exemple, le code détermine quelle information doit être affichée sur la page web (selon le client connecté) et ce code extrait l'information de la base de données. Selon l'échelle que vous visez, vous pouvez également spécifier la base de données doit être utilisé pour récupérer les informations.

un exemple élémentaire de la façon dont vous vous y prendriez.

Supposons que vous avez une application simple conçue pour résoudre un cas. Par exemple, vous avez créé une application pour gérer les réservations de chambres à votre bureau.

"convertir" cette application dans un service vous devez le configurer de manière à ce que la plupart des parties de l'application qui sont spécifiques à l'utilisateur soient paramétriques (elles peuvent être "templatisées"-faute de meilleur mot).

C'est comment le front-end serait converti. Vous pouvez créer des variables pour contenir le logo, le titre, le teaser, le schéma de couleur pour l'application; permettant à chaque utilisateur de personnaliser leur instance.

jusqu'à présent, votre application est capable de se personnaliser sur le devant. Elle utilise toujours la même base de données que celle qui a été conçue au cours de la première phase.

vient maintenant la question de montrer seulement les champs qui sont pertinents pour un utilisateur particulier. Ce serait paramétrer la base de données. Donc, vous pouvez ajouter une colonne qui identifie chaque ligne comme appartenant à un utilisateur particulier; puis créer des vues ou des procédures stockées qui filtrent les enregistrements basés sur l'utilisateur connecté.

maintenant l'application peut être "louée"; puisque vous pouvez personnaliser l'instance en fonction de l'utilisateur.

il devient alors juste plus grand d'ici-selon l'échelle, le type et la personnalisation prévue de votre application. Vous pourriez décider que votre application fonctionne mieux lorsque chaque utilisateur a son propre base de données dédiée à la place de la procédure stockée + vue combo.

vous pouvez décider que pour certains types d'utilisateurs (ou" paquets"), vous avez besoin d'une instance dédiée à votre application en cours d'exécution. Ainsi, pour les utilisateurs" premium "ou" ultra", vous souhaitez avoir leur propre système dédié.

si votre application nécessite beaucoup de stockage - vous pourriez décider de charger séparément pour le stockage.

au bout du compte, cela n'a rien à voir avec le langage utilisé. Son plus une architecture et un problème de conception.

j'ai un blog décrivant ma proposition sur la façon de faire une application web Saas multi locataires en utilisant Django. Multi-location signifie ici que lorsque les utilisateurs s'enregistrent, ils ont leur sous-domaine. Pour récapituler:

• tous les locataires partagent une base de données, mais chacun a son propre schéma. Imaginez que vous avez le site abc.com et quelqu'un a enregistré un xyz locataire afin qu'ils accèdent à leur page par xyz.abc.com, alors pour un locataire xyz vous avez un schéma séparé contenant toutes les tables, donc des données relatives à xyz locataire. Il y a d'autres façons, comme avoir une base de données et un schéma pour tous, ou même avoir des bases de données séparées. Mais les schémas approche est le meilleur compromis. django-locataires la documentation de la bibliothèque contient des informations plus détaillées si vous êtes intéressé
• Utiliser django-locataires bibliothèque pour abstraire le travail avec locataires. Lorsque quelqu'un accède à xyz.abc.com, vous devez savoir que xyz est locataire et que vous devez utiliser xyz schéma. django-locataires bibliothèque fait cela pour vous sur chaque demande, vous pouvez obtenir le locataire objet simplement en faisant current_tenant = request.tenant
• vous devez faire la différence entre les tables partagées et les tables propres aux locataires. Par exemple, le tableau avec la liste des commandes propres à un locataire. Chaque locataire pourrait avoir son propre base de données contenant toutes leurs commandes. Ce tableau doit être à l'intérieur de xyz schéma. En même temps, vous aurez quelques tables de Django, comme utilisateur. Les données peuvent être partagées, par exemple, pour interdire deux utilisateurs s'enregistrant avec le même email.
• Vous devez configurer votre DNS pour attraper une expression générique *.abc.com, pour laquelle vous pouvez ajouter un enregistrer dans votre CPanel avec *.abc.com les liens de l'IP de votre serveur