6 ms·

Omg, that’s clearly a trolling :) Or you’re really just talking to yourself.

by lyxsus 6y ago

stale2002 6y ago
No it is not. It sounds like you agree with the original person, on the specific point 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.". Great. You are in agreement with him on that specific point.
- 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.
- lyxsus 6y ago
  He’s trying to make it like I believe in magic. Like I’m saying long live the backend job. Hell no, but it lets you to work with arguably better abstractions. And that posthraphile didn’t appear from thin air, it’s not a part of graphql, somebody wrote it.

Omg, that’s clearly a trolling :) Or you’re really just talking to yourself.

by lyxsus 6y ago

Omg, that’s clearly a trolling :) Or you’re really just talking to yourself.

stale2002 6y ago

No it is not. It sounds like you agree with the original person, on the specific point 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.". Great. You are in agreement with him on that specific point.

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.
lyxsus 6y ago
He’s trying to make it like I believe in magic. Like I’m saying long live the backend job. Hell no, but it lets you to work with arguably better abstractions. And that posthraphile didn’t appear from thin air, it’s not a part of graphql, somebody wrote it.