6 ms·

Yes, it can and often will. That’s the point.

by lyxsus 6y ago

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

Yes, it can and often will. That’s the point.

by lyxsus 6y ago

Yes, it can and often will. That’s the point.

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