3 ms·

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

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.

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.