profile
viewpoint
遗忘
Jesse Rosenberger abernix @apollographql, @meteor Helsinki, Finland Core developer at Meteor Development Group.

abernix/chexo 1

Configure Hexo with the help of a Node module!

abernix/cluster 1

Clustering solution for Meteor with load balancing and service discovery

abernix/accounts-ui-semantic-ui 0

A Meteor package skinning the accounts-ui package for Semantic UI

abernix/android-versions 0

A node module to get Android versions by API level, NDK level, semantic version, or version name.

abernix/apollo-server 0

:earth_africa: GraphQL server for Express, Connect, Hapi, Koa and more

abernix/apollo-tooling 0

✏️ Tooling for development and production Apollo workflows

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha b9576891a45921875929a573f93c8f1477b3f4c1

Use `watch` rather than `serve` to "start". This makes the hot-reloading work in CodeSandbox.

view details

push time in an hour

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha 7e6c68bce8c36d8c2a65698b06ee7592512e122e

Light theme, and formatting.

view details

push time in an hour

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha a1fd7655f8ec77cdf809c7e13d742ab6baed57c6

Mount to `/`, instead of `/graphql`.

view details

push time in 2 hours

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha 64b8bc938a50d4324d5ae8b174bf1b859fb76212

Largely try to make things work with CodeSandbox. * Yarn * Node version via an npm module because you can't configure it otherwise. * Yarn scripts * Yarn.lock * Codesandbox config that makes sure it runs "start" rather than "serve" (why would it do that?!) * Also, this is my authoring, not that of my employer.

view details

push time in 2 hours

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha 5253a1e6373414726755dff976e594efec256adb

Largely try to make things work with CodeSandbox. * Yarn * Node version via an npm module because you can't configure it otherwise. * Yarn scripts * Yarn.lock * Codesandbox config that makes sure it runs "start" rather than "serve" (why would it do that?!) * Also, this is my authoring, not that of my employer.

view details

push time in 2 hours

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha c6472327d2f51fd120e3eb1d937f70d091696775

Update `package.json` to latest versions, add `yarn.lock`, add `node` dep. Largely for CodeSandbox usage.

view details

push time in 2 hours

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha ae9edf231462334cea638c8358df17f7bae6cffa

Update `package.json` to latest versions, add `yarn.lock`, add `node` dep. Largely for CodeSandbox usage.

view details

push time in 2 hours

push eventabernix/apollo-server-typescript-express

Jesse Rosenberger

commit sha 79ffdf62e8f26c3639e7debdf3ec646866608824

Update `package.json` to latest versions, add `yarn.lock`, add `node` dep. Largely for CodeSandbox usage.

view details

push time in 2 hours

delete branch abernix/apollo-server-typescript-express

delete branch : master

delete time in 2 hours

create barnchabernix/apollo-server-typescript-express

branch : main

created branch time in 2 hours

issue commentapollographql/rust

Implement query-planner tests (i.e., Cradle) into this repository

Oooo, good looking out, @Enrico2! Opened https://github.com/apollographql/apollo-server/issues/4384 to track that.

abernix

comment created time in a day

issue openedapollographql/apollo-server

gateway: query planner "mutation" tests

Currently, while the query planner does also work for planning mutations in a federated model, we're lacking tests for them in the query planner tests that exist today.

This tracks the need for those!

created time in a day

Pull request review commentapollographql/apollo-server

[BREAKING] Expand didEncounterErrors API

 export class RemoteGraphQLDataSource<TContext extends Record<string, any> = Reco     >,   ): ValueOrPromise<GraphQLResponse>; -  public didEncounterError(error: Error, _request: Request) {-    throw error;-  }+  public didEncounterError?(+    requestContextWithError: { error: Error, response?: Response, context: TContext, request: Request }

Ok, a lengthy comment I wrote got on this line was lost (possibly because of a bug between the keyboard and the chair) and I cannot recover it. I'll try to come back to this later, but please forgive my brevity right now:


The object that we colloquially refer to as the "request context" is the GraphQLRequestContext. It takes on a number of more narrowed forms further down in the apollo-server-types file. The user context, which is TContext in this signature proposal, is on the context property of that GraphQLRequestContext<TContext>.

The object you are proposing that we pass here to didEncounterError as requestContextWithError is not that "request context" (or even really a variation of it with merely error attached as the name suggests). Specifically, the request and response (which are certainly what I think you intend on exposing!) is a fetch.Request and fetch.Response, respectively (though provided via our apollo-server-env package), whereas a GraphQLRequestContext would contain { request: GraphQLRequest, response: GraphQLResponse }).

