7 ms·

> yet since no thought was put into how it might integrate into existing typed languages [...] Says who? > [...] its actually surprisingly difficult to build

by 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/
    - chpmrc 4y ago
      This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL. At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I absolutely agree with you: raw GraphQL doesn't make any sense, the same way raw SQL (in 2022) doesn't make sense either. EDIT (mandatory before I get lynched lol): except in cases where the wrapper builds a query that is inefficient or should be tweaked manually.
      - spion 4y ago
        > I've never written a GraphQL scema or query by hand, always used a good wrapper Could you give me an example of a good client wrapper that doesn't require you to write queries as strings?
        valenterry 4y ago
        Not sure if you consider it "good" but I've used this one quite successfully: https://ghostdogpr.github.io/caliban/docs/client.html#query-building https://ghostdogpr.github.io/caliban/docs/client.html#query-...
        spion 4y ago
        Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem. To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder (https://typed-graphql-builder.spion.dev/ https://typed-graphql-builder.spion.dev/) and I can think of several ways the language could've been designed to make it easier to write typed query builders. This is not without consequences - since its quite hard to write the builder, most tools available for code generation (https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/) are built around editing GraphQL strings and will try to find them in your code and add type assertions. Additionally the rest of the ecosystem tools are built around supporting this workflow (graphql playgrund, etc)
- chpmrc 4y ago
  I'm not familiar with LINQ and even though it might be a good solution we're not debating GraphQL vs LINQ (which, as far as I can tell, is specific to C#, at least its reference implementation), I'm questioning your "string is bad" statement which, IMHO, doesn't make any sense.

by chpmrc 4y ago

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/
  - chpmrc 4y ago
    This is just a wrapper for SQL, every language has one. The same is true for GraphQL, I've never written a GraphQL scema or query by hand, always used a good wrapper that handled all the type safety I needed. Constructing GQL queries manually is the equivalent of doing it with SQL. At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I absolutely agree with you: raw GraphQL doesn't make any sense, the same way raw SQL (in 2022) doesn't make sense either. EDIT (mandatory before I get lynched lol): except in cases where the wrapper builds a query that is inefficient or should be tweaked manually.
    - spion 4y ago
      > I've never written a GraphQL scema or query by hand, always used a good wrapper Could you give me an example of a good client wrapper that doesn't require you to write queries as strings?
      - valenterry 4y ago
        Not sure if you consider it "good" but I've used this one quite successfully: https://ghostdogpr.github.io/caliban/docs/client.html#query-building https://ghostdogpr.github.io/caliban/docs/client.html#query-...
        spion 4y ago
        Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem. To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder (https://typed-graphql-builder.spion.dev/ https://typed-graphql-builder.spion.dev/) and I can think of several ways the language could've been designed to make it easier to write typed query builders. This is not without consequences - since its quite hard to write the builder, most tools available for code generation (https://www.graphql-code-generator.com/ https://www.graphql-code-generator.com/) are built around editing GraphQL strings and will try to find them in your code and add type assertions. Additionally the rest of the ecosystem tools are built around supporting this workflow (graphql playgrund, etc)
chpmrc 4y ago
I'm not familiar with LINQ and even though it might be a good solution we're not debating GraphQL vs LINQ (which, as far as I can tell, is specific to C#, at least its reference implementation), I'm questioning your "string is bad" statement which, IMHO, doesn't make any sense.