6 ms·

Going to reply here because, as a huge fan of GraphQL, I strongly disagree with every single one of your points. To start, I think the biggest misconception I s

Going to reply here because, as a huge fan of GraphQL, I strongly disagree with every single one of your points. To start, I think the biggest misconception I see about the value of GraphQL is people see it as some sort of generic "query language", which is unsurprising, given the name. If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. To your points: 1. I find GraphQL to be fantastic for security, primarily because all calls are strongly typed, so you can ensure by the time a request gets to your resolver it is guaranteed to match the defined input types. Furthermore, I always make heavy use of custom scalar types instead of String, which allows me to get rid of a whole host of potential security issues by limiting potential injection attacks before my code even sees it. As far as ensuring object ownership/permissions, this is trivially easy, or in any case just as easy as with REST. 2. Versioning is one of GraphQL's greatest strengths. The tooling makes it easy to deprecate some fields while adding replacement ones in a way that guarantees backwards compatibility. Far from "good luck figuring out what is used", the tooling e.g. in Apollo makes it very easy to see which clients are making use of which fields. Furthermore, if you do need to "hard version" a new endpoint, you can do it similarly to REST by including a version parameter in your URL (e.g. /v1/myGraphQLEndpoint). 3. Regarding qos, this again just gets to my original point about having well defined queries and mutations. Your queries don't need to say "allow me to see the world" any more than any other API framework. It's not hard to just have queries that only say "give me X by ID" and also a single bulk retrieval endpoint where you define the boundaries of what you want to return. If anything, I think perhaps a lot of misconceptions around the problems of GraphQL have to do with these tools that basically say "expose my whole DB with GraphQL", which in my experience usually leads to tears in the end. But starting with a thoughtful definition of your API surface area with GraphQL's type definition language can make it a joy to use and provides lots of benefits over a straight RESTful interface.

