cityofaustin / techstack

Project management for the City of Austin's new digital service delivery platform, Austin.gov.
11 stars 3 forks source link

Publisher Queue Architecture #4035

Open Niicck opened 4 years ago

Niicck commented 4 years ago

Architecture Ideas: We can create a dynamically updating publishing queuing app with all the information we want. I'd estimate a sprint and change to do any of the first 3 options.

Some Questions: Adding security is an extra 1/2 sprint to a sprint.

easherma commented 4 years ago

I think creating a Django app inside of Joplin would be a quick and easy route to success for MVP. Wouldn't any of those first three options would still need time and additional work to set up messaging between it and publisher and joplin? We’ll have handle sending the publish signal in joplin anyways, that can be a message that gets stored in the DB and then handled for how it gets added to a queue. Receiving additional messages in joplin then isn't much of a leap.

The publisher is going to need to message out for some kind of status (building, in progress, done) which we could set up an endpoint in joplin to receive.

Polling would be fine for MVP, as our builds take many minutes right now anyways so even if we polled every 30 seconds it would be fine.

Post-MVP, Wagtail now supports Django 3.0 which supports websockets natively so we could refine the endpoint further.

This is a pretty decent but simple example:

https://stackoverflow.com/questions/56913676/dynamic-updates-in-real-time-to-a-django-template

It uses Django REST Framework, which we already have. Or we could use graphene and have an endpoint there for page build status with some mutations for updating that status.

That would make handling security/authentication more at hand, already give us a database and api to write data into(and have a record of builds), and have the information already at it’s intended destination.

Any thoughts on that?