I see v2.0 just launched, with http package deprecated. Does this mean it will no longer work, or is there a transition period? I use it heavily throughout my project, so will need to spend time replacing and don’t want to upgrade before knowing the answer 
1 Like
Maybe this is a good time to ask, whether you guys think it makes sense instead of deprecating the package to rewrite it to use fetch under the hood (which is basically done already), while preserving the API to the outside. I think there are many core packages using HTTP, too (including accounts-* packages) and by doing so we can be sure to keep up with the tech (using fetch instead of request) but can keep things backwards-compatible until the next major release.
What do you think?
8 Likes
I think it’s a great idea.
In fact, a deprecation only expresses an intention to discontinue the given API in the future; for the time being the deprecated API can be used just as before. It’s a heads up, and, under circumstances, a deprecation can also be revoked.
3 Likes
I had the same question but I am struggling to find any documentation on the fetch package.
If I have an “HTTP.call(…)” on my server side, what do I need to replace it with?
This would be ideal for me. I’m using HTTP.get and HTTP.post all over – on both client and server side.
1 Like
That’s a very good point. We already have quite a number of abandoned packages on Atmosphere. It would be bad if some of them fail completely because they rely on HTTP. So, if it is doable, yes please!
2 Likes
…and ultimately, that’s what we have interfaces for: so that the implementation can be switched under the hood.
1 Like
@filipenevola what do you think about this? Should I open a PR? I have this already working and tested ready.
5 Likes
This is our migration plan
- Upgrade to Meteor 2.0
- Change Http package to @jkuester’s version
- Slowly move to fetch
With the http package using fetch, there is not much pressure to change existing code
1 Like
That is something that we have to remedy, but in general import fetch from meteor/fetch and then follow the docs here:
Following this migration looks correct:
Hi folks,
just a quick question, maybe I’ve missed something, but isn’t the HTTP package synchronous (I guess it uses fibers) while fetch uses a promise-based API?
I often use HTTP in method calls, and I just don’t like to return promises as it isn’t the common practice and AFAIK async/await isn’t supported in method calls as well.
As you suggest, the HTTP package appears to be synchronous because it uses fibers under the covers. However, it’s fundamentally an asynchronous request.
Promises are really easy to work with in Meteor and yes, you can use async/await in Meteor Methods.
1 Like
I think it should be merged in 2.3
2 Likes
Thanks. Yes, I just saw this in the change notes.
I read in the release notes of your http package that npmRequestOptions is not supported anymore. However, we are using this to get the response as a buffer (in our case, it’s a zip file we have to unzip):
const response = HTTP.get(this.url, { npmRequestOptions: { encoding: null } });
What would be the recommended way to workaround this limitation?
EDIT: I am now using fetch directly for this usecase.
I have now switched all of my HTTP usages to axios, which I was using anyways. But I am still getting these deprecation messages. I guess they are caused by 3rd party packages. Is there any way to suppress the deprecation notice? It’s pretty annoying. I’m getting it multiple times.
EDIT: One additional question here: I read that the http package has been replaced by @jkuester’s compatibility layer in Meteor 2.3. This is awesome.
However, the docs state that it is not 100% compatible, because support for npmRequestOptions is missing. This is fine for my own code. But meteor list --tree shows me that a lot of 3rd packages are still using http under the hood, namely a lot of the authentication packages.
Does that mean that there might be breaking changes in these packages users might not be aware of? Or has the fetch-based http package been adapted in a way that it is 100% backwards compatible now?
1 Like