Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

fix(sample): update gql federation samples to use production-ready#15539

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
mag123c wants to merge1 commit intonestjs:master
base:master
Choose a base branch
Loading
frommag123c:fix/graphql-federation-production-ready-samples

Conversation

@mag123c
Copy link
Contributor

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Other... Please describe:

What is the current behavior?

The GraphQL Federation sample applications (both code-first and schema-first) use IntrospectAndCompose from @apollo/gateway, which is not production-ready. This approach:

  • Performs runtime schema composition at gateway startup
  • Requires all subgraphs to be running when the gateway starts
  • Can cause inconsistencies across multiple gateway instances
  • Is explicitly marked as not suitable for production by Apollo

Issue Number:#14676

What is the new behavior?

The updated samples now demonstrate production-ready patterns:

  1. Static Supergraph Schema: Gateways read from a pre-generated supergraph.graphql file instead of runtime introspection
  2. Schema Generation Scripts: Added npm scripts for generating supergraph schemas:
    - generate:supergraph: Local development using file-based composition
    - generate:supergraph:rover: Production using Apollo Rover CLI
  3. TypeScript Type Generation (schema-first): Added generate:typings script for type safety
  4. Automated Build Process: Pre-start hooks automatically generate required schemas
  5. Comprehensive Documentation: Updated READMEs with clear development vs production workflows
  6. Tests: Added E2E tests to verify production-ready implementation

The samples now provide a clear migration path from development to production, following Apollo Federation best practices.

Does this PR introduce a breaking change?

  • Yes
  • No

injae-kim reacted with thumbs up emojiinjae-kim reacted with heart emojiinjae-kim reacted with rocket emoji
@mag123c
Copy link
ContributorAuthor

coverage collected failed 😨😨

@dberardo-com
Copy link

Two questions here:

Is the usage of rover CLI mandatory for generating super graph or is it just an alternative to the first generation method? This is not 100% from the text IMO

What would happen if one of the backend applications does not startup? Will the gateway keep crashing or will it simply return 500 for those methods requiring those services? Is the behavior the same even after startup?

injae-kim reacted with thumbs up emoji

@mag123c
Copy link
ContributorAuthor

@dberardo-com

Q1.

No, Rover CLI is NOT mandatory. The implementation provides two methods:

  1. Default method (npm run generate:supergraph)
  • Does NOT require Rover CLI
  • Generates a simplified supergraph for local development
  • Executes generateSupergraphLocal() function
  1. Rover CLI method (npm run generate:supergraph:rover)
  • Recommended for production
  • Composes schema from running subgraphs
  • More accurate supergraph generation

As shown in the code

// generate-supergraph.ts:108-114constuseRover=process.argv.includes('--rover');if(useRover){generateSupergraph();// Uses Rover}else{generateSupergraphLocal();// Local generation (no Rover needed)}

The README clearly states these are alternatives, with Rover being the production-recommended approach but not mandatory.

Q2.

Current implementation (static supergraphSdl)

  • At startup: Gateway starts successfully regardless of subgraph availability (only reads supergraph.graphql file)
  • At runtime: Queries requiring down services return errors, other services continue working normally
  • Gateway stability: Does NOT crash, remains operational

IntrospectAndCompose behavior (commented out)

  • At startup: Gateway fails to start if subgraphs are unreachable
  • At runtime: With subgraphHealthCheck option, can skip schema updates on failure but continues polling
  • Less resilient: Service downtime directly impacts gateway availability
injae-kim reacted with thumbs up emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

1 more reviewer

@Hardanish-SinghHardanish-SinghHardanish-Singh approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mag123c@dberardo-com@Hardanish-Singh
[8]ページ先頭
©2009-2025 Movatter.jp