Gatsby v3 + Apollo Client + Gatsby Cloud - ominous "unsafe method" warning.

[ardiewen]

I have a static site with dynamic data fetching capabilities utilizing:

• Gatsby v3
• Apollo Client v3 to make client-side dynamic queries
• an isomorphic fetch library like cross-fetch so that ssr pages don't complain
• Gatsby Cloud for fast cloud builds

Here's a minimal repro demonstrating a basic configuration of apollo client that is very much inline with both Gatsby and Apollo Client documentation.

If you're working at Gatsby and reading this, here's a build log for this minimal reproduction hosted on Gatsby Cloud.

When building the site, we get this particularly ominous message, emphasis on "future builds will need to rebuild all pages":

warn Unsafe builtin method was used, future builds will need to rebuild all pages
warn WebpackError: Unsafe builtin usage https.request
    at gatsby-starter-default/node_modules/node-fetch/lib/index.mjs:1432:1
    at gatsby-starter-default/node_modules/node-fetch/lib/index.mjs:1401:1
    at gatsby-starter-default/node_modules/cross-fetch/dist/node-ponyfill.js:10:1
    at gatsby-starter-default/node_modules/@apollo/client/link/http/createHttpLink.js:93:1
    at gatsby-starter-default/node_modules/zen-observable/lib/Observable.js:197:1
    at gatsby-starter-default/node_modules/zen-observable/lib/Observable.js:279:1
    at gatsby-starter-default/node_modules/@apollo/client/utilities/observables/Concast.js:57:1
    at gatsby-starter-default/node_modules/@apollo/client/utilities/observables/Concast.js:83:1
    at gatsby-starter-default/node_modules/@apollo/client/utilities/observables/Concast.js:75:1
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:474:1
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:513:24
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:627:1
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:650:1
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:576:1
    at gatsby-starter-default/node_modules/@apollo/client/core/QueryManager.js:583:1

  1430 |
  1431 |                // send request
> 1432 |                const req = send(options);
       | ^
  1433 |                let reqTimeout;
  1434 |
  1435 |                if (signal) {

My questions are:

1. Will this actually interfere with incremental / Gatsby Cloud cloud build functionality? Should I ignore this warning or will this actually cause issues if I want to get the max functionality out of a paid Gatsby Cloud instance.

2. Am I missing a configuration step in my minimal reproduction? We only use Apollo Client on the client side, but the Gatsby documentation for wrapRootElement says we should be mirroring the configuration for both gatsby-browser.js and gatsby-ssr.js

3. I've tried cross-fetch, isomorphic-fetch, isomorphic-unfetch libraries and they all show the same warnings, presumably because they all use node-fetch.

4. Is node-fetch intended to be labelled as unsafe? Or is this a mistake?

Thanks in advance for any insights!

[graysonhicks]

Hi @ardiewen , based on those logs it does appear that would impact Incremental Builds, but not Cloud Builds. I've contacted some other team members to help address the larger questions on node-fetch + v3.

[KyleAMathews]

Do you need to use a fetch library at all? It's built into the browser. Since you don't use fetch in ssr, you should just be able to drop the library which would fix the warning.

[ardiewen]

@KyleAMathews Thanks for following up. No, I don't have a specific requirement for a fetch library. The usage is based strictly on both Gatsby and Apollo documentation and examples:

1. Configuring Apollo Client v3 requires wrapping the root element with a provider. The gatsby-plugin-apollo community plugin maintained by @trevorblades sets the Apollo provider on both, and consequently is forced to use a fetch library, as I do in my minimal repro.

2. gatsby-browser documentation suggests using the equivalent wrapRootElement API in gatsby-ssr together.

   Note: There is an equivalent hook in Gatsby’s SSR API. It is recommended to use both APIs together. For example usage, check out Using redux.

3. Dropping the library is feasible for my use case, like you noted, since i'm only making client side calls with Apollo, but that means the wrapRootElement api on gatsby-browser and gatsby-ssr will differ. Is this okay?

Thanks again for your reply.

[ardiewen]

@graysonhicks sorry for the direct mention, but any chance I can get an update from the team on this? According to the documentation you linked:

This means that almost all builds in Gatsby Cloud will be incremental builds, building only the files that you have changed.

This is a bit contradictory, as it suggests that cloud builds are incremental by nature, unless you trigger manual actions such as a manual Trigger Build or Clear Cache and Build.

How do we test this in a minimal reproduction environment? How can I tell through gatsby-cloud logs when something is built incrementally vs not?

Finally, could I get a stance on whether or not using the wrapRootElement api in gatsby-browser.js is fine without replicating the same in gatsby-ssr.js?

It appears the Gatsby Store does it this way, but documentation says otherwise.

[ardiewen]

FWIW, here's an implementation with the Apollo Provider in gatsby-browser.js only:
https://gatsbyapolloclientsideonly.gatsbyjs.io/

And here's the changes in the minimal reproduction:
ardiewen/gatsby-with-apollo-warning#1

This seems to work fine. It just forces us to make "client-side only" components with Apollo queries in them to avoid Invariant / SSR errors during build.

[graysonhicks]

Hi @ardiewen . Yes, Incremental Builds are now part of open source, so a Cloud Build will be incremental by nature, but with parallelization and unique caching setting it apart from an Incremental Build anywhere else. I think if node-fetch is only used in gatsby-browser it shouldn't affect Incremental Builds.

As for identifying Cloud builds, there are a few ways. First, ensure you see this at the top of the logs:

Running Inc Build

That at least ensures the infrastructure is correct. But then you need to tell when the actual update is incremental. That really depends on the CMS source plugin, but here is a Wordpress example:

Note that it says which page is updating, and Gatsby is checking what has changed. The next place you would check is HTML page generation. If you edit one page, you expect only one page to be rebuilt. If you edit a component, however, you expect every page that uses that component to be rebuilt, but no more.

I hope that's helpful.

As for gatsby-ssr and gatsby-browser not matching, I believe that's okay when the browser code is only needed in the browser. There are many examples where pages need to SSR and re-render in the browser with the same Provider. But in your case, the fetches are only client side so not having them in gatsby-ssr seems fine.

[ardiewen]

Marking this as answered as this as it appears to be an issue with the particular fetch library being used.

• isomorphic-fetch DOESN'T have this issue while cross-fetch AND isomorphic-unfetch do

• isomorphic-fetch is implemented as a polyfill, while the others are implemented as ponyfill, so i tested the other two libraries as polyfills but unfortunately they still throw the same warning...

• isomorphic-fetch throws other errors / warnings, such as Node.js - realFetch.call is not a function Node.js - realFetch.call is not a function  matthew-andrews/isomorphic-fetch#194 , which is why we switched to cross-fetch in the first place.

TL;DR: use isomorphic-fetch