4 ms·
I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs. Right now, everyone who's supported both mobile and web APIs
by KirinDave 10y ago
I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs.
Right now, everyone who's supported both mobile and web APIs (or cared about bandwidth constraint) can tell you how frustrating it is that well factored restful (or rest-ish) APIs are often the casualty of accepting the realities in mobile client support. You end up increasingly collapsing requests into one Special Bigger Request because One Special Bigger Request almost always has better performance on bandwidth-constrained clients than the same performance elsewhere.
And this is especially frustrating because often times the client can't tell us exactly what they need in the initial request. The best we often can do is stash an etags header in the request and try and get very fancy there. We end up with smarter endpoints which require tons more programmer maintenance, and move us away from the world of autogenerated and automatically audited endpoints.
HTTP/2 w/ Push offers us a way to split the difference. While individual endpoints can be served very quickly, we can have our APIs recognize (via etags, probabilistic inference, previous negotiation, etc) that more data is about to be requested and push it immediately.
This means we can keep our well-factored, simple API designs that we developed 10 years ago without sacrificing performance to the bandwidth-constrained. It means that we can further lean on the abstraction Service Worker gives us in web clients to just naively poll in client code and trust in clientside caching to make this efficient (with the fallback being the same network call we would have always made).
It's why I'm absolutely infuriated with so many languages for balking at supporting HTTP/2 as part of their stack (more often than not, on the grounds that SSL + ALPN seems tedious to implement).
- renke1 10y agoI agree with everything you said. One thing though, I think "One Special Bigger Request" still makes sense in a lot of situation where you have some kind of "transaction" going on. I often encountered code that calls multiple HTTP endpoints and a failure in one of those requests would actually lead to inconsistent data in the backend. This code is pretty common because many developers assume that requests never fail.
- KirinDave 10y agoTransactional mutations have to have a commit phase. I agree.
- shanemhansen 10y agoI think that within a datacenter, a bunch of microservices make sense. When communicating with a customer, you want to craft just the data they need and minimize roundtrips. GraphQL seems to be a great candidate for bridging this gap. I recommend using graphql to allow clients can use to make "One Special Bigger Request" which then gets split into multiple requests on the backend.
- KirinDave 10y agoI see no reason why this isn't compatible with gql. But even then, gql is hard to architect right unless you fence off a rather minimal subset of it.
- derefr 10y agoThe thing about One Special Bigger Request is that it isn't cacheable. GraphQL is no exception: https://philsturgeon.uk/api/2017/01/26/graphql-vs-rest-caching/ https://philsturgeon.uk/api/2017/01/26/graphql-vs-rest-cachi... If you want network-level caching, you want multiple atomic resource requests. HTTP2 enables this.
- tootie 10y agoHATEOAS + Server Push would be beautiful.
- chucke 10y ago> I'd like to go further: HTTP/2 is the present not just for content serving, but could be for APIs. Very true. The talk around around server push has suffered a bit from tunnel-vision, only taking browser-media delivery into account, making it look like a browser feature only. HTTP2 + server push can actually make GraphQL less relevant, same way that there hasn't been talk around supporting websockets in it (it just doesn't look necessary anymore). But for all this to happen, server push needs to become cacheable. And I really hope that the cache digests rfc takes off and gets more implementations.