Apollo Federation - How to share customized types between services, except scalar types and enum

[CaroseKYS]

I have two services, there are some types and inputs to share：

• Service A

input Page {
  limit: Int
  offset: Int
}
type PageInfo {
  page: Int
  page_size: Int
}

• Service B

input Page {
  limit: Int
  offset: Int
}
type PageInfo {
  page: Int
  page_size: Int
}

When i federate them use apollo-gateway, i got errors like:
There can be only one type named "Page".,There can be only one type named "PageInfo".

What can i do? Is this method is wrong?

[ElliotChong]

If the type definitions are identical could we work around that slice of issues by simply discarding the duplication in a pre-processing step before the schema merge?

If types are not identical would it be possible to resolve this by namespacing when they collide within the Gateway?

i.e.: Gateway transforms type PageInfo into type PageInfo_ServiceA and type PageInfo_ServiceB

[ElliotChong]

Thinking about this more... Is the current intention to just mark the duplicated types in Service B as stub types? We'll still have an issue with inputs though since they can't be marked with @extends / @external. I also wonder if that would still work correctly with something that is truly service-specific like PageInfo.

[dredl]

This feature is available from apollo-server v2.8.0. Docs is updated: https://www.apollographql.com/docs/apollo-server/federation/core-concepts/#value-types.
Now you may create types in multiple services. But value types must be identical

//service A
type PageInfo {
  page: Int
  page_size: Int
}
//service B
type PageInfo {
  page: Int
  page_size: Int
  someProperty: Int <-- you cannot add additional property, you should duplicate it in service A to make it work
}

[dmoosajee]

@dredl is it possible to detail how this is expected to work in a microservice continuous deployment model? e.g. if service B requires a change to the type definition, should service A be redeployed?

[willbrazil]

We're currently running into a similar issue. It could very much be us misusing the federation/tooling. Each one of our federated services declare an identical copy of an Enum. We have to perform an apollo service:push in each service after updating the enum (i.e. adding a new value). However, performing a push in service A will put us in an inconsistent state where the Enum definition in service A will be different than its definition in service B - thus apollo service:check fails and prevents us from performing the initial apollo service:push to service A.

Apologies in advance if this issue is due to the misuse of Apollo Federation! Has anyone been able to resolve this?

Thank you for your time.

[patrick91]

@dredl I think that only works for scalars and unions, not for types

I'm trying to migrate some fields and types from one service to another. But I'm unable to do so as I get this error:

 Field "XXX.id" can only be defined once.

for each field in the type, even if the type is the same 🤔

oh and at the end:

There can be only one type named "XXX".

Edit, my bad, one field was missing in one of the services, seems to be ok now :)

[batatababa]

This is really disappointing, even value types. From the docs it looks like subgraph's are can correspond to different microservices. Ideally it's nice that there will be a consistent Page type used across the graph. But in practice microservice teams will not implement this consistency and will instead create their own namespacing by prefixing typenames. It would be nice to not have to deal with this added complexity and have some namespacing baked into apollo federation.

[trevor-scheer]

For anyone who's still interested in this and hasn't kept up with the changes, I encourage you to check out the changes that came with Federation 2.0+. I suspect all of the concerns in here have been resolved, but if not please open a specific issue in the federation repo for the functionality you're looking for.