[FpUser]

>"We provision approximately 7,500 instances for 1 million requests per second."

Looking at this numbers makes me think that a single instance of properly written server running on a single dedicated piece of hardware can handle this without breaking a sweat. My servers for example handle thousands of requests per second. It looks to me like one giant waste of human and hardware resources. Not very "green" approach I would say.

[lbriner]

The benefit you are getting from GraphQL is massive flexibility of the query in return for probably sub-par performance.

The fact that you can get X 100K requests/per second best-case is not really the point. The point is if I don't want to write hand-cranked code for every kind of possible query, I take a performance hit as a result.

Not sure how easy it would be for them to identify poorly performing queries and split them out into their own optimised code.

[FpUser]

>"The point is if I don't want to write hand-cranked code for every kind of possible query, I take a performance hit as a result."

This is how we end up with the architectures consuming orders of magnitude more computing resources and giant management overhead. Just because someone wants to be spared from a bit of thinking.

I can see how GraphQL would work for orgs with the massive scale like FB/Google/Insert your favorite. For the most of rest of the world it is nothing but unneeded overhead on resource both human and computing.

And of course cloudy people like Amazon would love you to use all this tech. The more you slow down your application the more resources you will be leasing from them so they get more money

[quonn]

The default implementation of GraphQL has a lot of overhead in query parsing and validation alone. You can try this yourself with complex queries and simulating some load.

But it‘s an issue that can be solved.

[FpUser]

">You can try this yourself with complex queries and simulating some load."

I do not need to try it. I know what it takes to parse/validate this kind of queries and then manage to get and assemble the results from numerous sources.

>"But it‘s an issue that can be solved."

No. This issue will not be solved as in general it is a problem of mapping one storage / functionality format to end client format. It can be easily solved for particular situations by writing custom servers (this is for example one of the things I do) but doing it generically introduces overhead / costs that are very unhealthy for a normal businesses.

And it is of course bad as it wastes energy.