Hi,
I'm planning to build a full stack application. I have plan to scale the application and make it a really big project over time. Before I start working on my project, I just wanted to know if it's a good idea to build the backend of my project with NextJS API or should I use a node-express backend server separately.
I will use nextJS as the front end and that's why I'm asking this question.
Thanks for your help in advance.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (23)
First of all, pick the tools you are comfortable with. Next.js is a good start and you can extract the backend / API parts eventually as you outgrow the framework. Don't overengineer your project from the start.
That being said, personally I wouldn't pick Next.js for more complex APIs. Their "API routes" functionality provides poor primitives for building complex backends and you spend a lot of time reinventing abstractions other frameworks provide for you out of the box – frameworks like NestJS, FeathersJS, Adonis, Meteor…
For example, at superface.ai we use Next.js as a stateless frontend, while the backend is built with NestJS and exposes an API for the frontend, our SDK, and CLI. This works especially well if you have dedicated developers for frontend and backend parts.
First paragraph says it all. Don't over-engineer. Long term I think next's api layer is pretty basic and you'd benefit from having a dedicated api. But until you start to hit those pain points, or if your app is small, or during early development, then sure why not.
Thanks Jack, It helps a lot.
Thanks Jan, for such a detailed comment. I got your point of view.
First try to create a minimal viable product with the tools you are used to work with. As for creating a Full Stack app using Next.js, nowadays it is conceivable and you can take advantage of technologies like tRPC.
In case, a few years later, if you want to leave the monolith and split the frontend and the backend, you can reuse the tRPC router and use it with an adapter in an Express api. And if you want to change the frontend framework eventually, you have the possibility to use the vanilla client.
But speaking outside the scope of Next.js, if you want to work with job queues, data processing, etc. I would create a REST or GraphQL api to be honest and to solve most problems I would have in the future I would use a high scope framework like NestJS or Adonis.
If I had an idea and wanted to take the idea off paper and test it with real users, I would choose:
Stack: Next.js + tRPC + Prisma ORM
External services:
But this question of scale and which tools to use has a lot to be said.
Find the problem you want to solve, then deconstruct it and make it possible with what you know and the things you need to learn. All this takes time and planning.
Cheers mate! 💪
Thanks for the great overview of the entire thing, Francisco. I would love to checkout your API solution. Make it opensource if possible, and provide an update on dev.to
The tRPC documentation has great guides, if you want to take a look at the adapter for Express you can click on this link.
If you want to read the Next.js guide you can click on this link.
With the tools you are accustomed to using, start by trying to construct a minimally viable product. Today, it is possible to build a Full Stack app utilizing Next.js and you may benefit from tools like tRPC.
You may reuse the tRPC router and use it with an adaptor in an Express api if, a few years from now, you decide to break apart the monolith and separate the frontend and the backend. Additionally, you have the option of using the vanilla client if you decide to eventually change the frontend framework. octordle.io
Personally I would find something that will help me scale in the future using languages I’m already familiar with. I suggest taking a look at NestJS as a backend. It has great docs and has a lot of good conventions that’ll save you time and money in the future. nestjs.com/
You can make it work without much hassle, next-connect does all the heavy-lifting, and then it's just about keeping a proper files organisation.
It's a bit dated now, but I wrote a series about it: dev.to/noclat/series/11054
This is probably not the best solution for a huge API though, I would separate the front-end and back-end into 2 distinct projects so each team can work on their part without polluting the other. And for this you have better API frameworks than Next.js.
Thanks Nicolas, I was looking for this answer exactly :)
It's normal to have a React frontend and a Node backend.
That's true. But the purpose of my question is, I'm using NextJS as my front end. And as NextJS supports backend as well. In such case, if it's a good choice to stick with only NextJS or I should run a Node-express server separately for my backend.
Thank you for your advise.
It depends on your app. If your API is complex, I recommend not to use Next JS. But before building project its a good idea to build a MVP. It helps you to understand what is missing, what should be added & how should be its build.
I suggest using Next JS API for your MVP. If it help you to get what you want, Then use it. You can switch from Next Js API to custom NodeJS-express server whenever you want.
If you explain what is your app & how is your API, maybe we can help you by giving right info.
Good luck with the project mate 👍
Thanks Fadhil, you guys are already helping a lot :)
I really appreciate you for your advise.
Ideally it's best to have a dedicated API server.
However if you are working some something basic, then it's not wrong to have API in NextJS itself as well.
But as far as possible, always have dedicated API server/code.
Thanks for the Advise, I think I will go with the separate server now.
I’ll adhere to the “don’t over-engineer” messages. But my experience tells me to warn you that if you plan on growing, you need to engineer it as well as you can to avoid headaches in the future. I do not go with “a problem for the future ME”. I try to stick to the old-school way and retain the client with a good solution. Not just a product, nor a simple software. My experience says that if it takes too little for you to build a solution, then you’re doing it wrong and the client probably will find another programmer.
Nowadays for simple stuff I like svelte and sveltekit. With the warning that it hasn't hit 1.0. so you have to keep up with it. But I like how it allows me to make things quickly with out much tricks. When I tried using next, I found myself working around the framework sometimes. Maybe React 18 will make things easier just as hooks definitely did.
Exactly
I've been using Nest.js for the past few years and am generally satisfied with it. However, if I start a new project today, I'll definitely try to build the entire stack with Next.js, at least for the MVP version. The framework is robust enough and has everything you need to create a full-stack app. Also, the backing from Vercel makes the deployment experience sweet and easy.
Having all your frontend and backend code in one simple project is a great benefit: no hassle for coordinating multiple repos or the complexity of setting up monorepo. Code sharing is straightforward. That's the direction of future web-app development for the majority.
I'm building an open-source full-stack development toolkit for Next.js called ZenStack, which combines data access policies with ORM. If your app is CRUD-intensive, maybe you can check it out. I would love to hear your feedback if you did so 😄.
Consider fetching directly with an ORM inside of getServerSideProps similar to the Blitz approach, and then pick a proper library (such as using express) and build an API later.
(I would lean towards hotwire or liveview initially, then break out an API (phoenix) and client side rendering (elm) from that once the project started to grow).
You raised a very good question. It would be great if you could tell what decision you finally reached.