Import JavaScript @apollo/federation and @apollo/gateway from the apollo-server repository.
#134
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ble. This doesn't comprehensively fix places where we use `console` but `logger` isn't already in scope, but these are easy wins. cc @trevor-scheer Apollo-Orig-Commit-AS: apollographql/apollo-server@397a735
…graphql/apollo-server#3825) Apollo-Orig-Commit-AS: apollographql/apollo-server@c33d01f
Apollo-Orig-Commit-AS: apollographql/apollo-server@4f911ba
…reality. Apollo-Orig-Commit-AS: apollographql/apollo-server@71e5956
- [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@a07ce0f
…llographql/apollo-server#3829) These types are compatible, but this change is necessary to account for the fact that, while we have provided types for `make-fetch-happen` which matter during development of Apollo Server, we don't include those types in the distribution. We could do that, of course, but as I'll note in a minute, we want something more generic anyhow. The omission of the types in the published package (currently, before this commit) results in typing errors for consumers of `@apollo/gateway` since the `import` statement for the `Fetcher` type from `make-fetch-happen` is still emitted (see attached [[Screenshot]]). Switching to the type that `apollo-serve-env` already provides via its `fetch` implementation (literally, `typeof fetch`) should be a no-op change and actually provide the more generic compatibility we want for those who want to bring-their-own-fetch. This should be the same as any type provided by other Fetch-compatible packages as well, including `isomorphic-fetch`, etc. [Screenshot]: https://cc.jro.cc/E0uqEXrX Apollo-Orig-Commit-AS: apollographql/apollo-server@daac9ee
- @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@5235abd
...except in a different place. cc @trevor-scheer Apollo-Orig-Commit-AS: apollographql/apollo-server@ce5ac56
- @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@062e6a3
* Centralize mocking fixtures and reuse them * Simplify mock request signatures for more easily read and written tests * Create nock/nockSuccess pairs for the most common use case and flexibility cc @abernix Apollo-Orig-Commit-AS: apollographql/apollo-server@4155e73
…l/release-2.11.0 Release 2.11.0 Apollo-Orig-Commit-AS: apollographql/apollo-server@491c80d
- [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - @apollo/[email protected] - @apollo/[email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] - [email protected] Apollo-Orig-Commit-AS: apollographql/apollo-server@056f083
This message was being issued when a new server starts up, prior to ever having a schema, when a storage secret (or any other artifact) can't be fetched from GCS (or any error within `updateServiceDefinitions`) despite the fact that there may be no `previousSchema`. While I could use `previousSchema` to change the error message, I don't think that it's this methods concern to decide what happens in the event of an error. I think it's only this methods concern to actually do the update, if it is in fact successful. Apollo-Orig-Commit-AS: apollographql/apollo-server@06c3267
Currently, we log the error and just return without throwing which causes `load` (one of two places where `updateComposition` is called to not actually fail and follow-up logic then suggests "Gateway successfully loaded schema", even though that cannot be true. The nice thing about this change (in addition to allowing someone to `catch` an error from `ApolloGateway.prototype.load`) is that this should bubble all the way up to the place where we currently call `load` within Apollo Server's constructor, and stop the server from starting in this failure condition: https://github.com/apollographql/apollo-server/blob/7dcee80ff33061c0911458d593ebbca5a9c73939/packages/apollo-server-core/src/ApolloServer.ts#L366 The other place we call `updateComposition` is within a `setTimeout`. That particular case is less troublesome since it will retry on the next interval. Apollo-Orig-Commit-AS: apollographql/apollo-server@1655f4b
Apollo-Orig-Commit-AS: apollographql/apollo-server@827cba2
No need to have them so far away from their usage and to even do these assignments at all when there are already escape routes that exit this code path. Apollo-Orig-Commit-AS: apollographql/apollo-server@7250bfe
* Refer to the thing we are processing consistently as "schema definitions". * Also make them generally more factual. Apollo-Orig-Commit-AS: apollographql/apollo-server@c1ee91e
…an error. Apollo-Orig-Commit-AS: apollographql/apollo-server@c3fb481
Rely on `message` only if it's present, and fall back to serialization methods which might exist on the prototype otherwise (e.g. `toJSON`, `toString`). Also, switch to a single parameter usage of the logging facility. While `console.log` supports it, its certainly possible that the logger will _not_, and will need that positional parameter for something else. Apollo-Orig-Commit-AS: apollographql/apollo-server@e1d97d3
While successful `updateComposition` invocations were working properly, failed invocations (including GCS access errors, network hiccups and just general configuration mistakes) were currently cluttering the logs with warnings of unhandled promise rejections. While those unhandled rejections did include the actual error messages, this adjusts them to be caught and logged in a structured manner with our `logger`, sparing our logs from those unnecessarily verbose (and scary!) messages. Apollo-Orig-Commit-AS: apollographql/apollo-server@da06fa8
Overall, the success/failure behavior should be expected to be similar for all of these requests, as they all access the same GCS store. Apollo-Orig-Commit-AS: apollographql/apollo-server@ee4c9ac
…cts. Because we want the actual executor to work when a schema might eventually become available, as it may when `onSchemaChange` hooks eventually succeed. Apollo-Orig-Commit-AS: apollographql/apollo-server@f878c7f
Apollo-Orig-Commit-AS: apollographql/apollo-server@4f2fbff
Co-Authored-By: Trevor Scheer <[email protected]> Apollo-Orig-Commit-AS: apollographql/apollo-server@03038e3
Co-Authored-By: Trevor Scheer <[email protected]> Apollo-Orig-Commit-AS: apollographql/apollo-server@4d4ab5b
This reverts commit d4e5b6e. Apollo-Orig-Commit-AS: apollographql/apollo-server@0a50943
To correct the syntax error. Co-Authored-By: Trevor Scheer <[email protected]> Apollo-Orig-Commit-AS: apollographql/apollo-server@554e20c
|
Minor suggestion: Update the names of the GitHub action status checks to be clear that they only apply to the Rust code? It was a bit surprising to see things like |
This was referenced Sep 11, 2020
abernix
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 11, 2020
Everything will continue, however, as federation becomes more independent from Apollo Server, it (and its concerns, like Apollo Gateway) move to their own repository. (It's always been relatively independent, but it didn't necessarily warrant its own repository before.) This includes `apollo-federation-integration-testsuite` (unpublished to npm), `@apollo/gateway (which lived in `packages/apollo-gateway` here and as `/gateway-js` on the new repository), and `@apollo/federation` (which lived in `packages/apollo-federation` here and as `/federation-js` on the new repository). See #4560 for details, and also apollographql/federation#134 for where (and how) it was introduced on the other side.
gateway-js/package.json
Outdated
| @@ -23,7 +23,6 @@ | |||
| "@apollo/query-planner-wasm": "0.0.2", | |||
| "@types/node-fetch": "2.5.4", | |||
| "apollo-engine-reporting-protobuf": "^0.5.2", | |||
| "apollo-env": "^0.6.1", | |||
abernix
added a commit
that referenced
this pull request
Sep 15, 2020
abernix
added a commit
that referenced
this pull request
Sep 15, 2020
This brings the existing documentation and its supporting infrastructure (in this case, modeled after the Apollo Server repository, but this is standard "Apollo infrastructure" in the general sense) to the Federation repository where it can live alongside the code that was migrated over in #134. Related: #142 Related: #143
This was referenced Sep 16, 2020
This was referenced Sep 16, 2020
Gateway: pass through errors encountered when running final execute
apollographql/apollo-server#4523
Closed
Closed
Closed
abernix
added a commit
that referenced
this pull request
Sep 17, 2020
… repo. (#158) This brings the existing documentation and its supporting infrastructure (in this case, modeled after the Apollo Server repository, but this is standard "Apollo infrastructure" in the general sense) to the Federation repository where it can live alongside the code that was migrated over in #134. Related: #142 Related: #143
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the renaming of this repository from
rusttofederation, this repository is slated to become the home for all Apollo Federation related concerns — including the current JavaScript implementations. Migrating these to a single repository will allow us to track conversations and development in a single place without being coupled to the Apollo Server repository.This has become particularly important as Apollo Federation has grown into its own product over the course of the last year, which can evolve separate from Apollo Server. In practice, changes have rarely affected or needed to be coupled to Apollo Server directly, apart from the initial support for accepting a
gatewayparameter on theApolloServerconstructor. We also see the increasing need for Apollo Gateway and Federation progress to be tracked separately from Apollo Server, since they tend to attract different segments of the community than a standalone GraphQL server does.Therefore, this PR brings the
@apollo/gatewayand@apollo/federationpackages which currently live in the Apollo Server repository along with the relevant JavaScript infrastructure for building them (with TypeScript) and testing them (with Jest).This is comprised of:
A
git filter-branchof commits on theapollo-serverrepository(Though technically I used the
git-filter-repowrapper for it for the first time, with great success.)In particular, targeting commits which have touched the
packages/apollo-gatewayandpackages/apollo-federationpackages. This preserves the entire history of commits from that repository. To create links to those for posterity, I've amended the commits withApollo-Orig-Commit-ASmetadata and also replaced any relative issue/PR numbers in those commit messages (e.g.,#1234) with absolute GitHub references pointing to the same (i.e.,apollographql/apollo-server#1234). And I did the same for bare commit identifiers when possible! (e.g,abc123👉apollographql/apollo-server@abc123).The CircleCI configuration to run on the
apollographql/federationrepoWhile we use GitHub Actions on the Federation repository today, the amount of automation for testing and publishing (including the generation of tarballs) which is already written into CircleCI configuration files is somewhat extensive right now and would require a fair bit of porting to make it exclusively GitHub Actions-based. (Perhaps a chore for another year.)
VSCode editor preferences for editor rules which must be enforced
This is just for line-endings, tab-rules, newline-at-end-of-file things, since VS Code doesn't support
.editorconfig(by default). I realize that most folks are using IntelliJ at the moment, so this is just for completeness to be on-par with the previous configuration. It parallels the.idea/configuration that is already present, but no attempts to modify that configuration have been made.Lerna configuration.
This is for publishing and management of npm versions since all of the tooling for such should be automated right now via the above CircleCi bits.
Affected PRs
Next steps
Push Lerna
gittags from theapollo-serverrepository 👉 (now tracked as [js-repo-migration] Push Lernagittags fromapollo-serverto this repo. #140)Since
lernauses Git tags to determine what has been released from which version and how to apply its version bumps, thegit tags that exist on theapollo-serverrepository (i.e.,@apollo/[email protected]) need to be pushed to this repository. I have those staged locally, but it's not worth pushing them if this PR doesn't land.Address above PRs 👉 (now tracked as [js-repo-migration] Address affected PRs #141)
As noted above, we'll need to prioritize which PRs there need to be brought over in what order. I will help usher this process through.
Move issues 👉 (now tracked as [js-repo-migration] Move federation issues to this repository #144 )
We have a number of outstanding issues on the Apollo Server repository. We should consider how those are involved the Rust-based Apollo Gateway and move them over accordingly.
Remove code from the
apollo-serverrepository (tracked in ℹ️ Federation Packages Repository Move apollo-server#4560)A corresponding PR on the
apollo-serverrepository should be opened which sunsets those files on that side of the equation, after this PR is landed.Move Documentation (in subsequent PRs on both
apollo-serverand here onfederation) 👉 (now tracked as [js-repo-migration] Migrate federation documentation #142 )Currently, this still lives in the Apollo Server documentation. I will coordinate with the DX and documentation teams to figure out what the correct information architecture might be so we could have that documentation live in this repository.
Move federation specification (in subsequent PRs, per previous bullet-point) 👉 (now tracked as [js-repo-migration] Migrate federation specification #143)
This should be automatically covered by the previous step for moving documentation (since the federation specification currently lives in the documentation), but it's worth noting here by itself to make sure it gets a proper home.
Unify Cradle 👉 (now tracked as [js-repo-migration] Give Cradle tests a singular home in this repo #145 )
Right now, this PR actually duplicates the
.featureCucumber files which were already being copied to this repository. A subsequent step should reduce the number of copies of them to one and that single copy should become the single source of truth for these gateway acceptance tests.Maybe: Move federation bits from
apollo-graphqlinto@apollo/federation👉 (now tracked as [js-repo-migration] RFC: Moveapollo-graphql's federation utilities into@apollo/federation#147)Bonus Maybe: Move
federation-jvmhere (in subsequent PR, maybe) 👉 (now tracked as RFC: Shouldfederation-jvmmove into this repository? #146)This is entirely contingent on outstanding ownership questions.
I can open any number of these as separate issues for tracking once we advance this PR.See issue links next to ticked check box items for follow-up issues.
What to review?
Since this is largely a replay of commits from the
apollo-serverrepository, nothing code-wise needs to be reviewed besides the last several commits on this branch.— listed here for your convenience!: