10

The 'request' module has been a long-time standard for Node.js. They have recently deprecated the library.

I am starting a new project, and looking for the best solution to do my networking. I started off using the native 'https' module, but ran into problem after problem. Using the request module seemed to be easy and work just fine. There are also many other libraries to replace the request module.

Generally speaking, you should avoid using deprecated libraries when possible. But does that rule of thumb apply here?

Is it bad to start a new project with the 'request' module? If so, what is the new standard?

2
  • 1
    This is personal opinion, but I would not start a new project with the request() library unless it has a feature that no other library has that I need. I'm using got() for new projects instead. I'd personally rather be using libraries that have a stated objective to continue to evolve with new developments in the language and add new features. I also like using a library that has promise support built-in from the core rather than added on only as a wrapper.
    – jfriend00
    Commented Feb 16, 2020 at 16:18
  • Has anyone used npmjs.com/package/postman-request? What are the views on the same as a Request stopgap?
    – pratikpc
    Commented Jan 30, 2022 at 0:35

3 Answers 3

17

I would personally not start a new project with the request() library unless it has a feature that no other library has that I absolutely need or unless I need another module that depends upon the request() module itself.

When I have the freedom to choose, I'm using got() for new projects instead. Choosing from the list of alternatives is a personal decision so you just have to evaluate the type of interface they each have and what features they have. For what I typically do with this type of library, got() seemed simple and clean, built from the ground up with promises, meets my needs and I've had no problems using it.

Axios, node-fetch and superagent have advantages in that you can use a similar interface in both node.js and in the browser. All are popular and in wide use.

I tried bent, but didn't click with its programming interface.

I'd personally rather be using libraries that have a stated objective to continue to evolve with new developments in the language, new developments in nodejs libraries and add new features over time rather than a library that says it will not be adding new features.

I also like using a library that has promise support built-in from the core rather than added on only as a wrapper since I do all asynchronous programming with promises now.


Some other resources in examining the alternatives:

Feature comparison chart (written by the makers of got())

Migrating to got() from request


And, if you want to read about why the request() library has gone into maintenance mode, read here.

In a nutshell, it's an old architecture with tons of features glued onto the side, but because there are so many modules dependent upon it, they can't really break their API to fix or smooth things out. And, because it's so popular, it is holding back the success of competing solutions that have designed a cleaner interface. So, the decision was made to let the alternatives that have been designed in a more modern way take the mantle going forward and request() will go into maintenance mode to continue to support the other modules that are dependent upon it, but not try to evolve into a more modern interface.

1

The author of request mentions that request was written in the old ways when the best practices were so different. He tried to recreate a similar library with better practices and made bent.

I would say the only problem with request was not the underlying code, but also its interface: callbacks belong to the stone age and make your code ugly.

My personal suggestion would be using RxJS-based solutions:

  • RxJS's bundled ajax library for frontend code (comes with rxjs),
  • RxJSx's request library for backend (@rxjsx/request).
0

Request isn’t really deprecated. It’s no longer considering new features or breaking changes, but it is still being maintained. It’s safe to use for the foreseeable future, but how good an idea it is to use it is up to the developer. Not really a right or wrong answer here.

They’ve stopped new work on it because they believe the patterns it uses are out of date and to switch over to modern patterns would effectively make request an entirely new module, so rather than invalidate thousands of blogs and SO answers by making a massive update, they’ve decided to stop in order to make space for a new standard to emerge that effectively uses new features. As of yet, a new standard does not exist.

If you like request, and the outdated patterns it uses are good for your purposes, then go for it. But new patterns and features exist for a reason, and they might be worth exploring.

5
  • 5
    "Request isn’t really deprecated" - I dont think this is correct. See here for more details - npmjs.com/package/request It clearly says request module has now being deprected. Commented Feb 16, 2020 at 14:21
  • Deprecated to me means no longer being maintained. Request is still being maintained. The message is to let developers know that it’s no longer being actively developed with new features so they should look for alternatives
    – bryan60
    Commented Feb 16, 2020 at 15:41
  • 1
    There you go. As you say "so they should look for alternatives". That seems like your answer right there.
    – jfriend00
    Commented Feb 16, 2020 at 16:25
  • 2
    I tend to agree, but if request and it's current feature set is getting the job done, and OP is happy with it and not interested in newer features or patterns, then go for it. My point is that request isn't going to be rendered unusable or broken any time soon, so OP isn’t creating a situation where in a year or two they’ll be forced to go and completely refactor if they elect to use request, and despite being somewhat outdated, it's full featured, mature, and well vetted, and possibly no js lib in existence is better documented... and there's a bit to be said for that
    – bryan60
    Commented Feb 16, 2020 at 16:59
  • github.com/request/request#deprecated Commented Apr 22, 2022 at 9:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.