8. Publishing our schemas


We're well on our way with the accounts ! We've defined our User interface and the Host and Guest entities in both . It's time to get these changes composed into the !

In this lesson, we will:

  • Learn about how can (and cannot) be shared between s
  • Publish our changes to the registry and test our updated

Publishing our schema changes

We've made a lot of changes to our two . Let's check to see if our still composes.

Note: We're going to publish our current to the registry, which will take care of for us. However, when working in a production environment, you'll want to first test these schema changes using a combination of and integrated into your CI pipeline. We'll dive into these concepts in Voyage III, the next course of the series.

To publish our schema changes in the accounts , we'll use the rover subgraph publish command with the corresponding values. Since this is the first time we're publishing the accounts , we'll also need to add a routing-url. (Our is running locally, so make sure you specify http and not https!)

rover subgraph publish <APOLLO_GRAPH_REF> \
--schema ./subgraph-accounts/schema.graphql \
--name accounts \
--routing-url http://localhost:4002

Remember to replace the <APOLLO_GRAPH_REF> value with your own, and take note that we're running this command in the root directory of our project!

Wait - what are these errors in the terminal? Here's an example of one of the errors we see after running the command.

INVALID_FIELD_SHARING: Non-shareable field "Host.name" is resolved from multiple subgraphs:
it is resolved from subgraphs "accounts" and "monolith" and defined as non-shareable in all of them

What we're seeing is an example of invalid field sharing.

Invalid field sharing

Let's talk about what this error means, and what we can do to fix it!

We published our accounts schema to Studio, which triggered . But right now, the latest version of the monolith that Studio is aware of is the one without our most recent changes. As far as it knows, the monolith still includes these accounts-related on Host and Guest!

As a result, the process discovered a number of that are defined in both of the Studio knows about. This causes an error because by default, a can't be defined or resolved by more than one subgraph.

If we did want a to be defined or resolved by multiple , we'd need to enable this explicitly by using the @shareable .

The @shareable directive

The @shareable enables multiple to resolve a particular object (or set of object fields).

For example, if we wanted to allow both the monolith and accounts to resolve the Host.name , we could leave the definitions in both and mark the field with @shareable.

type Host implements User @key(fields: "id") {
# ... other Host fields
name: String @shareable

Note: You'd also need to add the @shareable to the Federation 2 schema definition imports in the , as detailed in the docs.

Adding the @shareable to both definitions would take care of the build error.

However, in our case, we don't want to do this! For Airlock, we've decided that only the accounts will be responsible for these . Fortunately, we can fix this error by publishing our changes to the monolith . This will bring Studio up to date on our decision to relocate accounts-related to the accounts .

Publishing the monolith subgraph

Let's take care of this step now, and clear up those errors in the terminal! Run the following rover subgraph publish command for the monolith , swapping in the values specific to your graph.

rover subgraph publish <APOLLO_GRAPH_REF> \
--schema ./monolith/schema.graphql \
--name monolith

With that, we should see that the process was successful! Studio is now up to speed on how we've decided to divide between our .

The 'monolith' subgraph for the <APOLLO_GRAPH_REF> graph was updated
The gateway for the <APOLLO_GRAPH_REF> graph was updated with a new schema, composed from the updated 'monolith' subgraph

Testing our schema changes

Let's check the results in our on Apollo Studio. Navigate to the Schema page and the SDL tab. We'll see a new on this list called accounts! 🎉

Next up, we'll put these changes to the test. Head over to the Explorer and run this :

query GetMyProfile {
me {

Make sure your Headers are set to:

Authorization: Bearer user-1

When you run the ... uh-oh! We get a new error: Cannot return null for non-nullable field Host.name.

That's because we have yet to move the corresponding over to the accounts ! (And we'll need to move that me entry point over as well.) Let's take care of the first, in the next lesson.


In which of the following scenarios should the @shareable directive be used?

Key takeaways

  • The INVALID_FIELD_SHARING error occurs when multiple implement the same without designating it as shareable.
  • Applying the @shareable enables multiple to resolve a particular object (or set of object fields). This allows the field(s) to which the directive is applied to exist in more than one subgraph.

Up next

We don't have any set up in the accounts , so we aren't getting any data back about users! Let's tackle that next.


Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.