Architecture of an app that uses models of another project

Using Django Getting Started
1

Hi folks!

I’m trying to figure out the best way to build a new django application that imports models of another project, paperless-ngx.

  • My project has its own models, views, UI, etc., served at the web server root.
  • I wish to reuse paperless-ngx’ features by importing functions and models paperless-ngx, create foreign keys to those from within my app, and call the methods of paperless-ngx’ models.
  • Code of paperless-ngx should be touched as little as possible.
  • In the end there should be 2 domains, 1 that serves my app at its root, 1 that serves paperless-ngx at its root, with both apps using the same database.

How would you structure this project? Just with regards to git repos, directory structure, and settings.py/urls.py. I have some ideas but I’d love to hear what you think first.

Thank you <3

2

Welcome @hut !

There are two separate and distinct issues here - first, the physical implementation of the Django code, and second, the deployment behind the web server.

Depending upon the size and complexity of your app, I’d approach this in one of two ways.

  1. Use paperless-ngx as the “base project”, and add your app as an installable app. You then create a second settings file that effectively uses the provided settings file, except the second version adds your app to INSTALLABLE_APPS, and changes the ROOT_URLCONF to reference your urls.

  2. Set up your project as a completely separate project, and add the paperless-ngx apps (and its related dependencies) as INSTALLABLE_APPS to your project. This gives you access to all the models, views, forms, etc from paperless-ngx. (And, as a separate project, that implies a completely separate directory structure, with the only requirement that the paperless-ngx project be added to your pythonpath.)

In both cases, the DATABASES settings would be the same.

I’m not seeing anything requiring any “mixing” of directory structures or git repos. (Remember, there’s no requirement that the settings file be located directly within the project structure. As long as it can be imported, the location is effectively irrelevant.)

For deployment, you can do this a couple different ways. If I were doing it, my first approach would be to run each of the projects with their separate settings files as separate instances of uwsgi. Then, I would use the nginx server_name directive to direct the appropriate requests to each instance. (In this case, it would be no different than any of our other servers that handle multiple projects.)

There might be some little “nit” that I’m not seeing here, but I can’t envision anything that can’t be worked around.

1 Like