9 ms·

This is a refreshing read, every time I ask someone what they like about GraphQL or read an article about the benefits of GraphQL I get the same boilerplate, no

This is a refreshing read, every time I ask someone what they like about GraphQL or read an article about the benefits of GraphQL I get the same boilerplate, non-answers that made me avoid GraphQL on my latest app after working with it on 2 freelance projects over the last couple years. The tooling around Apollo is pretty good, and that’s great but so many of the “why GraphQL” arguments are either short sided, assume you are doing REST badly, or imply you are an organization that is much bigger and has scaling problems most of the projects I’ve worked on do not have. So far I am very happy I went back to a REST API. Oh and here’s another REST benefit: when working on my REST API I spend most of my time thinking about good API design and testing practices. When working with GraphQL I spent most of my time figuring out how GraphQL ecosystem libraries worked. I would much rather spend my time thinking about how to do the job well than how to glue together an ecosystem of tools that someone else designed. Admittedly this is a very subjective line to draw, for instance I loved Rails and some people make the same criticism of Rails that I make here for the GraphQL ecosystem.

golergka 6y ago
GraphQL is great when your entities are complicated and interconnected with each other. If you just need to get one user object, it's not different from rest. If you need to get user, then 5 of his posts, then 50 of comments for each post and then 100 reactions for each post, all connected by IDs in your DB, GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. (This example is pretty silly, but I have very similar and not silly examples that I just can't share because of respect for my employer's NDA).
- vidarh 6y ago
  My experience is that giving front-end developers who does not understand databases the ability to do this is a great way of killing performance across the board. I don't particularly want that to be easy, because I've too many times had to clean up the consequences. If you have a team where everyone understands the database implications, then awesome. In that case this consideration may not apply.
  - golergka 6y ago
    It can be a very bad thing or an acceptable payment for developer velocity, based on what's your business priorities with the project. I have a couple of issues that I worked on that started exactly like this: front-end developer implemented a feature based on GraphQL, but when we deployed this feature, we quickly disabled it after receiving alerts from production database, and re-enabled it back only after backend developer (me) went and worked on database indexing. But for my team, at the current point of the project's development, this scenario is a net positive overall, because we're exactly in "move fast and break things" mentality, which suits our product and our place in the market. If our project would require a lot of 9s, or worked with very confidential data, or had 10s of millions of daily users, we would have completely different internal procedures and development practices: much safer and much slower. Also, I wrote about this exact problem in another thread under this post: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918
    - vidarh 6y ago
      I agree with this - my current main focus is effectively a CRM where I've exposed abilities for front-end devs to outright write SQL directly - as a shortcut when you need to get things done fast it can be fine. But I've also never seen this done without getting horribly abused, and so I tend to lock things down gradually as a service matures or the team grows. Then again, developers will try to work around it - I had one project many years ago where I on purpose introduced a very restrictive template language to ensure proper separation of content and logic, in large party because the templates were translated to 17 languages, and avoiding breakage was a lot easier the less logic there were in them... Cue two of the developers trying to sneak in a tag to allow embedded Perl...
  - coward8675309 6y ago
    And this is why in general I don’t like ORMs, even my favorite ORM, Django’s. They hide from you the query complexity — and perhaps also the number of queries — that your ORM query produces. There are situations where a different ORM approach would yield similarly shaped data yet consumes orders of magnitude more or fewer resources. And this is without adding any new indices. In general I don’t like giving anyone the ability to write queries unless I trust they understand the performance ramifications. This can be difficult to enforce because someone “on the outside” can always abuse your thoughtfully constructed set of access points you’ve provided by sticking them in nested loops. Perhaps an answer is strict allocation of quotas outside the realm of assumed competence and good will.
- dmitriid 6y ago
  > GraphQL is great when your entities are complicated and interconnected with each other. It's great for the frontend, but in this case it's awful for the backend. > GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. Yeah, right. Because that SQL query will just magically write itself. Especially if that ad-hoc GraphQL query requests extra fields (or doesn't request extra fields) or taps into data that' only available from an external service etc.
  - lyxsus 6y ago
    Yes, it can and often will. That’s the point.
    - dmitriid 6y ago
      No, it can't, and it often won't. Just because you stumbled across a single application server that can do that doesn't mean it's true for GraphQL in general. And once you go you go beyond toy examples on minuscule data, even those magical tools immediately run into problems: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918 (note: this is by the author of the comment I replied to) and https://news.ycombinator.com/item?id=25015173 https://news.ycombinator.com/item?id=25015173
      - lyxsus 6y ago
        I think that these misconceptions a result of lack of experience/knowledge in graphic/databases and FP in general. I don’t see people writing assembly code trying to beat compiler optimizer very often, same thing here. We just need more competent engineers and a bit of time. If anything, we’ll move forward, to more conceptually complex protocol, definitely not back to the plain rest, that I saw many have nostalgia about.
        dmitriid 6y ago
        > I think that these misconceptions a result of lack of experience/knowledge in graphic/databases and FP in general. Which conception will magically convert an ad-hoc GraphQL query into "single SQL query and with 0 lines written by backend developer"? > I don’t see people writing assembly code trying to beat compiler optimiser very often, same thing here. No idea what you're talking about and how this is relevant > If anything, we’ll move forward, to more conceptually complex protocol, definitely not back to the plain rest, that I saw many have nostalgia about. As long as you pretend that GraphQL is magic that requires 0 backend work (but at the same time requires "more competent engineers and a bit of time"), then sure.
- eterps 6y ago
  To me that sounds like wilfully ignoring all the caching and concurrency opportunities you could have in addition to forcing all data through a single point of congestion. At least caching can be solved somewhat, but not on the protocol level. I think GraphQL is great for applications where there are no apparent caching or concurrency options.
BenGosub 6y ago
For me it boils down to: - Flexibility -Type safety - Developer experience (like caching out of the box with Apollo), or self-documenting

golergka 6y ago

GraphQL is great when your entities are complicated and interconnected with each other. If you just need to get one user object, it's not different from rest. If you need to get user, then 5 of his posts, then 50 of comments for each post and then 100 reactions for each post, all connected by IDs in your DB, GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. (This example is pretty silly, but I have very similar and not silly examples that I just can't share because of respect for my employer's NDA).

vidarh 6y ago
My experience is that giving front-end developers who does not understand databases the ability to do this is a great way of killing performance across the board. I don't particularly want that to be easy, because I've too many times had to clean up the consequences. If you have a team where everyone understands the database implications, then awesome. In that case this consideration may not apply.
- golergka 6y ago
  It can be a very bad thing or an acceptable payment for developer velocity, based on what's your business priorities with the project. I have a couple of issues that I worked on that started exactly like this: front-end developer implemented a feature based on GraphQL, but when we deployed this feature, we quickly disabled it after receiving alerts from production database, and re-enabled it back only after backend developer (me) went and worked on database indexing. But for my team, at the current point of the project's development, this scenario is a net positive overall, because we're exactly in "move fast and break things" mentality, which suits our product and our place in the market. If our project would require a lot of 9s, or worked with very confidential data, or had 10s of millions of daily users, we would have completely different internal procedures and development practices: much safer and much slower. Also, I wrote about this exact problem in another thread under this post: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918
  - vidarh 6y ago
    I agree with this - my current main focus is effectively a CRM where I've exposed abilities for front-end devs to outright write SQL directly - as a shortcut when you need to get things done fast it can be fine. But I've also never seen this done without getting horribly abused, and so I tend to lock things down gradually as a service matures or the team grows. Then again, developers will try to work around it - I had one project many years ago where I on purpose introduced a very restrictive template language to ensure proper separation of content and logic, in large party because the templates were translated to 17 languages, and avoiding breakage was a lot easier the less logic there were in them... Cue two of the developers trying to sneak in a tag to allow embedded Perl...
- coward8675309 6y ago
  And this is why in general I don’t like ORMs, even my favorite ORM, Django’s. They hide from you the query complexity — and perhaps also the number of queries — that your ORM query produces. There are situations where a different ORM approach would yield similarly shaped data yet consumes orders of magnitude more or fewer resources. And this is without adding any new indices. In general I don’t like giving anyone the ability to write queries unless I trust they understand the performance ramifications. This can be difficult to enforce because someone “on the outside” can always abuse your thoughtfully constructed set of access points you’ve provided by sticking them in nested loops. Perhaps an answer is strict allocation of quotas outside the realm of assumed competence and good will.
dmitriid 6y ago
> GraphQL is great when your entities are complicated and interconnected with each other. It's great for the frontend, but in this case it's awful for the backend. > GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. Yeah, right. Because that SQL query will just magically write itself. Especially if that ad-hoc GraphQL query requests extra fields (or doesn't request extra fields) or taps into data that' only available from an external service etc.
- lyxsus 6y ago
  Yes, it can and often will. That’s the point.
  - dmitriid 6y ago
    No, it can't, and it often won't. Just because you stumbled across a single application server that can do that doesn't mean it's true for GraphQL in general. And once you go you go beyond toy examples on minuscule data, even those magical tools immediately run into problems: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918 (note: this is by the author of the comment I replied to) and https://news.ycombinator.com/item?id=25015173 https://news.ycombinator.com/item?id=25015173
    - lyxsus 6y ago
      I think that these misconceptions a result of lack of experience/knowledge in graphic/databases and FP in general. I don’t see people writing assembly code trying to beat compiler optimizer very often, same thing here. We just need more competent engineers and a bit of time. If anything, we’ll move forward, to more conceptually complex protocol, definitely not back to the plain rest, that I saw many have nostalgia about.
      - dmitriid 6y ago
        > I think that these misconceptions a result of lack of experience/knowledge in graphic/databases and FP in general. Which conception will magically convert an ad-hoc GraphQL query into "single SQL query and with 0 lines written by backend developer"? > I don’t see people writing assembly code trying to beat compiler optimiser very often, same thing here. No idea what you're talking about and how this is relevant > If anything, we’ll move forward, to more conceptually complex protocol, definitely not back to the plain rest, that I saw many have nostalgia about. As long as you pretend that GraphQL is magic that requires 0 backend work (but at the same time requires "more competent engineers and a bit of time"), then sure.
eterps 6y ago
To me that sounds like wilfully ignoring all the caching and concurrency opportunities you could have in addition to forcing all data through a single point of congestion. At least caching can be solved somewhat, but not on the protocol level. I think GraphQL is great for applications where there are no apparent caching or concurrency options.

BenGosub 6y ago

For me it boils down to: - Flexibility -Type safety - Developer experience (like caching out of the box with Apollo), or self-documenting