Customized node-fetch instance for source?


In our cloud infra, Node.js services (including the ones just for SSR) use standardized basic libraries/middlewares to make sure common DevOps operations such as observability of the service can be enforced, and engineers can achieve this goal by using the internally published such NPM packages.

One example of such libraries is a custom-configured node-fetch instance - standardizing things such as logging, universal request id generation, etc.

Looks like Frontity uses node-fetch library for the source package (implemented by wp-source):

Currently it doesn’t look like this node-fetch instance can be customized officially as a supported feature of Frontity. I’m requesting this for the reasons explained above.



Allow passing in one or more of the following for node-fetch customizations:

  • an already configured/wrapped node-fetch instance
  • an option object to configure all node-fetch supported options



Possible solution

To make such customizations more scalable/flexible, an alternative architecture choice is to allow registering custom Koa middlewares, but it might be tricky since Frontity support both SSR/CSR and it’s hard to make the middlewares isomorphic.

@luisherranz Could this be related to the Server Extensibility feature somehow? Is this something that will be covered there or it’s something different?

@fancheng33 would something like this help?

If so, maybe you can create a Frontity package that does just that and it is abstracted from your other packages, can be installed in multiple projects, and so on.