Question

We work on a Django app for researchers that manages research data. Upstream of the app itself there are bas scripts that move data around until the app can reach it. (Different deployments of the app use different kinds of upstream scripts).

Now, those scripts produce status information like "Instrument X is down" which users would want to know about. In fact, we’d like to have a status box on the front page showing several of these statuses (so on a good day, you see a row of green lights).

I’m just not sure what the "right" approach would be:

1. Scripts write an HTML file which the Django app includes with an iframe
2. Scripts write to some other file, which the Django app parses and renders
3. Scripts call some web address (eg, example.com/app/status?source=instrumentx&status=down)

Possible downsides, respectively:

1. HTML logic gets spread into scripts. Also writing HTML might be hard from a script.
2. Having to define and maintain this interface
3. As for 2, also potential security issues.

Basically the key issue here is that although the app itself is fairly well defined, it is used in a few different disciplines, and therefore the potential range of "status" information is quite broad and not really explored yet. Hence, well-defined interfaces will likely be inadequate.

Answer 1

I might not be totally right here but I would maybe look at 3 as a probable solution. If the app handles a lot of the data via models declared in Django, django-piston may be a good fit. It handles authentication fairly well out of the box so it might resolve some of your security concerns.

If you are looking at solution 2, and maybe have the scripts write to a well-structured table format of some sorts, there’s Tablib.

I would probably implement some sort of messaging framework like RabbitMQ, and have the app function as a ‘receiver’ where the scripts will be sending their update as messages.