4 ms·

When GraphQL comes up there is always a lot of talk about the frontend (justifiably), but I never hear anything about what the story for the backend will be. A

by platz 6y ago

When GraphQL comes up there is always a lot of talk about the frontend (justifiably), but I never hear anything about what the story for the backend will be. Are there any unique challenges, assumptions, tradeoffs? The backend seems like a black hole of information in the GraphQL content that gets pushed to news aggregators.

filleokus 6y ago
I agree! One thing to consider is that it depends a lot on the way you decide to use it. On one "extreme", you only have predefined queries, meaning it could almost be implemented the same way you implement REST API (however you decide to that). On the other extreme of the spectrum, you allow the client to query the data with much freedom. This means that you have more of a generic resolver which maps GraphQL queries into an ORM or something else that generates your DB queries. In this mode, you have challenges regarding speed and optimisations. At a previous assignment we for example hand crafted the resolution of some especially nasty queries to increase performance, and left most for some ORM to figure out. We kept the database index structure up to date to match queries we saw from the frontend using metrics tools. Another thing is security. If you use this model, you are basically allowing the client to query around your graph of data in whatever way they want. This means you need to have some way to answer the question "Should User 37 be able to read field X on Object Y with ID 42", and implement that in your resolver. This is quite tricky, compared to REST or static graph QL queries where you just decide which objects / fields should be returned. (There is also some interesting DoS attack scenarios when going this route, where a malicious query can just explode in complexity, so you'll have to make sure to solve that some way as well...)
zomglings 6y ago
This is an astute question. I have only ever built a non-toy GraphQL server in 2016, for evaluation purposes. Never used in production. Tooling back then was probably much more primitive than it is today, so apply that discount to the subsequent statements. Writing GraphQL resolvers for the API that we were building was painful and required a solid understanding of our data model and what the database was capable of (we were using MongoDB). We were much happier at the time to stick to tried and true REST API tools and frameworks than to jump on the GraphQL bandwagon. All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server. This complexity seems irreducible to me, and I am highly skeptical of anyone claiming that they can make this complexity vanish. Have never so much as been tempted to use GraphQL since then. Unfortunately, this probably also marks my entry into dinosaur-hood.
- TheCoelacanth 6y ago
  > All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server That itself is useful. It is much easier to manage complexity on a server that you control in the same datacenter as your DB in a language of your choice than it is in JS with limited bandwidth.
  - zomglings 6y ago
    The easiest way for us to manage this complexity was to add new, simple, RPC endpoints to our vanilla API. It certainly wasn't worth adding GraphQL resolvers to the mix.

by platz 6y ago

filleokus 6y ago

I agree! One thing to consider is that it depends a lot on the way you decide to use it. On one "extreme", you only have predefined queries, meaning it could almost be implemented the same way you implement REST API (however you decide to that). On the other extreme of the spectrum, you allow the client to query the data with much freedom. This means that you have more of a generic resolver which maps GraphQL queries into an ORM or something else that generates your DB queries. In this mode, you have challenges regarding speed and optimisations. At a previous assignment we for example hand crafted the resolution of some especially nasty queries to increase performance, and left most for some ORM to figure out. We kept the database index structure up to date to match queries we saw from the frontend using metrics tools. Another thing is security. If you use this model, you are basically allowing the client to query around your graph of data in whatever way they want. This means you need to have some way to answer the question "Should User 37 be able to read field X on Object Y with ID 42", and implement that in your resolver. This is quite tricky, compared to REST or static graph QL queries where you just decide which objects / fields should be returned. (There is also some interesting DoS attack scenarios when going this route, where a malicious query can just explode in complexity, so you'll have to make sure to solve that some way as well...)

zomglings 6y ago

This is an astute question. I have only ever built a non-toy GraphQL server in 2016, for evaluation purposes. Never used in production. Tooling back then was probably much more primitive than it is today, so apply that discount to the subsequent statements. Writing GraphQL resolvers for the API that we were building was painful and required a solid understanding of our data model and what the database was capable of (we were using MongoDB). We were much happier at the time to stick to tried and true REST API tools and frameworks than to jump on the GraphQL bandwagon. All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server. This complexity seems irreducible to me, and I am highly skeptical of anyone claiming that they can make this complexity vanish. Have never so much as been tempted to use GraphQL since then. Unfortunately, this probably also marks my entry into dinosaur-hood.

TheCoelacanth 6y ago
> All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server That itself is useful. It is much easier to manage complexity on a server that you control in the same datacenter as your DB in a language of your choice than it is in JS with limited bandwidth.
- zomglings 6y ago
  The easiest way for us to manage this complexity was to add new, simple, RPC endpoints to our vanilla API. It certainly wasn't worth adding GraphQL resolvers to the mix.