Is it a good idea to build backend with nextJS?

You raised a very good question. It would be great if you could tell what decision you finally reached.

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.

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 😄.

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

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 👍

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).

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

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/

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.

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.