5 ms·

How would you represent more complex types? It would work fine if your models are flat and containing only POD, but if it contains something like GeoJSON (from

How would you represent more complex types? It would work fine if your models are flat and containing only POD, but if it contains something like GeoJSON (from Postgres for example), it would be pretty difficult to ensure that the serialization works properly.

013a 9y ago
I'd imagine any decent library would provide an escape hatch around the codegen, so you can specify your own types if you'd like. The other option is to only write the Go types, then use codegen to generate the GraphQL schemas. In a way, I prefer this because it keeps everything in the same language, using all of the great tooling Go has. There is some prior art for this; the Juniper [1] Rust library. [1] https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper
- sorenbs 9y ago
  It's worth keeping in mind that GraphQL often finds itself in organisations that use multiple languages. A trend we have seen starting to emerge over the last 6 months is that backend teams write core business logic in languages like Java or Python and want to expose this as GraphQL microservices. Then you either have a central team responsible for the public GraphQL API. They will typically write a server in Javascript that composes all the microservices. Or alternatively you have multiple product teams that all want separate GraphQL APIs tailored to their use case. They too typically use Javascript for the server. When multiple languages are involved it turns out to be really useful to be able to use GraphQL SDL as the canonical representation and use code-gen on each stack. This is the use case GraphQL binding is intended for: https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding
- vektah 9y ago
  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?

013a 9y ago

I'd imagine any decent library would provide an escape hatch around the codegen, so you can specify your own types if you'd like. The other option is to only write the Go types, then use codegen to generate the GraphQL schemas. In a way, I prefer this because it keeps everything in the same language, using all of the great tooling Go has. There is some prior art for this; the Juniper [1] Rust library. [1] https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper

sorenbs 9y ago
It's worth keeping in mind that GraphQL often finds itself in organisations that use multiple languages. A trend we have seen starting to emerge over the last 6 months is that backend teams write core business logic in languages like Java or Python and want to expose this as GraphQL microservices. Then you either have a central team responsible for the public GraphQL API. They will typically write a server in Javascript that composes all the microservices. Or alternatively you have multiple product teams that all want separate GraphQL APIs tailored to their use case. They too typically use Javascript for the server. When multiple languages are involved it turns out to be really useful to be able to use GraphQL SDL as the canonical representation and use code-gen on each stack. This is the use case GraphQL binding is intended for: https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding
vektah 9y ago
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?