We were talk­ing at work about Server­less: What’s the right tool­ing for de­vel­op­ers build­ing that kind of ap­p? One of the busi­ness­peo­ple in the room said “Won’t de­vel­op­ers need s spe­cial UI con­struc­tion kit for Server­less apps?” The tech­ni­cal peo­ple all looked blank, be­cause REST. Brows­er code doesn’t care (nor does a new-fangled Re­act thingie, nor an iOS/An­droid ap­p) what’s hid­ing be­hind that HTTP POST. REST is more or less to­tal­ly dom­i­nant among app builders to­day. Is there any prospect of that chang­ing?

What we talk about when we talk about REST · HTTP CRUD. Wel­l, HTTPS ac­tu­al­ly these days, thank good­ness. GET and POST, maybe a lit­tle PUT if you’re dar­ing. Not much HATEOAS, to be hon­est. No deep think­ing about idem­po­tence, that I see any­how.

All of which is per­fect­ly OK, be­cause it work­s. So your serv­er doesn’t need to know whether it’s talk­ing to a groovy TheNewHot­ness.js Single-Page App or a C++ Unity-engine First-Person Shoot­er run­ning on a phone. And your SPA or FPS client doesn’t need to know whether it’s talk­ing to a baroque Ja­va EE mono­lith or a posse of funky micro-services. It’s on­ly the most suc­cess­ful large-scale in­te­gra­tion ar­chi­tec­tural style in the his­to­ry of ar­chi­tec­tures.

[I may be par­doned a bit of glowi­ness about this, hav­ing spent a decade or so shout­ing that objects-on-the-wire (CORBA/DCOM/etc) were a bad idea, then an­oth­er decade say­ing the same about SOAP, WSDL, and friend­s.]

Is REST run­ning out of gas? · I don’t think so, but the app ar­eas where you see non-RESTful de­ploy­ments are in­ter­est­ing. Now, I’m talk­ing main­stream busi­ness app­s, so the use of UDP by the real-time bits of games is a big deal, but nobody’s ex­pect­ing to see un­se­quenced data­grams re­plac­ing con­ven­tion­al web-site net­work­ing.

But what is in­ter­est­ing is stream­ing. I’m not talk­ing about video stream­ing; that’s done with HTTP, any­how. I mean, for ex­am­ple, Slack’s Real Time Mes­sag­ing API; I bet a lot of peo­ple read­ing this are in a few Slack chan­nel­s, and at the mo­men­t, that’s be­ing done with We­bSock­et­s.

Which as­ton­ished me when I found out. It’s like this: Con­nec­tions across the In­ter­net, par­tic­u­lar­ly when one end is a mo­bile de­vice, are flaky, evanes­cent things. They all have one thing in com­mon: Soon­er or lat­er, they break. Look at that Slack doc­u­men­ta­tion I linked to above; it cov­ers how to deal with dis­con­nec­tion­s. That’s sort of a pain for client au­thors, but ap­par­ent­ly not too aw­ful judg­ing by Slack’s suc­cess. Stil­l, a Google search for slack dis­con­nect is amus­ing.

What I can’t fig­ure out, though, is how they man­age the server-side; maybe the tech­nol­o­gy has ad­vanced, but I wouldn’t have the vaguest idea how to con­fig­ure a fleet to ter­mi­nate a few hun­dred thou­sand We­bSock­et con­nec­tion­s. A hun­dred thou­sand HTTP trans­ac­tion­s/sec­ond? No prob­le­mo, these days. But per­sis­tent con­nec­tion­s? Cool stuff; Let’s see if it catch­es on.

I won­dered aloud about this and Peter Coop­er point­ed me at The Road to 2 Mil­lion Web­sock­et Con­nec­tions in Phoenix, which has im­pres­sive num­ber­s. Mind you, they cheat­ed  —  they used Er­lang.

Stream­ing for vol­ume · There’s one sce­nario where I’ve be­come con­vinced that HTTP is stupid and waste­ful. That’s where you have a small num­ber of par­ties (like, for ex­am­ple, two) ex­chang­ing a huge num­ber of mes­sages. At some point, stream­ing has to win, right? Well yeah, but gosh, HTTP is still hard to let go of. There’s so much ma­chin­ery there for it: au­then­ti­ca­tion and en­cryp­tion and rout­ing and bench­mark­ing and trac­ing and caching, so much a part of the ecosys­tem that you most­ly don’t have to think about it.

Any­how, seems pret­ty like­ly that the next lit­tle bit of the fu­ture will stay REST-centric. One of the nice things about that is you can think about chang­ing out your server-side ar­chi­tec­tures, like for ex­am­ple go­ing server­less, with­out break­ing the world.


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.


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.



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 )


author · Dad · software · colophon · rights
picture of the day
July 09, 2016
· Technology (78 fragments)
· · Web (386 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.