GraphQL gateway?

[StevenACoffman]

Hi! I maintain gqlgen and I was wondering how hard it would be to adapt knit gateway to act as a GraphQL gateway. (browser -> graphql -> knit -> Connect/gRPC )

There's grpc-graphql-gateway and protoc-gen-graphql (and even old rejoiner) to get from protobuf to graphql, so it seems doable.

One tricky piece is as @jhump mentioned:

from my experience with graphql implementation they handle it internally

That is because graphQL requires a unique id field on every entity. But knit does not require that -- so that it can be used with existing Protobuf schemas and RPCs that do not contain that. So knit has no way of "automagically" correlating results with the input IDs.

Also, it is common in microservice architectures for the main entity to not know about IDs of its relations. Instead, a separate service will contains that other data and also contain the foreign relation knowledge. In the SWAPI example, this would be like the Planet entity not having a list of residents/person IDs. So the way to join in the residents of a planet is to ask the "Person" service for all people with a particular "homeworld" planetID. In this case, the framework (be it knit or graphql) cannot know how to join person to planet because it doesn't know which field to join on (in the example case, joining "person.homeworld_id" to "planet.id").

So, since there's not enough information in the schema alone to "explain" the relations and join criteria to the knit framework, it's up to the resolver.

[jhump]

@StevenACoffman, this is definitely a feature we've considered. It likely plays into similar discussions about the current mechanism to resolve relations. Before the initial open-source release (v0.0.1), we actually experimented with two other, different ways of expressing/configuring resolvers. We landed on the current shape for a variety of reasons, but it is admittedly more challenging to implement than if the relationship information could somehow be configured via Protobuf annotations and have the Knit framework itself handle resolution. I think in a future where relationships are easier to implement and configure, we'd be more likely to investigate tackling GraphQL support. We'd likely also need some extra configuration to map entity types/domains to RPC entry points and perhaps also be able to configure aliases for columns and relationships, to make it easier to port existing GraphQL schemas to Knit.

[StevenACoffman]

That's entirely fair. I quite like what you've done with knit and appreciate everything you are doing over at buf. Thanks for your kind response.