Replacement for http package using fetch

packages
1

As you might have realized, the http package will soon be deprecated, since it uses the deprecated request on the server.

However this would break a lot in our code, since it is a great isomorphic abstraction to HTTP calls and I managed to replace request with node-fetch on the server and kept the client code as it is.

You can check out the package on atmosphere and on GitHub.

Install via meteor remove http && meteor add jkuester:http

The API is 95% the same, expect for npmRequestOptions that were removed due to request being removed.

Any feedback is very welcomed!

9 Likes
2

There is the fetch package which is suppose to replace the http package, but it is not documented in the docs.
This is a good transition though!

3

nice work! since Meteor offers isomorphic fetch couldn’t you use the same code that you have for the server in your package more or less and use Meteor’s fetch to provide an http package compat. layer?

4

This could be a good direction. I simply didn’t touch the client code, since tests passed and I am currently a bit under pressure to deliver at work :sweat_smile:

5 Likes
5

@jkuester thanks so much for doing this. I spent about 4 hours yesterday trying to convert some of my REST calls to use fetch, and I was completely buried in all of the encoding issues, and trying to get the URL parameters and body in shape. In particular, Twilio was driving me crazy.

I just replaced all of that with your HTTP and it is working perfectly. Thanks again :unicorn:

4 Likes
6

Just updated to 2.0. Got the deprecation warning in my logs. From my packages, the following are dependent on HTTP:

  • facebook-oauth
  • mdg:meteor-apm-agent
  • mizzao:timesync

@jkuester am I right in thinking that under normal circumstances, if I use your HTTP package those aforementioned packages automatically default to it?

7

am I right in thinking that under normal circumstances, if I use your HTTP package those aforementioned packages automatically default to it?

Unfortunately not, because HTTP is not a global export and thus the accounts- packages will use the deprecated version (using request). This is why I’d like to discuss this topic. We have several options:

  • update accounts (and other core packages) to use fetch
  • update http to use the fetch (via merging jkuester:http into http)
  • keep accounts packages use the (updated/merged) http until they have been migrated
  • other options?
1 Like
8

On a project level, what we did as a transition is to copy jkuester:http to /packages/http folder and rename the package as http

3 Likes
9

I think we should do a major version upgrade to http where we merge your package in. In the meantime upgrading as much as possible in Meteor core to fetch would be great.

10

OK I will open a PR tonight

1 Like
11

Did the initial replacement in the usage (just the code, so far no testing, so there are probably mistakes):

12

noob question: is there a way to suppress the deprecation warning while we work on upgrading all the affected packages?

we have a user-status package which is causing deprecation messages afresh every few seconds and it’s pretty painful to use the browser console.

13

Ughh that would drive me crazy! I’m not aware of any measure to turn off such warnings; last resort could be to clone the package locally, then add it to your project and fix the code that’s causing the deprecation warning.

14

it’s certainly not ideal :sweat_smile:

I’m a little surprised HTTP has been deprecated and not patched, given how widely used it is in the meteor ecosystem. I guess a patch would be difficult though given that it semi-officially exposes the internal request instance on the server.

15

Patch is in progress: Patch http package to use fetch by jankapunkt · Pull Request #11313 · meteor/meteor · GitHub

3 Likes
16

FYI: I added a branch core-replacement, which is designed to allow you to override http until it’s fully patched. Read the docs on how to do it: GitHub - jankapunkt/meteor-http at core-replacement

4 Likes
17

FYI - I just released v. 2.1.0 of jkuester:http which now

  • adds AbortController support for distinct timeout handling on the server until we get native support on Node 16
  • moved all tests to meteortesting:mocha; added more tests
  • supports EJSON so sending custom types via HTTP is now possible, too :star_struck:
  • updated all code with linter fixes

Links:

5 Likes