Graphql-ruby: Camelize client-facing identifiers

Created on 13 Feb 2017  路  10Comments  路  Source: rmosolgo/graphql-ruby

It would be nice to handle the transform from underscored Ruby identifier to camelized GraphQL identifier at the library-level. Something schema-level and opt-in, like:

MySchema = GraphQL::Schema.define do 
  camelize(true)
end 

This would transform:

  • field :some_thing into someThing (but still call method #some_thing on the underlying object)
  • argument :some_argument into someArgument (but still args[:some_argument] in resolve functions)
  • Input object fields also need to be transformed

For example,

field :total_count, !types.Int do 
  argument :include_archived, types.Boolean, default: false 
  resolve -> (obj, args, ctx) {
    if args[:include_archived]
      obj.count 
    else 
      obj.where(archived: false).count 
    end 
  } 
end 

would become

totalCount(includeArchived: Boolean = false)

(But the above Ruby code would still work)

Are there other identifiers that need to be transformed?

This might be implemented as an instrumenter: It could redefine the fields to have camelized names and also redefine their arguments., No, that won't quite work because of input objects, which can't be redefined there.

All 10 comments

We're currently migrating an existing ruby REST api to graphql, and also three existing clients that rely on underscored identifiers. We do want to migrate to CamelCase though to conform with the overall GraphQL convention, but doing so at once would havoc clients. What if we could have an option for keeping compatibility with the underscored identifiers? Maybe also adding a deprecation notice automatically.

That would be interesting, you mean to make _both_:

  • underscored fields, with a deprecation reason
  • camelized fields (which are the replacements for the underscored ones)

Is that right? Seems like a good idea!

Exactly, this way clients could gradually migrate to the CamelCase version.

Sorry for going off topic but @khamusa you could look into https://github.com/vigetlabs/olive_branch for letting the client specify the casing of the response.

(I haven't tried this with graphql)

@rmosolgo how is this progressing?.
I could really use something like this for fields and arguments.

I would really like to help out with a PR if you want me to.

@rmosolgo underscored fields with a deprecation reason not clean, how about make two schema? One is underscored with deprecation, but no camelized fields. And another is camelized.

And how is progressing?

@jgrau interesting.

@cpunion, is being developed here: https://github.com/rmosolgo/graphql-ruby/pull/555.

Although I'm not sure if it's going to make it, I think I would just settle for some refactoring to ease the develop of an external gem with this feature.

@pabloh thanks.

The class-based API described in #1037 will include this feature, keep an eye there!

Was this page helpful?
0 / 5 - 0 ratings