Add context aware custom scalars

Hi @OlegIlyenko,

again congrats to the awesome conference. As we discussed yesterday, here’s the write-up of the scalar problem we’re facing.

Context

We’re exposing our schema to two types of clients. Native mobile and web clients. Historically native mobile clients in our APIs don’t expose the APIs raw, but scramble them based on the current users consumer key. That means if we receive a request from the mobile channel we need to descramble the IDs before passing them on to the resolvers (and scramble the ids when we return a response back to the client). The web part doesn’t have to do that.

Our Sangria app is sitting behind our OAuth gateway and gets the consumer key and all oauth related information via HTTP headers passed on from the gateway. The key and some other data in the headers is necessary for successful scrambling / descrambling.

We tried to implement this with a middleware, but there’s one scenario that really doesn’t work that well, when you have parametrised queries that also send the variables. Ids in there naturally also need to be descrambled.

Problem

I guess the natural way to solve this would be to use a custom scalar and treat scrambling and descrambling as value coercion. The problem though is that we don’t have access to the active context (which holds all the necessary data) in the functions of a custom scalar.

Our problem would become trivial to solve if we figure out a way to allow custom scalar functions to access the context.

We’re happy to help with implementation from our side, if you give us a hint how that could be implemented (/cc @axxiss).

In order not to break the existing scalar implementation, what do you think about a new ContextAwareScalarType?

[BjRo]

Though I have a question about the use-case. If header is not present, but user asked for an encoded ID, wouldn’t it be better to validate it on a query validation phase or in query reducer, even before the query is executed? If it is a clear client configuration error than it can be immediately rejected with 400 HTTP status. Or did I miss something?

No, you’re absolutely right. We talked about it internally and that’s how we’ve implemented it now. Simpler 😃.

From our point making toScalar and fromScalar symmetric is not strictly necessary. Both solutions would work for us.

[OlegIlyenko]

Thanks for the feedback! It is quite interesting. I think I always had this assumption that scalar values can’t fail when serialized to the user (and if they fail for some reason that it is quite an exceptional situation, like OOM), but need validation when deserialized from the user input. This is where this asymmetry comes from

This dynamic is, of course, different when middleware is involved. Thanks for pointing this out! I can change toScalar signature like this, and make it symmetric:

def toScalar(value: Any, inputType: InputType[_], ctx: Ctx): Option[Either[Violation, Any]]

Though I have a question about the use-case. If header is not present, but user asked for an encoded ID, wouldn’t it be better to validate it on a query validation phase or in query reducer, even before the query is executed? If it is a clear client configuration error than it can be immediately rejected with 400 HTTP status. Or did I miss something?