There should be a way of defining custom scalars

[jensneuse]

Custom scalars, e.g. JSON, Date etc. should be able to be defined and registered to the engine from outside the engine itself. That is, possible scalars should be externalized and able to be configured.

[lyueyang]

Hello! Firstly, I'd like to start by saying thank you for writing such a brilliant library!

I would just like to know if there are any updates regarding this as I'm currently faced with the following situation:

I've written 2 custom scalars in gqlgen, 1 which unmarshals to a string (named Point) and another for uint64 for my subgraphs. The gateway has no issues handling the Point scalar but it has issues resolving fields which use uint64 as its type.

I've spent some time looking at how the nodes are resolved and so far I've observed that the uint64 node is resolved as a String when it should be an Integer. This issue doesn't occur when I update the schemas in my subgraphs to use Int instead of Uint64.

Thank you!

[jensneuse]

It's definitely something that needs a solution at some point in the future. Could you explain a bit more about your use case? I like to understand how devs use the library.

On the concrete example: How do we communicate between GraphQL Schema (SDL) and engine what parser (e.g. uint64) to use for a field? Do we simply assume that "uint64" and "Uint64" should be resolved by the corresponding resolver?

If you want to speed up the implementation, you could add failing tests and I'll have a look at implementing it. That said, I cannot guarantee any timeline as this feature is currently no high priority.

Obviously, you're free to raise a PR with the full implementation but I assume it's hard for an "outsider" to find the right place and the right level of abstraction. It needs changing of the planner as well as the execution engine which means finding a good implementation is a bit complex if you're not familiar with the codebase. However, writing a failing test should be doable.

[lyueyang]

Thank you for the reply!

In my current use case, I have my scalars written as a separate library all together, similar to how gqlgen has their scalars here. In such a case, would it be possible to have the gateway to be aware of these scalars?

[jensneuse]

Thank you for the reply!

In my current use case, I have my scalars written as a separate library all together, similar to how gqlgen has their scalars here. In such a case, would it be possible to have the gateway to be aware of these scalars?

So if I understand you correctly it would be sufficient if we do the following:

• create an interface to marshal & unmarshal a scalar
• allow the library user to "register" their own scalar interface to the engine by specifying the scalar name and the interface

If that's all we need I think it's not a big problem to solve. Please clarify if this would solve your issue.

[PBholewasi]

@jensneuse when can we expect a solution for this ?

[dastein1]

I tried this fantastic lib today and quickly ran into the issue with custom scalars.

PR #555 allows users now to register a map which allows to parse/validate/resolve custom types. This should allow to pass through any custom scalar to the federated gql apis.

Here's how that would work for a custom scalar type called Long.

// Create customResolver
type customResolver struct{}

// customResolver implements resolve.CustomResolve.
func (customResolver) Resolve(data []byte) ([]byte, error) {
    return data, nil
}

// Create resolver map
var customResolveMap = map[string]resolve.CustomResolve{
    "Long": &customResolver{},
}

// Register map
engineConfigFactory := graphql.NewFederationEngineConfigFactory(
  newDataSourcesConfig,
  graphqlDataSource.NewBatchFactory(),
  graphql.WithFederationHttpClient(g.httpClient),
  graphql.WithCustomResolveMap(customResolveMap))

[LimhorngSok]

Hello @dastein1 I have a problem custom scalar is not Nullable. it always return unable to resolve