In the past decade, we have seen a defined separation between the backend and the frontend with backend servers being used exclusively as API backends for a static frontend hosted on CDNs or a separate server like NextJs, Nuxt etc.
In a multi-tenant API backend, the server is hosted at a single endpoint and the tenant is mostly identified via a header or path-based routing. However, Django’s default sites framework assumes that the application will always serve multiple domains.
It would be great if we could have an AbstractSite model with a swappable Site model (like the user ), so that we could target the same API / functions while implementation details (like tenant lookup and additional fields) differ.
What of the API do you want to reuse? It looks like
get_current_site() also wouldn’t work for you, as it’s host-based.
Not really, the biggest issue I have is that the
domain field is unique. This limits what I can do with the Site model.
Something like ,
name = CharField()
tenant_key = CharField(null=True) # Header / path Key
domain = Charfield() # Non-unique | override to be unique if needed (also maintains compatibility)
LOOKUP_TYPE= "HEADER" # or PATH / DOMAIN
SITE_HEADER = None
## Get Header if LOOKUP_TYPE is HEADER
## Get the first URL subpath if LOOKUP_TYPE is PATH
# compare request URL against domain + LOOKUP_TYPE if not DOMAIN
abstract = True
We have multiple projects like django-tenants, django-pgschemas that reimplement the same logic with custom tables.
Having a swappable abstract model with a default lookup logic allows us to extend and manage each tenant and even add additional config.
For my case, I’ve created a separate SiteConfig model with a OneToOneField to the Site model. A custom middleware does the lookup and caching.
I’d like to see if we can extend the scope of the Site model to ensure the other common types of multitenancy are also supported.
That didn’t really answer my question. What of the sites API do you want? ISTM that after replacing the model and the get-current logic, there’s not much of it left to use, except these fairly small usages in other apps: The “sites” framework | Django documentation | Django . Writing your own “tenant” app could be the easiest way forward.