11–20 of 50 posts
Earlier quoted context omitted.
I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
> I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
Earlier quoted context omitted.
I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
> I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
https://twitter.com/meixnertobias/status/1704565814022770857
Earlier quoted context omitted.
I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
> I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
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…
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 now only uses GraphQL for querying CommerceTools, and their GraphQL implementation seems like someone told a dev hey, we need GraphQL, make our SQL backend available over that, and he completed his ticket anywhere from 4 hours to 4 days, but certainly not in any amount of time to make a solution that had any of the advantages of GraphQL in it.
We used to have GraphQL for the part of the project using Contentful - but their GraphQL was so problematic we moved to their Rest API (I say was because that move was over 1 year ago, it would be wrong to say it is bad now - who knows what improvements they might have had)
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…
"Make another endpoint for getting the whole thing in one go" is a pretty good description of what GraphQL does . Except instead of writing an endpoint in some general purpose language you define it declaratively.
Maybe but the implementation is orders of magnitude more complex compared to simply making a couple of DB queries and then sending a JSON.
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…
It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.
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…
> It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.
I think people miss the point a lot when ranting about graphql. It’s not particularly their fault, I didn’t get it either until I experienced multiple massive rest messes like you describe.
Also, as social/org tech you don’t really see the benefits in small teams / simple products / small apis. It just feels like extra complexity at that size.
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…
The Guild [0] does some exceptional work in the GQL world and specifically server side with Yoga, Envelope, Hive, and some other stuff; but it does tend to be JS focused for now.
when splitting your request the user can view his profile picture before the main content finished loading. this cam hurt user experience
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…
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 does have some downsides (eg it's easy for the person iterating away on the FE to not have to think about the cost of querying that data on the BE).
GraphQL does have a few other advantages though, like being able to build your typing around it (again, doable with REST but with more work).