4 ms·

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap becaus

by chpmrc 4y ago

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There are plenty of good GraphQL libraries that make writing queries/mutations and the whole schema a breeze. I've been using graphene for Python for a couple of years and, although it has some rough edges, it's actually pretty decent. And GraphQL is quite a good mental model to work with that both backend and frontend can share. <rant>Honestly I'm getting tired of seeing these comments on HN, it's the same for Kubernetes or other technologies. Often written by someone who didn't take the time to actually study and understand the tech and use it for actual projects. Often with no data to back it up whatsoever. The quality of posts and comments here used to be a lot higher but it's slowly turning into a plaintext version of dev.to </rant>

endisneigh 4y ago
Yeah, if you use something like Postgres and Hasura for a new project it's pretty simple. I doubt you could make a REST API much easier. Django + Django Admin is close, but that's not really an equivalent per se.
spion 4y ago
The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it. And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At least with SQL we have a reasonably good way to model it with methods (see LINQ). LINQ was built 15 years ago, so this problem was well understood back then.
- chpmrc 4y ago
  > yet since no thought was put into how it might integrate into existing typed languages [...] Says who? > [...] its actually surprisingly difficult to build a type-safe API around it. Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs based on examples of what JSON each endpoint might output? > And yes, SQL is "bad" because you write query strings Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.
  - spion 4y ago
    > Says who? Says me, and also any other person that has tried to build a type-safe GraphQL query builder > Consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to watch your query strings to generate the right types for them? > Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point. Instead of arguing, why not look at what LINQ does? For the best experience, you should probably try them with an editor/compiler: https://github.com/dotnet/try-samples#basics https://github.com/dotnet/try-samples#basics
    - valenterry 4y ago
      It would be helpful if you actually explain how LINQ does it better.
      - spion 4y ago
        LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc. Examples: https://www.c-sharpcorner.com/article/writing-complex-queries-using-linq-and-lambda https://www.c-sharpcorner.com/article/writing-complex-querie... The hard bit here is making sure the language type-checker is fully aware of the involved types, both while writing the query as well as while selecting the results to be returned This approach has since been copied in more capable languages. One of my favorite examples lately is Rust's Diesel: https://diesel.rs/ https://diesel.rs/ (see the "complex queries") example. A query language designer aware of the above lessons learned with SQL might take special care to ensure their new query language is easier to model in existing languages. For example, they might consider an alternative OOP or FP based syntax, or to generalize they might put some thought into what would make it easy to write a type-safe query builder. After all, while SQL was developed in 197x and we had a different model for data access early on (stored procedures instead of flexible language-integrated queries) so its easier to understand that we didn't consider integration with other languags. TypeScript already did exist when GraphQL first appeared in 2015, and it's been 7 years of LINQ at that point. Yet, we still went the stored procedures route. Tools such as graphql-codegen [1] require you to regenerate your types every time you edit your query strings [1]: https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/
jwr 4y ago
> That's like saying SQL is crap because you need to build queries by hand If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.
- zokier 4y ago
  https://graphql.org/learn/queries/#variables https://graphql.org/learn/queries/#variables ?
- chpmrc 4y ago
  Calling SQL crap just because there's a way to abuse it is like saying C is crap because I could do `int * userGuess = get_number_from_user(); * userGuess;` with nothing more than a compiler warning (if I'm lucky). Would be nice if we all stopped with these blanket statements and just focused on evaluating individual pros/cons of things. EDIT: formatting of pointer
oznog 4y ago
> The quality of posts and comments here used to be a lot higher but it's slowly turning into a [..] You can go on with your GraphQL, Kubernetes, gigantic frameworks, and pages with 3MB of JS if you want. And let's see what stands the test of time.
- chpmrc 4y ago
  Well, GraphQL aside I've been using the same stack for almost ten years and it's only becoming more and more popular so I'd say I'm doing pretty well in terms of choosing the tech, thanks for your concern though!

by chpmrc 4y ago

endisneigh 4y ago

Yeah, if you use something like Postgres and Hasura for a new project it's pretty simple. I doubt you could make a REST API much easier. Django + Django Admin is close, but that's not really an equivalent per se.

spion 4y ago

The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it. And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At least with SQL we have a reasonably good way to model it with methods (see LINQ). LINQ was built 15 years ago, so this problem was well understood back then.

chpmrc 4y ago
> yet since no thought was put into how it might integrate into existing typed languages [...] Says who? > [...] its actually surprisingly difficult to build a type-safe API around it. Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs based on examples of what JSON each endpoint might output? > And yes, SQL is "bad" because you write query strings Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.
- spion 4y ago
  > Says who? Says me, and also any other person that has tried to build a type-safe GraphQL query builder > Consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to watch your query strings to generate the right types for them? > Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point. Instead of arguing, why not look at what LINQ does? For the best experience, you should probably try them with an editor/compiler: https://github.com/dotnet/try-samples#basics https://github.com/dotnet/try-samples#basics
  - valenterry 4y ago
    It would be helpful if you actually explain how LINQ does it better.
    - spion 4y ago
      LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc. Examples: https://www.c-sharpcorner.com/article/writing-complex-queries-using-linq-and-lambda https://www.c-sharpcorner.com/article/writing-complex-querie... The hard bit here is making sure the language type-checker is fully aware of the involved types, both while writing the query as well as while selecting the results to be returned This approach has since been copied in more capable languages. One of my favorite examples lately is Rust's Diesel: https://diesel.rs/ https://diesel.rs/ (see the "complex queries") example. A query language designer aware of the above lessons learned with SQL might take special care to ensure their new query language is easier to model in existing languages. For example, they might consider an alternative OOP or FP based syntax, or to generalize they might put some thought into what would make it easy to write a type-safe query builder. After all, while SQL was developed in 197x and we had a different model for data access early on (stored procedures instead of flexible language-integrated queries) so its easier to understand that we didn't consider integration with other languags. TypeScript already did exist when GraphQL first appeared in 2015, and it's been 7 years of LINQ at that point. Yet, we still went the stored procedures route. Tools such as graphql-codegen [1] require you to regenerate your types every time you edit your query strings [1]: https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/

jwr 4y ago

> That's like saying SQL is crap because you need to build queries by hand If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.

zokier 4y ago
https://graphql.org/learn/queries/#variables https://graphql.org/learn/queries/#variables ?
chpmrc 4y ago
Calling SQL crap just because there's a way to abuse it is like saying C is crap because I could do `int * userGuess = get_number_from_user(); * userGuess;` with nothing more than a compiler warning (if I'm lucky). Would be nice if we all stopped with these blanket statements and just focused on evaluating individual pros/cons of things. EDIT: formatting of pointer

oznog 4y ago

> The quality of posts and comments here used to be a lot higher but it's slowly turning into a [..] You can go on with your GraphQL, Kubernetes, gigantic frameworks, and pages with 3MB of JS if you want. And let's see what stands the test of time.

chpmrc 4y ago
Well, GraphQL aside I've been using the same stack for almost ten years and it's only becoming more and more popular so I'd say I'm doing pretty well in terms of choosing the tech, thanks for your concern though!