I have been confused recently with the moving best practices. What is the server architecture Next.js is most often plugged into?
expressjs at this point is battle-tested, minimal, easy to understand (both in usage and internals) and have a huge community still. It's very mature and does what it does well.
Since iirc you send responses directly from handlers in Express, I'm not sure the latter is possible even with express-promise-router since you basically need downstream routes/middleware to return a Response object rather than send it directly.
I think Express is never going to unify with Koa's direction since it's just too disruptive to Express' ecosystem (the v5.x branch is stale) which is probably for the best.
const db = {
async getUsers() {
throw new Error("failed to connect to database");
},
};
app.get("/", async (req, res) => {
const result = await db.getUsers();
return result;
});
Is it? It performs slower than e.g. Fastify. Don't see how that's doing well.
> Who cares how old something is, if it works well, why not use it?
It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
I thought this was slightly awkward due to error handling, but it looks like Express 5 (in beta) supports async callbacks natively.
Imo the docs need a major re-write, beginning at "getting started". New users don't know whether they should use "fastify-cli gen", "npm init fastify" or copy manually from the "getting started"-guide.
And people also tried to push their fastify-plugins to the top of the plugins-site by adding a "@username" for every plugin: https://i.imgur.com/hHyI6JO.png (left are the old docs, right are the current docs where ppl try to game the system).
Also, fastify-cli needs to rework the custom options in typescript projects imo.
Ok, that's all. Other than that, fastify rocks!
One thing nice about Koa is that it's simple, so it's timeless in that way—it's not a moving target nor does it try to do something that needs a lot of core maintainers.
They recently pushed their long awaited v5 update, which adds a Koa transport alongside the historic express transport, and improves the "code reuse between client & server" story for schemas/models/types.
I really like express + routing-controllers [1], if you're on typescript.
Express was really cool and different from what was out there at the time (at least in terms of simplicity and JS support).
But nowadays there's not a lot of difference between them. Sure, some are more ergonomic than others in certain areas but the patterns are almost the same in all of them.
The only exception is when I’m working inside an established Node shop where they already have a prolific framework, I’ll reach for what they already have in that case to avoid fragmenting their stack. Almost always, that’s express.
fastify is performant, thoughtfully designed, and well architected.
So I'd still say Express is the main choice. Personally I've never loved the Express API as it encourages a lot of heavy mutation (Koa does too), so I tend to be on the lookout for good alternatives - I haven't seen any that seem to be sticking (gaining significant enough community to bet on) more than Express.
There's a few things like Next/SvelteKit that cover all bases in one, from your web app backend -> SSR frontend -> client states, but if you're looking at pure backend for e.g. an API, Express is still going strong.
- With a bunch of middleware included and pre-configured, like body-parser, cookies, Helmet, etc. All express middleware works with Server.js
- async/await routers as expected: get('/users', async (ctx) => {...}); (ctx inspired by Koa)
- Websockets, where messages behave just as another route: socket('message', async ctx => { ... });
fastify https://www.fastify.io/
nest.js https://nestjs.com/
hapi.dev https://hapi.dev/
You write your own middleware stack, and router every time you start a new "typescript" server project?
Of course not. If you're not using a third party library you're using your own framework. The Node.js API is too barebone for any serious web application.
Architect serverless (https://arc.codes) is pretty good for serverless.
I generally chose tape/ava in the past and vitest these days, but it’s awesome that now a very simple testing mechanism is available in core
Another reason Jest is slow is due to how it's usually configured to build code using Babel or tsc. Like vitest, you can configure Jest to use esbuild which makes it much faster than using Babel or tsc.
I am not a big Jest fan, but it seems like the most pragmatic test runner when you have 100+ engineers working on a project.
The refactoring of expect to a reusable library (that hopefully everyone could depend on) would be awesome as well. AFAIK there are multiple expect() implementations out there right now, would be nice if there was one.
Deno and Node are converging more and more on every release, such a deja vu. The main difference being that deno offers much more as a business than just the "deno" product itself, so an eventual merge wouldn't be so trivial.
Denode or Nodeno? Who wants to place bets?
Hopefully, NodeJS learned from the whole Npm Inc history and tries to remain more independent from for-profit companies.
The whole io.js thing was a very different thing than Deno. Contributors tired of slow pace of NodeJS forked NodeJS into another FOSS version, with no for-profit motives, which meant it could eventually be merged back once the people behind the two projects reconciled.
It made us see a world where javascript can be (much more) secure and typed without a compilation step, and this is an important contribution I would like to still acknowledge.
Now the fact that NodeJS is learning from Deno and making strides to support capabilities (are you related? lol) is extremely exciting to me and it will surely improve the state of the Javascript/Typescript ecosystem and pull along a lot of projects/devs who would never have moved to something like this purely due to inertia and dev cost. One can dream.
This. Microsoft owns NPM so it basically owns Node.js ecosystem.