-
Notifications
You must be signed in to change notification settings - Fork 7
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
Conversation
src/zipPackage.js
Outdated
'const typeDefs = parse(schema);'; | ||
|
||
indexFile = indexFile.replace(originalLine, newCode); | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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);
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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'.
Nit:
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. |
c79048f
to
3902ee1
Compare
7acb748
to
a165707
Compare
Co-authored-by: andreachild <[email protected]>
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.