21–30 of 50 posts
does merging all of your api calls to a single one means that the slowest request is a bottle neck? when splitting your request the user can view his profile picture before the main content finished loading. this cam hurt user experience
And puts all the complexity on the backend :-)
As far as I've seen, front-end developers are generally quite happy about graphql. Back-end developers on the other hand are a different story.
> Which brings some simplicity to the client And puts all the complexity on the backend :-) As far as I've seen, front-end developers are generally quite happy about graphql. Back-end developers on the other hand are a different story.
So if GraphQL front-end developers into discussion about schema I rather take that over whatever REST solution they're using today.
But I might be biased here...
> Which brings some simplicity to the client And puts all the complexity on the backend :-) As far as I've seen, front-end developers are generally quite happy about graphql. Back-end developers on the other hand are a different story.
So basically frontend+backend effort with GraphQL is much smaller than frontend+backend with REST
If the primary selling point of the new technology is something like GraphQL's "if your API doesn't have a good single route to get the data for this page, GraphQL can synthesize it"; frontend just doesn't, in general, iterate at a speed that is such orders-of-magnitude higher than how quickly a new API view can be built, such that a new structurally-different communications layer is necessary. Additionally; GraphQL…
>Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Ok, well for some reason every project I've been on in the past 4-5 years has used GraphQL? What makes me so special? As I conclude that I am not special I have to go back to what my previous position was that GraphQL is pretty much the standard way front-enders query nowadays. That said - the project I am on right n…
Aww, don’t sell yourself short!
If you need to request multiple REST resources for a single "operation", then you don't have enough REST resources defined. [1] Just make another endpoint for getting the whole thing in one go and call it a day, don't try to overly generalise your API. Going even further, your server requests to the database could be similar as well, one query to get everything needed, then you don't even need to worry about server t…
> Just make another endpoint for getting the whole thing in one go and call it a day. That's pretty much the point (well, one of the main points) of GraphQL... precisely so you don't have to do that. Want to request a new object or list of objects? Request a new field on an existing object? You don't have to go "make another endpoint", you just change your GraphQL query. This is really nice for iterating, though it d…
I'm not actually opposed to Graphql as a technology, One of my favourite pieces of technology is actually PostGraphile.
I just believe it's easy to misuse it (in similar ways to an ORM) that result in not utilising server capabilities to their fullest.
If you need to request multiple REST resources for a single "operation", then you don't have enough REST resources defined. [1] Just make another endpoint for getting the whole thing in one go and call it a day, don't try to overly generalise your API. Going even further, your server requests to the database could be similar as well, one query to get everything needed, then you don't even need to worry about server t…
My practical experience with that idea is pretty negative, at least with any degree of scale (either in how widely used the resource in question is or in number of people working on the system). I saw a multi-year mess made at a company when the widely used `ResourceA` got endpoints for `ResourceAandB` and C, and D, and E... for the reasons you mention. Then somebody added some fields to make a `ResourceA'` with a sp…
I don't buy this argument. Imagine if an airplane manufacturer had the same philosophy. "We can't just substitute that component because it wouldn't fit the existing frame... Oh but wait, we can't just change the frame or the new component to make it fit because of social factors within the engineering team. Let's just tack it on as originally planned and then work around the issue by implementing a complex solution in the software to make up for the structural design flaw.."
That's basically the Boeing 737 MAX story. We know the result of that philosophy.
I never really got graphql until I stumbled upon Wundergraph. ( https://github.com/wundergraph/wundergraph ). I have no affiliation with them except that I have been building an app with it. I'm honestly puzzled how it's not more popular. Maybe people are solving these problems in other ways? But I tried out a bunch of stuff: Vapor, Supabase, Hasura, firebase, nhost, etc. None of it simplifies building complex system…
1. https://github.com/manifold-systems/manifold/tree/master/man...
I don't get it, how is this significantly more complex than what the author suggests? How is this shifting complexity to the backend with REST and not with GraphQL if all you're changing is the transport layer?