vektah

graphql is just one representation of your applications data, it shouldn't dictate your models.

I'm thinking about adding something that generates a model if it doesn't exist, but after its generated it becomes the users problem to keep it in sync.

> recipe for mistakes and drift between the schemas and those types.

The type system enforces there is no drift, it won't compile if its not perfect.

I explored going type first before writing this and you could get pretty close.

The details get hard though, how do you represent unions vs enums? even knowing what implements an interface? default arguments? directives?

I think its still pretty early days, the easy stuff is fine. Once you throw in data loading or subscriptions you quickly run out of docs or find that its just flat out unsupported.

I'm hoping to change that though :)

Yeah, it takes your schema and your models and generates as much of the resolver graph as it can, then leaves you with an interface to implement for the bits it cant (usually trips back to the db).

Yeah, would be more for existing apps that already have a bunch of domain logic.