Our existing Django project with a couple of apps has new API requirement.
I’m thinking of the possibility to deploy the new restful API in a separate wsgi server so the API service will be independent from the orignal Django project.
I can see two options:
- Create new API project which will inherit models and auth. This allows semi-independent update and deployment on production.
- Or just create new app in the same project, but use another wsgi server with separate settings.
While I’m writing this down I’m already having other insights (magic of writing thoughts), but the objective is to have API updated and deployed without penalize the availability of the existing apps.
There is a third option here as a variation of #2:
- Create the new app in the same project, using the same settings file, run in two different uwsgi instances, and use your web server / proxy server (e.g. nginx or haproxy) to route the urls to the two different uwsgi instances.
If there are settings that need to be different between the two, you could make those entries environment variables and define them in the files that runs each.
(This is effectively what I do with our Channels projects. The Django portion is run by uwsgi, and the Channels consumers are run by Daphne. It’s one consolidated code base and one settings file. The difference is that uwsgi uses the wsgi.py file while Daphne uses asgi.py.)
Thanks @KenWhitesell for your confirmation. Actually I’m have done the #3 option in a multi-tenant configuration.
This put all in the same working git directory which feed an automatic deployment pipline, so I have to figure out now how to automate the API deployment without touching the rest of the project in production.