Adding Entry Point for custom coercion on standard scalars #3145
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I want to add an entry point for custom coercion in ValuesResolver.json
Essentially, I'd want to keep the current coerceVariableValues and add another flavor of it that takes a Function<Object, Object> preCoercionFunction.
This would get passed to ValuesResolverConversion.externalValueToInternalValueForVariables where if not-null, would translate the value right before this line here
At linkedIn, our APIs pass around a custom null class instance to represent null (say Data.NULL) instead of the java null. This is an issue for us even pre-v20 because this Data.null instance is converting to a string "null" instead of java null. To work around this we are rebuilding the entire rawVariables map to convert Data.NULL to null before parsing our raw input variables. However, we have found that this may be causing performance issues so we would like a way to be able to do our custom conversions while still using the grapql native scalars.
Beyond that, migrating to v20 for us is a challenge because of the stricter string coercer. Ideally a new type would be made for non-strings that fail string coercion in v20. The reason we want to not build our own new scalars is because currently our APIs are using schemas with the native scalars and creating a new type would make all of our schema backwards incompatible which is not an option for us.