For now, I might just propose we merely add response: http.Response as the third parameter and not introduce a breaking change, barring further API design discussion. If the need is to also have user context (or it's important to have other GraphQLRequestContext-y things, like logger!) and it warrants a breaking change (which I will say, comes with the burden of making a more clear CHANGELOG record that explains the change to consumers), perhaps another approach could be to have the well-known requestContext as the first argument and the HTTP-transport specific properties as their own secondary parameter object, e.g.:

    requestContext: GraphQLRequestContext<TContext>,
    http: { error: Error, response: Response, request: Request },`

Though will need to pause and consider whether we want the pattern to be "The request context is always the last argument", which can sometimes be more durable for other-use-cases.

Anyhow, long-story-longer, but with forced brevity because I deleted everything: Maybe we can just add response as the third argument? (And probably rename both the positional parameters to httpRequest and httpResponse to reduce confusion?

michael-watson

comment created time in a day

pull request commentapollographql/apollo-server

[BREAKING] Expand didEncounterErrors API

Ok, looks like I lost a somewhat sizable comment on this PR. I will try to recover it!

michael-watson

comment created time in a day

Pull request review commentapollographql/apollo-server

[BREAKING] Expand didEncounterErrors API

 export class RemoteGraphQLDataSource<TContext extends Record<string, any> = Reco     >,   ): ValueOrPromise<GraphQLResponse>; -  public didEncounterError(error: Error, _request: Request) {-    throw error;

I don't quite understand what the original intention of this throw was, but I like the idea of removing it in the default implementation!

michael-watson

comment created time in a day

push eventapollographql/apollo-server

Andrew Levine

commit sha aaeac7197488096b11c8a35615cea9c32e366841

docs: Correct GET example variables in requests.md (#4381)

view details

push time in a day

PR merged apollographql/apollo-server

Correct GET example in docs/source/requests.md

variables URL parameter should be a URL-encoded, JSON-stringified object.

Verified the behavior with the apollo-link unit tests and the apollo-link GET implementation.

+1 -1

2 comments

1 changed file

DrewML

pr closed time in a day

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha 43470d6561bee31101f3afc56bdd154db3f92b30

Add CHANGELOG.md for #3895

view details

push time in a day

push eventapollographql/apollo-server

Holden Whitehead

commit sha 090586ce59026a76df223a61c6232e3e72e4e417

feat(fastify): context now receives request/reply object. (#3895) - Add createGraphQLServerOptions method.

view details

push time in a day

PR merged apollographql/apollo-server

apollo-server-fastify's context function now receives reply object. 🖇️ fastify

Problem

The context function in apollo-server-fastify is not receiving the reply object. This is due to the request and reply being spread into graphqlServerOptions(in resolveGraphqlOptions via runHttpQuery) - but graphqlServerOptions is expecting an object (here).

Related Issues

  • https://github.com/apollographql/apollo-server/issues/3156

Solution

Add applyContextArgs function which receives the reply and request being spread in, and places them into an object which is then passed into graphqlServerOptions.

Test plan

Confirm unit tests pass:

$ cd packages/apollo-server-fastify && jest

Closes https://github.com/apollographql/apollo-server/issues/3156

+53 -5

9 comments

3 changed files

HW13

pr closed time in a day

issue closedapollographql/apollo-server

Not able to access response object from context in apollo-server-fastify

Previously I was using apollo-server-express and I wanted to migrate to fastify so I change it to apollo-server-fastify. But it started giving lots of issues.

One of such issue is - Not able to access res object from context function. Below code was working perfectly but res object itself was not available with apollo-server-fastify

context: async ({ req, res, connection }) => {
// res <--------- undefined
    if (connection) {
      return {
        models,
      }
    }
    if (req) {
      const me = await getMe(req, res)
      return {
        models,
        me,
        secret: process.env.SECRET,
      }
    }
  },

closed time in a day

techyrajeev

push eventabernix/apollo-server

Jesse Rosenberger

commit sha 1bc02b9a08ed08c43ce40f1aa0d161e97b305f1d

Add CHANGELOG.md

view details

push time in a day

push eventapollographql/starwars-server

Jesse Rosenberger

commit sha 5aa2ab87eda591ef2a51b67712e197b0911dd59e

Pin the `graphql-subscriptions` at the version that doesn't break. See https://github.com/apollographql/starwars-server/pull/16 for details.

view details

Jesse Rosenberger

commit sha 22a3e91854aed259f882001cc2766fda3075fcd5

Delete `yarn.lock`. It was out of date and broken anyway.

view details

push time in 2 days

delete branch apollographql/starwars-server

delete branch : abernix/upgrade-deps-202007

delete time in 2 days

push eventapollographql/apollo-server

renovate[bot]

commit sha 6c72193a7ace54b8522c69f3ba26ab38da37ff9d

chore(deps): update dependency nodemon to v2 (#4374) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 3 days

PR merged apollographql/apollo-server

chore(deps): update dependency nodemon to v2 dependencies

This PR contains the following updates:

Package Type Update Change
nodemon (source) devDependencies major 1.19.4 -> 2.0.4

Release Notes

<details> <summary>remy/nodemon</summary>

v2.0.4

Compare Source

Bug Fixes

v2.0.3

Compare Source

Bug Fixes
  • package.json & package-lock.json to reduce vulnerabilities (a4490e2)

v2.0.2

Compare Source

Bug Fixes

v2.0.1

Compare Source

Bug Fixes

v2.0.0

Compare Source

Bug Fixes
Features
BREAKING CHANGES
  • Upgrading to chokidar@3 drops support for node@4, so nodemon is doing the same, and now supports node@8+
  • Chokidar upgrade means: massive CPU & RAM consumption improvements. 17x package & deps size reduction.

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+1 -1

0 comment

1 changed file

renovate[bot]

pr closed time in 3 days

PR closed apollographql/apollo-server

chore(deps): update dependency graphql-upload to v11 dependencies

This PR contains the following updates:

Package Type Update Change
graphql-upload dependencies major ^8.0.2 -> ^11.0.0

Release Notes

<details> <summary>jaydenseric/graphql-upload</summary>

v11.0.0

Compare Source

Major
  • Updated Node.js support to ^10.13.0 || ^12.0.0 || >= 13.7.0.
  • Added a package exports field with conditional exports to support native ESM in Node.js and keep internal code private, whilst avoiding the dual package hazard. Published files have been reorganized, so previously undocumented deep imports will need to be rewritten according to the newly documented paths.
  • Updated dev dependencies, some of which require newer Node.js versions than previously supported.
Patch
  • Updated the graphql peer dependency to 0.13.1 - 15, fixing #​200 via #​201.
  • Updated Prettier related package scripts.
  • Configured Prettier option semi to the default, true.
  • Ensure GitHub Actions run on pull request.
  • Also run GitHub Actions with Node.js v14.
  • Fixed the ignoreStream function tests for Node.js v14 with a new CountReadableStream test helper, fixing #​209.
  • Minor JSDoc wording tweak for consistency.
  • Mention Promise.allSettled in the readme “Tips” section.
  • Updated MDN Web Docs links.

v10.0.0

Compare Source

Major
  • Updated Node.js support from v8.10+ to v10+, as earlier versions have reached end-of-life.
  • Updated the fs-capacitor dependency to v6, which now requires Node.js v10+, via #​179.
  • Updated dev dependencies, some of which now require Node.js v10+.
  • Replaced the tap dev dependency with test-director, coverage-node, and hard-rejection to improve the dev experience and reduce the dev install size by ~75.7 MB. These new dev dependencies require Node.js v10+.
  • Reorganized files. This is only a breaking change for projects using undocumented deep imports.
  • Removed now redundant Node.js version compatibility logic in the processRequest function.
  • The processRequest function now places references to instances of the now exported and documented Upload class in the GraphQL operation for the GraphQLUpload scalar to derive its value, and the GraphQLUpload scalar now throws a GraphQLError when it parses an invalid value, fixing #​175 via #​181.
  • The GraphQLUpload scalar parseLiteral and serialize methods now throw GraphQLError (instead of Error) instances, with tweaked messages.
Minor
  • The createReadStream function in resolved file uploads now accepts options to configure the encoding and high water mark, fixing #​177 via #​179.
Patch
  • Removed the now redundant eslint-plugin-import-order-alphabetical and express-async-handler dev dependencies.
  • Stop using husky and lint-staged.
  • Use isobject for checking if values are enumerable, non-array objects.
  • Tests have been massively reorganized, refactored, and improved.
  • Test the GraphQLUpload scalar.
  • Test the ignoreStream function.
  • Moved the Upload class to its own file.
  • Added JSDoc for the Upload class instance property file.
  • Test the Upload class.
  • Improved JSDoc FileUpload typedef description.
  • Removed now redundant eslint-disable-next-line comments.
  • Use strict mode for scripts.

v9.0.0

Compare Source

Major
  • Updated Node.js support from v8.5+ to v8.10+, to match what the eslint dev dependency now supports. This is unlikely to be a breaking change for the published package.
  • Removed the Upload scalar promise resolved stream property that has been deprecated since v7, along with associated tests.
  • ESM is no longer published, due to CJS/ESM compatibility issues across recent Node.js versions, via #​169.
  • The file structure and non-index file exports have changed. This should only affect projects using undocumented deep imports.
Minor
  • Updated the fs-capacitor dependency to v4 to support Node.js v13, making required changes to the source and tests, via #​166.
  • JSDoc comments are now included in the published code.
  • Several anonymous functions have been named, for better error stack traces.
  • Setup GitHub Sponsors funding:
    • Added .github/funding.yml to display a sponsor button in GitHub.
    • Added a package.json funding field to enable npm CLI funding features.
Patch
  • Updated dev dependencies.
  • Removed the .nycrc.json file:
    • tap now ignores test files by default.
    • The lib/test-helpers directory is now ignored using tap CLI arguments due to tapjs/node-tap#​612.
  • Removed the esm and mjs package tags; they will be added back once native ESM is properly supported.
  • Updated JSDoc code examples to use CJS instead of ESM, as native ESM is not yet properly supported.
  • No longer test fs-capacitor implementation details such as temp file creation and cleanup.
  • Commented the reasons for several istanbul ignore next comments.

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+46 -18

1 comment

2 changed files

renovate[bot]

pr closed time in 3 days

PR closed apollographql/apollo-server

chore(deps): update dependency graphql-tools to v6 dependencies

This PR contains the following updates:

Package Type Update Change
graphql-tools dependencies major ^4.0.0 -> ^6.0.0
graphql-tools devDependencies major 4.0.8 -> 6.0.12

Release Notes

<details> <summary>ardatan/graphql-tools</summary>

v6.0.12

Compare Source

Come talk to us directly on our Discord channel Contact us here: the-guild.dev

What’s Changed

🐛 Bug Fixes

v6.0.11

Compare Source

Come talk to us directly on our Discord channel Contact us here: the-guild.dev

What’s Changed

🚀 Features

🐛 Bug Fixes

v6.0.10

Compare Source

Come talk to us directly on our Discord channel Contact us here: the-guild.dev

What’s Changed

🚀 Features

🐛 Bug Fixes

v6.0.9

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

  • Fix bad typing imports
  • transforms should support custom root type names (#​1607)
  • temporarily make delegationContext optional until next major version (#​1614)
  • feat(url-loader): ability to get executor and subscriber without introspected schema

v6.0.8

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

  • introduce Subschema class (#​1583)
  • refactor application of transforms (#​1574)
  • introduce input object field transformers: Filter/Rename/TransformInputObjectFields #​1551
  • Able to get generated subschema config instead of wrapped schema from UrlLoader.

v6.0.7

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

  • Introduce Webpack Loader and Node Require Extension (#​1579)
  • Fix skipGraphQLImport's behavior

v6.0.6

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

v6.0.5

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

  • Fix: resolve correct data if schema is wrapped (#​1562)

v6.0.4

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

v6.0.3

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

v6.0.2

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

v6.0.1

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

  • Fix issue in printSchemaWithDirectives (#​1528)
  • Fix mergeSchemas issuee with custom scalars (#​1530)
  • Add missing packages in graphql-tools npm package (#​1524)

v6.0.0

Compare Source

Contact us here for help, more necessary open source tools and Enterprise support or Chat with us on discord

A huge v6 release with a new monorepo structure!

You can learn more about changes by checking out our:

New Monorepo Structure

v5.0.0

Compare Source

If you like GraphQL Tools, maybe you will also like some of our other projects. Chat with us on discord

That is a major release where we went through all issues and PRs and got the library back into great shape. All known issues with schema stitching had been fixed. The main person which did the heavy lifting is @​yaacovCR which made the work alone on his own fork for many months.

List of changes:

Features
  • Support GraphQL v15 #​1332
  • Adds graphql-upload compatible scalar and link for proxying remote file uploads #​671
  • Add ability to merge fields from types from different schemas
  • Add transforms to wrap, extract, and rename fields #​1183
  • Add transform to filter object fields #​819
  • Exports visitSchema, SchemaVisitor, healSchema, healTypes, cloneSchema, cloneType, cloneDirective to enable more custom transforms. #​1070
  • Allow removing extra delegation layers by passing fetcher/link options directly to delegateToSchema, mergeSchemas, and transformSchema and by filtering directly with filterSchema without additional transformation round #​1165
  • Support CJS and ESM #​913 PR #​1320 PR #​1329
  • Add TransformQuery transform to allow delegating to subfields with error preservation #​543 PR #​1307
  • add WrapType transform to namespace subschema root queries (not for use with mutations) #​961 #​439 PR #​1307
  • Add HoistFields transform to hoist subfields from field to parent type #​781 PR #​1307
  • Add ability to specify custom root type names, with new transform RenameRootTypes that allows changing a subschemas root type, a necessary transform when the subschema includes the root query type within another output type #​892 PR #​1307
  • Add type merging, and otherwise restore onTypeConflict #​1133 #​1118 #​1044 #​863 #​642 #​447 PR #​1307
  • Expose createRequest functionality for alternative method of batching besides using links #​724 PR #​1307
  • Provide support for GraphQLUpload scalar with schema stitching #​671 PR #​1307
  • Let makeRemoteExecutableSchema, wrapSchema, transformSchema, mergeSchemas to specify a custom delegating resolver #​1302
  • Expose mapSchema (which creates new schemas), visitSchema (which modifies existing schemas), healSchema (which visitSchema uses), toConfig, as well as additional utility functions #​1070 #​922 #​786 #​761 PR #​1307
Bug Fixes
  • Avoid using internal api of graphql-js #​1331
  • Filter unused variables from map when proxying requests
  • Preserve subscription errors when using makeRemoteExecutableSchema
  • Preserve extensions when transforming schemas
  • Fix merging and transforming of custom scalars and enums #​501, #​1056, #​1200
  • Allow renaming of subscription root fields #​997, #​1002
  • Fix alias resolution to no longer incorrectly fallback to non-aliased field when null #​1171
  • Do not remove default directives (skip, include, deprecated) when not merging custom directives #​1159
  • Fixes errors support #​743, #​1037, #​1046
  • Fix mergeSchemas to allow resolvers to return fields defined as functions #​1061
  • Fix default values with mergeSchemas and addResolveFunctionsToSchema #​1121
  • Fix interface and union healing
  • Fix stitching unions of types with enums
  • Fix mocking to work when schema stitching
  • Fix lost directives when adding an enum resolver
  • Fix Circular Dependencies #​924 PR #​1326
  • Fix types #​1298 #​1279 #​837 #​1307 #​1325 #​1324
  • issues involving importing directories #​1242 #​1307
  • fix n^2 problem within makeRemoteExecutableSchema #​1346 PR #​1352

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+2978 -475

1 comment

11 changed files

renovate[bot]

pr closed time in 3 days

push eventapollographql/apollo-tooling

Jesse Rosenberger

commit sha cbf2e16489b68b37bf3488cdd05a4aedca36019e

Attempt to fix `graphql` pinning strategy within `apollo` package. Ref: https://cc.jro.cc/qGuK4gZn

view details

push time in 3 days

PR opened apollographql/starwars-server

Mostly upgrade dependencies, but avoid `graphql-subscriptions`.

A number of prior attempts to upgrade the dependencies in this repository (mostly in an effort to resolve the security advisories in dependent packages as surfaced by GitHub Security Advisories) has resulted in an upgrade that yielded a functioning GraphQL endpoint, but ultimately resulted in failing tests within the apollo-ios repository which tests against this repo's starwars-server.

The failing test in the apollo-ios repository is in the ApolloWebSocketTests scheme's StarWarsSubscriptionTests suite, notably testConcurrentSubscribing and testMultipleSubscriptions.

Being a bit more conservative about the upgrades, I was able to determine that it was the upgrade from graphql-subscriptions@1.0.0 to graphql-subscriptions@1.1.0 which yielded the failures in those tests.

Going in a bit further, it seems that https://github.com/apollographql/graphql-subscriptions/commit/c8a7f7cf4 is the specific culprit, since after git bisect-ing to that commit and subsequently applying the reversion to that commit to the default branch on graphql-subscriptions resolves the test failures.

We should zoom in more carefully on why that commit introduces failures. Even if it may be "working as intended", as a semver-minor bump, that should be unexpected. Further, the package's own test conditions were changed in that release. Given that the package was released over a year ago, I guess we'll need to figure out what it means.

+5513 -4947

0 comment

4 changed files

pr created time in 3 days

create barnchapollographql/starwars-server

branch : abernix/upgrade-deps-202007

created branch time in 3 days

startedgraphql-java/nadel

started time in 4 days

push eventapollographql/apollo-server

renovate[bot]

commit sha e97be6ca6d923879980bac25ecd81a27a9443b6c

chore(deps): pin dependencies (#4341) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 5 days

PR merged apollographql/apollo-server

chore(deps): pin dependencies dependencies

This PR contains the following updates:

Package Type Update Change
@types/react devDependencies pin ^16.9.9 -> 16.9.43
concurrently devDependencies pin ^4.1.2 -> 4.1.2
jest-cucumber devDependencies pin ^2.0.11 -> 2.0.11
nodemon (source) devDependencies pin ^1.19.3 -> 1.19.4
react (source) devDependencies pin ^16.10.2 -> 16.13.1
typescript (source) devDependencies pin ^3.6.3 -> 3.9.6

:pushpin: Important: Renovate will wait until you have merged this Pin PR before creating any upgrade PRs for the affected packages. Add the preset :preserveSemverRanges your config if you instead don't wish to pin dependencies.


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:ghost: Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+11 -11

0 comment

7 changed files

renovate[bot]

pr closed time in 5 days

push eventapollographql/apollo-server

Adam Zionts

commit sha 14b2b99e982b2654765f5b6e7e0d168f0f7aa97a

Follow up on changes to stitching migration doc (#3383) Co-authored-by: Adam Zionts <adam@meteor.com> Co-authored-by: Jesse Rosenberger <git@jro.cc>

view details

renovate[bot]

commit sha 59e1965d9dddd6d7f59918a930cd1afe825b6d29

chore(deps): update dependency ts-jest to v26 (#4129) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

Glen Thomas

commit sha 753e60cce49cd69a401ec0c82cfba1f0d9fa04b3

Fix federation Query/Mutation extends documentation (#4201) Co-authored-by: Jesse Rosenberger <git@jro.cc>

view details

renovate[bot]

commit sha be91c053453873628200069905dd9266543482f0

chore(deps): update dependency gatsby-theme-apollo-docs to v4.3.2 (#4307) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha a4f3709e41861f9f66badb1abd38b9d2fcc14182

chore(deps): update dependency winston to v3.3.3 (#4295) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha e1f17547b0a5d20d6e86654893e9e7429ce927c5

chore(deps): update dependency bunyan to v1.8.13 (#4319) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha df596adb99cc228238ee07a23557feec9fa49cda

chore(deps): update dependency gatsby to v2.23.11 (#4320) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 7df012a96f1f962032f7efd31f3e0c466d3b1f27

chore(deps): update dependency @types/aws-lambda to v8.10.57 (#4316) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 94828103497268f10af9896c61f21f25f08a32ac

chore(deps): update dependency @types/ioredis to v4.16.7 (#4317) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha cf7e66ec5560c4d30babba75d5f21092af0470cd

chore(deps): update dependency @types/lodash to v4.14.157 (#4318) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 5960e4273d6e5da7a82803c499cb56c673d61c4f

chore(deps): update dependency koa to v2.13.0 (#4296) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 89ccf3ff6595fba2ba3c0421ae8d35f7c458d861

chore(deps): update dependency winston-transport to v4.4.0 (#4294) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha e4341f7fc59b2e5bd7e439f2eaba8fda52d6ea8e

chore(deps): update dependency bunyan to v1.8.14 (#4321) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

Michael Watson

commit sha 452e816a6fe5139ec29ecda11554b77ecb6b6d6f

Upload Acephei Example

view details

Michael Watson

commit sha a2228fd20e07ea67a9c9222acae211cf2f2861a5

Enable running repo without Apollo Account using serviceList

view details

Michael Watson

commit sha 71bfafd7a1dc72526731a9ff8590460af8b45655

Fix op reg plugin

view details

jakeblaxon

commit sha de9095348b4debab536d539b5f6d5eab66b26453

fix(gateway): maintain immutability when merging selection sets (#4239)

view details

Kevin Mui

commit sha 2d2fddb10085c491d5d23122a9c25e3d005274bf

docs: Fix wrong url (#4322)

view details

Michael Watson

commit sha f62a2f107ee265b1872fb2bf38caa2da36466edf

Disable op reg if no api key Code cleanup: -Remove client code - Removed apollo cli reference as it was creating a duplicate graphql module that conflicted with Apollo Server library

view details

Michael Watson

commit sha 09bb4271a3da5f7131d1f342ce8fa128c93ea73a

Add readme LOL - had to purge that API key :smirk:

view details

push time in 5 days

push eventapollographql/apollo

renovate[bot]

commit sha 05cf4b70b94d92475076232c3057b7b2db56edc9

Update dependency react to v16.13.1 (#799) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 5 days

PR merged apollographql/apollo

Reviewers
Update dependency react to v16.13.1

This PR contains the following updates:

Package Type Update Change
react (source) dependencies minor 16.12.0 -> 16.13.1

Release Notes

<details> <summary>facebook/react</summary>

v16.13.1

Compare Source

React DOM
  • Fix bug in legacy mode Suspense where effect clean-up functions are not fired. This only affects users who use Suspense for data fetching in legacy mode, which is not technically supported. (@​acdlite in #​18238)
  • Revert warning for cross-component updates that happen inside class render lifecycles (componentWillReceiveProps, shouldComponentUpdate, and so on). (@​gaearon in #​18330)

v16.13.0

Compare Source

React
React DOM
Concurrent Mode (Experimental)

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+8 -8

0 comment

4 changed files

renovate[bot]

pr closed time in 5 days

create barnchapollographql/starwars-server

branch : abernix/try-again

created branch time in 5 days

startednst/iOS-Runtime-Headers

started time in 6 days

push eventapollographql/starwars-server

Jesse Rosenberger

commit sha a27e39d7c57409b3c57a75590f828ef884cd1323

Revert updates from previous commits This reverts commit b04fd3a11423b2fc7c90ec8207b663010dcc6abf. and This reverts commit 6fcc14166554d2cb7252d95597afb958ada20207. and This reverts commit 8a237445dc295bf09a605bd1f4079cb04bb39603. and This reverts commit bff8463a3c8594ff5ff583f9fe32a4c4907aa3b5. and I shouldn't attempt this upgrade again like everyone else already has before fixing the actual problem with the `ApolloWebSocket` test scheme's failing tests after applying the upgrade.

view details

push time in 6 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha 61314b44fd86e64af3765bfdc931be88e0452d07

Update Node.js version of docs Netlify builds.

view details

push time in 6 days

push eventapollographql/starwars-server

Jesse Rosenberger

commit sha b04fd3a11423b2fc7c90ec8207b663010dcc6abf

Also update `yarn.lock`.

view details

push time in 6 days

push eventapollographql/starwars-server

Jesse Rosenberger

commit sha 8a237445dc295bf09a605bd1f4079cb04bb39603

Remove `eslint`, which is already not passing .

view details

Jesse Rosenberger

commit sha 6fcc14166554d2cb7252d95597afb958ada20207

Update to latest babel and nodemon.

view details

push time in 6 days

push eventapollographql/starwars-server

Jesse Rosenberger

commit sha bff8463a3c8594ff5ff583f9fe32a4c4907aa3b5

Bump dependencies to resolve security warnings. Worth noting that linting was failing, even before this commit.

view details

push time in 6 days

push eventapollographql/fullstack-workshop-server

Jesse Rosenberger

commit sha 18215534dd60f5437d0c1d4c43bcae5abde920e2

General dependency updates. Largely just to silence a lot of outdated package's transitive dep warnings.

view details

push time in 6 days

push eventapollographql/fullstack-workshop-server

Jesse Rosenberger

commit sha dda616b275c36c97fc8e88128018810490646d32

General dependency updates. Largely just to silence a lot of outdated package's transitive dep warnings.

view details

push time in 6 days

startedlukeed/uvu

started time in 6 days

issue commentapollographql/apollo-tooling

apollo client:codegen --target typescript gives TypeError: context.getErrors is not a function

@anark @hamzahsn:

I'm copying and pasting the comments from @trevor-scheer on #1908 so you make sure you see them and can help test:

Update: The releases associated with this change can be found on the next dist-tag for the following packages.

apollo-graphql@0.5.0-alpha.0apollo-language-server@1.23.0-alpha.0apollo@2.29.0-alpha.0

To install the CLI from the next dist-tag, for example: npm i -D apollo@next

I'll be closing this PR in favor of the previously mentioned PRs. Thanks again @benhjames for the help with this!

Please try them out and provide feedback on the release PR #2032. Barring any issues I'll release this officially before the end of the week.

Please try the next versions and report back with updates!

anark

comment created time in 7 days

issue commentapollographql/rust

Implement federation query planner to be used by Apollo Gateway

@Enrico2 Sounds great to me; I like that suggestion.

Enrico2

comment created time in 7 days

issue openedapollographql/rust

Find a home for Cradle, the query-planner compatibility acceptance tests

apollographql/apollo-server#4297 introduced what are meant to be language-agnostic compatibility acceptance tests for query-plans. For now, Cucumber ".feature files" are the extent of this testing, but we believe this is just the beginning of a larger federation test-suite — which we're calling Cradle — that can satisfy testing requirements of various initiatives.

For example, when https://github.com/apollographql/rust/issues/103 has brought these tests into this repository, the work in https://github.com/apollographql/rust/issues/101 can take place and build a query-planner (in Rust!) that meets the expectations of the test-suite.

Thankfully, manually copying the files into this repository to maintain test-completeness is not our end-game. Furthermore, the Apollo Server repository should not remain the source of truth for those files. Cradle needs a home repository which will house its documentation and allow it to be utilized by other projects.

We need to figure out the details of how that work! (And this is the issue to discuss that in, if anyone has ideas!)

Incredibly naive, half-baked, straw-dog proposal: A separate repository that can be used as a Git submodule (or git subtree).

created time in 7 days

issue openedapollographql/rust

Implement query-planner tests (i.e., Cradle) into this repository

With the landing of https://github.com/apollographql/apollo-server/pull/4297 in the apollo-server repository, we now have the ".feature files" which are the beginnings of what we are calling Cradle.

These test files now act as compatibility acceptance tests for the current JavaScript query planner. The .feature format is meant to be language-agnostic and introducing them to this repository should act as the basis for implementing the port of our current buildQueryPlan into (I think) the query-planner module in this repository.

We imagine Cradle growing into something more complete in the future (along with finding an agnostic home for them to match our intention for them to stand on their own), but that work will be tracked in another issue. This issue is meant to track bringing those tests into this repository!

I believe the deliverables here are:

  1. Be able to iteratively develop on implementation of a Rust build_query_plan using the .feature files introduced in https://github.com/apollographql/apollo-server/pull/4297.
  2. Ensure that the same tests are also executed within CI.
  3. All tests to be demonstrated as being executed, but failing, as there is no implementation yet! (And the implementation is out of scope for this issue)
  4. Wholesale disabling of these tests in order to allow them to be incrementally disabled as the implementation grows to support their use-cases. This disabling might just be demonstrated as a separate commit.

Just to repeat: the very large caveat here is that all the tests will be failing. 😄

Some (possible!) considerations worth discussing, either along the way to or during exploration to implementing it might be:

  • Determine where the .feature files and the tests should live in this repository

    Likely no need research extensively — as I think moves would be somewhat effortless — but some parity with best-practices or patterns of other repos utilizing Cucumber tests might be worth considering.

  • Confirming that it's okay to merely copy (yes, roughly, cp there/*.feature here/.) the .feature files into this repository.

    Copy, you say?! My claim would be that, while I DO think we need to find a more permanent home for them, that they are not currently changing at a rapid-enough pace that copying them will be a problematic ergonomic. With this query-plan-porting-work in-progress, the JS query planner is effectively feature-frozen in its current state. I think the source of truth could remain in the apollo-server repository until either the point the Rust query planner is shipped OR we answer the question: "where is the permanent home for Cradle tests?" and migrate them there. (Also, I will open a separate issue for this!)

  • How to ignore .feature files. (I don't know enough about the implementation that will be necessary to understand what that would look like, but I think it will be important to be able to skip them or focus specific tests).

Possibly more! Feel free to discuss!

(cc @JakeDawkins who has been thinking about this)

created time in 7 days

issue commentapollographql/rust

Implement federation query planner to be used by Apollo Gateway

@Enrico2 Thanks for opening this issue; exciting to have the prototype bridge done.

I realize the function is currently a hard-coded, but otherwise empty shell of a complete implementation, but if @JakeDawkins were to start implementing the query plan tests against a function, would it be an appropriate to do it on the query_plan function in this branch?

https://github.com/apollographql/rust/blob/f88556cc2e3535162e8f495083b8fb3ef2a55c02/wasm-bridge/src/lib.rs#L11-L13

(All the tests would fail unless they are the actual hard-coded query-plan that is currently in there.)

Enrico2

comment created time in 7 days

pull request commentapollographql/rust

Add dependabot.yml for automatic updates.

In my experience, the automatic bumping of transitive dependencies by Renovate has only allowed surprise changes that were not documented in CHANGELOGs or were semantically larger breaking changes than claimed to slide in. Not automatically updating dependencies can actually maintain stability.

This repository should already get security updates through other means and running a dependency once every six months is, I think, not unreasonable.

The automatic updates also create extra PR noise. I'm not saying we should not turn this on eventually, I just don't see why this is a priority this month. We can turn this bot on in the future with the same number of lines of code.

Enrico2

comment created time in 7 days

pull request commentapollographql/rust

Add dependabot.yml for automatic updates.

I don't understand how updating our dependencies more often in an automated fashion would do anything to find gaps in a test suite that doesn't test those dependencies nuances.

I do not believe that automated dependency management, or even bumping our dependencies manually, is a critical part of this project at a stage like this and is more like to create subtle problems that we are more likely to get hung up on. Put another way, if we're building something today I don't see the need to bump dependencies ruthlessly as new versions come out and surprise us during our progress, particularly as we're just learning — and less equipped — how to debug subtle surprises.

Enrico2

comment created time in 7 days

pull request commentapollographql/rust

Add dependabot.yml for automatic updates.

I enjoy automated dependency management and think this is a worthy consideration.

In my experience, I've found that its success largely depends on the extensiveness of the repository's testing suite to exercise the stability and expectations of our usage of those dependencies (to be clear: not re-testing the package, but testing the expectations of the integration with the package). It does, to varying degrees, result in what appears to be successful upgrades which end up breaking something unexpectedly and undetected by the tests in place.

As this is a relatively new repository, and we're a relatively new team to Rust, I would lean on punting this for a few months. I think when the time arrives that the components from this repository are actually in a deliverable-ish form where they are ready to be consumed by external, that it's prudent to have dependency management to make sure bug fixes and security fixes are applied. (Though I think GitHub will still provide Security advisories regardless!)

Enrico2

comment created time in 7 days

push eventapollographql/apollo-tooling

renovate[bot]

commit sha 1bc3b29cb341e82fe554829c5e553e44ee847fb8

chore(deps): update dependency change-case to v4 (#1693) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 8 days

PR merged apollographql/apollo-tooling

chore(deps): update dependency change-case to v4 dependencies

This PR contains the following updates:

Package Type Update Change
change-case dependencies major ^3.0.1 -> ^4.0.0

Release Notes

<details> <summary>blakeembrey/change-case</summary>

v4.1.1

Compare Source

v4.1.0

Compare Source

v4.0.1

Compare Source

v4.0.0

Compare Source

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+589 -178

0 comment

5 changed files

renovate[bot]

pr closed time in 8 days

push eventapollographql/apollo-tooling

Renovate Bot

commit sha 23611bbea9dc46478f729ccb991fa7642b3cbf00

chore(deps): update dependency @types/table to v5

view details

Jesse Rosenberger

commit sha 4d1ce65414fe987c86c85924796befe632ba396b

chore(deps): update dependency @types/table to v5 (#1868) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 8 days

PR merged apollographql/apollo-tooling

chore(deps): update dependency @types/table to v5 dependencies

This PR contains the following updates:

Package Type Update Change
@types/table devDependencies major 4.0.7 -> 5.0.0

Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in 8 days

push eventapollographql/apollo-tooling

renovate[bot]

commit sha 569b2507fb401278e368cedf7b77a5bd24a7d212

chore(deps): update dependency memfs to v3 (#1692) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in 8 days

PR merged apollographql/apollo-tooling

chore(deps): update dependency memfs to v3 dependencies

This PR contains the following updates:

Package Type Update Change
memfs devDependencies major 2.17.1 -> 3.2.0

Release Notes

<details> <summary>streamich/memfs</summary>

v3.2.0

Compare Source

Bug Fixes
  • 'fromJSON()' did not consider cwd when creating directories (3d6ee3b)
Features
  • support nested objects in 'fromJSON()' (f8c329c)

3.1.3 (2020-05-14)

Bug Fixes
  • deps: update dependency fs-monkey to v1.0.1 (10fc705)

3.1.2 (2020-03-12)

Bug Fixes
  • should throw EEXIST instead of EISDIR on mkdirSync('/') (f89eede)

3.1.1 (2020-02-17)

Bug Fixes
  • deps: update dependency fs-monkey to v1 (ccd1be0)

v3.1.3

Compare Source

Bug Fixes
  • deps: update dependency fs-monkey to v1.0.1 (10fc705)

v3.1.2

Compare Source

Bug Fixes
  • should throw EEXIST instead of EISDIR on mkdirSync('/') (f89eede)

v3.1.1

Compare Source

Bug Fixes
  • deps: update dependency fs-monkey to v1 (ccd1be0)

v3.1.0

Compare Source

Features
  • replace fast-extend with native Object.assign (934f1f3)
  • specify engines field with node constraint of >= 8.3.0 (7d3b132)

3.0.6 (2020-02-16)

Bug Fixes
  • export DirectoryJSON from index (c447a6c)

3.0.5 (2020-02-15)

Bug Fixes
  • remove space from error message (42f870a)
  • use IStore interface instead of Storage (ff82480)
  • use PathLike type from node (98a4014)

3.0.4 (2020-01-15)

Bug Fixes
  • 🐛 handle opening directories with O_DIRECTORY (acdfac8), closes #​494

3.0.3 (2019-12-25)

Bug Fixes
  • rmdir: proper async functionality (cc75c56)
  • rmdir: support recursive option (1e943ae)
  • watch: suppress event-emitter warnings (1ab2dcb)

3.0.2 (2019-12-25)

Bug Fixes
  • watch: trigger change event for creation/deletion of children in a folder (b1b7884)

3.0.1 (2019-11-26)

Performance Improvements
  • ⚡️ bump fast-extend (606775b)

v3.0.6

Compare Source

Bug Fixes
  • export DirectoryJSON from index (c447a6c)

v3.0.5

Compare Source

Bug Fixes
  • remove space from error message (42f870a)
  • use IStore interface instead of Storage (ff82480)
  • use PathLike type from node (98a4014)

v3.0.4

Compare Source

Bug Fixes
  • 🐛 handle opening directories with O_DIRECTORY (acdfac8), closes #​494

v3.0.3

Compare Source

Bug Fixes
  • rmdir: proper async functionality (cc75c56)
  • rmdir: support recursive option (1e943ae)
  • watch: suppress event-emitter warnings (1ab2dcb)

v3.0.2

Compare Source

Bug Fixes
  • watch: trigger change event for creation/deletion of children in a folder (b1b7884)

v3.0.1

Compare Source

Performance Improvements
  • ⚡️ bump fast-extend (606775b)

v3.0.0

Compare Source

Bug Fixes
  • 🐛 adjust definition of TCallback to accept null for error parameter (aedcbda)
  • 🐛 adjust return of Link#walk to return Link | null (1b76cb1)
  • 🐛 adjust type of children in Link to be possibly undefined (b4945c2)
  • 🐛 allow _modeToNumber to be called w/ undefined (07c0b7a)
  • 🐛 allow _modeToNumber to return undefined (3e3c992)
  • 🐛 allow assertEncoding to be called w/ undefined (e37ab9a)
  • 🐛 allow Dirent~build to accept undefined for the encoding parameter (8ca3550)
  • 🐛 allow flagsToNumber to be called w/ undefined (dbfc754)
  • 🐛 allow mkdtempBase to be called w/ undefined for encoding (f28c395)
  • 🐛 allow modeToNumber to be called w/ undefined (336821d)
  • 🐛 allow realpathBase to be called w/ undefined for encoding (e855f1c)
  • 🐛 create tryGetChild util function (b5093a1)
  • 🐛 create tryGetChildNode util function (62b5a52)
  • 🐛 define the type elements in the Volume.releasedFds array (9e21f3a)
  • 🐛 don't assign null to ._link property in FSWatcher (71569c0)
  • 🐛 don't assign null to ._steps property in FSWatcher (0e94b9c)
  • 🐛 don't assign null to .buf property in Node (00be0c2)
  • 🐛 don't assign null to .link property in File (5d01713)
  • 🐛 don't assign null to .node property in File (d06201e)
  • 🐛 don't assign null to .node property in Link (4d7f439)
  • 🐛 don't assign null to .parent property in Link (b3e60b6)
  • 🐛 don't assign null to .symlink property in Node (9bfb6f5)
  • 🐛 don't assign null to StatWatcher.prev property (fd1a253)
  • 🐛 don't assign null to StatWatcher.vol property (1540522)
  • 🐛 don't set #vol or #parent of link to null (b396f04)
  • 🐛 enable strictNullChecks (3896de7)
  • 🐛 make StatWatcher.timeoutRef property optional (d09cd03)
  • 🐛 refactor #access to be compatible w/ strictNullChecks (82ed81b)
  • 🐛 refactor #copyFileSync to be compatible w/ strictNullChecks (40f8337)
  • 🐛 refactor #createLink to be compatible w/ strictNullChecks (7d8559d)
  • 🐛 refactor #ftruncate to be compatible w/ strictNullChecks (f2ea3f1)
  • 🐛 refactor #mkdir to be compatible w/ strictNullChecks (d5d7883)
  • 🐛 refactor #mkdirp to be compatible w/ strictNullChecks (6cf0bce)
  • 🐛 refactor #mkdtempBase to be compatible w/ strictNullChecks (d935b3b)
  • 🐛 refactor #mkdtempSync to be compatible w/ strictNullChecks (7e22617)
  • 🐛 refactor #newFdNumber to be compatible w/ strictNullChecks (0bc4a15)
  • 🐛 refactor #newInoNumber to be compatible w/ strictNullChecks (e9ba56c)
  • 🐛 refactor #openFile to be compatible w/ strictNullChecks (1c4a4ba)
  • 🐛 refactor #openLink to be compatible w/ strictNullChecks (216a85f)
  • 🐛 refactor #read to be compatible w/ strictNullChecks (87b587f)
  • 🐛 refactor #readdirBase to be compatible w/ strictNullChecks (ab248b4)
  • 🐛 refactor #readFileBase to be compatible w/ strictNullChecks (27a4dad)
  • 🐛 refactor #readlinkBase to be compatible w/ strictNullChecks (b2e0f76)
  • 🐛 refactor #resolveSymlinks to be compatible w/ strictNullChecks (6dc4913)
  • 🐛 refactor #statBase to be compatible w/ strictNullChecks (ba0c20a)
  • 🐛 refactor #symlink to be compatible w/ strictNullChecks (4148ad3)
  • 🐛 refactor #truncate to be compatible w/ strictNullChecks (fadbd77)
  • 🐛 refactor #watch to be compatible w/ strictNullChecks (415a186)
  • 🐛 refactor #watchFile to be compatible w/ strictNullChecks (2c02287)
  • 🐛 refactor #write to be compatible w/ strictNullChecks (2ba6e0f)
  • 🐛 refactor #writeFile to be compatible w/ strictNullChecks (ac78c50)
  • 🐛 refactor #writeFileBase to be compatible w/ strictNullChecks (e931778)
  • 🐛 refactor #writeSync to be compatible w/ strictNullChecks (7b67eea)
  • 🐛 refactor copyFile tests to be compatible w/ strictNullChecks (e318af2)
  • 🐛 refactor errors to be compatible w/ strictNullChecks (b25c035)
  • 🐛 refactor exists tests to be compatible w/ strictNullChecks (81a564f)
  • 🐛 refactor renameSync tests to use tryGetChildNode (8cd782a)
  • 🐛 refactor volume tests to be compatible w/ strictNullChecks (f02fbac)
  • 🐛 refactor volume tests to use tryGetChild (5a6624f)
  • 🐛 refactor volume tests to use tryGetChildNode (34acaac)
  • 🐛 refactor writeFileSync tests to be compatible w/ strictNullChecks (4b7f164)
  • 🐛 remove unused getArgAndCb function (f8bb0f8)
  • 🐛 replace throwError fn w/ inline throw createError() calls (c9a0fd6)
Features
  • 🎸 enable TypeScript strict null checks (1998b24)
BREAKING CHANGES
  • TypeScript strict null checks are now enabled which may break some TypeScript users.

2.17.1 (2019-11-26)

Bug Fixes
  • set-up semantic-release packages (0554c7e)

2.15.5 (2019-07-16)

Bug Fixes

2.15.4 (2019-06-01)

Bug Fixes
  • 🐛 accept null as value in fromJSON functions (9e1af7d)
  • 🐛 annotate return type of toJSON functions (6609840)

2.15.3 (2019-06-01)

Bug Fixes
  • 🐛 mocks process.emitWarning for browser compatibility (e3456b2), closes #​374

2.15.2 (2019-02-16)

Bug Fixes
  • 🐛 BigInt type handling (c640f25)

2.15.1 (2019-02-09)

Bug Fixes
  • 🐛 show directory path when throwing EISDIR in mkdir (9dc7007)
  • 🐛 throw when creating root directory (f77fa8b), closes #​325

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+8 -15

0 comment

2 changed files

renovate[bot]

pr closed time in 8 days

Pull request review commentapollographql/apollo-server

Michael watson/add acephei example

+{+  "name": "federation-demo",+  "description": "Full federation demo to illuminate good design patterns and practices.",+  "scripts": {+    "watch": "tsc --build tsconfig.json --watch",+    "start": "nodemon -e js,graphql,json --watch services start.js",+    "postinstall": "tsc --build tsconfig.json",+    "check": "concurrently \"npm:check:*\"",+    "push": "concurrently \"npm:push:*\"",+    "clean": "git clean -dfqX -- ./node_modules **/{dist,node_modules}/ ./{services,clients}/*/tsconfig.tsbuildinfo ./__tmp__*",+    "check:accounts": "npx apollo service:check --localSchemaFile=./services/accounts/schema.graphql --serviceName=accounts",+    "check:books": "npx apollo service:check --localSchemaFile=./services/books/schema.graphql --serviceName=books",+    "check:products": "npx apollo service:check --localSchemaFile=./services/products/schema.graphql --serviceName=products",+    "check:reviews": "npx apollo service:check --localSchemaFile=./services/reviews/schema.graphql --serviceName=reviews",+    "push:accounts": "npx apollo service:push --localSchemaFile=./services/accounts/schema.graphql --serviceName=accounts --serviceURL=https://acephei-accounts.herokuapp.com",+    "push:books": "npx apollo service:push --localSchemaFile=./services/books/schema.graphql --serviceName=books --serviceURL=https://acephei-books.herokuapp.com",+    "push:products": "npx apollo service:push --localSchemaFile=./services/products/schema.graphql --serviceName=products --serviceURL=https://acephei-products.herokuapp.com",+    "push:reviews": "npx apollo service:push --localSchemaFile=./services/reviews/schema.graphql --serviceName=reviews --serviceURL=https://acephei-reviews.herokuapp.com"+  },+  "dependencies": {+    "accounts": "file:services/accounts",+    "books": "file:services/books",+    "gateway": "file:services/gateway",+    "products": "file:services/products",+    "reviews": "file:services/reviews"+  },+  "devDependencies": {+    "@types/react": "^16.9.9",+    "concurrently": "^4.1.2",

Oh, right. Thank you. I forgot about the two-copies of graphql conflict, even though it has been a low-key bane of its (it being apollo, the CLIs) existence and a pressing reason why it needs to be npx'd.

michael-watson

comment created time in 8 days

push eventapollographql/apollo-server

renovate[bot]

commit sha be91c053453873628200069905dd9266543482f0

chore(deps): update dependency gatsby-theme-apollo-docs to v4.3.2 (#4307) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha a4f3709e41861f9f66badb1abd38b9d2fcc14182

chore(deps): update dependency winston to v3.3.3 (#4295) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha e1f17547b0a5d20d6e86654893e9e7429ce927c5

chore(deps): update dependency bunyan to v1.8.13 (#4319) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha df596adb99cc228238ee07a23557feec9fa49cda

chore(deps): update dependency gatsby to v2.23.11 (#4320) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 7df012a96f1f962032f7efd31f3e0c466d3b1f27

chore(deps): update dependency @types/aws-lambda to v8.10.57 (#4316) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 94828103497268f10af9896c61f21f25f08a32ac

chore(deps): update dependency @types/ioredis to v4.16.7 (#4317) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha cf7e66ec5560c4d30babba75d5f21092af0470cd

chore(deps): update dependency @types/lodash to v4.14.157 (#4318) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 5960e4273d6e5da7a82803c499cb56c673d61c4f

chore(deps): update dependency koa to v2.13.0 (#4296) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 89ccf3ff6595fba2ba3c0421ae8d35f7c458d861

chore(deps): update dependency winston-transport to v4.4.0 (#4294) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha e4341f7fc59b2e5bd7e439f2eaba8fda52d6ea8e

chore(deps): update dependency bunyan to v1.8.14 (#4321) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

jakeblaxon

commit sha de9095348b4debab536d539b5f6d5eab66b26453

fix(gateway): maintain immutability when merging selection sets (#4239)

view details

Kevin Mui

commit sha 2d2fddb10085c491d5d23122a9c25e3d005274bf

docs: Fix wrong url (#4322)

view details

Jesse Rosenberger

commit sha 0830b6604e23eff21c5415f16833231c8bd30b51

chore(op-reg): Switch from `node-fetch` to `make-fetch-happen`. (#4326) This is a similar treatment as to what was applied to `@apollo/gateway` in https://github.com/apollographql/apollo-server/pull/3783. This replaces a "fetcher" implementation we'd been maintaining (which continues to grow in complexity) which was built on [`node-fetch`][1]. Instead, it switches to an off-the-shelf [Fetch API][2]-compliant implementation called [`make-fetch-happen`][3] which leverages [`minipass-fetch`][4] under the hood. It's also what `npm` uses internally! Whereas `node-fetch` is relatively bare-bones and necessitated us writing our own [conditional request][5], `make-fetch-happen` just does these things (and also other things, like supporting `HTTP_PROXY` out of the box!). It does, however, need us to provide a cache store since we cannot use its (default) file-system based cache (which leverages the powerful [`cacache`][6] implementation used by `npm`) since file-systems are not available in all of our supported integrations. Therefore, this duplicates the same cache implementation used in `@apollo/gateway`. If there was a suitable place to depend on this code from both of these packages, we could depend on this implementation from that location, but I didn't immediately see a great place for that to live. Also, rule of threes or something? (Also worth noting that it _already includes_ the fix which I opened in https://github.com/apollographql/apollo-server/pull/4325 / 2f29c604095fc which needed to be applied to the gateway implementation.) This does REMOVE A TEST which was previously valuable but should no longer be nearly as valuable. Specifically, since we now have an HTTP implementation that handles conditional requests, a cache, and retries itself, we do handle intermediary retries within that layer. We still test the polling (i.e, the literal existence of an interval which re-fires) in other tests, but it was too tricky to try to re-jigger this test with the abstraction. I think this is a good thing to not need to worry about, but we can consider re-adding it in the event of regressions. [1]: https://npm.im/node-fetch [2]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API [3]: https://npm.im/make-fetch-happen [4]: https://npm.im/minipass-fetch [5]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests [6]: https://npm.im/cacache

view details

Jesse Rosenberger

commit sha 4736c18753322f5978a2c1199348015c1a218d4f

fix(gateway): Don't cache 302 responses from the registry. (#4325) This affects only the communication with the registry, not with anything related to sending requests to the implementer's graph or its downstream services. A `HEAD` request has no body to cache and a 304 response could have only been negotiated (with the server) by means of a conditional request header (e.g., `if-none-match` or `if-modified-since`). We do NOT want to write to the cache in either of these cases! Without avoiding this cache write, we will invalidate the cache, thus causing subsequent conditional requests (e.g., `If-None-Match: "MD%") to be lacking content to conditionally request against and necessitating a full request/response.

