4 ms·

Ok, so you've failed to provide an example, I'll make you a big favour just this time. > If you need to get user, then 5 of his posts, then 50 of comments for

by lyxsus 6y ago

Ok, so you've failed to provide an example, I'll make you a big favour just this time. > If you need to get user, then 5 of his posts, then 50 of comments for each post That was the original database structure, right? So we assume there're 3 tables, related by FK, right? Now let's take a "magic" tool. It wasn't specified, which one or what db is used, so I'll take "postgraphile" and assume it's a Postgres. No problem here, right? Now if I as an absolutely naive person, will run "postgraphile" and point it to my database schema, it will generate respective types and mutations, pretty much usable from the beginning. No problem here, right? Now let's say I add an extra field to db schema to any table. Oh, dear, do I need to write a code? Let's try to restart it. Boom, it works. Right? Need something more complex? Create a stored sql function (x: users|post|comment) => T that maps the data you need, restart a service and query your new field from your updated gql schema. ffs, read before you write.

stale2002 6y ago
Alright.... now what if I were to tell you that most applications that use graphql are not using, or going to use, some singular magic tool, and therefore it does not get rid of all backend work, regarding adding new fields, for most applications? So therefore, it is not applicable, for most applications, and the original comment was correct.
- lyxsus 6y ago
  Amazing. Original comment I've reacted to: > Yeah, right. Because that SQL query will just magically write itself. Oh, just did, sorry > Especially if that ad-hoc GraphQL query requests extra fields Just did, whoops parent comment: > GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. Just did, ha-ha! Does it allow it? Yes, just as illustrated. > I were to tell you that most applications that use graphql are not using, or going to use, some singular magic tool That's not relevant and you know it. > So therefore, it is not applicable, for most applications, and the original comment was correct. Critical logic error, no intelligent lifeforms detected.
  - stale2002 6y ago
    > That's not relevant and you know it. It is pretty relevant actually. Because, as the original poster stated "Just because you stumbled across a single application server that can do that doesn't mean it's true for GraphQL in general." In general, when talking about most graphql applications, that people use, the original statement is true. So the original statement is true, for most people. Which was the other person's point. I'd note once again that the statement was "in general". Usually, when discussing large frameworks, and technical issues, that effect many people, we are mostly concerned with how it applies to the vast majority of people and applications.
    - lyxsus 6y ago
      In general. In general what? You can't take an advantage of having an abundant amount of data about data sources, schema and query you're about to execute (in general)? The original example simply illustrates that if you have the right problem and understand it well, you can work on it a bit and make it look like magic. It says "G has some property, that lets us do X to solve problem Y", to what the other guys says "No, G doesn't have these properties, because you can't apply X to solve Z. And W." How dumb is that? It's not an alternative to SQL in general and it's not a drop-in replacement for backend. Do you realise, that I can run graphql entirely in browser and make resolvers call the same rest api? That'll work pretty well. Or that also looks too problematic? > we are mostly concerned with how it applies to the vast majority of people and applications Applications – yes, people – no. In last couple of years I saw a few dozens implementations of graphql on a backend and I think only 2-3 were really good. The rest is usually a complete clusterfuck and I wish they didn't use it and never touched it. But that's also true for too many other things. So maybe you're right. Maybe if somebody realises that his competence isn't enough, it's better to stay away.
      - stale2002 6y ago
        > It's not an alternative to SQL in general and it's not a drop-in replacement for backend Oh, awesome! So then you agree with the original commentary then, that we cannot just replace all this with "0 lines written by a backend developer". Great.

by lyxsus 6y ago

stale2002 6y ago

Alright.... now what if I were to tell you that most applications that use graphql are not using, or going to use, some singular magic tool, and therefore it does not get rid of all backend work, regarding adding new fields, for most applications? So therefore, it is not applicable, for most applications, and the original comment was correct.

lyxsus 6y ago
Amazing. Original comment I've reacted to: > Yeah, right. Because that SQL query will just magically write itself. Oh, just did, sorry > Especially if that ad-hoc GraphQL query requests extra fields Just did, whoops parent comment: > GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. Just did, ha-ha! Does it allow it? Yes, just as illustrated. > I were to tell you that most applications that use graphql are not using, or going to use, some singular magic tool That's not relevant and you know it. > So therefore, it is not applicable, for most applications, and the original comment was correct. Critical logic error, no intelligent lifeforms detected.
- stale2002 6y ago
  > That's not relevant and you know it. It is pretty relevant actually. Because, as the original poster stated "Just because you stumbled across a single application server that can do that doesn't mean it's true for GraphQL in general." In general, when talking about most graphql applications, that people use, the original statement is true. So the original statement is true, for most people. Which was the other person's point. I'd note once again that the statement was "in general". Usually, when discussing large frameworks, and technical issues, that effect many people, we are mostly concerned with how it applies to the vast majority of people and applications.
  - lyxsus 6y ago
    In general. In general what? You can't take an advantage of having an abundant amount of data about data sources, schema and query you're about to execute (in general)? The original example simply illustrates that if you have the right problem and understand it well, you can work on it a bit and make it look like magic. It says "G has some property, that lets us do X to solve problem Y", to what the other guys says "No, G doesn't have these properties, because you can't apply X to solve Z. And W." How dumb is that? It's not an alternative to SQL in general and it's not a drop-in replacement for backend. Do you realise, that I can run graphql entirely in browser and make resolvers call the same rest api? That'll work pretty well. Or that also looks too problematic? > we are mostly concerned with how it applies to the vast majority of people and applications Applications – yes, people – no. In last couple of years I saw a few dozens implementations of graphql on a backend and I think only 2-3 were really good. The rest is usually a complete clusterfuck and I wish they didn't use it and never touched it. But that's also true for too many other things. So maybe you're right. Maybe if somebody realises that his competence isn't enough, it's better to stay away.
    - stale2002 6y ago
      > It's not an alternative to SQL in general and it's not a drop-in replacement for backend Oh, awesome! So then you agree with the original commentary then, that we cannot just replace all this with "0 lines written by a backend developer". Great.