A question I see being asked a lot online and a lot on company projects too is - should we still be using Express to build REST API's?
On the surface, it looks like Express hasn't been maintained in a long time. It gets a couple minor version and patch version upgrades each year but version 5 (the next major version) has been in development for years and doesn't seem like it will ever be released at this point.
Couple that with the fact there are many other options out there now - Hapi, Koa, Adonis, Nest, Fastify, Feathers just to name a few. These are more actively developed, so should you use one of those instead? Theoretically because some of those options are newer, they should have the latest and greatest functionality right?
Despite all this, I still think Express makes sense to use. And in a lot of cases, it probably makes the most sense.
This is not going to be a post comparing Express to all the other frameworks. There are many discussions and articles that do that out there. This is going to be a discussion about why I still primarily use Express and why it's still a great option. And why the anxiety around it being "old" doesn't mean that you shouldn't still use it.
Express is mature
Express - despite not receiving any major version upgrades/new features in a long time - has reached a strong level of maturity. It's stable and proven. It's being used in hundreds of thousands (if not more) of production REST API's. While it may not have every feature under the sun, it's close enough to being feature-complete that it works very well for API's.
Compared to Express, newer frameworks might have some extra features, but in a lot of cases you might not need those features. Remember, there are a lot of other things that go into choosing the right tool than just features, which leads me to my next point...
The Express ecosystem is large
Express easily has the biggest ecosystem - the most middleware, supplemental libraries, and the biggest community of developers.
If you need some middleware, chances are pretty high someone already created it. If you encountered a bug (which given its maturity would be rare), chances are pretty high someone already encountered it and posted a workaround or fix. If you have a question around implementation or some error you're running into, StackOverflow more than likely has the answer.
For me, the size of the community is always one of the biggest factors in making a framework/library decision, which is why I always feel confident choosing Express in this regard.
Express is still the most commonly used REST API framework out there
Related to the above point, Express is still the most commonly used framework in the Node world. Which means if this is a project for a company and you have other developers working on it, they most likely already know Express. If you need to hire more people, they likely already know Express and can hit the ground running.
Tool switching incurs costs
Tool switching, in this case from Express to something else, always incurs a cost. Unless you and/or your team are very familiar with a different framework, it's going to take some time getting up to speed not only on the framework but also how it operates in production, any weird nuances, etc. If there's one thing I've learned in my years as a developer it's that just learning a tool is only one aspect. It's all the other stuff like deploying, packages, operationalizing, monitoring, etc. that go into it that people often forget about.
And because Express doesn't have an opinionated way of doing everything (which is both good and bad), if you switch to another framework often they are opinionated. Nest for example is much more opinionated on how things are structured, how things get wired up, etc. Which may be beneficial for your particular scenario, but the learning curve jumping from Express which mostly gets out of your way to something like Nest will incur a cost - additional developer learning time.
Project deadlines and priority
Related to this cost is project deadline. If you have a tight deadline or are working on a major project with a lot of visibility, you probably don't want to be switching from Express to a framework you don't know.
Anecdotally, one time I was working on a project with a very tight deadline, a ton of work needed to fit into that deadline, and a lot of business stakeholders breathing down our necks because it was an important project to the profitability of the company. We wasted a week or two testing out Fastify then decided to dump it. Not because Fastify is a bad framework but because we realized it wasn't worth the transition risk given all the other project factors out of our control.
For example, what if we ran into a framework bug in production that required a workaround? Not to mention that we could get things much faster with Express since it's the tool we all knew the most.
Bridging the gap
The two biggest complaints I see about Express in terms of missing features are:
- async handling
- HTTP/2
For async handling - particularly around errors - I agree this would be nice but you can workaround this fairly easily. An often-used package that helps with this is express-async-handler which is a basically a simple "drop-in".
For HTTP/2, generally nginx or some other reverse proxy is going to handle that for you. Express is usually not directly exposed to the web, you've usually got a reverse proxy in front of it. And this gets you around the lack of HTTP/2 support in Express anyways, so that's a non-issue.
Summary
To wrap up, if you or your team have a lot of comfortability and knowledge around [insert other framework here], and said framework has some features you absolutely need then by all means choose or continue using that one.
But for many Express is still going to be a strong option. Developers often have anxiety around not using the latest and greatest, but I think a lot of that comes from the "old" becoming cumbersome to use or newer tools/libraries frameworks doing it much better. For example, languages like Visual Basic have long been overtaken by Python, Node, Java, etc. because those languages just make programming much easier, faster, better, etc. That's a valid option for wanting to switch, but in the case of Express I don't think it's as well-founded a concern.
To be fair, one of the most valid downsides of Express in my opinion is it's lack of prescribed structuring/organizing of logic. If you want to see how I structure my Express REST API's and learn where your code should go, subscribe below to be sent an email with an explanation of that as well as a repo with that structure. You'll also get all my future posts delivered directly to your inbox!
No spam ever. Unsubscribe any time.
