We were talking at work about Serverless: What’s the right tooling for developers building that kind of app? One of the businesspeople in the room said “Won’t developers need s special UI construction kit for Serverless apps?” The technical people all looked blank, because REST. Browser code doesn’t care (nor does a new-fangled React thingie, nor an iOS/Android app) what’s hiding behind that HTTP POST. REST is more or less totally dominant among app builders today. Is there any prospect of that changing?

What we talk about when we talk about REST · HTTP CRUD. Well, HTTPS actually these days, thank goodness. GET and POST, maybe a little PUT if you’re daring. Not much HATEOAS, to be honest. No deep thinking about idempotence, that I see anyhow.

All of which is perfectly OK, because it works. So your server doesn’t need to know whether it’s talking to a groovy TheNewHotness.js Single-Page App or a C++ Unity-engine First-Person Shooter running on a phone. And your SPA or FPS client doesn’t need to know whether it’s talking to a baroque Java EE monolith or a posse of funky micro-services. It’s only the most successful large-scale integration architectural style in the history of architectures.

[I may be pardoned a bit of glowiness about this, having spent a decade or so shouting that objects-on-the-wire (CORBA/DCOM/etc) were a bad idea, then another decade saying the same about SOAP, WSDL, and friends.]

Is REST running out of gas? · I don’t think so, but the app areas where you see non-RESTful deployments are interesting. Now, I’m talking mainstream business apps, so the use of UDP by the real-time bits of games is a big deal, but nobody’s expecting to see unsequenced datagrams replacing conventional web-site networking.

But what is interesting is streaming. I’m not talking about video streaming; that’s done with HTTP, anyhow. I mean, for example, Slack’s Real Time Messaging API; I bet a lot of people reading this are in a few Slack channels, and at the moment, that’s being done with WebSockets.

Which astonished me when I found out. It’s like this: Connections across the Internet, particularly when one end is a mobile device, are flaky, evanescent things. They all have one thing in common: Sooner or later, they break. Look at that Slack documentation I linked to above; it covers how to deal with disconnections. That’s sort of a pain for client authors, but apparently not too awful judging by Slack’s success. Still, a Google search for slack disconnect is amusing.

What I can’t figure out, though, is how they manage the server-side; maybe the technology has advanced, but I wouldn’t have the vaguest idea how to configure a fleet to terminate a few hundred thousand WebSocket connections. A hundred thousand HTTP transactions/second? No problemo, these days. But persistent connections? Cool stuff; Let’s see if it catches on.

I wondered aloud about this and Peter Cooper pointed me at The Road to 2 Million Websocket Connections in Phoenix, which has impressive numbers. Mind you, they cheated — they used Erlang.

Streaming for volume · There’s one scenario where I’ve become convinced that HTTP is stupid and wasteful. That’s where you have a small number of parties (like, for example, two) exchanging a huge number of messages. At some point, streaming has to win, right? Well yeah, but gosh, HTTP is still hard to let go of. There’s so much machinery there for it: authentication and encryption and routing and benchmarking and tracing and caching, so much a part of the ecosystem that you mostly don’t have to think about it.

Anyhow, seems pretty likely that the next little bit of the future will stay REST-centric. One of the nice things about that is you can think about changing out your server-side architectures, like for example going serverless, without breaking the world.



Contributions

Comment feed for ongoing:Comments feed

From: John Cowan (Jul 10 2016, at 19:28)

The natural candidate for exactly two parties exchanging huge numbers of streaming messages, complete with the bells, whistles, and gongs you mention, is of course ssh. Just do JSON streaming from either or both ends.

[link]

From: Gavin B. (Jul 11 2016, at 00:45)

Hi Tim

> Erlang

I don't know when you last road-tested Erlang. It got a whole lot more manageable and elegant since Elixir came along to run on top of it. Pheenix is written in Elixir.

http://elixir-lang.org/

[link]

From: Dov (Jul 11 2016, at 11:12)

Alan Kay ( http://c2.com/cgi/wiki?AlanKayOnMessaging ):

"The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."

(via Joe Armstrong's http://joearms.github.io/2016/01/28/A-Badass-Way-To-Connect-Programs-Together.html )

[link]

author · Dad · software · colophon · rights
picture of the day
July 09, 2016
· Technology (81 fragments)
· · Web (388 more)

By .

I am an employee
of Amazon.com, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.