Right now, each variant of machinery needs to be known in both the front-end and the back-end. Let's refactor this so that it's purely on the server side.
This is good for Mozilla's instance, but also for 3rd party installs that might want to trigger other combinations.
There's two basic approaches:
- Have one API publicizing all machineries for a locale, and then have the front-end ask each machinery.
- Have one API for all machineries, and dispatch the request server side, with each response being marshalled into one global response.
The first approach would be relatively straight-forward, but still keeps a lot of individual requests between the frontend and the backend.
The latter approach requires parallel IO from the server to external machineries, and it should respond incrementally to not regress responsiveness of the current UX. We can use asyncio now, and we can talk to a Django StreamingHttpResponse. That requires a sync generator, though, https://code.djangoproject.com/ticket/31852. We should be able to fake that via https://docs.djangoproject.com/en/3.0/topics/async/#async-adapter-functions. The front end would read the response incrementally from fetch via https://developer.mozilla.org/en-US/docs/Web/API/Streams_API/Using_readable_streams#Consuming_a_fetch_as_a_stream.
This would require an update to Django 3.0, but no further at this point.