[Fixed]-Django models across multiple projects/microservices. How to?

10šŸ‘

Django basic idea is to couple the entire app functionality together, but this does not hold in your case. Itā€™s a style and opinion question, here is what I did in a similar situation.

Split the app functionality into two project lairs:

mysite
   |
   | - db_access
   |         | --- app1
   |                 | ---- models.py
   |                 | ---- db_api.py
   |         | --- app2
   |                 | ---- models.py
   |                 | ---- db_api.py
   | - service
   |         | --- app1
   |                 | ---- urls.py
   |                 | ---- views.py
   |         | --- app2
   |                 | ---- urls.py
   |                 | ---- views.py

The db_access part has the models, and db_api.py has the queries, get objects etc, so you donā€™t query the models, but the db_api.

Instead of

item = app1.models.Items.objects.get(user=request.user)

Use

item = app1.db_api.get_first_item(user=request.user)

This style lets you share the db & models access together, while each service consumes what it needs, and then use it for API, website etc. If a service consumes some data in a way that other services donā€™t (and will not) use, then put this query in the service code, otherwise in the db_api.py.

This is more like a traditional laired application, but it works.

Another thing, the same project can use two git repositories, one for the db_access (which all services pull), and one for the specific service. So each django project is actually the db_access repo, and the service repo ā€“ wsgi doesnā€™t care, of course, if the project code comes from two repositories.

šŸ‘¤Aviah Laor

5šŸ‘

Two potential options:

Option 1 ā€“ Use a common codebase and deploy multiple instances of it (one for each microservice). You could follow 12factor Apps Methodology and just load a different set of environment variables for each deployed instance. http://12factor.net/

Option 2 ā€“ Split your django code up into self contained applications then have a project for each microservice that just includes these projects and a url config.

I can expand further if this is helpful?

šŸ‘¤xxx

4šŸ‘

If you want to use same models in different python apps (not modules, but apps, with different uwsgi-instances etc.), then I think that the much common and handy solution ā€“ provide interface for these models through some API:

  1. You can build REST interface in each of your projects, and then call appropriate API methods to get result.
  2. You can use Celery package to build internal API based on the AMQP transport. Then you need to configure your apps to listen some RabbitMQ queue which will be used as message storage for your projects communnication.

2šŸ‘

Django models is just a Python module, of course Django does a lot of ā€˜magicā€™ in other modules (i.e. forms, admin) using introspection, but the models itself could be used separately if desired.

So thereā€™s no problemā€¦ If you use different ā€œDjango projectsā€ for each project you named (on same machine or different), then just make your models as separate ā€œDjango appā€ and set each project to use it. If each project named by you is ā€œDjango appā€ (in this case on same machine obviously) then just import your models module in each ā€œprojectā€ and use it. Even if you donā€™t use Django, say your ā€œAPI projectā€ is based on Flask, you can still import Django models in Flask modules.

Behind the scene of Django models thereā€™s the database, which doesnā€™t care from where it is queried, and Django just provides a convenient way to use the DB via Python classes. So if the models from different apps or projects are set to use the same DB, then they will be ā€˜sharedā€™.

šŸ‘¤Nikita

Leave a comment