refactor(node): moving to native fetch
#1053
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🐳 Context
The amount of dependencies we use to make a
fetch
call to both the ReadMe and Metrics APIs is a bit off the rails right now:node-fetch
for the POST request to record a log.api@6
which uses not onlynode-fetch
, by way ofisomorphic-fetch
, but it also usesoas
,@readme/oas-to-har
,fetch-har
,json-schema-to-ts
, but also our OpenAPI definition to make very simple GET requests to retrieve project and version data.api@7
wouldn't be much of a change because that still uses everything listed her butnode-fetch
. The complexity overhead for these two small API calls is a bit much.api@6
also uses a very old version of ouroas
library and the work involved to upgrade that here, without just outright moving over toapi@7
is non-trivial. It's easier to move off it entirely.1So I'm refactoring all of this away.
🧰 Changes
node-fetch
for nativefetch
.fetch
is readily available to us.api
for ReadMe API calls for nativefetch
.json-schema-to-ts
.msw
to the latest release as the v2 release better supports nativefetch
.form-data
as we have access a nativeFormData
API.2multer
too because in the tests it was used it wasn't actually being used.caseless
.@types/har-format
to being a dev dependency as we're only using it for types and aren't exporting anything from it for external use.Footnotes
There's something to be said for dogfooding our own SDK software here but because we are unable to do so in any other SDK language, and
api
is unoptimized due to its design language requiring consulting an OpenAPI definition before every request IMHO it's not worth it for something as mission critical as our Metrics SDKs. ↩Not to mention one that actually follows the
FormData
spec. Don't get me started... ↩