GraphQL: A Retrospective
verve.co
GraphQL: A Retrospective
1–10 of 48 posts
Re: GraphQL: A Retrospective
#2While this post is supposed to be about GraphQL, it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs and nothing unique to GraphQL.
Their rule of "AVOID NESTING OBJECTS, JUST RETURN IDS OF RELATED OBJECTS" definitely is missing out one of the core benefits of GraphQL: being able to fetch related resources in a single request. Feels to me like they decided to switch to GraphQL cause it's supposedly better but are still utilizing it exactly like you would a REST API.
Re: GraphQL: A Retrospective
#3Sounds like they implemented an ESB. What’s old is new.
Re: GraphQL: A Retrospective
#4While this post is supposed to be about GraphQL, it seems to focus more about the benefits of having a centralized request broker / gateway for your APIs and nothing unique to GraphQL. Their rule of "AVOID NESTING OBJECTS, JUST RETURN IDS OF RELATED OBJECTS" definitely is missing out one of the core benefits of GraphQL: being able to fetch related resources in a single request. Feels to me like they decided to switch…
My understanding is that they are keeping their REST endpoints flat, however their gateway graphql layer can still respond with nested resources - it would require aggregating multiple REST requests together.
Re: GraphQL: A Retrospective
#5This article is really hard to understand. Is the gateway just for the UI as per normal or is it for all the backend services also?! The diagram doesn't help much because it looks like the backend services can call the front-end services. I don't quite get that a gateway can be on each backend service too, is that just to save a single network hop at the expense of every service taking a dependency on the gateway and thus every service..
Re: GraphQL: A Retrospective
#6The best part about Graphql is that it's a query language for API. It was my dream years ago to have a query language from my frontend code. Using REST always seems a smell to me.
Re: GraphQL: A Retrospective
#7I haven't yet had much luck in finding a GraphQL review that addresses my general concerns (I'm frontend).
1) GraphQL almost always means everything is POST, removing CDN and browser caching of GET-like requests is gone (and ServiceWorker caching just got much more complicated, nigh-impossible if CORS is involved). Everyone says "oh, clients can do better caching", as if that's not true without GraphQL. Still, the caching I mention might be trivial and mostly worthless. I'd just like to see some actual inspection of the issue.
2) The models I've seen work well if your frontend is largely a thin skin over the services with minimal business logic of their own. (this isn't GraphQL directly, but the client libs that use it, but those exist because talking GraphQL without them is more effort). Which is, of course, what we really want. Business logic in the front end is always a painful idea. But it also definitely happens, for real business reasons - are we making those cases harder? How much so? With REST we have a lot more flexibility, it seems, even if we choose to avoid using most of it.
Re: GraphQL: A Retrospective
#8The best part about Graphql is that it's a query language for API. It was my dream years ago to have a query language from my frontend code. Using REST always seems a smell to me.
It's not really a query language. Certainly not a general purpose query language. It's more of a somewhat flexible RPC, honestly.
It smells like a query language from a distance, but when you get close it smells much more of SOAP.
For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on their side. I have to get all colors of Widgets and filter it myself. The amount of unessessary data then can really multiply when you're getting the children and children's children of those widgets.
Having ported a number of APIs connectors from REST to GraphQL, I can say it has certainly greatly reduced the number of requests I've needed to make, but has often also greatly increased the amount of actual bytes I've received, particularly the bytes I don't need.
Re: GraphQL: A Retrospective
#9The best part about Graphql is that it's a query language for API. It was my dream years ago to have a query language from my frontend code. Using REST always seems a smell to me.
It's not really a query language. Certainly not a general purpose query language. It's more of a somewhat flexible RPC , honestly. It smells like a query language from a distance, but when you get close it smells much more of SOAP. For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on thei…
Maybe GraphQL is not the best specification for what a real query language looks like, but it's enough for most of CRUD use cases. Thanks GOD i can say goodbye to the ugly REST.
Re: GraphQL: A Retrospective
#10The best part about Graphql is that it's a query language for API. It was my dream years ago to have a query language from my frontend code. Using REST always seems a smell to me.
It's not really a query language. Certainly not a general purpose query language. It's more of a somewhat flexible RPC , honestly. It smells like a query language from a distance, but when you get close it smells much more of SOAP. For instance say I'm receiving a list of widgets, but I only need the red ones. Unless the API developers explicitly foresaw the need to include a color filter, I can't filter that on thei…
>It smells like a query language from a distance, but when you get close it smells much more of SOAP.
This smell is something I just can't move past when it comes to graphql.