[sibeliuss]

> Somehow I doubt it

I don't know. They seem to be satisfied customers, and were simply optimizing an already working pipeline in anticipation of saving money.

As a side note, I haven't seen a single "We tried GraphQL and it failed us" story on HN. Not that they don't exist, of course. It's just that there doesn't seem to be much debate about its promise.

[mirekrusin]

If you read between lines you'll see failures. This article is an example. Spawning 7500 servers to handle this traffic is a facepalm failure.

[yxhuvud]

To be fair, looking at what kind of optimizations they did to improve the situation, it looks like GQL is not to blame but rather a pretty big disconnect between their implementation practices and understanding about what is costly and what is not costly (ie lack of mechanical sympathy). People may get by without that writing client side javascript, but backend code is not as generous.

[mirekrusin]

Yes, their optimisation team did great job, including writing post about it. They had 5 months from zero to some solution deployed on prod. And they shaved numbers. Great work.

However number of servers required to serve this traffic has still very poor ratio. And if you read between lines – they maxed out their optimisation effort on it. They cache at multiple layers. To be more precise this statement that they haven't found any low hanging fruits for optimisation should raise some serious questions and their analysis from "first principles" should probably be more thorough.

[pdimitar]

Yep, they seem to have settled at about 2100 servers which is bonkers insane. Go or Rust will likely max at no more than 100. If not 20-30 even.

[FpUser]

>"As a side note, I haven't seen a single "We tried GraphQL and it failed us" story on HN"

Why would it "fail". It is just one of many possible protocols to query data. It is like arguing about using this computer language vs that computer language. Bar difference in performance they would all work.