0

I'm writing the backend for a SaaS application in django. Need some guidance on the architecture. So the product will have 2 offerings: a general one where all users will share the same database and a premium one with a dedicated database. How I'm planning to translate this to django is the following:

  • Within the django project, there'll be one app for the general offering.
  • For every premium client, there'll be a separate app.
  • Each app has the same models.
  • Every app communicates with a separate database. Achieved this using: stackoverflow post and django documentation
  • I'll write views for all the APIs in the project's views.py, not inside any app and decide on the basis of a token which app's models to communicate to.

The problems I see right now with this architecture:

  • In all of the views, I'll have to write a lot of conditional statements once the number of premium clients increases.
  • Onboarding of new premium clients requires quite a bit of code change.
  • Code duplication in models.py of all the different apps. But it's almost similar to writing statements for creating tables in a new database every time a premium client signs up. Comments?

Please advise me on the architecture as a whole. I went through a lot of articles and stack overflow posts before going this way, but none were completely specific to django so I'm not 100% confident. Much thanks in advance.

Community
  • 1
  • 1
Chetan
  • 1,724
  • 2
  • 14
  • 18

1 Answers1

0

If the functionality of the free and premium offerings will be exactly the same you shouldn't need any code duplication. This is of course a big IF, because it's very conceivable that you'll add extra features to the premium offering.

If the functionality will be exactly the same then all you need to do is add any new premium databases to your settings.py and use a middleware to determine which database your models should communicate with (using the using attribute), and for the shared database add an owner column to every table that records who the owner of that row is so you can filter querysets appropriately.

voodoo-burger
  • 2,123
  • 3
  • 22
  • 29