5 ms·

I don't feel like I want to agree with that part, sorry. But I can admit I'm wrong if I had a counter-example relevant to that toy example. I'm very confused o

by lyxsus 6y ago

I don't feel like I want to agree with that part, sorry. But I can admit I'm wrong if I had a counter-example relevant to that toy example. I'm very confused on where you're going to with that. > Because that SQL query will just magically write itself Do we have any disagreement on whenever we can have a full computer-generated query for the case where there're a few tables connected by FKs which is not worse than anything a human could write? If not, can I have some hint on why?

stale2002 6y ago
You do not agree with the idea that it definitely requires more than "0 lines written by a backend developer" for most graphql applications to do something like support "ad-hoc GraphQL query requests extra fields" Really? You actually don't agree with that? You think that graphql is setup in such a way for most services, that it add "extra fields" to a backend service endpoint, that was not returning those "extra fields" in it before, and that it would require zero lines of backend code in most applications to add those extra fields to a backend endpoint, that was not returning those extra fields before?
- lyxsus 6y ago
  No, because then I won't get anything from this conversation. Please, tell me, what else can I say to make you use a practical illustration of your position constructed on top of original example? I believe it's the only form of productive communication left that is possible in current context.
  - stale2002 6y ago
    > No So you think that graphql, for most applications, magically allows you to request an "extra fields" from a backend service, with zero backend work, that was not previously returning though fields? Really? > use a practical illustration I just told you the illustration. There is an additional field. That does not exist on a backend endpoint. And you think that graphql magically add that field, for most people, to the backend endpoint, with zero backend work? That is a pretty simple and common practical example. Needing a extra field from a backend endpoint, that does not already exist in that backend service. IE, to quote the original post, it would be to support "ad-hoc GraphQL query requests extra fields". IE, an extra field that does not exist in the backend service. That was the original post. And originally you disagreed with the original poster, when they claimed that such a thing would require more than "0 lines of code" on the backend, for most applications.
    - 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.
deleted 6y ago
[deleted]

by lyxsus 6y ago

stale2002 6y ago

You do not agree with the idea that it definitely requires more than "0 lines written by a backend developer" for most graphql applications to do something like support "ad-hoc GraphQL query requests extra fields" Really? You actually don't agree with that? You think that graphql is setup in such a way for most services, that it add "extra fields" to a backend service endpoint, that was not returning those "extra fields" in it before, and that it would require zero lines of backend code in most applications to add those extra fields to a backend endpoint, that was not returning those extra fields before?

lyxsus 6y ago
No, because then I won't get anything from this conversation. Please, tell me, what else can I say to make you use a practical illustration of your position constructed on top of original example? I believe it's the only form of productive communication left that is possible in current context.
- stale2002 6y ago
  > No So you think that graphql, for most applications, magically allows you to request an "extra fields" from a backend service, with zero backend work, that was not previously returning though fields? Really? > use a practical illustration I just told you the illustration. There is an additional field. That does not exist on a backend endpoint. And you think that graphql magically add that field, for most people, to the backend endpoint, with zero backend work? That is a pretty simple and common practical example. Needing a extra field from a backend endpoint, that does not already exist in that backend service. IE, to quote the original post, it would be to support "ad-hoc GraphQL query requests extra fields". IE, an extra field that does not exist in the backend service. That was the original post. And originally you disagreed with the original poster, when they claimed that such a thing would require more than "0 lines of code" on the backend, for most applications.
  - 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.

deleted 6y ago

[deleted]