0

I am trying to decide how to implement this architecture. I have a base Django package, let's call it BaseApp. I have been developing this for distribution as a tool for others to use. BaseApp defines some view behavior and some base models, mostly. A developer can install BaseApp, and then make another app, let's call it NeatThing, that only has to define a few models and templates, and BaseApp does the rest, and for very little effort they now have a mini-application that Does Their Neat Thing. Repeat x 100, and we have 100 different developers doing 100 different Neat Things. And they all work just peachy as separate servers in separate environments, etc.

Now I want to take that and provide 1 version of BaseApp, and 1 database of users, and all 100 different Neato-Whiz-Bang applications, and serve them together on one domain, so users all come to the same place.

How do I do that so that:

  1. 1 URL points to one of the 100 different applications (programmatically in a way I configure)
  2. ensure the 100 different applications are isolated from each other (can't interact with each other at all)
  3. give each application (limited) access to the User database so that users can be associated with the models in their application (I am aware of Django multi-database support - but how can I secure one user database while giving each application access?)

I am asking this as a high-level implementation approach standpoint. I.e. which direction do I go from here?

andy
  • 1,399
  • 3
  • 12
  • 32

1 Answers1

1

What you're describing sounds a lot like what postgresql tries to accomplish with schemas. See django-tenant-schemas for an excellent implement implementation of this approach in django. Disclaimer: I'm a contributor to that project.

Stephen Fuhry
  • 12,624
  • 6
  • 56
  • 55
  • 1
    No problem with promoting projects you contribute to :) Does that lock me in to Postgresql? Also, why a "schema" vs separate databases? What is the advantage there? Better for foreign keys? – andy Sep 19 '13 at 20:51
  • also, regarding the tenant identification via hostname...would that work if each tenant has a subdomain, tenant1.mysite.com, tenant2.mysite.com, etc...but I serve a page at mysite.com/thing that hands off to tenant1.mysite.com/thing or tenant2.mysite.com/thing (while maintaing the url of mysite.com/thing)? – andy Sep 19 '13 at 20:56
  • The point of a database is to separate applications, the point of schemas is to separate tenants within an application. Yes, schemas would certainly lock you into postgres, but that's not necessarily a bad thing because postgres is extremely flexible. "Unlike databases, schemas are not rigidly separated: a user can access objects in any of the schemas in the database he is connected to, if he has privileges to do so." (from the docs) – Stephen Fuhry Sep 20 '13 at 18:06
  • As for the hostname, I believe that can be accomplished easily by simply using your own middleware instead of the middleware django-tenant-schemas ships with. Basically just copy this file into your repository, and change it so it uses the part of the url you want to use to determine which schema to use: https://github.com/bcarneiro/django-tenant-schemas/blob/master/tenant_schemas/middleware.py – Stephen Fuhry Sep 20 '13 at 18:09
  • One other problem with trying to accomplish what you want with multiple databases in postgres: you'll probably run into memory issues. Having many schemas in a database, however, will not have the same sort of negative effect. Also, you can't join across databases in postgres like you can in MySQL. See also: http://stackoverflow.com/questions/1152405/postgresql-is-better-using-multiple-databases-with-1-schema-each-or-1-database – Stephen Fuhry Sep 20 '13 at 18:11
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/37752/discussion-between-stephen-j-fuhry-and-andy) – Stephen Fuhry Sep 20 '13 at 19:21