politelemon 3y ago
If I'm understanding correctly, there is a lot more work a team has to do to build and maintain a GraphQL API and should only do it if they understand what they're getting into and what its advantages are. It's not for everyone, and everyone shouldn't assume it's for them.
- hn_throwaway_99 3y ago
  > there is a lot more work a team has to do to build and maintain a GraphQL API I wouldn't say that. It's simple and straightforward to get around some pitfalls of GraphQL, if you treat it as an enumerated set of RPC-style endpoints. The commenter I was replying to stated "Thr fact that you're arguing that it should not be treated as a generic query language when it's in the name and this is how it's sold is hilaruous". Perhaps so. By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL (I heard someone ask once on HN "Can you do joins in GraphQL?", which isn't even a question that makes sense). It should be treated as a competitor to OpenAPI, and there are reasons why I would prefer using GraphQL in many scenarios. I think I'll probably write some longer form blog posts at some point about how I think GraphQL is easy to set up and get running quickly, and how to avoid some common misconceptions.
  - deleted 3y ago
    [deleted]
  - troupo 3y ago
    > It's simple and straightforward to get around some pitfalls of GraphQL It isn't > if you treat it as an enumerated set of RPC-style endpoints. It's not that. > I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL "GraphQL is a query language for APIs" is literally the tagline at https://graphql.org/ https://graphql.org/ And the frankly insane complexity of GraphQL comes from the fact that you now have to implement that query language, often over completely different sources of data. Which leads to frankly inane solutions like the requirement to inspect the full request and the full response on the fly just to be able to cache responses.
  - throwaway2990 3y ago
    > By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name No. The biggest mistake why not emphasising to people the usecase they solved which was having many many different front end consumers and having to create many permutations of the same endpoints to cover web, mobile, various applications in different states, time to deliver endpoints to the teams. Etc Most people are not working on the same number of implementations that Facebook or similar need. But they want to be on the bandwagon.
x86x87 3y ago
[flagged]
- runeks 3y ago
  > Falling back to arguing about typing show me that maybe you are not aware of the many interseting ways you can get screwed or maybe you just worked on simple straightforward things. Please provide a few examples of this.
  - x86x87 3y ago
    Since I'm not going to type a novel here is an example: https://wundergraph.com/blog/the_complete_graphql_security_guide_fixing_the_13_most_common_graphql_vulnerabilities_to_make_your_api_production_ready https://wundergraph.com/blog/the_complete_graphql_security_g... Also look at hackerone: https://hackerone.com/hacktivity?querystring=graphql https://hackerone.com/hacktivity?querystring=graphql
- zeroxfe 3y ago
  > So in conclusion, you're moving the goalposts and asserting that everyone that has issues with the tech must be an idiot since it works for you. That's not what GP asserted at all. You made some vague statements about gql, and they refuted with very concrete arguments.
- hn_throwaway_99 3y ago
  I didn't call anyone else an idiot. You don't actually seem to be open to hear about how people can use GraphQL, in production, to solve a host of thorny issues that "plain REST" APIs commonly have to deal with. Congrats on your intellectual superiority.
dcre 3y ago
This is helpful, but it confirms my sense that a REST API with a typed spec like OpenAPI is going to get you basically all the benefits of GraphQL.
- magic_quotes 3y ago
  Pretty much, they are fundamentally both RPC flavors, so it's impossible for them to have different properties beyond more or less convenient tooling. It's always jarring to see those heated GraphQL vs REST APIs (as implemented in practice) vs gRPC discussions as if they are as different as, say, client-side CRDTs.
  - e12e 3y ago
    > Pretty much, they are fundamentally both RPC flavors, so it's impossible for them to have different properties beyond more or less convenient tooling. REST arguably has better support for catching for read queries.
- ttymck 3y ago
  Pretty much except writing graphql schemas is actually quite enjoyable and expressive. I was always the biggest advocate for schema-first development, but OpenAPI specs were always such a pain to write and maintain. For this reason alone I would choose graphql (yet there are other benefits).
  - dcre 3y ago
    I agree, the schema language itself is very nice. The trick is to use a web server framework that generates the OpenAPI spec for you.
- ghnws 3y ago
  While taking half the time to do it. I've yet to see one good reason to use GQL for anything but public facing APIs, like GitHub API.
Philip-J-Fry 3y ago
>If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. But isn't this "infinite object graph" like the only real valuable part of GraphQL? People get caught up on that because all the other things you mention aren't really an issue with normal REST API. If you're saying you use GraphQL but don't use the key defining feature of GraphQL. Then what's the point of using GraphQL if you're just using a strict predefined set of things you can query/mutate?
- scotty79 3y ago
  Value of GraphQL imho is the ability for the api to be driven by frontend requirements without bothering the backend guys "to expose that one field in that one query". Once the app is developed I think you might put up reasonable general limits to what queries are responded to in a general manner over the whole api.
  - OJFord 3y ago
    So you move the issue to the resolver instead? IMO graphql is trying to allow the frontend to be the 'driver', the first bit; otherwise you just have the backend publish an API and then that is what it is, if that one field is available from a different endpoint than the one you're currently using, that's the one you need to hit (as well), tough. Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. (Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)
    - scotty79 3y ago
      > So you move the issue to the resolver instead? Yes. Where it can be logged, inspected and dealt with wholesale. It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods. > Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.
jakubmazanec 3y ago
> if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. Can you explain this more? How can you avoid infinite graphs? If I have User {things: Thing[]} and Thing {owner: User}, you have to deal with this issue.
- vinnymac 3y ago
  I have been writing GraphQL APIs on and off for the last 5 years, and in practice haven't had many scenarios where this was an issue. In GraphQL the query for the example you gave could look like this ```gql query { user { things { owner { id } } } } ``` When resolving an array of type `Thing` for the `things` field, you would query for the user that the `owner` field represents. Rather than assuming all relations should be loaded for an owner by default, the client would specify the fields for the `owner` that it needs. Such as I have above for the owner id. Even if no fields are specified, it would be weird to assume all relations should be loaded by default. Now if your developers are intentionally creating infinitely deep queries, then you'd solve this the same way you'd solve an infinite loop in your code today. An issue you would catch during development or CI/CD. This can be easy to catch using a linter or during review. ```gql query { user { things { owner { things { owner { things { } # etc } } } } } } ``` To simply protect from bad parties / developers, you might use something like https://github.com/slicknode/graphql-query-complexity https://github.com/slicknode/graphql-query-complexity In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments. https://graphql.org/learn/queries/#fragments https://graphql.org/learn/queries/#fragments
  - troupo 3y ago
criddell 3y ago
For the security comment, I was thinking they were talking about authorization. According to GraphQL, authorization belongs in the business logic layer[1]. A lot of projects ignore this advice and put it into the resolvers. This decentralized approach can be difficult to maintain and keep correct. [1]: https://graphql.org/learn/authorization/ https://graphql.org/learn/authorization/
Humphrey 3y ago
This! But I'll add one more: "Standardisation". Every RESTful API uses different URL paths, naming schemes, HTTP verbs, data structures, headers. Whereas those are defined by the GraphQL spec. When consuming or creating a GraphQL API, those (usually meaningless) decisions are defined by the spec, so I only need to learn how the data is structured. Since it's a spec, my queries can be strongly typed in both frontend and backend.
- throw1234651234 3y ago
  I don't understand what you are saying here. RESTful APIs are supposed to follow a specific format, e.g. GET: candidate/{id}, GET: candidate, POST: candidate, body: CandidateDto, etc. How is GraphQL different? Keep in mind that you can "see what's available" on a Swagger page easily with a REST API.
rockyj 3y ago
Not sure it this is a great reply. Some valid concerns were raised, and in summary all you are saying is GraphQL is awesome because it has types, schema and defined queries / mutations. This is of-course the basics of GQL, there are a lot of complexities under the surface. GraphQL does add some risks IMHO, e.g. client can send a really complex query (even a recursive one, e.g. get accounts for user, get user for each account). We cannot say this will not happen as we define the queries ourselves, since sometimes the API is exposed to clients which are not in our control. Queries can be sent which can almost bring a server down, so you need to handle that. Also error reporting / handling is trickier as compared to REST (e.g. https://the-guild.dev/blog/graphql-error-handling-with-fp https://the-guild.dev/blog/graphql-error-handling-with-fp).
joshstrange 3y ago
I think you misinterpreted the security aspect. I assume what they meant (and what I mean when I talk about how dire security is on GraphQL) is visibility first and foremost. Which users have access to which data. Things like multi-tenant or even just “you have access to X-model or this specific field on this model”. Couple that with inconsistent performance (at least for RDMS) and inability to make use of state stores in a sane way (IMHO) on the frontend makes it a non-starter.

politelemon 3y ago

If I'm understanding correctly, there is a lot more work a team has to do to build and maintain a GraphQL API and should only do it if they understand what they're getting into and what its advantages are. It's not for everyone, and everyone shouldn't assume it's for them.

hn_throwaway_99 3y ago
> there is a lot more work a team has to do to build and maintain a GraphQL API I wouldn't say that. It's simple and straightforward to get around some pitfalls of GraphQL, if you treat it as an enumerated set of RPC-style endpoints. The commenter I was replying to stated "Thr fact that you're arguing that it should not be treated as a generic query language when it's in the name and this is how it's sold is hilaruous". Perhaps so. By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL (I heard someone ask once on HN "Can you do joins in GraphQL?", which isn't even a question that makes sense). It should be treated as a competitor to OpenAPI, and there are reasons why I would prefer using GraphQL in many scenarios. I think I'll probably write some longer form blog posts at some point about how I think GraphQL is easy to set up and get running quickly, and how to avoid some common misconceptions.
- deleted 3y ago
  [deleted]
- troupo 3y ago
  > It's simple and straightforward to get around some pitfalls of GraphQL It isn't > if you treat it as an enumerated set of RPC-style endpoints. It's not that. > I think the original designers of GraphQL made was putting "QL" in the name, as many people think it's in the same category of tools as SQL "GraphQL is a query language for APIs" is literally the tagline at https://graphql.org/ https://graphql.org/ And the frankly insane complexity of GraphQL comes from the fact that you now have to implement that query language, often over completely different sources of data. Which leads to frankly inane solutions like the requirement to inspect the full request and the full response on the fly just to be able to cache responses.
- throwaway2990 3y ago
  > By far the biggest mistake I think the original designers of GraphQL made was putting "QL" in the name No. The biggest mistake why not emphasising to people the usecase they solved which was having many many different front end consumers and having to create many permutations of the same endpoints to cover web, mobile, various applications in different states, time to deliver endpoints to the teams. Etc Most people are not working on the same number of implementations that Facebook or similar need. But they want to be on the bandwagon.

x86x87 3y ago

[flagged]

runeks 3y ago
> Falling back to arguing about typing show me that maybe you are not aware of the many interseting ways you can get screwed or maybe you just worked on simple straightforward things. Please provide a few examples of this.
- x86x87 3y ago
  Since I'm not going to type a novel here is an example: https://wundergraph.com/blog/the_complete_graphql_security_guide_fixing_the_13_most_common_graphql_vulnerabilities_to_make_your_api_production_ready https://wundergraph.com/blog/the_complete_graphql_security_g... Also look at hackerone: https://hackerone.com/hacktivity?querystring=graphql https://hackerone.com/hacktivity?querystring=graphql
zeroxfe 3y ago
> So in conclusion, you're moving the goalposts and asserting that everyone that has issues with the tech must be an idiot since it works for you. That's not what GP asserted at all. You made some vague statements about gql, and they refuted with very concrete arguments.
hn_throwaway_99 3y ago
I didn't call anyone else an idiot. You don't actually seem to be open to hear about how people can use GraphQL, in production, to solve a host of thorny issues that "plain REST" APIs commonly have to deal with. Congrats on your intellectual superiority.

dcre 3y ago

This is helpful, but it confirms my sense that a REST API with a typed spec like OpenAPI is going to get you basically all the benefits of GraphQL.

magic_quotes 3y ago
Pretty much, they are fundamentally both RPC flavors, so it's impossible for them to have different properties beyond more or less convenient tooling. It's always jarring to see those heated GraphQL vs REST APIs (as implemented in practice) vs gRPC discussions as if they are as different as, say, client-side CRDTs.
- e12e 3y ago
  > Pretty much, they are fundamentally both RPC flavors, so it's impossible for them to have different properties beyond more or less convenient tooling. REST arguably has better support for catching for read queries.
ttymck 3y ago
Pretty much except writing graphql schemas is actually quite enjoyable and expressive. I was always the biggest advocate for schema-first development, but OpenAPI specs were always such a pain to write and maintain. For this reason alone I would choose graphql (yet there are other benefits).
- dcre 3y ago
  I agree, the schema language itself is very nice. The trick is to use a web server framework that generates the OpenAPI spec for you.
ghnws 3y ago
While taking half the time to do it. I've yet to see one good reason to use GQL for anything but public facing APIs, like GitHub API.

Philip-J-Fry 3y ago

>If anything I think the biggest problem with GraphQL is that, if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. But isn't this "infinite object graph" like the only real valuable part of GraphQL? People get caught up on that because all the other things you mention aren't really an issue with normal REST API. If you're saying you use GraphQL but don't use the key defining feature of GraphQL. Then what's the point of using GraphQL if you're just using a strict predefined set of things you can query/mutate?

scotty79 3y ago
Value of GraphQL imho is the ability for the api to be driven by frontend requirements without bothering the backend guys "to expose that one field in that one query". Once the app is developed I think you might put up reasonable general limits to what queries are responded to in a general manner over the whole api.
- OJFord 3y ago
  So you move the issue to the resolver instead? IMO graphql is trying to allow the frontend to be the 'driver', the first bit; otherwise you just have the backend publish an API and then that is what it is, if that one field is available from a different endpoint than the one you're currently using, that's the one you need to hit (as well), tough. Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. (Personally I'd love to use something like OpenAPI, with tooling more mature than probably exists, to be properly schema-driven, with both backend and frontend stubs/clients derived from that.)
  - scotty79 3y ago
    > So you move the issue to the resolver instead? Yes. Where it can be logged, inspected and dealt with wholesale. It's moveing a problem from intra-team verbal communication into software where it can be dealt with more efficiently with software tools and methods. > Not to say either way around is inherently better, I just see it as a switch from backend-driven to frontend-driven. Yes. I think that's the whole point and main benefit of GraphQL which makes a lot of sense since apps that evolve through their development usually have most changes UI driven.

jakubmazanec 3y ago

> if people just saw it is a simple alternative to REST, with a well defined set of query (GET) and mutation (PUT/POST/DELETE) endpoints, they wouldn't get caught up in all this "infinite object graph" stuff that I never hit in my day-to-day. Can you explain this more? How can you avoid infinite graphs? If I have User {things: Thing[]} and Thing {owner: User}, you have to deal with this issue.

vinnymac 3y ago
I have been writing GraphQL APIs on and off for the last 5 years, and in practice haven't had many scenarios where this was an issue. In GraphQL the query for the example you gave could look like this ```gql query { user { things { owner { id } } } } ``` When resolving an array of type `Thing` for the `things` field, you would query for the user that the `owner` field represents. Rather than assuming all relations should be loaded for an owner by default, the client would specify the fields for the `owner` that it needs. Such as I have above for the owner id. Even if no fields are specified, it would be weird to assume all relations should be loaded by default. Now if your developers are intentionally creating infinitely deep queries, then you'd solve this the same way you'd solve an infinite loop in your code today. An issue you would catch during development or CI/CD. This can be easy to catch using a linter or during review. ```gql query { user { things { owner { things { owner { things { } # etc } } } } } } ``` To simply protect from bad parties / developers, you might use something like https://github.com/slicknode/graphql-query-complexity https://github.com/slicknode/graphql-query-complexity In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments. https://graphql.org/learn/queries/#fragments https://graphql.org/learn/queries/#fragments
- troupo 3y ago

criddell 3y ago

For the security comment, I was thinking they were talking about authorization. According to GraphQL, authorization belongs in the business logic layer[1]. A lot of projects ignore this advice and put it into the resolvers. This decentralized approach can be difficult to maintain and keep correct. [1]: https://graphql.org/learn/authorization/ https://graphql.org/learn/authorization/

Humphrey 3y ago

This! But I'll add one more: "Standardisation". Every RESTful API uses different URL paths, naming schemes, HTTP verbs, data structures, headers. Whereas those are defined by the GraphQL spec. When consuming or creating a GraphQL API, those (usually meaningless) decisions are defined by the spec, so I only need to learn how the data is structured. Since it's a spec, my queries can be strongly typed in both frontend and backend.

throw1234651234 3y ago
I don't understand what you are saying here. RESTful APIs are supposed to follow a specific format, e.g. GET: candidate/{id}, GET: candidate, POST: candidate, body: CandidateDto, etc. How is GraphQL different? Keep in mind that you can "see what's available" on a Swagger page easily with a REST API.

rockyj 3y ago

Not sure it this is a great reply. Some valid concerns were raised, and in summary all you are saying is GraphQL is awesome because it has types, schema and defined queries / mutations. This is of-course the basics of GQL, there are a lot of complexities under the surface. GraphQL does add some risks IMHO, e.g. client can send a really complex query (even a recursive one, e.g. get accounts for user, get user for each account). We cannot say this will not happen as we define the queries ourselves, since sometimes the API is exposed to clients which are not in our control. Queries can be sent which can almost bring a server down, so you need to handle that. Also error reporting / handling is trickier as compared to REST (e.g. https://the-guild.dev/blog/graphql-error-handling-with-fp https://the-guild.dev/blog/graphql-error-handling-with-fp).

joshstrange 3y ago

I think you misinterpreted the security aspect. I assume what they meant (and what I mean when I talk about how dire security is on GraphQL) is visibility first and foremost. Which users have access to which data. Things like multi-tenant or even just “you have access to X-model or this specific field on this model”. Couple that with inconsistent performance (at least for RDMS) and inability to make use of state stores in a sane way (IMHO) on the frontend makes it a non-starter.