What’s the difference between this and react relay, which generates typescript types for Graphql queries?
I replied below
Show HN: Game Changing Typed GraphQL
11–19 of 19 posts
Re: Show HN: Game Changing Typed GraphQL
#12https://hasura.io/blog/your-guide-to-graphql-with-typescript... So I guess this is a recommended option from Hasura to generate typed API bindings; I was going to try following that tutorial at some point, looks pretty slick. Am I understanding correctly that this tool works with something like Hasura (GraphQL backend) to generate an API schema / query client that can be used with something like react-query to retrie…
yes
Re: Show HN: Game Changing Typed GraphQL
#13Not a fan of uselessly sensational titles, but will give it a try. Currently using urql and codegen that already handle that pretty well. What is your edge?
I plan to integrate urql. I generate the whole lib with complicated generic types, so you don't have to write gql queries and run codegen. Just generate once and write interactive queries. No watching and stuff
Any time horizon ? 1 year ? 6 months ?
Re: Show HN: Game Changing Typed GraphQL
#14Re: Show HN: Game Changing Typed GraphQL
#15Earlier quoted context omitted.
I replied below
Where?
above now :). I can do it again. Zeus allows you to generate client library from schema - not from queries. Then you can write queries in TS, you will receive:
- typed args
- typed response
It also offers selectors from which you can create typings for your response objects if you are persisting those somewhere in state, so yeah it is a game changer not only for GraphQL, but for communication with backend and Frontend developer experience.
To be honest it has also some cons, for example: - variables are custom implementation and don't have typings as for now - some edge cases are not supported yet
Here are full docs: https://zeus.graphqleditor.com/
Re: Show HN: Game Changing Typed GraphQL
#16Earlier quoted context omitted.
I plan to integrate urql. I generate the whole lib with complicated generic types, so you don't have to write gql queries and run codegen. Just generate once and write interactive queries. No watching and stuff
Any time horizon ? 1 year ? 6 months ?
Dunno, if you ping me I can do next week
Re: Show HN: Game Changing Typed GraphQL
#17Something I’ve been wondering: does graphQL Zeus increase code size as schema grows? I get that there’s a constant code size for the package, but I’m running on cloudflare workers for some processes, and scripts have a limit of 1MB. I’m using Hasura, so the gql schema is quite large. I’d like to switch over to Zeus for typings, but I’m worried it’ll push me over the 1MB limit.
Re: Show HN: Game Changing Typed GraphQL
#18Something I’ve been wondering: does graphQL Zeus increase code size as schema grows? I get that there’s a constant code size for the package, but I’m running on cloudflare workers for some processes, and scripts have a limit of 1MB. I’m using Hasura, so the gql schema is quite large. I’d like to switch over to Zeus for typings, but I’m worried it’ll push me over the 1MB limit.
how big is your schema then? Of course code grows as schema grows as it is translated to TS. However productivity boost is huge.
If you want to use it with bigger than 1mb schemas create an issue , maybe we can split it to more files if that works for this limit
Re: Show HN: Game Changing Typed GraphQL
#19Something I’ve been wondering: does graphQL Zeus increase code size as schema grows? I get that there’s a constant code size for the package, but I’m running on cloudflare workers for some processes, and scripts have a limit of 1MB. I’m using Hasura, so the gql schema is quite large. I’d like to switch over to Zeus for typings, but I’m worried it’ll push me over the 1MB limit.
how big is your schema then? Of course code grows as schema grows as it is translated to TS. However productivity boost is huge. If you want to use it with bigger than 1mb schemas create an issue , maybe we can split it to more files if that works for this limit
Not sure about “of course” - TS gets erased at runtime, so while “of course” it’ll increase the pre-compiled code size, it’s not so easy post compile.
If you weren’t aware, you can’t run TS directly - you have to compile it to JS for execution