591–600 of 721 posts
Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms…
Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms…
Earlier quoted context omitted.
Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me
Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something. A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no a…
Earlier quoted context omitted.
I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions. Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL…
I might be thinking about this the wrong way, but with GraphQL you're writing a query (in the GraphQL syntax) on the frontend which gets whatever data the frontend needs for whatever it's doing, and that query is interpreted by the backend to fetch specific data. But if you're whitelisting specific queries, which has to be done on the backend, what if you just move the queries themselves to the backend, and call them…
Earlier quoted context omitted.
Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me
With REST I can fairly easily filter out any data based on roles/permissions either at query time or before turning it into JSON. With GraphQL I need that info deep in the resolver logic and for nested data I don't want to fetch the name of a person if they calling user doesn't even have access to see that user (and I don't want to fetch the user and their name only to delete it from the response later). GraphQL, bei…
With GraphQL you can just do the exact same thing? I do this all the time. I don't understand how you wouldn't be able to do that.
Earlier quoted context omitted.
To claim that pretty much every .NET project adding Newtonsoft.JSON as a first step was somehow a problem is just strange. No adequate team would claim this to be a problem.
It was enough of a problem that Microsoft eventually saw it fit to come up with the official replacement.
This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL API rather than knowledge of the whole backend architecture, which is generally useful if the backend and frontend are written by different people or teams.
That's the way Facebook uses it on their main website: they pass the query id in the "doc_id" form field, the arguement in the "variables" field, the server gets the actual GraphQL query based on the doc_id from some sort of internal dictionary and AFAIK no GraphQL query string ever goes on the wire in production.
I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs. The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you…
OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.
I think the only reasonable way to use GraphQL on a freely accessible server is to only allow a set of whitelisted queries, ideally automatically extracted from the frontend codebase, stored on the server and invoked by id and arguments. This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL…
That's already how it works, it is not an open ended SQL query. The GraphQL schema is the whitelist.
I think the only reasonable way to use GraphQL on a freely accessible server is to only allow a set of whitelisted queries, ideally automatically extracted from the frontend codebase, stored on the server and invoked by id and arguments. This essentially turns GraphQL into a DSL for implementing REST endpoints, which is still a useful thing since it allows to write the REST endpoint with only knowledge of the GraphQL…
> I think the only reasonable way to use GraphQL is to only allow a set of whitelisted queries That's already how it works, it is not an open ended SQL query. The GraphQL schema is the whitelist.