You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the GraphQL schema is linked to a URL (roundest-go.fly.dev/graphql), however it's preferable to have explicit schemas to then codegen the Go types, and general reproduction of the project not having to rely on deployed data.
My current intent is to reverse engineer the current schema so that the project doesn't rely on a deployed schema - although it could also be reversed engineered from the Go-backend code - to then tie in gql.tada (sources: Theo, and Fireship) for codegen, types, and syntax highlighting. These were the main pain points Theo mentioned on his video of these versions.
The text was updated successfully, but these errors were encountered:
Marcial1234
changed the title
[GraphQL-versions] Provide explicit schema file
[go-graphql-spa-version] Provide explicit schema file
Nov 16, 2024
I do believe Theo's frustration with GraphQL field asserts can be mitigated using qgl.tada as asserting every schema field (e.g. [Foo!]!), as it uses a tsconfig plugin and LSP for type safety. However, the code savings are negligible (I implemented it but decided not to include it in the above PR). In Theo's gql.tada video itself it also included syntax highlighting for "unused" field, but couldn't replicate it. This method might have saved him frustration with his current codegen approach.
Code Gen in go is possible, but to have DB annotations it'd require extra config (if using https://github.com/99designs/gqlgen per LLMs suggestions) that's equivalent to the hard-coded typings. With graphql-codegen-go they auto populate code similar to the current go-structs, but they auto gen many all possible types that aren't used which will increase the "LOC" metric.
Currently the GraphQL schema is linked to a URL (roundest-go.fly.dev/graphql), however it's preferable to have explicit schemas to then codegen the Go types, and general reproduction of the project not having to rely on deployed data.
My current intent is to reverse engineer the current schema so that the project doesn't rely on a deployed schema - although it could also be reversed engineered from the Go-backend code
- to then tie in.gql.tada
(sources: Theo, and Fireship) for codegen, types, and syntax highlighting. These were the main pain points Theo mentioned on his video of these versionsThe text was updated successfully, but these errors were encountered: