Comment by pestaa | Hacker News Reader

Comment by pestaa | Hacker News Reader

Parent Full thread

I'm always eager to hear whatever Armin has to say, but I feel so-so this time, probably because I didn't fully understand or his point was not clearly communicated.

The premise is that you can serialize request and response objects only after you made sure they are fully independent of the underlying protocol.

However, when the protocol is in fact underlying, you cannot fully get rid of its nature, and, for example, resources are still going to be requested by their URLs. The middleware he develops already takes care of the details like the protocol headers and encoding. I believe that even with the best efforts and intentions, HTTP will remain implied.

It is also not clear to me what something like Flask would gain from buffered and serializable objects. At first sight it is a performance penalty rather than a practical improvement, isn't it? I'd like to hear more.

Edit: I'd like to add that maybe Fireteam should have not chosen HTTP as a transfer protocol for games, where state is everywhere and HTTP is stateless. Although I don't feel qualified to suggest alternatives.

I have to say that I was equally puzzled by this post the first time I read it. Perhaps having some background information about what exactly he's working on might have helped.

On a second read, it looks like the meat of the post is about decoupling the implementation of your API from the underlying network protocol. Unless I'm missing something, that would be MVC.

Controllers are completely oblivious to the fact that HTTP is being used behind the scene. The routing mechanism takes care of parsing the request, deserializing the request body, instantiating the appropriate controller and invoking the correct action passing the deserialized objects as parameters. Once the controller's action has completed and returned its result, the View is responsible for serialising the response to HTML, JSON, XML or whatever serialisation format you use, and for setting the correct HTTP status code and headers.

So still puzzled, even after a second read.

Trying to over-abstract network communication is one of the classic mistakes in distributed system design.

Remember the old "RPC" idea from the 1980's? Despite a huge amount of effort to optimize remote procedure calls, nobody could ever get an RPC to be within orders of magnitude of a real procedure call in speed.

The RPC concept only became mainstream in the 2000's when people had given up on performance; SOAP and POX systems use inefficient XML and JSON serializations and are integrated into http stacks that were designed to use something else. These systems flourished in the 2000's because interoperability, not performance, was the driver.

Now, if you're in an AJAX, Flex or Silverlight environment, you've got the whole asynchronous communications issue -- you can't paper that over with an abstraction layer, you've got to build the whole application around the fact of async comm if you want to build something that really works.

Abstraction gone wrong almost always come down to wanting to abstract for the wrong reasons. RPC was all about pretending from the client side that accessing a remote resource was the same as calling a local method. This was and still is non-sense and a prime example of leaky abstraction.

My understanding of the OP's post is that he is talking about server-side issues rather than client-side though. Others have pointed out that he's talking about the design of a specific python library or framework that I'm not familiar with - I'll need to read up on this first.

We're not abstracting HTTP away, we're just looking at the whole thing differently. In a way our code is RESTful and considers HTTP a way to implement REST. XMLRPC and other things throw all of HTTP over board with the exception of the entity body which removes all the advantages and reasons to use HTTP.

Our stuff gives us an unified API and it's fully embracing HTTP.

Reply on news.ycombinator.com