4 ms·

Is the author somehow implicitly assuming that APIs are only to be used between microservices in the same data center or something? As far as I can see, the ar

Is the author somehow implicitly assuming that APIs are only to be used between microservices in the same data center or something? As far as I can see, the argument is "http2 removes handshake overhead and therefore you don't need to combine multiple things in a single response anymore". If my request takes a second to go around the world and back, how does http2 help me? It's very weird to me to read an article about API design, written in an expert tone, that does not address this.

psturgeon 6y ago
Hi, I am not assuming all microservices are in the same data center. Your reply assumes that API requests need to be made in sequence. If you need 3 resources, and you make 3 requests, you are not waiting for 1 then 2 then 3. 1 and 2 and 3 are all coming back along the multiplexed connection and none are blocking the other. That is generally what a lot of compound documents are doing, but sure the article also talks about when you need to know some information from 1 before you can call 2 or 3. - Server Push - since axed from some browsers, but the idea there is to proactively push the resource to you before you request it, because you know people often request Bar after requesting Foo. That means its not 1s it could be 100ms or less. The GraphQL community took this idea and created @defer. - If people ALWAYS need to request 1 and 2 and 3, that API sounds like it was overly normalized and not too well planned. Maybe its more of a "Data Store" than an API. It also talks about how by making endpoints smaller and more targeted, the cachability of one resource does not impact another, so you dont need to wait 1s for each requests, you just skip a lot of the requests. This article covers a lot of the same points. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...
83457 6y ago
The author specifically talks about browser support so I guess not. Given they are talking from the context of a large modern company (however you want to put that) I doubt they have to worry about users communicating with a server on the other side of the world.
- psturgeon 6y ago
  Which modern company am I writing from? WeWork? Mate that place was a global shitshow. Funny backstory if you're interested. https://phil.tech/2020/prioritizing-api-ecosystem-maturity/ https://phil.tech/2020/prioritizing-api-ecosystem-maturity/ No my article was not ignoring the concept of latency. Let fastly try and make the same points better. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- skrebbel 6y ago
  As far as I can tell, eg by the extremely slow speed of the Stripe dashboard from Europe, even the most "modern" companies struggle to get their data close enough to the users that network latency no longer matters. It's a lovely ideal but I know few companies that have achieved it. Sure, edge computing is a thing but if all the edge workers still need to go to some read replica database at least half a continent away, then in the end the 1+N requests the author suggests aren't going to get you very far.
quickthrower2 6y ago
Thanks I was going to make the same comment but felt a bit of imposter syndrome as someone who has picked up http and networking as I’ve gone along. But latency is always on my mind! Articles like this talk about a world I don’t understand anyway. It’s like the rest/hateois etc. stuff. I just make an MVC action that does what I need in a way that makes sense and call it from the browser. If shit is slow, I profile it. No highfalutin design philosophy!
- psturgeon 6y ago
  RPC thinking is one way of doing things, but not making a call is quicker than making a call. Took me a while to figure that one out too. If this article hasn't helped, see if fastly can make some of these points better. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...
GlennS 6y ago
In addition, database accesses aren't free either. Both in terms of latency (to be fair, probably pretty small in comparison), and in terms of knowing that all the data you fetched is consistent (because you fetched it in the same transaction).
slver 6y ago
There's a long list of API problems not addressed by HTTP/2, because HTTP/2 set out to make sites faster, it didn't set out to make APIs more "RESTful". Most advice I've heard from REST aficionados tends to be terrible for simplicity, correctness and performance. All in favor of an abstract set of goals, most of which never materialize. This is no exception.
- psturgeon 6y ago
  As a consultant I meet a lot of people who think the goals of REST are pointless and have created an absolute shitshow of poor API design, reinventing loads of wheels and getting to a point they had to get me to come in. Usually explaining the background for why those goals are not pointless is the first step to unfucking their API ecosystem. https://apisyouwonthate.com/blog/rest-and-hypermedia-in-2019 https://apisyouwonthate.com/blog/rest-and-hypermedia-in-2019 That's a post which aims to explain the tangible benefits of each step, but I've got plenty more articles explaining when REST is overkill and simple RPC would be a better fit.

psturgeon 6y ago

Hi, I am not assuming all microservices are in the same data center. Your reply assumes that API requests need to be made in sequence. If you need 3 resources, and you make 3 requests, you are not waiting for 1 then 2 then 3. 1 and 2 and 3 are all coming back along the multiplexed connection and none are blocking the other. That is generally what a lot of compound documents are doing, but sure the article also talks about when you need to know some information from 1 before you can call 2 or 3. - Server Push - since axed from some browsers, but the idea there is to proactively push the resource to you before you request it, because you know people often request Bar after requesting Foo. That means its not 1s it could be 100ms or less. The GraphQL community took this idea and created @defer. - If people ALWAYS need to request 1 and 2 and 3, that API sounds like it was overly normalized and not too well planned. Maybe its more of a "Data Store" than an API. It also talks about how by making endpoints smaller and more targeted, the cachability of one resource does not impact another, so you dont need to wait 1s for each requests, you just skip a lot of the requests. This article covers a lot of the same points. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...

83457 6y ago

The author specifically talks about browser support so I guess not. Given they are talking from the context of a large modern company (however you want to put that) I doubt they have to worry about users communicating with a server on the other side of the world.

psturgeon 6y ago
Which modern company am I writing from? WeWork? Mate that place was a global shitshow. Funny backstory if you're interested. https://phil.tech/2020/prioritizing-api-ecosystem-maturity/ https://phil.tech/2020/prioritizing-api-ecosystem-maturity/ No my article was not ignoring the concept of latency. Let fastly try and make the same points better. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
skrebbel 6y ago
As far as I can tell, eg by the extremely slow speed of the Stripe dashboard from Europe, even the most "modern" companies struggle to get their data close enough to the users that network latency no longer matters. It's a lovely ideal but I know few companies that have achieved it. Sure, edge computing is a thing but if all the edge workers still need to go to some read replica database at least half a continent away, then in the end the 1+N requests the author suggests aren't going to get you very far.

quickthrower2 6y ago

Thanks I was going to make the same comment but felt a bit of imposter syndrome as someone who has picked up http and networking as I’ve gone along. But latency is always on my mind! Articles like this talk about a world I don’t understand anyway. It’s like the rest/hateois etc. stuff. I just make an MVC action that does what I need in a way that makes sense and call it from the browser. If shit is slow, I profile it. No highfalutin design philosophy!

psturgeon 6y ago
RPC thinking is one way of doing things, but not making a call is quicker than making a call. Took me a while to figure that one out too. If this article hasn't helped, see if fastly can make some of these points better. https://www.fastly.com/blog/optimise-api-cache-improved-performance https://www.fastly.com/blog/optimise-api-cache-improved-perf...

GlennS 6y ago

In addition, database accesses aren't free either. Both in terms of latency (to be fair, probably pretty small in comparison), and in terms of knowing that all the data you fetched is consistent (because you fetched it in the same transaction).

slver 6y ago

There's a long list of API problems not addressed by HTTP/2, because HTTP/2 set out to make sites faster, it didn't set out to make APIs more "RESTful". Most advice I've heard from REST aficionados tends to be terrible for simplicity, correctness and performance. All in favor of an abstract set of goals, most of which never materialize. This is no exception.

psturgeon 6y ago
As a consultant I meet a lot of people who think the goals of REST are pointless and have created an absolute shitshow of poor API design, reinventing loads of wheels and getting to a point they had to get me to come in. Usually explaining the background for why those goals are not pointless is the first step to unfucking their API ecosystem. https://apisyouwonthate.com/blog/rest-and-hypermedia-in-2019 https://apisyouwonthate.com/blog/rest-and-hypermedia-in-2019 That's a post which aims to explain the tangible benefits of each step, but I've got plenty more articles explaining when REST is overkill and simple RPC would be a better fit.