How to allow multiple implementations of the same scalar

[Bertg]

One of the most used scalars is ID, it's great! However our application has 2 types of ids. Some of them are UUID based, and others are some weird base54 thingy.

Now, we want to start validating these IDs (especially on input), but I don't want this to be reflected in the input (over time some of the UUID based IDS become the base 54 ones) and is more of an internal issue then it is an external one.

So I was thinking of leaving the uuid based ones to GraphQL::Types::ID and extend its coerce_input method to deal with the validation. And I would create a new Scalar with the same graphql_name for the base54 based ids.
Not unsurprising I got a GraphQL::Schema::DuplicateNamesError and there seems no way around this...

I think the above case is a valid example where I can have 2 internal implementations for the same external type. (I really don't want to change the external types). Is there an other way to achieve what I want to do? Or is this an opportunity for a new feature?

[rmosolgo]

Hey, great question. As you noticed, you can't have two types with the same name. I think the best way would be to implement ID with an "or" condition in its validation code, for example:

def self.coerce_input(value, context)
  if valid_uuid?(value) || valid_base54_thingy?(value)
    value 
  else 
    raise GraphQL::ExecutionError, "Invalid ID: #{value.inspect}"
  end 
end 

That way, in GraphQL, it looks like a single type (ID), but under the hood, two formats are expected.

Now that I write it up, it strikes me that maybe you want some fields to require UUIDs while other fields require base54 IDs. If that's the case, you'd still use a single ID, but you'd validate it on an argument-by-argument basis. A couple options there:

• You could add an assertion to the resolver to check that the incoming ID matches the expected format. The upside here is that it's very simple. (And depending on your situation, maybe the best implementation isn't even in your app's GraphQL layer -- maybe it belongs in the business logic layer, eg, model classes, service objects, and so on.)
• You could write two custom GraphQL argument validators, one to check for UUIDs and one to check for base54 IDs. Then, apply them to fields as needed.

How does all that sound?

[Bertg]

So what you are suggesting is we do something like this?

argument :id, ID, required: false, validates: { IDValidator => { type: :uuid } }
# Then somewhere else
argument :id, ID, required: false, validates: { IDValidator => { type: :base54 } }

[rmosolgo]

Yes, that certainly seems like a reasonable approach to me!

[Bertg]

Understood. it would be cool if we could do something like this, as for me it looks more "correct" in ruby. But I get that allowing duplicate scalars may create a confusing developer experience.

argument :id, UuidID, required: false
argument :other_id, Base54ID, required: false

[rmosolgo]

You could do it, just swap the arguments around under the hood in BaseArgument#initialize:

def initialize(*args, **kwargs, &block) 
  # TODO handle list and non-null types
  if self.type == UuidID
    self.type = GraphQL::Types::ID
    self.validate(...)
  elsif self.type == Base54ID
    self.type = GraphQL::Types::ID
    self.validate(...)
  end 
end 

The only catch is list types ([...]) and non-null types (required: true). There's no built-in way to "clone" those types with a new inner type. You'd have to add some code like this:

graphql-ruby/lib/graphql/schema/addition.rb

Lines 128 to 143 in ea9d1ea

	orig_type = owner.type
	unwrapped_t = type
	# Apply list/non-null wrapper as needed
	if orig_type.respond_to?(:of_type)
	transforms = []
	while (orig_type.respond_to?(:of_type))
	if orig_type.kind.non_null?
	transforms << :to_non_null_type
	elsif orig_type.kind.list?
	transforms << :to_list_type
	else
	raise "Invariant: :of_type isn't non-null or list"
	end
	orig_type = orig_type.of_type
	end
	transforms.reverse_each { |t| type = type.public_send(t) }