How to create SaaS application with Python and Django

Question

Can you advice me with some articles/applications that allows you create SaaS(Software as a Service) application with Python and Django.

For the moment the general topics I do not understand are:

1. Do you have one working application for all clients or one app per client
2. How do you manage database access, permissions or different DB for each client
3. Are there any tools that allows you to convert one app to SaaS

Answer 1

1. one project, this will make maintenance easier. I handle host resolution with middleware in django-ikari.
2. you don't. see #1

3. I use the following :

   • django-ikari : anchored (sub)domains
   • django-guardian : per object permissions
   • django-tastypie : easy RESTful api
   • django-userprofiles : better than django-registration
   • django-billing : plan based subscription controls
   • django-pricing : plan based subscription definition

4. While not necessary, the following will help in the long run:

   • django-hunger : private beta signups
   • django-waffle : feature flip
   • django-classy-tags : nice, easy and neat templatetag creation
   • django-merchant : abstracted payment gateway framework
   • django-mockups : fast testing with models
   • django-merlin : better multi-step forms (wizards)

5. Finally, nice to have

   • django-activity-stream

Answer 2

A very basic, elementary example of how you would go about it.

Suppose you have a simple app designed to solve a particular business case. For example, you created an app to handle room reservations at your office.

To "convert" this app into a service you have to configure it such that most of the user-specific parts of the application are parametric (they can be "templatized" - for lack of better word).

This is how the front end would be converted. You might create variables to hold the logo, headline, teaser, color scheme for the app; allowing each user to customize their instance.

So far, your app is able to customize itself on the front end. It is still using the same database that was designed in phase one.

Now comes the matter of showing only those fields that are relevant to a particular user. This would be parameterizing the database. So you might add a column that identifies each row as belonging to a particular user; then create views or stored procedures that filter records based on the logged in user.

Now the application is able to be "rented" out; since you are able to customize the instance based on the user.

It then just gets bigger from here - depending on the scale, type and intended customization of your application. You might decide that your application performs better when each user has their own dedicated database instead of the stored procedure + view combo.

You may decide that for some user types (or "packages"), you need a dedicated instance of your application running. So for "premium" or "ultra" users you want to have their own dedicated system running.

If your application requires lots of storage - you might decide to charge separately for storage.

The bottom line is it has nothing to do with the language used. Its more an architecture and design problem.