3 ms·

But that’s absolutely not what the original example was showing. It was showing that even an dumb tool can do cool tricks on simple tasks. And that’s because yo

by lyxsus 6y ago

But that’s absolutely not what the original example was showing. It was showing that even an dumb tool can do cool tricks on simple tasks. And that’s because you have an abundance of information about query and schema, so you can possibly do a more high-level reasoning about how to fulfill it. There’re design flaws, but the direction is most promising.

stale2002 6y ago
It is still not really clear because you haven't really said yes or no. But I am going to take a guess and say that you agree that: it definitely requires more than "0 lines written by a backend developer" to do something like "taps into data that' only available from an external service etc."? This is a yes or no question here. It should be pretty simple. Just say yes or no. Since you keep misdirection though, I am going to assume that the answer is Yes, you agree with this original statement. > Like I’m saying long live the backend job So then you agree that it require more than "0 lines written by a backend developer" to do something like "taps into data that' only available from an external service etc.". Awesome. You agree with this statement.
- lyxsus 6y ago
  I was talking about the example originally provided, that had no data tapping with external services. That was a detail added by the guy I was replying to. idk why he decided it’s relevant there. If you want my yes or no answer, on is there an out-of-a-box solution for querying external services, then probably not. There can be, for some use cases, but I never researched them. And that’s actually not a bad idea to have some generic kick-in lib for that. So here, you have it. I hope you understand that my issue is with the person who’s currently very busy with coming up with the infinitely recursive graphql query.
  - stale2002 6y ago
    > then probably not. Alright, cool. So then you agree with that statement. Got it. Great. You are in agreement! Furthermore, when you made this statement "Like I’m saying long live the backend job", it also is in agreement that there is definitely more than 0 backend lines required to solve something such as "if that ad-hoc GraphQL query requests extra fields", as that person originally stated.
    - 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.

by lyxsus 6y ago

stale2002 6y ago

It is still not really clear because you haven't really said yes or no. But I am going to take a guess and say that you agree that: it definitely requires more than "0 lines written by a backend developer" to do something like "taps into data that' only available from an external service etc."? This is a yes or no question here. It should be pretty simple. Just say yes or no. Since you keep misdirection though, I am going to assume that the answer is Yes, you agree with this original statement. > Like I’m saying long live the backend job So then you agree that it require more than "0 lines written by a backend developer" to do something like "taps into data that' only available from an external service etc.". Awesome. You agree with this statement.

lyxsus 6y ago
I was talking about the example originally provided, that had no data tapping with external services. That was a detail added by the guy I was replying to. idk why he decided it’s relevant there. If you want my yes or no answer, on is there an out-of-a-box solution for querying external services, then probably not. There can be, for some use cases, but I never researched them. And that’s actually not a bad idea to have some generic kick-in lib for that. So here, you have it. I hope you understand that my issue is with the person who’s currently very busy with coming up with the infinitely recursive graphql query.
- stale2002 6y ago
  > then probably not. Alright, cool. So then you agree with that statement. Got it. Great. You are in agreement! Furthermore, when you made this statement "Like I’m saying long live the backend job", it also is in agreement that there is definitely more than 0 backend lines required to solve something such as "if that ad-hoc GraphQL query requests extra fields", as that person originally stated.
  - 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.