JSWhen I saw the below video, the first reaction that came to my mind was exactly as Theo described:
Isn’t Next.js that React thing for building websites and web apps?
After a second thought, I do realize that it is actually true:
Next.js is the best backend to serve your react application
Although Theo has made a strong point in his video, I will explain my second thought from different aspects.
What does a backend framework do?
If we know what a backend framework does, we should be able to verify this statement. However, after searching for a little while, there seems to be no specific widely accepted definition of backend framework. Indeed, the framework is just a concept notion: a pre-prepared standard kit from which to work. In that case, let’s look at the self-positioned minimalist framework Express.js to see what it does.
What does Express.js do?
If you look at the Hello World example of Express.js, it’s very simple:
const express = require('express')
const app = express()
const port = 3000
app.get('/', (req, res) => {
res.send('Hello World!')
})
app.listen(port, () => {
console.log(`Example app listening on port ${port}`)
})
The essential functionality is to provide the ability to handle response/request to a particular endpoint, so-called Routing, which is the top item in the Guide menu of its website.
Of course, besides the Routing, there are also other important features like Middleware, Error Handling, you can think of it as the complementary ability to response/request handling. In other words, it won’t cause you too much trouble even if you implement those by yourself in some cases.
What does Next.js do?
Therefore, it comes to a simple question: does Next.js provide response/request handling?
The answer is definite: it does through its API Routes. As most people might not be aware, it also has Middleware feature.
Actually, if you take a look at the package.json of Next.js, you can actually find the express dependency below:
If it’s built on top of a backend framework, I guess it should count for a backend framework itself, right? 😄
Furthermore, if you ask the early adopters why they are using Next.js at first, most of the answers would be for the SSR(Server Side Rendering). Indeed, that’s probably the most attractive feature from day one, as you can see in the initial website front page:
No matter whether adopting SSR(Server Side Rendering) by *getServerSideProps* or SSC(Static Site Generation) by *getStaticProps*， they are both running at the server backend.
What’s the difference with the other backend framework?
Stateless vs Stateful
In Theo’s video, he seems to point out that it’s the difference between Stateless and Stateful design. However, I don’t have strong feelings about it personally. Although I have been using Nestjs for several projects, I always adopt a stateless design for scalability.
Moreover, except for something like Websocket(There are alternative solutions, as Theo mentioned, or you can just implement it using a separate backend), I think we should always try to make a stateless design. And in most cases, we could achieve that by using centralized storage like cache/database/message queue, etc.
Of course, you can implement a similar pattern in Next.js too. But under the hood, that’s exactly what a framework does, doesn’t it? The framework itself defines the conventions for how the code is written and structured, which standardizes how the developers write their code. But everything comes with a price, and it does require a deeper learning curve which is deeper than the distance between Angular(Nestjs) and React(Next.js).
Architecture
If compared to Nestjs the underlying difference for me is the architecture as specified in Nestjs’s official document:
However, while plenty of superb libraries, helpers, and tools exist for Node (and server-side JavaScript), none of them effectively solve the main problem of - Architecture.
Nest provides an out-of-the-box application architecture which allows developers and teams to create highly testable, scalable, loosely coupled, and easily maintainable applications. The architecture is heavily inspired by Angular.
It organizes the architecture pattern and keeps it clean and modularized, separating development concerns makes it extremely simple to maintain and scale the app.
A concrete example of the benefit for me was when I switched from one project to another one, it was so much easier for me to understand the code of the new project, and I could easily extend it with very less touching of the existing code.
However, as the growing trend and big ambition of Next.js, it won’t surprise me in the future if it absorbs the advantage of other frameworks and makes a good balance between easy to use and simple to scale. Hope it would come soon!
When should I use Next.js as my backend
Munger has a famous quote:
All I want to know is where I'm going to die, so I'll never go there.
So I will instead list when you shouldn’t use Next.js as your backend instead:
- You are totally fine with the current solution.
- Your frontend is not based on React.
- You do have to use a stateful design in your backend, like Websocket.
- You have something not convenient to be implemented in Javascript, like some machine learning processing.
- You have a very complicated backend processing logic and have different people to maintain different parts.
ZenStack
If you consider using Next.js as your backend, You could checkout ZenStack we are trying to build to help you fill the gap:
ZenStack is a TypeScript toolkit for building high-quality, scalable apps faster, smarter, and happier. It centralizes the data model, access policies, and validation rules in a single declarative schema on top of Prisma, well-suited for AI-enhanced development. Start integrating ZenStack with your existing stack now!
See the tutorial I wrote about how to use it:
