221–230 of 243 posts
Earlier quoted context omitted.
This is more or less what dataloader accomplishes. Generally speaking when creating a gql service, graph traversal is not app code but library code.
Dataloader avoids the N+1 but I wouldn't call it a good solution, you have to twist your app code to make it work. Its an inelegant solution, imo.
Earlier quoted context omitted.
We’ve had these aspects out of the box with oData REST endpoints that have been in production for half a decade.
What do you think may account for the lack of take up iof oData?
Another factor may be that Microsoft used it so some sectors thought it was uncool and spent a long time building other stuff instead ..
If you are creating a data service then I think you really need to have both. Which you do, and how much of it, is more likely to be dictated by time and budget. Many will need to figure out who their 80% audience is and prioritize based on that.
Still a few REST services can be done, then GraphQL added with not mutators, then add mutators and more queryable data, etc. Start with the bare bones, just like you would a startup MVP and grow organically from there.
Earlier quoted context omitted.
> There is one huge advantage that i don't believe REST can solve: a GraphQL server returns a schema that tells you exactly what can be queried. So, commonly, does a REST endpoint that observes HATEOAS (without which it is not REST.) > I know there are tools like Swagger that solve this problem to some extent, but its not baked into the standard like with GraphQL. REST is an architectural style, not a standard, but i…
Of course you can build these elements into your own implementation, but there is value in a higher level standard that has these items guaranteed. If a product advertise a GraphQL api you know immediately there will be no trouble with determining what the api can return and accept.
That's what OpenAPI is. (You mention the Swagger tool, but claim it's not baked into “the standard” the way GraphQL is; as well as a tool, Swagger was also the name of the standard, though the current version of that standard is called OpenAPI.)
It is also what JSON:API is.
It is also what OData is.
It is also what RAML is.
Heck, there's a good argument that it is what GraphQL is, too: https://hasura.io/blog/rest-view-of-graphql/
Earlier quoted context omitted.
My sense is that GraphQL makes the impossible stuff hard and the easy stuff hard. So its relative merits have a lot to do with how complicated a thing you're trying to do in the first place.
Do you mean "GraphQL makes the impossible stuff easy "? If so, I do agree with that statement.
Perhaps that's my bias showing. Lately I've mostly been working in Java, a context where the words "easy" and "Web" rarely belong together in the same sentence.
Earlier quoted context omitted.
It is really hard to do business logic in GraphQL. The language syntax is literally limited to ‘I want this data’.
Well, when you say 'give me all cars and all users joined by user ID = owner id', that's business logic. With a good REST API you would just do a GET on /cars and find any user details that are needed already in each car (perhaps under a link, which may lead to the N+1 problem, but that's another discussion). Of course, a bad REST API may expect that you do a GET /cars and GET /users and match them in your code, whic…
Earlier quoted context omitted.
REST endpoints typically return data I don't need. For example, the twitter REST API `/1.1/users/show.json?screen_name=twitterdev` it will show me the last tweet for the user. Presumably this involves perhaps waiting for tweet service when the client may not even want the tweet. A GraphQL client can be more explicit about what edges to select.
Yes, the advantage of a GraphQL endpoint is you can ask for a variety of things and the tradeoff is potential performance issues for unforeseen queries doing N+1s or something. If you control the API and know all the use cases for a REST endpoint, the advantage is predictable performance characteristics and the tradeoff is flexibility. It all depends on what you need (and maybe what tools you're using to mitigate Gra…
Earlier quoted context omitted.
So, you're basically proposing to create a poor imitation of REST. What's the point of GraphQL in this case?
I suggest you to take a step back and re-read the thread. Maybe the context got lost. I replied to the following post: > https://news.ycombinator.com/item?id=25432655 In particular: > Its much harder to make an efficient resolver than it is making an efficient REST endpoint. As I showed, the claim is not true because it can be solved in the same way in both GraphQL and REST.
I've read the thread. And no, the context wasn't lost.
The whole point of GraphQL is flexible queries. And it is harder to make an efficient resolver in GraphQL than it is in REST.
And yes, your solution (and the solution everyone ends up arriving at) is reimplementing REST in GraphQL, poorly. Precisely because it is much harder to make an efficient resolver in GraphQL.
I'll be honest. I hate GraphQL. It probably makes sense in a world where everyone uses graphQL, but to me it felt like having to learn yet another query language to do what to me seems straightforward using a simple REST api. I may also be old and cranky and you should probably get off of my lawn.
You write the moral equivelent of __attribute__((graphql)) on your code, and boom, you can query it. You want mutations? __attribute__((graphql_root_mutation)). If your object is stored in TAO, everything works perfect. You can add custom fields or even custom objects implemented in PHP that can do whatever the hell they want.
You never have to think about a database. And you barely even have to think about security if you're using pre-existing objects, the rules for which users should be allowed to see which objects are written in one centralized place and enforced everywhere in the codebase, graphql included.
Of course, it only works that well because there are multiple ~20-30 person teams maintaining that infrastructure. And GraphQL was designed with Facebook's infrastructure in mind.
Outside of Facebook, I cannot see myself using GraphQL for any reason.
Earlier quoted context omitted.
I agree with GP as well, but I do think there are unique circumstances with GraphQL. One difference is that if the front-end makes N+1 REST calls, it's (hopefully) obvious to the front-end developer. It's also generally easy to map the REST requests to the database queries being made. Swap it all out for a single GraphQL query and now you have no idea how it will perform or whether it was optimized for the specific f…
The GraphQL equivalent to creating a new, specialized REST route would be to create a new, specialized query. E.g. the following REST /articles-with-comments?number=20 which returns title, contents etc. would map to a completely new query in graphql articlesWithComments(number: Integer) { title contents ... } so it is exactly as easy to optimize. Of course this is not very composable, but that is equally true for bot…