This repository has been archived by the owner on Apr 15, 2020. It is now read-only.
Overriding remote custom scalars/enums not working when renaming types #34
Comments
|
Solutions include:
|
yaacovCR
added a commit
that referenced
this issue
Jan 21, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Jan 21, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Jan 21, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Feb 17, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Feb 27, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Mar 26, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
yaacovCR
added a commit
that referenced
this issue
Mar 26, 2020
now that all directly proxied args are serialized automatically, including variables, appropriate to standardize args passed to delegateToSchema. Previously, the typeName would be inferred from the proxy target, but serialization would be according to the gateway schema if the type names matched. This would introduce a lot of edge cases and was only necessary as a workaround to facilitate serialization of variables. Now we can standardize as follows: args format is the internal representation of the proxy target schema. By default, local schemas internal representation will be imported, so that local schema custom enums/scalars do not require manual serialization. For remote schemas should, the internal and external representation is the same, so this is the same as the external representation. If the gateway introduces a new internal representation, args must be converted to the old internal representation manually. addresses #34 reverts fd1bd8f#diff-06b180be3290dd53bea4c1c98c9dfdd2
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently, you can merge custom scalars/enums from a subschema and then provided new internal values such that the external values will be parsed into the internal ones prior to hitting your resolvers.
This is supported, although not necessarily a great idea, as the main purpose of internal values is when you know that you are going to be using an external api that expects these values to be of a different form -- see https://www.apollographql.com/docs/apollo-server/schema/scalars-enums/#internal-values -- and in this case the subschema is at least one external api that is expecting the values to be in the external form!
But, nevertheless, it is supportable, and supported. However, because type renaming is currently not handling directly by the stitching logic, but by user definable transforms, and there is no interaction between the transforms, the transform that performs the serialization of args prior to delegation (AddArgumentsAsVariables) and the transform that renames types (RenameTypes) cannot communicate, and so if the subschema has a type that is renamed, AddArgumentsAsVariables does not realize that it should use that types serializer.
This will only hit users if they are using schemaConfig objects within mergeSchemas, as if you fully transform the schema using wrapSchema or transformSchema prior to merging, and get hit by that extra round of delegation, all types in the subschema will be of the same name as the merged schema, avoiding this problem.
The text was updated successfully, but these errors were encountered: