ASGI and WSGI

AirHockey was finally playable on our local machines. But before celebrating, we needed to put it on the web and confirm the networking actually held up between two real players on two real connections.

That is where I ran into WSGI and ASGI.

Whenever deploying a normal Python web app, WSGI, the Web Server Gateway Interface, is probably the go-to. It is the old, dependable standard: a request comes in, your app does its thing, a response goes out, done. Clean and synchronous. The problem is that a game does not behave like a form submission. Players need a live, two-way pipe that stays open the whole match, and WSGI has no idea what a WebSocket even is.

ASGI, the Asynchronous Server Gateway Interface, on the other hand, has the same idea but is built for the async world. Long-lived connections, WebSockets, and many things happening at once without blocking each other. Exactly what a real-time game needs.

So when deploying a WebSocket app, instead of a plain WSGI server, you run an ASGI server (we used Uvicorn), hand it your app, and it keeps those socket connections alive so two different laptops can shove a puck at each other in real time.

It sounds obvious written down like this. It was a lot less obvious at 2am when nothing would connect.