Skip to content

fix: Updated index.mjs file to be modified for Apollo subgraph Federation 2 features #126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 13, 2025

Conversation

flora-jin
Copy link
Contributor

@flora-jin flora-jin commented Aug 12, 2025

There was an issue with the index.mjs file when generated with --create-update-apollo-server-subgraph as it did not include support for the Apollo Subgraph Federation 2 features.

Updated so that when user runs --create-update-apollo-server-subgraph the index.mjs file includes the support for the subgraph federation 2 features and if run with just --create-update-apollo-server, the index.mjs file is not modified and same as the original template.

Also added an index.mjs file check to the apollo subgraph integration test (Case09) to ensure the index.mjs file is always modified correctly to add support for the subgraph federation 2 features.

'const typeDefs = parse(schema);';

indexFile = indexFile.replace(originalLine, newCode);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sort of file patching is super fragile and difficult to parse out for correctness. Is there any chance this logic can become a conditional inside /templates/ApolloServer/index.mjs or ./output.schema.graphql? I'm not sure if it is possible to do, but if it is I'd prefer that approach.

Copy link
Contributor

@andreachild andreachild Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the only change would be to the Apollo template index.mjs file. There's already an env var to indicate if it is a subgraph and it is already referenced for this code:

const server = process.env.SUBGRAPH === 'true' ? new ApolloServer({
    schema: buildSubgraphSchema([{
        typeDefs,
        resolvers
    }])
}) : new ApolloServer({typeDefs, resolvers});

So for this federation 2 change, it should be something like:

const fileContent = readFileSync('./output.schema.graphql', 'utf-8');
let schema = fileContent;
if (process.env.SUBGRAPH === 'true') {
  schema = `extend schema @link(
        url: "https://specs.apollo.dev/federation/v2.0"
        import: ["@key", "@shareable"]
  )${fileContent}`;
}
const typeDefs = parse(schema);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this implementation would an integration test be necessary then. I feel that the most that can be done is check the file contents of the index.mjs file although I think it would be insignificant in this case as it is just copying the file directly from the templates folder 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The most important would be a manual check that the Apollo API works as expected after deployment.

Nice to have is modifying an existing integration test for apollo subgraph which uses the testApolloArtifacts function in testLib.js. You can add a check to testApolloArtifacts that the index.mjs file has 'https://specs.apollo.dev/federation/v2.0'.

@andreachild
Copy link
Contributor

Nit:

There was a bug with the index.mjs file when generated with --create-update-apollo-server-subgraph as it did not include support for the Apollo Subgraph Federation 2 features.

This is not a bug as it just assumed Federation 1 as default but Apollo is pushing Federation 2 over Federation 1 and Federation 2 is backwards compatible with Federation 1.

@flora-jin flora-jin force-pushed the apolloSubgraph branch 2 times, most recently from c79048f to 3902ee1 Compare August 12, 2025 17:05
@andreachild andreachild merged commit 90215c2 into aws:main Aug 13, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants