[usrbinbash]

This is the client side of things. And I think this is a great resource that everyone who writes clients for anything, should see.

But there is an additional piece of info everyone who writes clients needs to see: And that's what people like me, who implement backend services, may do if clients ignore such wisdom.

Because: I'm not gonna let bad clients break my service.

What that means in practice: Clients are given a choice: They can behave, or they can

    HTTP 429 Too Many Requests

[rewmie]

> This is the client side of things.

The article is about making requests, and strategies to implement when the request fails. By definition, these are clients. Was there any ambiguity?

> But there is an additional piece of info everyone who writes clients needs to see: And that's what people like me, who implement backend services, may do if clients ignore such wisdom.

I don't think this is the obscure detail you are making it out to be. A few of the most basic and popular retry strategies are designed explicitly with a) handling throttled responses by the servers, b) mitigate the risk of causing self-inflicted DDoS attacks. This article covers a few of those, such as the exponential backoff and jitters.

[usrbinbash]

> Was there any ambiguity?

Did I say there was?

> I don't think this is the obscure detail you are making it out to be

Where did I call this detail "obscure"?

My post is meant as a light-hearted, humorous note pointing out one of the many reasons why it is in general a good idea for clients to implement the principles outlined in the article.

[samwho]

Throttling, tarpitting, and circuit-breakers are something I'd love to visualise in future, too. Throttling on its own is such a massive topic!

[rewmie]

> Did I say there was?

Yes. You explicitly wrote in your comment "This is the client side of things", as if there was any ambiguity in where requests came from.

> Where did I call this detail "obscure"?

You explicitly wrote that "(...) there is an additional piece of info everyone who writes clients needs to see" on what people like you "who implement backend services, may do if clients ignore such wisdom", as if somehow this was obscure, arcane and secret knowledge that no team whatsoever working on backend services with client teams ever dared share with the outside world.

> (...) why it is in general a good idea for clients to implement the principles outlined in the article.

I don't think there is a single developer out there working on client/server projects that aren't aware of the need to handle request failures and be mindful of service level agreements, specially when dealing with retries.

Your post reads like addressing life guards to let them know that there is an additional piece of info everyone who works as a lifeguard needs to see: that the water is wet.