Field of type UUID scalar on GraphQL Server

[valeriob23]

Hey there! I am implementing a GraphQL server, using SmallRye GraphQL version 2.1.3.
I'm experiencing some problems with the UUID scalar, and in general with Custom Scalars (not clear to me how to declare new ones and see them appear under https://<host>:<port>/graphql/schema.graphql).

Focusing on UUID, at the moment it doesn't seem possible to declare a field of a GraphQL Type as a UUID field. Indeed, this is always handled as a String, and shown as such on the autogenerated schema, as well as on the playground. This might not be an insurmountable problem, except that ideally the service should work in a federated context (therefore using GraphQL Federation), where keeping the same type of field shared between several subgraphs is crucial (link).
I tried to have a look at the source code, and I didn't understand exactly whether it is an intended choice to handle a UUID field as a String. Below is an example:

@Key(fields = "id")
class User(
    @Id
    val id: UUID,
    val name: String,
)

# schema.graphql
type User @key(fields : "id") {
  id: String! # this field is declared as UUID in other subgraphs
  name: String!
}

I've also tried playing with @AdaptWith and @AdaptToScalar, but no way to achieve that for different reasons.

Do you have any thoughts/considerations about this? Should this not be the 'desirable' behavior, I could try opening PR.
Thanks!

[valeriob23]

hi! Any thoughts, feedback, or ideas?

[phillip-kruger]

@t1 @jmartisk ^^^

[jmartisk]

I don't think we have a way to add custom scalar types by the application, or do we, @phillip-kruger?
Frankly I have little understanding of how @AdaptToScalar works, we should have some examples in the docs, but I think it only can map classes to one of the built-in scalar types?

[valeriob23]

Sure, this should be the latest (the "newest" is still in draft): https://spec.graphql.org/October2021/#sec-Scalars.Custom-Scalars .
Other docs:

• https://graphql.org/blog/2023-01-14-graphql-scalars/
• https://scalars.graphql.org/

I think it may be very useful to declare custom scalars. For instance, I needed to do it in other projects (where I used different stacks).

[phillip-kruger]

Great thanks! @jmartisk I think we need to look at this. I know there is/was an issue about this as well. We might need to brainstorm on the best way to make this available for users. Let start with discussing how this will be used by users, before we get into implementation. Anyone want to suggest how a user will go about to define a custom scalar?

[valeriob23]

Good news, thanks! I'll try to provide some suggestions.

Instead, what about UUID specifically? At the moment, it seems already managed (in other words, no need to declare it as a custom scalar), although forced to String. Do you think guys it is better to wait for a solution and treat it as a custom scalar? Or may we think about changing the current UUID management in the meantime?

[jmartisk]

We could switch UUID to be mapped to a scalar named UUID, but it's a breaking change and some users might already rely on it being mapped to a String

