5 ms·

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 tryi

by 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.
- lyxsus 6y ago
  In thread you’ve pointed before there’s a link to postgraphie. Even without tweaks it already gives a decent code. With some little efforts you can optimize anything you want, score query complexity and etc. If you don’t want unpredicted performance, use persistent queries in production. Nobody says backend work will magically disappear, but ignoring a generational improvement only because of job security concerns is insane.
  - dmitriid 6y ago
    > Nobody says backend work will magically disappear, That was literally what was directly stated in the original comment I responded to. > but ignoring a generational improvement only because of job security concerns is insane. Ah yes. People who have only one database with a magical tool try to berate people with significantly different requirements.
    - lyxsus 6y ago
      Lol The original post, if you’ll read it again, carefully, pointed out that you can compose a complex query in a single graphql query. And if you need this data, you have to get that data one way or another. What’s so hard about that? Now if you can make a single query to select that data, then great. In most cases there’s enough information to generate it automatically and efficiently and refine it if not. What’s not clear about that? Oh, maybe you have some magical and complicated infrastructure? Well, you have to query them anyway, right? It’s not automated you say? Sure, but you can always get insight from libs like Haxl, made by same Facebook. The magical database tool is a simple and comprehensible example (but still is brilliant in how well it works). The bottom line is that if dev team is capable of working with graphql, it’s just a better choice. Most of the projects I saw unfortunately are made in such a way that you hope they sticked to the good old Rest, because when you do that, use graphql as rest, the result will be disappointing. But come on, that’s the same as people migrating from react to vuejs bc it’s feels less alien or use mobx and other bi-directional storage instead of relay or redux, they’re obfuscating the problem for short-term benefit.
      - dmitriid 6y ago
        > The original post, if you’ll read it again, carefully Literally says this, emphasis mine: --- start quote --- 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. --- start quote --- No. In general, it doesn't. There's a magical tool that they use, and they still have issues with it: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918 So much for "single SQL with 0 lines of backend code" when you have "weird joins that we won't optimise for, and sooner or later there will be determined DDoSers who will figure it out" > The magical database tool is a simple and comprehensible example (but still is brilliant in how well it works). Yeah, this magical tool is only a tool, that works with a single database, for a single set of problems, and has to be constantly fine-tuned because you can't optimise ad-hoc queries. But yeah, dismiss all that and just shout to the world: "REST sucks, GraphQL is so much better because we have this one single tool". The moment you step outside the limitations of that tool, you're screwed. But you haven't reached that point yet, so you consider yourself "competent". > The bottom line is that if dev team is capable of working with graphql, it’s just a better choice. This still has to be empirically proven by anyone without magical handwaving and dismissing any issues.

by lyxsus 6y ago

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.

lyxsus 6y ago
In thread you’ve pointed before there’s a link to postgraphie. Even without tweaks it already gives a decent code. With some little efforts you can optimize anything you want, score query complexity and etc. If you don’t want unpredicted performance, use persistent queries in production. Nobody says backend work will magically disappear, but ignoring a generational improvement only because of job security concerns is insane.
- dmitriid 6y ago
  > Nobody says backend work will magically disappear, That was literally what was directly stated in the original comment I responded to. > but ignoring a generational improvement only because of job security concerns is insane. Ah yes. People who have only one database with a magical tool try to berate people with significantly different requirements.
  - lyxsus 6y ago
    Lol The original post, if you’ll read it again, carefully, pointed out that you can compose a complex query in a single graphql query. And if you need this data, you have to get that data one way or another. What’s so hard about that? Now if you can make a single query to select that data, then great. In most cases there’s enough information to generate it automatically and efficiently and refine it if not. What’s not clear about that? Oh, maybe you have some magical and complicated infrastructure? Well, you have to query them anyway, right? It’s not automated you say? Sure, but you can always get insight from libs like Haxl, made by same Facebook. The magical database tool is a simple and comprehensible example (but still is brilliant in how well it works). The bottom line is that if dev team is capable of working with graphql, it’s just a better choice. Most of the projects I saw unfortunately are made in such a way that you hope they sticked to the good old Rest, because when you do that, use graphql as rest, the result will be disappointing. But come on, that’s the same as people migrating from react to vuejs bc it’s feels less alien or use mobx and other bi-directional storage instead of relay or redux, they’re obfuscating the problem for short-term benefit.
    - dmitriid 6y ago
      > The original post, if you’ll read it again, carefully Literally says this, emphasis mine: --- start quote --- 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. --- start quote --- No. In general, it doesn't. There's a magical tool that they use, and they still have issues with it: https://news.ycombinator.com/item?id=25014918 https://news.ycombinator.com/item?id=25014918 So much for "single SQL with 0 lines of backend code" when you have "weird joins that we won't optimise for, and sooner or later there will be determined DDoSers who will figure it out" > The magical database tool is a simple and comprehensible example (but still is brilliant in how well it works). Yeah, this magical tool is only a tool, that works with a single database, for a single set of problems, and has to be constantly fine-tuned because you can't optimise ad-hoc queries. But yeah, dismiss all that and just shout to the world: "REST sucks, GraphQL is so much better because we have this one single tool". The moment you step outside the limitations of that tool, you're screwed. But you haven't reached that point yet, so you consider yourself "competent". > The bottom line is that if dev team is capable of working with graphql, it’s just a better choice. This still has to be empirically proven by anyone without magical handwaving and dismissing any issues.