4 ms·

> If you just need to get one user object, it's not different from rest. So then in this specific example, you agree that definitely it is not different than r

by stale2002 6y ago

> If you just need to get one user object, it's not different from rest. So then in this specific example, you agree that definitely it is not different than rest, and we cannot solve these problems "with 0 lines written by backend developer." then? Cool. Awesome. You agree with the person you responded to on that specific issue. To be even more specific, it seems like you agree that it would not require "0 lines written by a backend developer" in order to do something like "taps into data that' only available from an external service etc.". > you need the data, you have to get the data Thats great that you agree with the other person that it does not require "0 lines" in order to do something like "taps into data that' only available from an external service etc.". > But that doesn't change the fact that client needs data Awesome. So then you agree with the person you are responding to, that you cannot, with "0 lines written by a backend developer" 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
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?
  - 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.

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