Question

Other posters have previously said in this forum that when your Django app starts getting big and unmanageable, you should split it up into several apps. I’m at that point now. What are the best practices for allowing communication between these apps?

One of my apps (let’s call it Processor) processes very large data sets. Once an hour it produces a small amount of new data for the other app. This other app (let’s call it Presenter) displays the data to users.

How should Processor hand new data to Presenter? Should it simply import parts of Presenter’s model, so it can create and save records in Presenter’s database? That seems like tight coupling to me. Or should it pass the data by calling a function in Presenter? Or put the data in some sort of data store that both Processor and Presenter know about?

How do you all usually solve this problem?

/Martin

Answer 1

I would definitely go for the importing Processor’s models in the Presenter app. That’s how, for instance, you can add extra user info: you have a UserPreferences model with a ForeignKeyField to django.contrib.auth.models.User. Your might have less of a bad feeling doing that that between your two apps because django.contrib is the “standard library”, but nevertheless, it is direct coupling.

If your applications are coupled, then your code should be coupled to reflect this. This follows the idea that explicit is better than implicit, right?

If, however, your’re designing something a tad more generic (i.e. you’re going to use multiple Presenter app instances for Processors of different kinds), you can store the specific models as a setting:

import processor_x.models
PRESENTER_PROCESSOR_MODELS = presenter_x.models

Then, in your Presenter models:

from django.conf import settings
class Presenter:
    processor = models.ForeignKey(settings.PRESENTER_PROCESSOR_MODELS)

Caveat: I have never attempted this, but I don’t recall a limitation on settings to be only strings, tuples or lists!