CODEWITHSUNDEEP
djangosubdomainmultiple-instancessingle-instancesites
architux
architux

Reputation: 657

What is the best structure for Django project with multiple sites based on the same backend logic?

I've began working on a new large project - many city-based webshops, each working on its own subdomain of the one domain, for example, citydomain.webshop.com. There whould be about 40 of these websites at start to run simultaneously.

Project's backend business logic and template styling is the same on every site. Some static files and database data would be both general across all sites and site-specific (logs, images, selling items, orders, etc.).

My question is how to implement the best possible architecture in such a way that a certain user visiting the same URLs on different subdomains would get that subdomain's specific data processed by the same backend logic.

I assume the following options of the possible architecture:

1) Django project instance: one instance for all sites OR many instances for each site?

The first way seems far more logical than the second one in terms of DRY principle. I believe that ideally there should be ONE project instance with many subfoolders with subdomains' names for each site's specific images, logs, etc.

2) Database: one db for all sites OR many databases for each site?

I tend to have ONE database too because of the same DRY principle. The great amount of data would be repeated in different site-specific databases, and also switching between them on-the-fly could be troublesome (database routers seems to be the tool here according to documentation).

Having only one database, should I probably use sites framework to store site-specific data in various tables (with foreign keys to Site model, as far as I understand)? How then should I change SITE_ID according to current subdomain? Should I use either: a) some custom middleware or b) some addon like django-subdomains, django-multisite, Airavata?

Or maybe there's no use to implement sites framework at all?

3) Settings: store settings in settings.py files (the main one and many site-specific ones) OR combine the main settings.py file with site-specific options stored in database only (maybe within Site table or another table that would extend it)?

4) Virtual hosts: one for the main domain only OR many virtual hosts for each site? The second option could be established with many small site-specific settings.py files with its own SITE_ID (inheriting from the one main settings.py) sticked with many site-specific WSGI files for each subdomain?

Please give me an advice of some best practices for that project described above. What should be the right decision on each of these "crossroad"-like options, what would you recommend?

Upvotes: 2

Views: 701

Answers (1)

architux
architux

Reputation: 657

OK, I'll answer my own question after a bunch of work.

According to my project needs I've decided to concentrate almost everything in one place not to be confused later with so many versions of the same thing. One project instance, one database, one settings package, one virtual host.

Subdomain-specific data is stored a) either within database (being linked to custom-written Domain model), if it's plain-text data b) or as files saved to some subdomain-specific directory tree within the project instance, if it's binary data (images for the most part).

Settings package consists of the basic settings file and three environment-specific files (development, staging, production) importing everything from this one basic file. You have to choose what file to use and rename it to settings.py.

Upvotes: 1

Related Questions