Architecture: combine frontend and backend?

[stsievert]

Right now, Redis is used to communicate between the frontend and backend. The frontend handles serving queries, and the backend handles processing queries. Redis serves as the communication channel between these.

This architecture works, but might be over-engineering. This issue will focus on different the architecture of Salmon.

[stsievert]

Another idea would be to use asyncio.Queue to communicate between the frontend and backend (which would now be consolidated under one module/Docker container. It's challenging to share global state (like Queues) among different processes (which is database are required).

The backend algorithms require running on one process to avoid doing repeated work. I think serving queries should be done on multiple Gunicorn workers (/processes) because it's common practice and ensures a response web app. Those two requirements necessitate launching with a different number of workers.

But, that's only a requirement on Redis. Why not use Redis and run algorithms on in the same processes as the server? The algorithms would send any heavy computation to Dask, and asyncio would provide the required concurrency.

[stsievert]

https://github.com/stsievert/salmon/issues/33#issuecomment-621383398 is only a requirement on Redis. Why not use Redis and run algorithms on in the same Docker container? The algorithms would send any heavy computation to Dask, and the separate servers will provide the required concurrency. This would be a lot simpler: one Dockerfile, easier imports for testing, much simpler versioning, easier PyPI deployment.

The frontend and backend servers could be launched like so:

uvicorn salmon:backend --port 8400 --host 0.0.0.0
gunicorn -w 4 -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8421 salmon:frontend

And then they would communicate with localhost:8400 and localhost:8421.