tapioca icon indicating copy to clipboard operation
tapioca copied to clipboard

DSL compiler for graphql-ruby mutations and input objects

Open jeffcarbs opened this issue 2 years ago • 3 comments

Motivation

You can manually type the resolve method of your graphql mutations but there's nothing guaranteeing the sig you added will match the types specified in your graphql definition. It's also fairly cumbersome to type the getters of InputObjects.

Implementation

This PR adds two DSL compilers that reflects on the graphql definition on your mutations and input objects and type the resolve method of mutations and getter methods of input objects.

Some notes:

  • The return value of the resolve is typed as T.untyped. It seems like it should be possible to type the return value but given that graphql objects can be backed by anything (e.g. Objects::Foo can be back by an instance of the model Foo, a value object that implements the necessary methods, even just a hash, etc) it's not really feasible.
  • If you write an inline sig on the resolve method, no RBI will be generated. This gives control to the consumer to write their own sig if desired.

Open questions:

  • How should we handle custom argument types (e.g. custom scalars)? This PR was pulled out of an internal implementation that had just hard-coded our custom types but obviously we need some way to make it configurable or instruct folks to prepend a monkey-patch for GraphqlTypeHelper#type_for.

Tests

See included tests.

jeffcarbs avatar Jul 06 '22 04:07 jeffcarbs

We have tried this and it seems to work fine 🎉

thinca avatar Aug 03 '22 06:08 thinca

I can work on adding more tests and fixing the merge conflicts. Do you have thoughts on how to configure custom argument types (eg custom scalars)? We can just not for now and folks could just monkey-patch/prepend to handle.

jeffcarbs avatar Aug 10 '22 15:08 jeffcarbs

We can either prepend or look for a module with a hardcoded name that we can offload the work to. We currently use something similar in ActiveRecordColumns compiler. I don't have strong opinions. @paracycle do you have a better alternative in mind?

KaanOzkan avatar Aug 10 '22 19:08 KaanOzkan

Not sure why there are build failures

These are fixed 🙂 I had missed gem("graphql", require: false) in the additional gemfiles (e.g. Gemfile-rails-6-1), which meant that when we required the files for those compilers they would return early due to the LoadError handling:

begin
  require "graphql"
rescue LoadError
  return
end

jeffcarbs avatar Aug 30 '22 16:08 jeffcarbs