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
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?
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.
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?
We use axios and are happy with it.
This would be ideal for me. I’m using
HTTP.post all over – on both client and server side.
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!
…and ultimately, that’s what we have interfaces for: so that the implementation can be switched under the hood.
@filipenevola what do you think about this? Should I open a PR? I have this already working and tested ready.
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
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:
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.
Any updates on replacing
http with @jkuester’s approach?
I think it should be merged in 2.3
Thanks. Yes, I just saw this in the change notes.