3 ms·
Very interesting topic, actually it's one of my favourite ones. I've been working for the last year or so on the problem to improve type-safety for NextJS. My s
by jensneuse 5y ago
Very interesting topic, actually it's one of my favourite ones.
I've been working for the last year or so on the problem to improve type-safety for NextJS. My solution works like this:
Step 1: introspect your DataSources (Postgres, MySQL, GraphQL, REST, etc...)
Step 2: combine them into a virtual Graph (virtual GraphQL API)
Step 3: write GraphQL Operations and "compile" them into JSON RPC + generate a 100% type-safe client
Result? No more double declaration of types. No manual typing. More info on how this works with NextJS and Typescript here: [0]
Note, I'm the founder of WunderGraph and obsessed with creating the perfect developer experience for working with APIs. I appreciate any feedback.
[0]: https://wundergraph.com/docs/overview/features/generated_clients https://wundergraph.com/docs/overview/features/generated_cli...
- theobr 5y agoThis is super cool and I’m excited to dig in more Any chance there are some demos building a full stack app on this tech?
- jensneuse 5y agoHey, thanks for you feedback. Yes absolutely! Here's an example using Apollo Federation, REST APIs and a standalone GraphQL API: [0] Alternatively, you can also just run "wunderctl init --template nextjs-starter" to start with the NextJS template. (Obviously you need to install it first: yarn global add @wundergraph/wunderctl@latest) We're going open source with this solution soon. So, any feedback is appreciated! You can also join our discord and shoot questions. =) [0]: https://github.com/wundergraph/wundergraph-demo https://github.com/wundergraph/wundergraph-demo
- SlickStef11 5y agoSuper cool! Will be checking out the documentation!
- kansface 5y agoHow do you deal with multiple versions on the back end - like during a migration, or a partial migration, deploy, etc?
- striking 5y agoIf you're using GraphQL, you never make a breaking change (or make that breaking change only after all clients are proven to have stopped requesting the broken field) Tooling exists to prevent you from making this mistake at CI time (comparing your schema with the one currently in production) and ensuring an incompatible change is not made unless explicitly allowed.