8 ms·

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. I

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.
  - fendy3002 6y ago
    That's why I only use orm with the simplest query. It helps so much if the queries are just select where, create update delete rather than composing the queries myself.
    - coward8675309 6y ago
      I totally agree. I much prefer tools like the now-deprecated Yesql for Clojure that provide for easy mapping of actual SQL queries to function wrappers for those queries. Also, given that the database is where your data model’s consistency should be enforced, stored procedures and views are your friends. The last fifteen years of web app frameworks and developer practices have abused/neglected RDBMS systems by regarding them as simple table stores. ORMS are a classic “now you have two problems” non-solution.
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.

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.
- fendy3002 6y ago
  That's why I only use orm with the simplest query. It helps so much if the queries are just select where, create update delete rather than composing the queries myself.
  - coward8675309 6y ago
    I totally agree. I much prefer tools like the now-deprecated Yesql for Clojure that provide for easy mapping of actual SQL queries to function wrappers for those queries. Also, given that the database is where your data model’s consistency should be enforced, stored procedures and views are your friends. The last fifteen years of web app frameworks and developer practices have abused/neglected RDBMS systems by regarding them as simple table stores. ORMS are a classic “now you have two problems” non-solution.

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.