Just thinking: perhaps we could add the graphql-java-extended-scalars library (https://github.com/graphql-java/graphql-java-extended-scalars) and add a new variant of the AdaptToScalar annotation that takes an argument of type Class<? extends graphql.schema.GraphQLScalarType> instead of Class<? extends io.smallrye.graphql.api.Scalar> that we currently have (see https://github.com/smallrye/smallrye-graphql/blob/2.2.1/server/api/src/main/java/io/smallrye/graphql/api/AdaptToScalar.java). Then people could add their own scalar types as needed by implementing graphql.schema.GraphQLScalarType and they could also use the scalars already provided in the graphql-java-extended-scalars library, like UUIDScalar: https://github.com/graphql-java/graphql-java-extended-scalars/blob/master/src/main/java/graphql/scalars/id/UUIDScalar.java

Does this make sense?
I'm not yet completely sure it would be implementable on our side, but I assume it should be...

[giacomo-porro]

Hi all, sorry to jump in, I am also interested in this feature and I was actually thinking the same as @jmartisk . If it's possible not to reinvent the wheel, I'd use the custom scalar implementation that's in the library.

Taking a quick look at both the code bases ( smallrye-graphql and graphql-java-extended-scalars ) seems like it's a possible integration but since the devil's in the details I'll leave the last word to you guys who are the maintainers :)

Thanks a lot everyone for the effort!

[giacomo-porro]

Hi everyone, are there any news on this? I'm not that knowledgeable about this code base but maybe with some guidance I can work on that (?)

[jmartisk]

Hi, sure if you want to give it a shot, I think the solution with graphql-java-extended-scalars that I described earlier could work... If you need any help, I'm available on Quarkus zulip, for example (https://quarkusio.zulipchat.com/)

[pfaul]

Hello, is there any update on this?
I am trying to implement a custom scalar getting translated from 1 GraphQL server to another GraphQL server (which is also a client in this context). I am not happy that I don't have any type safety on the values contained.

https://smallrye.io/smallrye-graphql/2.5.0/typesafe-client-custom-scalars/
With this definition I am only able to transfer the custom scaler as a String.

I will present a bit more context here.
My custom scalar should be a percentage value:interface Percentage{ BigDecimal amount();}
(I need an Interface, so I don't get colliding doubled declaration in the GraphQL schema, which is also sad.)

I implemented a coercing to translate the custom scalar. When I am serializing the value as a String it works fine. But as I said, I want to have type safety here and serialize the value as a BigDecimal.

Another issue I have with the definition of method signatures given in the link above: I have to implement a toString method that handles serialization. I don't think this should be handled in that way. I think the serialization and deserialization must be handled differently. If you think one step further, and imagine using a third party library record as a custom scalar. How should you implement the serialization and register it? Also the methods "of", "valueOf" and "parse" are not defined in an interface somewhere. It feels like some reflection magic is happening, but I actually want to properly define the serialization.

I would be grateful for any help or suggestions!

[jmartisk]

I've created a work-in-progress sketch of how we could integrate extended scalars: See
https://github.com/jmartisk/smallrye-graphql/tree/extra-scalars
and
https://github.com/jmartisk/quarkus/tree/extra-scalars

Basically, how it would work is that the application would add just a configuration value, like

quarkus.smallrye-graphql.extra-scalars=UUID

and that would import the UUID scalar from the extended-scalars library. Only UUID is implemented now, but we could add some more.
When used with UUID, it would override the default integration of UUID, which translates to a String in the schema. Thus we would stay backwards compatible with this solution in place.

It would be nicer to be able to register the scalar through some kind of SPI, but the problem is that Quarkus builds the schema during build time, and we want to avoid loading and calling application classes during build time, hence I came up with this other solution.

Would this make sense?

[valeriob23]

definitely makes sense to me, moreover a comma-separated list for that property to ideally support multiple additional scalars in the future is great.

p.s.: just out of curiosity, talking about the extended-scalars library, I tested it by importing it and implementing EventingService, with no success 😞 I might have done the wrong test, though

[jmartisk]

p.s.: just out of curiosity, talking about the extended-scalars library, I tested it by importing it and implementing EventingService, with no success 😞 I might have done the wrong test, though

Yeah the problem is that EventingService methods are called during boot time, which is too late. The schema was already built at this time, so that way you'd only be importing a runtime implementation of the type (serializer/deserializer), but it would be unused in the schema and not wired up. Quarkus generally doesn't use any build-time SPIs for applications, so we probably need to go the configuration way. I'll probably try to clean it up a bit and try to submit it as PRs next week

[bdupras]

This is a very promising thread. 😄 Thanks for the ideas and the work on this @jmartisk! (Note: I tried viewing the branch https://github.com/jmartisk/smallrye-graphql/tree/extra-scalars, but the branch appears to be gone.)

Do you think this design could support the extended-scalars Alias Scalars and Regex Scalars? IIUC, this could allow applications to declare their own custom named scalars, but without requiring an application SPI at build-time. Seems like it could cover a lot of use-cases?

quarkus.smallrye-graphql.extra-scalars=UUID
quarkus.smallrye-graphql.extra-scalars-alias=SocialMediaLink:GraphQLString
quarkus.smallrye-graphql.extra-scalars-regex=PhoneNumber:`\([0-9]*\)[0-9]*`

[jmartisk]

I tried viewing the branch https://github.com/jmartisk/smallrye-graphql/tree/extra-scalars, but the branch appears to be gone.)

I removed it after merging the PRs - see #1956 and quarkusio/quarkus#37067 for reference

Do you think this design could support the extended-scalars Alias Scalars and Regex Scalars? IIUC, this could allow applications to declare their own custom named scalars, but without requiring an application SPI at build-time. Seems like it could cover a lot of use-cases?

quarkus.smallrye-graphql.extra-scalars=UUID
quarkus.smallrye-graphql.extra-scalars-alias=SocialMediaLink:GraphQLString
quarkus.smallrye-graphql.extra-scalars-regex=PhoneNumber:`\([0-9]*\)[0-9]*`

You can give it a try :) it will need changes in smallrye as well as quarkus though. We'd need to add it both into the build-time scanning context (like we do with UUID here: https://github.com/quarkusio/quarkus/blob/e56b8ec68d652385bf259bc7913fdc2fed3deddf/extensions/smallrye-graphql/deployment/src/main/java/io/quarkus/smallrye/graphql/deployment/SmallRyeGraphQLProcessor.java#L330) AND into the runtime wiring (https://github.com/quarkusio/quarkus/blob/e56b8ec68d652385bf259bc7913fdc2fed3deddf/extensions/smallrye-graphql/runtime/src/main/java/io/quarkus/smallrye/graphql/runtime/SmallRyeGraphQLRecorder.java#L34)