GraphQL isn't even good tho, I'll never understand why it got so popular. Firstly, the GQL queries are poor. Selecting the `exact` properties you want sounds good in theory, except the 9/10, you're pulling the full property sets from your database; with GQL creating the partial result objects from the full result. There is no optimization from your DB > Server where your Server is asking for these exact properties (fields) which would be a win, but it doesn't do that, and I don't understand why GQL advocates keep ignoring this Secondly, there is no GQL standard for filtering, projection and pagination. Instead GraphQL makes you write something analogous to a 'Function' where the parameters of the function are used to filter, project and paginate data. This doesn't actually solve anything you couldn't already do through a RESTful interface with query parameters. GQL needs some kind of query expression tree representation to do this properly (at least to a level inline with SQL or similar). More often than not, people just make up whatever (as they do for RESTful interfaces) Thirdly, GraphQL invented it's own formats for queries and defining schematics, along with needlessly inventing terms "Mutations" as well as drawing a distinction between read and write operations (even those a query could in theory write, (as would be case with caching a result), so what's the point of the distinction? GQL could used JSON Schema (or hell, even OpenAPI) for it's schematics, and at least tried to be a bit more "aligned" with accepted web standards (as well as making it easier for developers to try and fix it's inadequacies) Seriously, GraphQL is way more popular than it deserves to be. A better technology is OData (which literally solves all the above problems), but I guess the marketing for OData wasn't as good as GraphQL. If I'm being honest tho, OData is only really viable in equipped languages (those that support language integrated query, so C#, Elixir (ecto) and Rust's macro system, and I suppose any LISP). But I just find it surprising people continue to push GraphQL with these "known" issues, when far superior alternatives exist, and have existed well before GraphQL hit the scene.
@@mohammadrezaesmaeilzadeh7317 This isn't what I'm talking about at all. I don't have a problem with GraphQL being POST, I have a problem with it being inadequate as a query system. If a technology advertises itself as a "query language", that technology ought to bring something capable to the table, not some non-standard, propitiatory and ill equipped hacked thing loaded with terms like "mutations" and targeting the lowest common denominator. If you want an example of a capable query look at SQL. If you want an example of a HTTP accessible query language, look at ODATA. GraphQL is popular, but popularity does not mean something is good, it just means it's popular.
@@BinaryReader I was curious about GQL and I want to know how it works, because someone told me that, it's much easier to use GQL than having multiple GET request just to get the data that you need. Although having a lot of GET request is annoying but I did eventually found a solution by using the Server Components of NextJS and having a bunch of multiple async function to get my data using prisma. It is somehow a hack, I think, beacause not so many people that I know of are using those. It just came into my mind and it works for my application. Also, people also told me that you can use GQL to handle mobile app like for android and IOS however, I did not dove into it yet so, It's going to be a mystery Anyways, It's nice reading a constructive comment from time to time and I will look into the potential use of GQL if it is it better or not.
Yeah, I'm looking everywhere through nexus and trying to find a way to pass query parameters through to the prisma-or-whatever-SQL-library's actual query. They are obviously not in parent or args. Ctx (Context) isn't even documented... he just uses ctx.prisma and doesn't even say how it got there. Docs say you just have to do that on your own or your library will add it... huh. But you'd think there would be a typed parameter of what fields were requested. That's so, so very easy to do, yet the creators of this library never thought of it... why? I mean, all you'd need is a 4th parameter, `fields`, that would expose the fields requested and you could pass those to your db query. Dead simple, and here it is 2024 and it's not even available.
It really helped me to choose the right tool with less setup and definition boilerplate, thanks Daniel. Looking forward to see more like this.
GraphQL isn't even good tho, I'll never understand why it got so popular.
Firstly, the GQL queries are poor. Selecting the `exact` properties you want sounds good in theory, except the 9/10, you're pulling the full property sets from your database; with GQL creating the partial result objects from the full result. There is no optimization from your DB > Server where your Server is asking for these exact properties (fields) which would be a win, but it doesn't do that, and I don't understand why GQL advocates keep ignoring this
Secondly, there is no GQL standard for filtering, projection and pagination. Instead GraphQL makes you write something analogous to a 'Function' where the parameters of the function are used to filter, project and paginate data. This doesn't actually solve anything you couldn't already do through a RESTful interface with query parameters. GQL needs some kind of query expression tree representation to do this properly (at least to a level inline with SQL or similar). More often than not, people just make up whatever (as they do for RESTful interfaces)
Thirdly, GraphQL invented it's own formats for queries and defining schematics, along with needlessly inventing terms "Mutations" as well as drawing a distinction between read and write operations (even those a query could in theory write, (as would be case with caching a result), so what's the point of the distinction? GQL could used JSON Schema (or hell, even OpenAPI) for it's schematics, and at least tried to be a bit more "aligned" with accepted web standards (as well as making it easier for developers to try and fix it's inadequacies)
Seriously, GraphQL is way more popular than it deserves to be. A better technology is OData (which literally solves all the above problems), but I guess the marketing for OData wasn't as good as GraphQL. If I'm being honest tho, OData is only really viable in equipped languages (those that support language integrated query, so C#, Elixir (ecto) and Rust's macro system, and I suppose any LISP). But I just find it surprising people continue to push GraphQL with these "known" issues, when far superior alternatives exist, and have existed well before GraphQL hit the scene.
that is because get method (in standard REST) has not any way to send JSON body like post.
@@mohammadrezaesmaeilzadeh7317 This isn't what I'm talking about at all. I don't have a problem with GraphQL being POST, I have a problem with it being inadequate as a query system.
If a technology advertises itself as a "query language", that technology ought to bring something capable to the table, not some non-standard, propitiatory and ill equipped hacked thing loaded with terms like "mutations" and targeting the lowest common denominator.
If you want an example of a capable query look at SQL. If you want an example of a HTTP accessible query language, look at ODATA.
GraphQL is popular, but popularity does not mean something is good, it just means it's popular.
@@BinaryReader I was curious about GQL and I want to know how it works, because someone told me that, it's much easier to use GQL than having multiple GET request just to get the data that you need.
Although having a lot of GET request is annoying but I did eventually found a solution by using the Server Components of NextJS and having a bunch of multiple async function to get my data using prisma.
It is somehow a hack, I think, beacause not so many people that I know of are using those. It just came into my mind and it works for my application. Also, people also told me that you can use GQL to handle mobile app like for android and IOS however, I did not dove into it yet so, It's going to be a mystery
Anyways, It's nice reading a constructive comment from time to time and I will look into the potential use of GQL if it is it better or not.
Yeah, I'm looking everywhere through nexus and trying to find a way to pass query parameters through to the prisma-or-whatever-SQL-library's actual query. They are obviously not in parent or args. Ctx (Context) isn't even documented... he just uses ctx.prisma and doesn't even say how it got there. Docs say you just have to do that on your own or your library will add it... huh. But you'd think there would be a typed parameter of what fields were requested. That's so, so very easy to do, yet the creators of this library never thought of it... why? I mean, all you'd need is a 4th parameter, `fields`, that would expose the fields requested and you could pass those to your db query. Dead simple, and here it is 2024 and it's not even available.