Multiple product API moving to federation

Help
1

Hello, we have multiple apps each with their own graphql API. We want to move to federated services. However each app has overlapping types with different fields.

I am trying to find guidance on how to bring these different APIs into alignment. The idea of a single super graph really only works if you don’t have conflicting types. What is the recommended approach for this use-case?

1 Like
2

Combine what can be combined with an owning federated service, and manually create namespaces for the rest.

For example:

# Person service
type Person {
  id: ID!
  jobs: [Job]
}

type Job {
  ...
}

# Workflow service
type Job {
  ...
}

# User service
type User {
  is: Person
}

type Person {
  id: ID!
  ...
  specialField: String # a field that only the User service knows about
}

Would become:

# Person service
type Person {
  id: ID!
  jobs: [PersonJob]
}

type PersonJob {
  ...
}

# Workflow service
type WorkflowJob {
  ...
}

# User service
type User {
  is: Person
}

extend type Person @key(fields: "id") {
  id: ID!
  specialField: String # the Person service still does not know about this field, but now the User service only needs to know about "specialField" and the id.
}
3

As Kevin mentioned above, entity/type extension is the best way to go about sharing types across subgraph services. Take a look at the Separation of Concerns section of Federation docs to understand how it works.

1 Like
4

This doesn’t address my use-case. Maybe I can explain better:
We have 2 products, each with the same type, in this case a ‘Patient’ type.
In both product API’s the Patient type is implemented completely differently, they have similar fields however the internal implementation for resolvers is totally different.

In this case it seems having multiple graphql api’s is still the best approach.

1 Like
5

Sounds to me like if you have two services that do the same thing but are implemented completely differently in a way that doesn’t overlap, your architects and engineers need to sit down and actually agree on what your domain model is, because this doesn’t sound like a technical issue, it sounds like a lack of separation of concerns.

1 Like