5 ms·

The main advantage is that the query is resolved at runtime. It only queries for exactly what your component needs. No over-querying. No sharing queries across

The main advantage is that the query is resolved at runtime. It only queries for exactly what your component needs. No over-querying. No sharing queries across components, which is a huge mistake people make.

golergka 5y ago
> query is resolved at runtime Does it mean that we get errors at runtime and not build time, too?
- SketchySeaBeast 5y ago
  Have you found a way to get build errors with GraphQL queries? I only ever get them during runtime when the request is made, I assume because that's the point at which the back-end and front-end disagree on what you're requesting.
  - potatoz2 5y ago
    If you generate types from your GraphQL queries, they are validated against the schema at that time (so you'd get schema errors then, of course there can still be network errors, server errors or user/semantic errors at runtime)
  - nawgz 5y ago
    Using Typescript,GraphQL-codegen, and Hasura, I can build correct-by-construction React apps. GraphQL-codegen & Hasura introspect the DB to type the query result, and typescript confirms my JS is not accessing any of those fields illegally. It’s pretty killer to open GraphiQL, write a new query, drop it into a graphql file in my repo, rerun the codegen, and be able to have type safe operations on the queried data. Also makes me completely unsure why anyone would want what the OP is but that’s ok
    - atom_arranger 5y ago
      This solution seems to work like this: - Generate type safe client based on your schema. - Access GraphQL properties as if they were just JS object properties. So in this solution the codegen step comes before writing a query. You get the same advantages pretty much, and you have less likelihood of querying for unused data.
- revskill 5y ago
  This part is confusing to me. I prefer this will validate our component for correct schema usage at build time.
  - nwienert 5y ago
    It fully typed, so you get errors at build time.
    - coding123 5y ago
      I think the part that's throwing people off (including me) is if I'm looking at that main example, how do I get type completion on this line: Hello {query.me.name}! query dot me dot name should all have type completion. And in most TS "frameworks" you have some way to type hint this all out. us TS folk are not seeing the type hints in the example. Maybe it works in VSCode like that, but totally confused how it does. Believe me, I'm super interested in this project and it would save a ton of time if it's doing what some of us are hoping :)
      - nwienert 5y ago
        It does autocomplete with types on that line, and yes, it’s really that cool. Disclosure: I funded the development of version 2, and have written a large app using it. I am very happy with it, and believe it’s the best data fetching solution around.
      - atom_arranger 5y ago
        The client is generated from the schema, so “query.me.name” is fully typed.
andrewingram 5y ago
I'd say you're broadly right, the key idea is that your client code has a facade over the fact that you're using GraphQL, so it looks cleaner -- it's "just JavaScript". Whether this is an advantage or not is largely down to preference. The "Why" section in the docs is a pretty good summary: https://gqless.com/intro#why https://gqless.com/intro#why "I wanted a GraphQL client that lets you forget you're using GraphQL, whilst tackling some issues shared across all existing GraphQL clients" The fact that it's resolved at runtime isn't necessarily an advantage, it locks you out of some performance and security patterns. I believe GQLess is investigating support for static extraction of queries at build time. It's an interesting API, I'm not entirely sold on the idea of disguising the fact that you're using GraphQL though.

golergka 5y ago

> query is resolved at runtime Does it mean that we get errors at runtime and not build time, too?

SketchySeaBeast 5y ago
Have you found a way to get build errors with GraphQL queries? I only ever get them during runtime when the request is made, I assume because that's the point at which the back-end and front-end disagree on what you're requesting.
- potatoz2 5y ago
  If you generate types from your GraphQL queries, they are validated against the schema at that time (so you'd get schema errors then, of course there can still be network errors, server errors or user/semantic errors at runtime)
- nawgz 5y ago
  Using Typescript,GraphQL-codegen, and Hasura, I can build correct-by-construction React apps. GraphQL-codegen & Hasura introspect the DB to type the query result, and typescript confirms my JS is not accessing any of those fields illegally. It’s pretty killer to open GraphiQL, write a new query, drop it into a graphql file in my repo, rerun the codegen, and be able to have type safe operations on the queried data. Also makes me completely unsure why anyone would want what the OP is but that’s ok
  - atom_arranger 5y ago
    This solution seems to work like this: - Generate type safe client based on your schema. - Access GraphQL properties as if they were just JS object properties. So in this solution the codegen step comes before writing a query. You get the same advantages pretty much, and you have less likelihood of querying for unused data.
revskill 5y ago
This part is confusing to me. I prefer this will validate our component for correct schema usage at build time.
- nwienert 5y ago
  It fully typed, so you get errors at build time.
  - coding123 5y ago
    I think the part that's throwing people off (including me) is if I'm looking at that main example, how do I get type completion on this line: Hello {query.me.name}! query dot me dot name should all have type completion. And in most TS "frameworks" you have some way to type hint this all out. us TS folk are not seeing the type hints in the example. Maybe it works in VSCode like that, but totally confused how it does. Believe me, I'm super interested in this project and it would save a ton of time if it's doing what some of us are hoping :)
    - nwienert 5y ago
      It does autocomplete with types on that line, and yes, it’s really that cool. Disclosure: I funded the development of version 2, and have written a large app using it. I am very happy with it, and believe it’s the best data fetching solution around.
    - atom_arranger 5y ago
      The client is generated from the schema, so “query.me.name” is fully typed.

andrewingram 5y ago

I'd say you're broadly right, the key idea is that your client code has a facade over the fact that you're using GraphQL, so it looks cleaner -- it's "just JavaScript". Whether this is an advantage or not is largely down to preference. The "Why" section in the docs is a pretty good summary: https://gqless.com/intro#why https://gqless.com/intro#why "I wanted a GraphQL client that lets you forget you're using GraphQL, whilst tackling some issues shared across all existing GraphQL clients" The fact that it's resolved at runtime isn't necessarily an advantage, it locks you out of some performance and security patterns. I believe GQLess is investigating support for static extraction of queries at build time. It's an interesting API, I'm not entirely sold on the idea of disguising the fact that you're using GraphQL though.