view details

Jesse Rosenberger

commit sha 18449adc3a86f2a55ccb9db79179db1d51624465

Unify various `CHANGELOG.md` formats. Trying to further align these so its possible to copy-paste more effortlessly and be more comfortable with their (shared) patterns. cc @trevor-scheer

view details

Jesse Rosenberger

commit sha 65037ffa032595f2afcb6a39bd45049ccfcb366e

Add missing CL entry for `apollo-server-plugin-operation-registry@0.4.2`.

view details

Jesse Rosenberger

commit sha e4fc190242187600ed351fe1f6e4a44204c8cdde

Update CHANGELOG.md files prior to publishing.

view details

Jesse Rosenberger

commit sha 8cfc947ed56fa3f32b82b32b4bcca53470712984

Release - apollo-cache-control@0.11.1 - apollo-datasource-rest@0.9.3 - apollo-datasource@0.7.2 - apollo-engine-reporting-protobuf@0.5.2 - apollo-engine-reporting@2.2.1 - @apollo/federation@0.16.10 - @apollo/gateway@0.16.10 - apollo-server-azure-functions@2.15.1 - apollo-server-cache-memcached@0.6.6 - apollo-server-cache-redis@1.2.2 - apollo-server-caching@0.5.2 - apollo-server-cloud-functions@2.15.1 - apollo-server-cloudflare@2.15.1 - apollo-server-core@2.15.1 - apollo-server-env@2.4.5 - apollo-server-errors@2.4.2 - apollo-server-express@2.15.1 - apollo-server-fastify@2.15.1 - apollo-server-hapi@2.15.1 - apollo-server-integration-testsuite@2.15.1 - apollo-server-koa@2.15.1 - apollo-server-lambda@2.15.1 - apollo-server-micro@2.15.1 - apollo-server-plugin-base@0.9.1 - apollo-server-plugin-operation-registry@0.4.3 - apollo-server-plugin-response-cache@0.5.3 - apollo-server-testing@2.15.1 - apollo-server-types@0.5.1 - apollo-server@2.15.1 - apollo-tracing@0.11.1 - graphql-extensions@0.12.4

