lol, no. but nice cherry-picking, btw. too bad the original (and unedited) post is still available.
# part 1
Let me break it down for you:
> (This example is pretty silly, but I have very similar and not silly examples that I just can't share because of respect for my employer's NDA).
So that's an example, an illustration. Like a metaphor, it works if other person is willing to communicate. It doesn't work if you cut and stretch it to fit your agenda. That's not an object of discussion, it is a pointer. Ok?
> If you just need to get one user object, it's not different from rest.
That simply says if you need some data, you have to get some that data. That statement is correct no matter what protocol you use. What would you do in rest, btw? Have a single endpoint, where you're trying to make a guess about what's the structure of this data would be? Having separate endpoints and have client cycle them to get what he needs? Limit his ability to traverse domain schema? In my opinion, these are f-off solutions. Because you're basically saying, that's the structure I know how to optimise on a backend, live with it. Look, it works great! What does it matter that you can't efficiently get your data? Not my problem, see, each of my endpoint is fast and simple.
> If you need to get user, then 5 of his posts, then 50 of comments for each post and then 100 reactions for each post, all connected by IDs in your DB, GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer.
Yes, yes. That's exactly what will effectively work for that toy example. You actually can do that. Now, of course real-life is much more complicated and even if you're going to map gql to database, you don't want to map its structure as-is. It could be an interesting conversation on how to do that, but unfortunately, it's not.
But back on track, I believe the idea behind the quoted sentence is to illustrates, that you can do it, you can optimise a sequential and hierarchical query if that's possible. And in more complex cases, because you have a lot of information statically available and at query time you have a full structured query, you can know ahead its complexity and you know exactly what resolvers can be possibly executed to resolve the query. That gives you options:
1. Dumb and naive. Just call each resolver separately. That probably mirrors what would happen in rest. Because I'll repeat myself once again: you need the data, you have to get the data. In terms of transferring, transformation and querying, there should be zero difference.
2. A slightly smarter one. You can compose certain resolvers by grouping requests of same edges. That's fairly easy and should I explain why it's better than trying to do the same thing using rest, probably relying on intricacies of some query language a wise backend developer invented to solve a solved problem?
3. You can optimise for requests patterns. Yeah, that's right. You know that in order to satisfy gql client for such and such use-case, it needs certain data. So instead of making a separate endpoint with arbitrary degrees of freedom, you can have a better, cooler resolver that will perform your complex, which is exactly what you need. And if client requirement changes, he can extend that query and your optimised resolver will now work as a scaffold and additional resolvers will run on unexpected leafs. Which, again, you can optimise if you'll need. But that doesn't change the fact that client needs data. And he'll get it'll certainly get it anyway.
Now a reasonable combinations of these 3 options are required in reality. But that toy problem in topic illustrates exactly that: you can have a nice computer-assisted solution. And I don't think anybody doubt that in this particular case computer can generate a query almost as good as an average backend dev with "with 0 lines written by backend developer.".
> 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.
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.
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.
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.".
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
> 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.
Why don’t you just quote the word “by”? I agree with the word “by”. I fully support it and appreciate how precise and representative it is with respect to the topic. Thank you for walking that path with me, I am defeated by your debating skills and have no hope to recover.
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.
# part 1 Let me break it down for you:
> (This example is pretty silly, but I have very similar and not silly examples that I just can't share because of respect for my employer's NDA). So that's an example, an illustration. Like a metaphor, it works if other person is willing to communicate. It doesn't work if you cut and stretch it to fit your agenda. That's not an object of discussion, it is a pointer. Ok?
> If you just need to get one user object, it's not different from rest. That simply says if you need some data, you have to get some that data. That statement is correct no matter what protocol you use. What would you do in rest, btw? Have a single endpoint, where you're trying to make a guess about what's the structure of this data would be? Having separate endpoints and have client cycle them to get what he needs? Limit his ability to traverse domain schema? In my opinion, these are f-off solutions. Because you're basically saying, that's the structure I know how to optimise on a backend, live with it. Look, it works great! What does it matter that you can't efficiently get your data? Not my problem, see, each of my endpoint is fast and simple.
> If you need to get user, then 5 of his posts, then 50 of comments for each post and then 100 reactions for each post, all connected by IDs in your DB, GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. Yes, yes. That's exactly what will effectively work for that toy example. You actually can do that. Now, of course real-life is much more complicated and even if you're going to map gql to database, you don't want to map its structure as-is. It could be an interesting conversation on how to do that, but unfortunately, it's not. But back on track, I believe the idea behind the quoted sentence is to illustrates, that you can do it, you can optimise a sequential and hierarchical query if that's possible. And in more complex cases, because you have a lot of information statically available and at query time you have a full structured query, you can know ahead its complexity and you know exactly what resolvers can be possibly executed to resolve the query. That gives you options: 1. Dumb and naive. Just call each resolver separately. That probably mirrors what would happen in rest. Because I'll repeat myself once again: you need the data, you have to get the data. In terms of transferring, transformation and querying, there should be zero difference. 2. A slightly smarter one. You can compose certain resolvers by grouping requests of same edges. That's fairly easy and should I explain why it's better than trying to do the same thing using rest, probably relying on intricacies of some query language a wise backend developer invented to solve a solved problem? 3. You can optimise for requests patterns. Yeah, that's right. You know that in order to satisfy gql client for such and such use-case, it needs certain data. So instead of making a separate endpoint with arbitrary degrees of freedom, you can have a better, cooler resolver that will perform your complex, which is exactly what you need. And if client requirement changes, he can extend that query and your optimised resolver will now work as a scaffold and additional resolvers will run on unexpected leafs. Which, again, you can optimise if you'll need. But that doesn't change the fact that client needs data. And he'll get it'll certainly get it anyway. Now a reasonable combinations of these 3 options are required in reality. But that toy problem in topic illustrates exactly that: you can have a nice computer-assisted solution. And I don't think anybody doubt that in this particular case computer can generate a query almost as good as an average backend dev with "with 0 lines written by backend developer.".