Stop Building Synchronous Web Containers

Seriously, stop it. It's surreally difficult to build a sane ansynchronous service on top of a synchronous API, but building a synchronous service on top of an asynchronous API is easy.

-
WSGI: container calls the application as a function, and uses the return - value for the response body. Asynchronous apps generally use a non-WSGI - base (see for example Bottle).
-
-
Rack: container calls the application as a method, and uses the return - value for the complete response. Asynchronous apps generally use a non-Rack - base (see this Github ticket).
-
-
Java Servlets: container calls the application as a method, passing a - callback-bearing object as a parameter. The container commits and closes - the response as soon as the application method returns. Asynchronous apps - can use a standard API that operates by re-invoking the servlet method as - needed.
-
-
What does .Net do?
-

ExpressJS: container calls the application as a function, passing a - callback-bearing object as a parameter. The application is responsible for - indicating that the response is complete.

Synchronous web containers are bad API design

-
Make the easy parts easy (this works)
-
-
Make the hard parts possible (OH SHIT)
-

Writing synchronous adapters for async APIs is easy

def adapter(request, response_callback):
-    synchronous_response = synchronous_entry_point(request)
-    return response_callback(synchronous_response)
-

Going the other way is more or less impossible, which is why websocket -support, HTML5 server-sent event support, and every other async tool for the -web has an awful server interface.

- - - -

- - -comments powered by Disqus -

- - - - - -