Idea: gRPC plugin

[schickling]

It's a very common use-case to use GraphQL as a gateway (as opposing to a GraphQL monolith/service) in front of other services (e.g. gRPC, Thrift, ...). I'd like to explore the possible workflows of using graphqlgen to auto-generate/auto-scaffold resolvers mapping to gRPC services.

My current idea would be to create a scaffolding plugin (see #84) which instead of scaffolding a resolver that throws an error, actually scaffolds a runnable resolver that calls out to the corresponding gRPC service.

The needed configuration/mapping could either be provided via some namespace in graphqlgen.yml or partially in the application schema via schema directives. Here's an idea how the config could look like in the graphqlgen.yml

# ...

resolver-scaffolding:
  output: ./src/generated/tmp-resolvers/
  layout: file-per-type
  plugins:
    grpc:
      input: ./my-service.proto
      resolvers:
        Query:
          feed: GetPosts
        Mutation:
          createDraft: NewDraft

Related: https://github.com/99designs/gqlgen/issues/228

Open Questions

• [ ] What should be the plugin/config "input"? Do we assume there's already a generated TS gRPC client or is it the responsibility to also generate one (including the resulting model type definitions) based on a .proto file?

[vektah]

We are considering something similar for gqlgen.

A few things I would love to see:

• ability to bind to multiple servers is pretty much a must for this kind of stitching server IMO
• some way for users to pass in their own clients, so they can handle their own authentication, tracing, etc.
• directives on fields that let you skip wiring in config, eg cake: Cake @grpc(method:"EatCake", server: "cheescake-shop")

Some more questions:

• do the types from the grpc server get turned into an actual schema file somewhere? How best to make this intuitive for people coming in cold to make a small change to an existing codebase?
• If schema does get generated first, enums could even be generated for the methods / servers available.

What should be the plugin/config "input"? Do we assume there's already a generated TS gRPC client or is it the responsibility to also generate one (including the resulting model type definitions) based on a .proto file?

At 99designs all of our clients are generated when the downstream apps merge, and are pushed to a shared repo, so this wouldn't be super useful and might be kinda tricky to do well?