|
|
|
|
|
|
by g_delgado14
2561 days ago
|
|
|
I haven't ever used GraphQL (so take what I say with a grain of salt b/c i could be incorrect), but what gets me intrigued by it is that it helps your engineering organization scale by decoupling the back end and the front end. Say, for example, that you have a new UI on your app that requires some data stored on your db. Without graphql, you: A) Re-use existing REST endpoints and compose data that you need on the front end (but remember that browsers have a hard limit on the number of concurrent api requests. Not to mention that some requests can't be sent until others have arrived back with resource id's). So depending on what endpoints you currently have, this may not be a good option given the latency cost of composing many HTTP requests to get all the required data. B) You tell your back end devs to create a brand new route that meets the data requirements of the new UI. With GraphQL, my understanding is that there is zero back end work. You just tell the GraphQL engine what data you need and it magically arrives into your browser. |
|
|
It doesn‘t quite work like that. Someone still has to implement the backend (resolvers). If you want to request dogs from your backend someone still has to implement the dogs query, but (and I think that‘s one of the greatest things about GQL) as soon as it is implemented, you can introspect your backend and see exactly which properties a dog can have. So you know whether the dog object has a name property, or an isHungry property and so on. So now you can specifically ask for a dog and its name if that‘s all your view needs. Another view might only need the breed, so that‘s what you query for...view specific queries.