I run into an error when using a scalar like DateTime in two different microservices, and merging them together with Apollo Federation. Here is a snippet of the error being thrown UnhandledPromiseRejectionWarning: GraphQLSchemaValidationError: There can be only one type named "DateTime".
Apollo Federation
UnhandledPromiseRejectionWarning: GraphQLSchemaValidationError: There can be only one type named "DateTime"..
export const typeDefsFoo: DocumentNode = gql`
scalar DateTime
extend type Query {
foo(id: ID!): Sensor!
}
type Foo {
time: DateTime!
}
export const typeDefsBar: DocumentNode = gql`
scalar DateTime
extend type Query {
bar(id: ID!): Bar!
}
type Bar {
time: DateTime!
}
`;
I'm also having the same problem. We've structure our stuff a little differently, so wanted to add it for extra investigative input
type AlphaData @key(fields: "id") {
id: UuidV4!
created: String
updated: String
}
module.exports = gql`
${readFileSync(__dirname.concat('/inputs.graphql'), 'utf8')}
${readFileSync(__dirname.concat('/types.graphql'), 'utf8')}
scalar DateISO
scalar UuidV4
`;
module.exports = gql`
extend type AlphaData @key(fields: "id") {
id: UuidV4! @external
beta_data: BetaData
};
`
UuidV4 is a valid scalar on both microservices, they run as expected on their own. When we join them with federation, we get the same duplicate error. If we change them both to String!, it runs fine. We also had the same problem with other custom scalars.
I believe there should be internal deduplication for the scaler type in the Apollo Gateway library
Could you please suggest a workaround? Is it possible to transform individual service definitions or a composed schema on the gateway?
A more stable aproach would be to be able to declare each service as a module/namespace so the gateway calls every field of the service using service.field
Hello all! This is being fixed in the next release, currently worked on by @JakeDawkins!
Thank you for taking care of this. I would anyway suggest adding a possibility for some extensions, e.g. by invoking a function if present in gateway options for service schema pre/post processing on (like it was possible with stiching). What do you think?
I think the option of schema pre/post processing would be great with an option to rename types.
If the types are just merged, you might end up with a scalar that has different behavior in different parts of the schema.
Is there any hack around this for the time being @JakeDawkins ?
I'm currently JSON stringifying/parsing my JSON scalars instead but it's such a pain.
@Pruxis I’m not aware of a workaround, but I hope to be wrapping up work on this today, so this should work soon. Sorry for the trouble. If anyone else here has a workaround, feel free to share!
@JakeDawkins thanks for the effort.
@JakeDawkins Should this be available in @apollo/gateway version 0.6.7?
@byrnedo This should be available now in @apollo/[email protected]. @apollo/[email protected] should be published in the next couple hours with this
@JakeDawkins When dose @apollo/[email protected] will be published? We are stopped by this problem.
@CaroseKYS workaround is to update have @apollo/[email protected] in your package json and then remove the federation package in the gateway's node_modules dir:
rm -rf ./node_modules/@apollo/gateway/node_modules/@apollo/federation
Then it will use 0.6.4 instead of 0.6.3
@byrnedo Thanks, I just have solved problem in my local env. But in scenes like CI deployment and team work, it is troublesome.
@CaroseKYS you can add a postinstall script in package.json to solve it for ci
@byrnedo @apollo/[email protected] has been pulished. Do you have any ideas about this issue :https://github.com/apollographql/apollo-server/issues/2884? Thanks.
Most helpful comment
@byrnedo This should be available now in
@apollo/[email protected].@apollo/[email protected]should be published in the next couple hours with this