I wonder if they feel like GraphQL was worth it, vs. normal API servers. Maybe they saved some dev time on the front end, but did that outweigh the dev time spent on building, optimizing, etc? Somehow I doubt it.
I’ve been using graphql for years. In my experience, it dramatically simplifies microservice API architecture vs “normal” API servers.
Graphql is super easy to understand, easy to deploy, easy to scale and easy to grow.
It’s not perfect - the lack of namespaces can be a pain, a few more standard types would be good, and mutations feel a bit under baked - but there’s much to love, and very little to dislike.
Downsides afaik are:
(1) No way to do queries, which return recursive JSON objects of arbitrary depth. (2) Not using standard JSON as a format for writing your query, instead unnecessarily making up a new querying lang, a design flaw basically. (3) More dependencies in frontend as well as backend. (4) More difficult to determin what exactly is going on in processing 1 query, ergo more difficult to fix performance problems.
Can’t say I agree.. (1) you can easily create a json data type to emit arbitrary json in your response if that floats your boat (2) graphql queries can be far more expressive than straight json (3) graphql is just a REST call that takes a string and some optional JSON and returns JSON, no need for client side libraries unless you have complex use cases that are enabled by Graphql, (4) this has not been my experience, queries are run by the backend services, not by graphql itself, so the complexity of an individual backend query does not change.
OK, it's true that you can't do recursive queries to arbitrary depth with standard GraphQL queries, but I think most people who are familiar with GraphQL would consider that a feature: the query and the returned object are the same shape, and this correlation has useful properties that I've exploited in the past.
Nevertheless, there are ways to include arbitrary JSON in GraphQL responses and since the JSON really is arbitrary, you can include any JSON you want, to any arbitrary depth, and the field parameters that drive the JSON query can themselves also be arbitrarily complex.
I'd say that's also a feature of GraphQL: easy things are easy and hard things are possible. But still, if you have a use case that requires this functionality then GraphQL might not be for you, and that's OK. Nobody's forcing you to use it.
I mean, GraphQL is also poor at serving binary data. You can just use a different endpoint for it. It's not an all or nothing thing.
I think it would depend mostly on the diversity of combinations of data the frontend needs. Their GraphQL implementation is essentially automating the process of frontend teams asking the backend for new endpoints or configurations of existing endpoints to deliver new combinations of data for use by frontend clients. It’s pretty easy to see that certain for frontend requirements the backend GraphQL will be worth it, and for other frontend requirements the backend work would not be worth it. In this case I’m relatively confident that they’re coming out ahead.
I assume that to prevent DoS attacks, the backend would need to know the list of allowed queries. This change would be easier than changing a rest api, for example.
I would place a bet along with you on that one.
The question the graphql folk need to think about is who's paying for the value add of large one hit requests. cycles add up! There's a price to pay for having your api also have to parse and understand a request beyond just fetching the result.
I'd like to bet against you two. ;)
I think GraphQL + a REST (JSON RPC) interface will be an optimal balance between developer experience, performance and security. I'm the founder of WunderGraph and we're doing exactly that: https://wundergraph.com/docs/overview/features/json_rpc
I strongly believe developers should spend extra labor to ensure users and runtimes don’t waste cycles. I also believe labor or toil that repeats and can be automated, should. This marries both those ideas.
Finally, while thankfully you don’t say “we take security seriously” on your home page (buzzy but in practice usually a security red flag), your docs and baked-in approach show you genuinely do.
You’ll still very likely end up with dozens of http REST calls that could be one GraphQL query, hence one http call.
Bias alert (I’m the founder), but I believe you should have a look at GraphQL edge caching: https://graphcdn.io
I wonder why we haven't seen yet some more optimisation for JS. The only thing I'm aware of is the Google Closure Compiler. With everyone using TypeScript, there must be a way to use all that type information to make JS run more efficiently, or compile parts of your TypeScript code.
I adore Elixir and have made a good career around it. I'll love it until my grave.
But with that many servers I can't help but wonder if Rust wouldn't be a better choice. I don't think they'll even need 100 which, as OP pointed out, will drastically reduce their operational complexity.
Furthermore, the strong static typing would have avoided the megamorphic functions right from the start.
Yeah I agree with rust, I have some simple database fetching servers that run crypto functions as well (I.e. login) and for simpler operations they can quickly get to 100K+ requests per second on a single host
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.
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.
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.
>"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.
Graphql is super easy to understand, easy to deploy, easy to scale and easy to grow.
It’s not perfect - the lack of namespaces can be a pain, a few more standard types would be good, and mutations feel a bit under baked - but there’s much to love, and very little to dislike.