RFC: Multi-application serve
See original GitHub issueBackground
Running multiple applications has been possible in Sanic for a long time. It does, however, take a pretty decent understanding of the operation of the Sanic server to do it properly. Things to consider include:
- loop management
- listener execution
- startup time optimizations
- multi-worker and auto-reload multiprocessing
- cross-platform support issues (looking at you Windows)
Over the course of the last six months in particular, I have seen a noticeable rise in the number of support queries where people are trying to do this. Whether it is to have a HTTP >> HTTPS proxy, web server plus chatbot, or serve multiple routes on different host/port configurations, the point is that there is a definite rise in the number of people looking to run multiple Sanic applications side-by-side.
With the efforts we have taken to make sure that multiple applications can co-exist, it seems only natural that we provide a first-class API for running them.
Proposed solution
We create a new high-level API that can easily handle this.
First, we create a method with an identical signature to app.run
. Its job is to do everything that app.run
would do, cache the server_settings
for later usage, and stop at the point where it starts the loop.
app1 = Sanic("ApplicationOne")
app2 = Sanic("ApplicationTwo")
app1.prepare(port=7777)
app2.prepare(unix="/path/to/sock")
Second, there is a single class method that runs the loop and executes the server(s).
Sanic.serve()
The first application defined in the application registry becomes the “primary.” That application is run normally as would otherwise happen with app.run
. Any other applications in the registry that have been “prepared” will be setup using create_server
such that all of their lifecycle events are properly run.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:6 (6 by maintainers)
Top GitHub Comments
@Tronic
I am hoping to get #2347 finalized and merged in the next week or so. There are enough structural changes to how applications are started that it would be worth it to get this in before progressing too much further with HTTP/3. It would be great if we could get the initial HTTP/3 support out in March.