view details

Jake Dawkins

commit sha ba59c44d800bcc1aa6f65706d3694d26c3322987

Update QP tests to use JSON serializer (#4297)

view details

Trevor Scheer

commit sha 97c3acd03a315364de8420f9111c0f578cba494c

Colocate `make-fetch-happen` types within packages (#4333) The hand-written make-fetch-happen types are required to exist within the packages that use them in order for them to build correctly when installed within another project. This reverts the portion of #4326 which moves these types to the top level of the project and duplicates them across the two packages which depend on them: apollo-gateway and apollo-server-plugin-operation-registry.

view details

push time in 8 days

pull request commentapollographql/apollo-server

[apollo-server-lambda] Add support for `isBase64Encoded`

@styfle I put it on the milestone (2.16.0) where I believe it'll land. I try to drop messages on PRs within a release when the release ships, based on that milestone's contents — It's a manual ergonomic, but not usually too hard for me to remember. 😉

It probably won't be this week — since it'd be great to get a few more things into this release — but I'm trying to get some triaging and releasing done before Tuesday!

styfle

comment created time in 8 days

push eventapollographql/apollo-server

Steven

commit sha b830d6e850bca81111fca5c5358330bd8a0af6a0

feat(lambda): Add support for `isBase64Encoded` (#4311) Support AWS Lambda Proxy when `event.isBase64Encoded` is `true` by decoded from Base64 when that is the case.

view details

push time in 8 days

PR merged apollographql/apollo-server

[apollo-server-lambda] Add support for `isBase64Encoded` 🖇️ lambda

This PR adds support for Lambda Proxy when isBase64Encoded: true.

The body must be decoded from base64 before parsing JSON.

https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html

+11 -6

2 comments

2 changed files

styfle

pr closed time in 8 days

issue commentapollographql/rust

issue and PR templates

I think this is a great idea! In fact, I've been meaning apply this to the Apollo Server repository for a while and your opening of this issue was apparently the reignited inspiration I needed to execute.

So, NEW art ✨ :

  • https://github.com/apollographql/apollo-server/issues/new/choose

And some existing art 🎨 in our org:

  • https://github.com/apollographql/apollo-client/issues/new/choose
  • https://github.com/apollographql/apollo-android/issues/new/choose
ashleygwilliams

comment created time in 9 days

push eventstyfle/apollo-server

jakeblaxon

commit sha de9095348b4debab536d539b5f6d5eab66b26453

fix(gateway): maintain immutability when merging selection sets (#4239)

view details

Kevin Mui

commit sha 2d2fddb10085c491d5d23122a9c25e3d005274bf

docs: Fix wrong url (#4322)

view details

Jesse Rosenberger

commit sha 0830b6604e23eff21c5415f16833231c8bd30b51

chore(op-reg): Switch from `node-fetch` to `make-fetch-happen`. (#4326) This is a similar treatment as to what was applied to `@apollo/gateway` in https://github.com/apollographql/apollo-server/pull/3783. This replaces a "fetcher" implementation we'd been maintaining (which continues to grow in complexity) which was built on [`node-fetch`][1]. Instead, it switches to an off-the-shelf [Fetch API][2]-compliant implementation called [`make-fetch-happen`][3] which leverages [`minipass-fetch`][4] under the hood. It's also what `npm` uses internally! Whereas `node-fetch` is relatively bare-bones and necessitated us writing our own [conditional request][5], `make-fetch-happen` just does these things (and also other things, like supporting `HTTP_PROXY` out of the box!). It does, however, need us to provide a cache store since we cannot use its (default) file-system based cache (which leverages the powerful [`cacache`][6] implementation used by `npm`) since file-systems are not available in all of our supported integrations. Therefore, this duplicates the same cache implementation used in `@apollo/gateway`. If there was a suitable place to depend on this code from both of these packages, we could depend on this implementation from that location, but I didn't immediately see a great place for that to live. Also, rule of threes or something? (Also worth noting that it _already includes_ the fix which I opened in https://github.com/apollographql/apollo-server/pull/4325 / 2f29c604095fc which needed to be applied to the gateway implementation.) This does REMOVE A TEST which was previously valuable but should no longer be nearly as valuable. Specifically, since we now have an HTTP implementation that handles conditional requests, a cache, and retries itself, we do handle intermediary retries within that layer. We still test the polling (i.e, the literal existence of an interval which re-fires) in other tests, but it was too tricky to try to re-jigger this test with the abstraction. I think this is a good thing to not need to worry about, but we can consider re-adding it in the event of regressions. [1]: https://npm.im/node-fetch [2]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API [3]: https://npm.im/make-fetch-happen [4]: https://npm.im/minipass-fetch [5]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests [6]: https://npm.im/cacache

view details

Jesse Rosenberger

commit sha 4736c18753322f5978a2c1199348015c1a218d4f

fix(gateway): Don't cache 302 responses from the registry. (#4325) This affects only the communication with the registry, not with anything related to sending requests to the implementer's graph or its downstream services. A `HEAD` request has no body to cache and a 304 response could have only been negotiated (with the server) by means of a conditional request header (e.g., `if-none-match` or `if-modified-since`). We do NOT want to write to the cache in either of these cases! Without avoiding this cache write, we will invalidate the cache, thus causing subsequent conditional requests (e.g., `If-None-Match: "MD%") to be lacking content to conditionally request against and necessitating a full request/response.

view details

Jesse Rosenberger

commit sha 18449adc3a86f2a55ccb9db79179db1d51624465

Unify various `CHANGELOG.md` formats. Trying to further align these so its possible to copy-paste more effortlessly and be more comfortable with their (shared) patterns. cc @trevor-scheer

view details

Jesse Rosenberger

commit sha 65037ffa032595f2afcb6a39bd45049ccfcb366e

Add missing CL entry for `apollo-server-plugin-operation-registry@0.4.2`.

view details

Jesse Rosenberger

commit sha e4fc190242187600ed351fe1f6e4a44204c8cdde

Update CHANGELOG.md files prior to publishing.

view details

Jesse Rosenberger

commit sha 8cfc947ed56fa3f32b82b32b4bcca53470712984

Release - apollo-cache-control@0.11.1 - apollo-datasource-rest@0.9.3 - apollo-datasource@0.7.2 - apollo-engine-reporting-protobuf@0.5.2 - apollo-engine-reporting@2.2.1 - @apollo/federation@0.16.10 - @apollo/gateway@0.16.10 - apollo-server-azure-functions@2.15.1 - apollo-server-cache-memcached@0.6.6 - apollo-server-cache-redis@1.2.2 - apollo-server-caching@0.5.2 - apollo-server-cloud-functions@2.15.1 - apollo-server-cloudflare@2.15.1 - apollo-server-core@2.15.1 - apollo-server-env@2.4.5 - apollo-server-errors@2.4.2 - apollo-server-express@2.15.1 - apollo-server-fastify@2.15.1 - apollo-server-hapi@2.15.1 - apollo-server-integration-testsuite@2.15.1 - apollo-server-koa@2.15.1 - apollo-server-lambda@2.15.1 - apollo-server-micro@2.15.1 - apollo-server-plugin-base@0.9.1 - apollo-server-plugin-operation-registry@0.4.3 - apollo-server-plugin-response-cache@0.5.3 - apollo-server-testing@2.15.1 - apollo-server-types@0.5.1 - apollo-server@2.15.1 - apollo-tracing@0.11.1 - graphql-extensions@0.12.4

view details

Jake Dawkins

commit sha ba59c44d800bcc1aa6f65706d3694d26c3322987

Update QP tests to use JSON serializer (#4297)

view details

Trevor Scheer

commit sha 97c3acd03a315364de8420f9111c0f578cba494c

Colocate `make-fetch-happen` types within packages (#4333) The hand-written make-fetch-happen types are required to exist within the packages that use them in order for them to build correctly when installed within another project. This reverts the portion of #4326 which moves these types to the top level of the project and duplicates them across the two packages which depend on them: apollo-gateway and apollo-server-plugin-operation-registry.

view details

Trevor Scheer

commit sha 23f790bfe60074d545fc2703cf41204bb5860416

Release - @apollo/federation@0.16.11 - @apollo/gateway@0.16.11 - apollo-server-plugin-operation-registry@0.4.4

view details

Trevor Scheer

commit sha 1e60a798f3e119f53b0f3bb1f65158f4086ef9bb

Update changelogs for release

view details

Trevor Scheer

commit sha 39e678c58f984a52c8d5299449c333bda9f1e0be

feat(federation): Use extensions instead of custom `federation` objects (#4313) Note: BREAKING CHANGE In order to guarantee the safe usage of extensions, we must now require `graphql@>14.5.0`. As such, we've narrowed the range in federation and gateway's `peerDependencies`. Composition in its current form modifies the graphql-js types in order to accommodate some additional metadata required during composition, validation, query planning, and execution. This is no longer required due to the addition of 'extensions', which this is intended to be used exactly for. This commit transitions our usages of these custom metadata objects into the extensions object where they belong.

view details

Trevor Scheer

commit sha c508e67de169cb599b74ef5db11464bd5251ef92

Ignore changes in md files during release Currently, Lerna wants to release a change to apollo-server-plugin-operation-registry due to updates to the changelog. Changelog updates shouldn't be cause for a release, so we can ignore changes to those files (as well as other md files, except for some minor exceptions which we can work around).

view details

Trevor Scheer

commit sha 56d1bd9beb0658313bfb51ad00522dfabb57a186

Release - @apollo/federation@0.17.0 - @apollo/gateway@0.17.0

view details

Trevor Scheer

commit sha 81e92b2ad6e3d96e890096079e96a6368395552f

Update changelogs for publish

view details

renovate[bot]

commit sha 9ffb9502954b77b69a70fdb57a36d2aac3a900f0

chore(deps): update dependency @types/ioredis to v4.17.0 (#4342) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

Jesse Rosenberger

commit sha e376c891e1bc20a02ff2dc388f47a0fe6b201a8e

Adjust the GitHub Issue Templates

view details

Jesse Rosenberger

commit sha 74f08ccad001ddcf86a799c04389259b0a011c09

Merge branch 'abernix/issue-templates' into main

view details

Jesse Rosenberger

commit sha e88874d664c1f5817e6b8e7204328b365f102f9b

Add emojis to issue template configuration for consistency This aligns them with the other topics.

view details

push time in 9 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha e2accbecc49fa7eed768e6901b1e8f5ccacbda7b

Allow blank issues for the time-being.

view details

push time in 9 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha eeeecfb0999a80bc2710d8032a50c848a7b7d8ff

Prefix the "Question" types with "Question:"

view details

push time in 9 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha e88874d664c1f5817e6b8e7204328b365f102f9b

Add emojis to issue template configuration for consistency This aligns them with the other topics.

view details

push time in 9 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha e376c891e1bc20a02ff2dc388f47a0fe6b201a8e

Adjust the GitHub Issue Templates

view details

Jesse Rosenberger

commit sha 74f08ccad001ddcf86a799c04389259b0a011c09

Merge branch 'abernix/issue-templates' into main

view details

push time in 9 days

create barnchapollographql/apollo-server

branch : abernix/issue-templates

created branch time in 9 days

push eventstyfle/apollo-server

Jesse Rosenberger

commit sha e621ccb415df45fcee880725207b5d642c6a2568

Update CHANGELOG.md

view details

push time in 9 days

startedIBM/graphql-query-generator

started time in 10 days

startedmobile-shell/mosh

started time in 13 days

startedgraphile/federation

started time in 13 days

delete branch abernix/meteor-base

delete branch : patch-1

delete time in 14 days

starteddrop-ice/dear-github-2.0

started time in 14 days

PR opened graphql/graphql-wg

Add Jesse Rosenberger to 2020-07-02 agenda.
+1 -0

0 comment

1 changed file

pr created time in 14 days

push eventabernix/graphql-wg

Jesse Rosenberger

commit sha 2141d8198df0767453882f9dfade47b6bb7c4fbe

Add Jesse Rosenberger to 2020-07-02 agenda.

view details

push time in 14 days

delete branch abernix/graphql-wg

delete branch : patch-7

delete time in 14 days

delete branch apollographql/apollo-server

delete branch : jsegaran/schema_report_env_var

delete time in 15 days

issue commentapollographql/rust

move CDN into CLI dir

I like this. I believe that there is some auto-deployment of that code happening via a GitHub Action (to Cloudflare) that might need to be adjusted, but otherwise seems like a better tiered structure of concerns to me (due to the CDN being the component that is responsible for the installation/distribution of the CLI)

ashleygwilliams

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 export class ApolloGateway implements GraphQLService {   }    public async load(options?: { engine?: GraphQLServiceEngineConfig }) {-    await this.updateComposition(options);+    if (options && options.engine) {+      if (!options.engine.graphVariant)+        this.logger.warn('No graph variant provided. Defaulting to `current`.');+      this.engineConfig = options.engine;+    }      if (isManagedConfig(this.config) || this.experimental_pollInterval) {+      await this.updateComposition();       if (!this.pollingTimer) this.pollServices();+    } else {+      try {+        await this.updateComposition();+      } catch {+        // In the case that we're neither managed nor polling, the gateway should+        // crash in the event that it can't load service definitions. Leaving the+        // gateway running in a non-operable state doesn't make sense and this+        // allows container managers like K8s to restart the broken container.+        // Note: the error caught within `this.updateComposition` handles logging

Curious: What's the justification for having the error printed in updateComposition rather than here? There is fair amount of functionality that seems like it could throw in there and, broadly, this seems like a better place to catch any of those errors that are not explicitly catch'd within updateComposition right now (e.g., queryPlanStore.flush-ing, invocations of experimental_didUpdateComposition, etc.)

trevor-scheer

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 export class ApolloGateway implements GraphQLService {   }    public async load(options?: { engine?: GraphQLServiceEngineConfig }) {-    await this.updateComposition(options);+    if (options && options.engine) {+      if (!options.engine.graphVariant)+        this.logger.warn('No graph variant provided. Defaulting to `current`.');+      this.engineConfig = options.engine;+    }      if (isManagedConfig(this.config) || this.experimental_pollInterval) {+      await this.updateComposition();       if (!this.pollingTimer) this.pollServices();+    } else {+      try {+        await this.updateComposition();+      } catch {+        // In the case that we're neither managed nor polling, the gateway should+        // crash in the event that it can't load service definitions. Leaving the+        // gateway running in a non-operable state doesn't make sense and this+        // allows container managers like K8s to restart the broken container.+        // Note: the error caught within `this.updateComposition` handles logging+        // for the relevant error.+        process.exit(1);

At the very least, I think we need to guard if process exists before calling process.exit, but as a larger hesitation, I'm worried about to shipping this process.exit invocation either way.

Concretely: We have no idea what else is running successfully in this process that we're exiting.
It may be doing other important things! I think providing the primitives to users to make these decisions on their own is fine. In that regard, a failing health check seems like sufficient criteria for the container system to make a determination as to the process' fate. If the health check fails, K8s can terminate the process and restart it, no?

trevor-scheer

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 const serviceDefinitions = [   url: `http://localhost:${i}`, })); +let logger: Logger;++beforeEach(() => {+  const warn = jest.fn();+  const debug = jest.fn();+  const error = jest.fn();+  const info = jest.fn();++  logger = {+    warn,+    debug,+    error,+    info,+  };+});+

I have also been repeating this pattern in many places. Perhaps at some point soon (not now), we should just make a spyableLogger?

trevor-scheer

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 it.each([   spyGetServiceDefinitionsFromStorage.mockRestore(); }); -it('Rollsback to a previous schema when triggered', async () => {+it.skip('Rollsback to a previous schema when triggered', async () => {

it.goaway? 😄 😭 Just leaving this note here so we don't inadvertently commit it.

trevor-scheer

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 describe('Downstream service health checks', () => {       ).rejects.toThrowErrorMatchingInlineSnapshot(`"500: Internal Server Error"`);     }); -    it('Rolls over to new schema when health check succeeds', async () => {+    it.skip('Rolls over to new schema when health check succeeds', async () => {

🥌

trevor-scheer

comment created time in 15 days

Pull request review commentapollographql/apollo-server

WIP - fix(gateway): Prevent inoperable state on initial failure to load configuration

 describe('ApolloGateway executor', () => {       queryHash: 'hashed',       context: null,       cache: {} as any,+      logger,     });      expect(errors![0].message).toMatch(-      'Variable "$first" got invalid value "3"; Expected type Int.',+      'Variable "$first" got invalid value "3";',     );   });    it('still sets the ApolloServer executor on load rejection', async () => {-    jest.spyOn(console, 'error').mockImplementation();-     const gateway = new ApolloGateway({-      // Empty service list will throw, which is what we want.+      // Empty service list will trigger the gateway to crash on load, which is what we want.       serviceList: [],+      logger,     }); +    // Mock implementation of process.exit with another () => never function.+    // This is because the gateway doesn't just throw in this scenario, it crashes.+    const mockExit = jest+      .spyOn(process, 'exit')+      .mockImplementation((code) => {+        throw new Error(code?.toString());+      });+     const server = new ApolloServer({       gateway,       subscriptions: false,+      logger,     });      // Ensure the throw happens to maintain the correctness of this test.     await expect(       server.executeOperation({ query: '{ __typename }' })).rejects.toThrow();      expect(server.requestOptions.executor).toBe(gateway.executor);++    expect(logger.error.mock.calls).toEqual([+      ["Error checking for changes to service definitions: Tried to load services from remote endpoints but none provided"],+      ["This data graph is missing a valid configuration. 1"]

I guess 1 is the code from process.exit's callback above? Maybe we could just have the thrown error in these tests be prefixed with something (e.g. Exit code: ${code?.toString()}) just to make this stray 1 in this error seem more self-explanatory?

trevor-scheer

comment created time in 15 days

issue commentapollographql/apollo-server

Introduce `serverWillStop` life-cycle hook to plugin API

For me, this thinking about the nested nature begs another question of whether it makes sense to have requestDidStart (somewhere) within serverWillStart. This would be a breaking change (not too hard to re-structure for users, however!) to the current API, but here's my thinking...

Specifically, consider a case where an instance of something needs to be created by a plugin at server startup, made available to requests, and cleaned up on shutdown. Whether or not it needs to be available to the context that is received by resolvers is not specified. Some examples:

  • A pool of database connections.
  • A persistent connection / backhaul.
  • An audit log.

I demonstrated the intention of this nested approach in a comment on https://github.com/apollographql/apollo-server/pull/3988, but I'll quote it here:

A note about the pattern: The addition of the willResolveField hook in this PR continues with the nested approach (e.g. willResolveField is within executionDidStart is within requestDidStart) that the plugin API previous introduced and is one of its strengths. Seen in the example below, this provides a natural way to scope variables within related spans of the request life-cycle and provides narrowed TypeScript typing via the requestContext which is received along the way.

The TypeScript definitions demonstrate the precision of that narrowing and can be best seen within the apollo-server-plugin-base module:

https://github.com/apollographql/apollo-server/blob/52418a4f3732b004f581655d426d20df21c9e0be/packages/apollo-server-plugin-base/src/index.ts#L56-L116

The block scope approach within requestDidStart seems nice to me, particularly since the variable scope of objects initialized in requestDidStart are available naturally in willResolveField and fall out of scope naturally after the request. More granularly, this seems even more powerful: a variable declared and assigned in executionDidStart only exists during the execution-phases and not at the Request level.

     requestDidStart: () => {
        const variableScopedInExecutionDidStart = ":rocket:";
        return {
          executionDidStart: () => {
            const variableScopedInExecutionDidStart = ":wave:";
            return {
              willResolveField({ source, args, context, info }) {
                return () => {
                  console.log(variableScopedInExecutionDidStart, variableScopedInExecutionDidStart)
                }
              }
            }
          }
        }
      }

Currently, requestDidStart is not nested within the serverWillStart hook. I don't think requestDidStart would go directly within serverWillStart, but within serverDidStart seems right. (serverDidStart doesn't exist yet either, and is another extension of this issue's feature ask!).

What I'm getting at is, for me, it's seeming natural (and like we've not thus embraced this the way I would expect) on the serverWillStart hook, where this pattern would seem more aligned with the nested goals:

Note: This is not supported right now!

const plugin = {
  serverWillStart: async () => {
    const pool = await getPool();
    return {
      serverDidStart: () => ({
        requestDidStart: () => ({
          /* Request-hooks here! */
        }),
        serverWillStop: async () => {
          /* This would be triggered by calling `.stop` or a TERM/INT to the process */
          await pool.flushAndClose();
          return {
            serverDidStop: () => {
              console.log(":door:")
            }
          }
        }
      })
    }
  }
};

This feels more properly tiered to me, though it does eliminate the shorter-hand approach we have now for, e.g.:

const plugin = {
  requestDidStart() {
  }
};

Thoughts?

abernix

comment created time in 15 days

issue commentapollographql/apollo-server

Introduce `serverWillStop` life-cycle hook to plugin API

As a nexts step / natural extension of the feature: I think it may be reasonable to, when we have process Events and we're certain we understand the dynamics of the runtime (generally speaking, Node.js), pre-wire it to invoke ApolloServer.prototype.stop automatically.

I don't have firm feelings on the pairing between Node.js process events and this serverWillStop, but beforeExit seems somewhat relevant and it's possible that it could be an async hook to allow — in the same way beforeExit allows it — to keep work on the event loop prior to actual shutdown.

That prompts the question of whether the next hook to introduce might be a synchronous serverDidStop and whether it should be wired up to exit + SIGTERM + SIGINT.

abernix

comment created time in 15 days

issue commentapollographql/apollo-server

Introduce `serverWillStop` life-cycle hook to plugin API

Thanks for your perspective on this, @andrewmcgivery!

I agree with your point about the gotcha and I do think the most urgent need for this hook could first be met by documenting how to wire it up in Node.js!

abernix

comment created time in 15 days

startedwalmartlabs/lacinia

started time in 16 days

Pull request review commentapollographql/apollo-server

Update QP tests to use JSON serializer

+import gql from 'graphql-tag';+import path from 'path';+import {+  GraphQLSchemaModule,+  GraphQLSchemaValidationError,+} from 'apollo-graphql';+import { defineFeature, loadFeature } from 'jest-cucumber';+import { DocumentNode, GraphQLSchema, GraphQLError } from 'graphql';+import { composeServices, buildFederatedSchema, normalizeTypeDefs } from '@apollo/federation';++import { QueryPlan } from '../..';+import { LocalGraphQLDataSource } from '../datasources/LocalGraphQLDataSource';+import { buildQueryPlan, buildOperationContext } from '../buildQueryPlan';++const buildQueryPlanFeature = loadFeature(+  './packages/apollo-gateway/src/__tests__/build-query-plan.feature'+);+++const features = [+  buildQueryPlanFeature+];++function buildLocalService(modules: GraphQLSchemaModule[]) {+  const schema = buildFederatedSchema(modules);+  return new LocalGraphQLDataSource(schema);+}++features.forEach((feature) => {+  defineFeature(feature, (test) => {+    feature.scenarios.forEach((scenario) => {+      test(scenario.title, async ({ given, when, then }) => {+        let query: DocumentNode;+        let schema: GraphQLSchema;+        let errors: GraphQLError[];+        let queryPlan: QueryPlan;+        let options: any = {};++        const serviceMap = Object.fromEntries(+          ['accounts', 'product', 'inventory', 'reviews', 'books', 'documents'].map(+            serviceName => {+              return [+                serviceName,+                buildLocalService([+                  require(path.join(+                    __dirname,+                    '__fixtures__/schemas',+                    serviceName,+                  )),+                ]),+              ] as [string, LocalGraphQLDataSource];+            },+          ),+        );++        ({ schema, errors } = composeServices(+          Object.entries(serviceMap).map(([serviceName, service]) => ({+            name: serviceName,+            typeDefs: normalizeTypeDefs(service.sdl()),+          })),+        ));++        if (errors && errors.length > 0) {+          throw new GraphQLSchemaValidationError(errors);+        }++        const givenQuery = () => {+          given(/^query$/im, (operation) => {+            query = gql(operation)+          })+        }++        const whenUsingAutoFragmentization = () => {+          when(/using autofragmentization/i, () => {+            options = { autoFragmentization: true };+          })+        }++        const thenQueryPlanShouldBe = () => {+          then(/^query plan$/i, (expectedQueryPlan) => {+            queryPlan = buildQueryPlan(+              buildOperationContext(schema, query, undefined),+              options+            );++            const serializedPlan = JSON.parse(JSON.stringify(queryPlan, serializeQueryPlanNode));+            const parsedExpectedPlan = JSON.parse(expectedQueryPlan);++            expect(serializedPlan).toEqual(parsedExpectedPlan);+          })+        }++        // step over each defined step in the .feature and execute the correct+        // matching step fn defined above+        scenario.steps.forEach(({ stepText }) => {+          if (/^query$/i.test(stepText)) givenQuery();+          else if (/using autofragmentization/i.test(stepText)) whenUsingAutoFragmentization();+          else if (/^query plan$/i.test(stepText)) thenQueryPlanShouldBe();+          else throw new Error('Invalid steps in .feature file');

Ok! Not necessary to do it right now. There's only one file that it could be right now, as you noted!

JakeDawkins

comment created time in 16 days

created tagapollographql/apollo-server

tagpublish/20200630112026

🌍 GraphQL server for Express, Connect, Hapi, Koa and more

created time in 16 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha 8cfc947ed56fa3f32b82b32b4bcca53470712984

Release - apollo-cache-control@0.11.1 - apollo-datasource-rest@0.9.3 - apollo-datasource@0.7.2 - apollo-engine-reporting-protobuf@0.5.2 - apollo-engine-reporting@2.2.1 - @apollo/federation@0.16.10 - @apollo/gateway@0.16.10 - apollo-server-azure-functions@2.15.1 - apollo-server-cache-memcached@0.6.6 - apollo-server-cache-redis@1.2.2 - apollo-server-caching@0.5.2 - apollo-server-cloud-functions@2.15.1 - apollo-server-cloudflare@2.15.1 - apollo-server-core@2.15.1 - apollo-server-env@2.4.5 - apollo-server-errors@2.4.2 - apollo-server-express@2.15.1 - apollo-server-fastify@2.15.1 - apollo-server-hapi@2.15.1 - apollo-server-integration-testsuite@2.15.1 - apollo-server-koa@2.15.1 - apollo-server-lambda@2.15.1 - apollo-server-micro@2.15.1 - apollo-server-plugin-base@0.9.1 - apollo-server-plugin-operation-registry@0.4.3 - apollo-server-plugin-response-cache@0.5.3 - apollo-server-testing@2.15.1 - apollo-server-types@0.5.1 - apollo-server@2.15.1 - apollo-tracing@0.11.1 - graphql-extensions@0.12.4

view details

push time in 16 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha 65037ffa032595f2afcb6a39bd45049ccfcb366e

Add missing CL entry for `apollo-server-plugin-operation-registry@0.4.2`.

view details

Jesse Rosenberger

commit sha e4fc190242187600ed351fe1f6e4a44204c8cdde

Update CHANGELOG.md files prior to publishing.

view details

push time in 16 days

push eventapollographql/apollo-server

Jesse Rosenberger

commit sha 18449adc3a86f2a55ccb9db79179db1d51624465

Unify various `CHANGELOG.md` formats. Trying to further align these so its possible to copy-paste more effortlessly and be more comfortable with their (shared) patterns. cc @trevor-scheer

view details

push time in 16 days

Pull request review commentapollographql/apollo-server

Add ability to have user-specified cache headers and values

 app.use('/graphql', bodyParser.json(), graphqlExpress({   }, })); ```++### Using custom header keys and/or values++In certain situations you may want to specify the header key or value, for example, when using a CDN that requires a custom header for edge-caching. This can be achieved with the following configuration:++```javascript+cacheControl: {+  calculateHttpHeaders: true,+  headerKey: 'Edge-Control',+  buildHeaderValue: (hint) => `!no-store, max-age=${hint.maxAge}`

What if, rather than introducing headerKey and buildHeaderValue:

  • calculateHttpHeaders was allowed to be false, true, or an Object.

  • When false (i.e., calculateHttpHeaders: false), it would NOT include the header.

  • When defined as an Object (e.g., calculateHttpHeaders: {}), then the keys would be cache-control headers and the corresponding value for those keys would be functions to generate the value. Your buildHeaderValue function would seem almost perfectly appropriate for this, though I'd suggest calling the argument policy, rather than hint since "hints" are what are applied to the schema and the "policy" is the computation of the overall determination based on those hints. The type would, however, be a duplication of the current CacheHint type:

    calculateHttpHeaders: {
      "Edge-Control": (policy: CachePolicy) => `!no-store, max-age=${hint.maxAge}`,
    },
    
  • When it was true, it would continue to calculate cache-control exactly as it did before. It would be syntactic sugar for:

    calculateHttpHeaders: {
      "Cache-Control": (policy: CachePolicy) =>
                         `max-age=${hint.maxAge}, ${policy.scope.toLowerCase()}`,
    },
    
  • I think there's (maybe?) even an option here where the values on the Object could be Boolean values to enable the default header. That would enable someone to have a Cache-control header that uses the default Apollo Server behavior in addition to a Edge-Control that did something custom:

    calculateHttpHeaders: {
      "Edge-Control": (policy: CachePolicy) =>
                         `!no-store, max-age=${hint.maxAge}`,
      "Cache-Control": true,
    },
    

I think this also allows us to keep all HTTP-transport specific preferences within an HTTP-specific property and off the top-level options (since this package is theoretically intended for general cache control use, not just over HTTP).

tomphilbin

comment created time in 16 days

more