These days next js has become full stack. There are also other backend like nodejs, express js. So do you use next js for both frontend and backend or next js only for frontend and nodejs for backend? Which is good? Please recommend me.
Do you guys use Next js only for frontend or for both backend and frontend?
Help NoobThis is, for me, the best way to profit of NextJS capabilities.
Not authenticated? Redirect to x route thanks to what nextjs offers backend side. Resource does not exist? Redirect to not found page. No need to the browser to download the JS chunks, then run them, then make a call to the API, get the error response, and « push » to the needed route frontend side = better UX and performance.
How much more complicated if I use a traditional backend e.g. Django vs using BFF?
The BFF could be hosted in any technology. It's tightly coupled to the UI though, by design. The BFF pattern is part of our domain driven architecture. The core services are domain specific and are UI agnostic. If any compromises are made in order to accommodate the needs from the UI, they are made in the BFF. This allows the core services to remain a pure representation of the domain.
It's convenient for us that Next.js offers an API, because using Next.js APIs for BFFs happens to be closely aligned with how our logic is organized. No other reason.
Isn't it overcomplicating ? We add an additional layer of abstraction. Instead of communicating with backend api directly we use nextjs api routes for comunicating with backend.
It’s simpler in the case where we have quite a few micro services and rely on some external APIs too. The front end only calls the BFF service, even in our single page apps we do this.
Next js marries the front end in with the bff into the same repo. We’re free to call whatever we like directly in the server components, all the client will ever do is call the next js service.
I think it's better for security? But could be wrong :)
I think that's the best way of utilizing nextjs api feature
So in other words, you're using vercel's edge functions to call your API?
correct.
So you guys fetch() to an API route at the same project from RSC's right?
We don't use RSC's right now, but that's not relevant. We could (and we might in the future) We have three types of projects:
- The app-shell. This is what hosts the application. It stitches together all of the micro-frontends (MFE). It creates the UI by loading the JavaScript components for various MFEs from various domain specific frontend projects into the shell and executes them We use Webpack Module Federation as the technology for our MFEs The shell is domain agnostic. We only have one shell. It's in next.js
- The domain-specific front end projects. These contain the domain specific UI components as MFEs and the domain specific BFF (Backend for Frontend) endpoints. Our components only communicate with the BFFs and the BFFs use our core APIs for domain specific business logic. We have multiple front end projects. They only expose MFEs and BFFs It is also in next.js.
- Our core APIs. Our core APIs are domain specific and have no knowledge of our UI. They are meant to represent the domain as purely as possible. These are written in Nest.js.
How do you not use RSCs? Do you use page router instead of app directory?
Yep
Do you use a data layer model or just http routes?
in Next.js, we only call other services. The Next.js app never makes database queries directly. The BFF makes requests to API's written in Nest.js
In Nest.js, we use prisma as an ORM to execute database queries in order to hydrate the objects we return in the http requests.
Where do you host nestJs? Do you keep it in the same repo as next?
it's all hosted in AWS EKS. Nestjs services are in separate repos.
Do I understand properply that you use the nextjs api routes for communicating with nestjs api and frontend to comunicate with nextjs api routes ?
That's correct.
It's great for simple back-ends that don't need any crazy features, which are far more common than many devs want to admit.
One word. `middleware.js`.
Who thought using a global middleware (in the root dir of your files) was a good idea? Why doesn't it support the crypto module (How the hell do i do my own auth/identity)? How the hell am i supposed to separate my concerns in such a tightly coupled codebase
I agreed with you until the last sentence. On two points.
First, other than the global middleware, nextjs does just fine with separation of concerns IF you know how to do those things yourself.
Second. The modern dev world seems to have forgotten the premature optimization principles. They start separating concerns until they have 9 layers to a Hello World app. I've worked on 500,000-line projects where excessive separation of concerns was more of a detriment than a benefit. I've worked similarly large projects that were far more iterable and concerns were separated with import commands and best practices.
You have models, repositories, commands, requests, controllers, services, validators, all tied together with the magic of Dependency Injection. You've got this elegant 1000-line 80-step process that all goes together perfectly to say "Hello World!" in the most satisfying way. Unless there's a minor bug in one of those, then you get a stack trace that spends all of its time in node_modules. It takes about 3 hours for you to trace down that you failed to include one of the dependencies of ExclamationPointServiceModelRepository in DI-registration.
Had to create an account for this. Why are you saying this? I've built a full learning management system in nextjs, no separate backend. What's a "crazy" feature?
Why are you saying this?
Beacuse it's true. Nextjs gives minimal API or backend functionality. I'd be a fool if I decided to build a backend-heavy product like a configurable ETL pipeline in Nextjs.
I've built a full learning management system in nextjs, no separate backend
I don't see a problem with this.
What's a "crazy" feature?
Let's see. NextJS's swagger integration is "okay". On-service cron functionality is nonexistent (some philosophies would say that's fine and you should use another service anything, but it means using something more than nextjs). I don't love CQRS, but implementing it in nextjs is a mess. Getting a bit more personal to things I've needed, nextjs' middleware is just terminally falling behind.
You don't write web apps in Assembly. You don't write your kernel in python. You don't use xml libraries to write webpages. It's similarly questionable to build a heavy-duty back-end in nextjs.
EDIT: Also, why so passionate about using nextjs for backends to literally create your account to reply to my comment?
I think I it's fine. Ive built some huge platforms with nextjs and trpc and all the server code is abstracted away to server files and there is barely anything in the actual dynamic API route file that it would be easy to switch to a separate server at some point if I need but i don't see the need. You can deploy next server less or serverful depending on your usecase. We have hundreds of endpoints and it scales great. I kinda laugh when people say it's only for very simple stuff. I have yet to hit any issues.
User deleted comment
3mo
I use next js with laravel too. It's a pretty good combination. But i have a question. Does your app have authentification? And have some static page with generateStaticParams? Do authentification not messing your staticParams?
Is a laravel box capable of the largest traffic sites in the world?
No. That’s not what it is designed for. There are always teadeoffs. If you want to power something like Facebook you can’t use anything that is going to reduce throughput. But most of us aren’t working on things of that scale and for normal stuff, Laravel excels.
Yes but no. Instagram uses Django. System design matters way more than what framework you use
Damn. I stand corrected. Just read an article about what Instagram is doing and that’s pretty cool. Thanks for the info.
Both but I also have an API that is separate to NextJS. The front end can call the API directly if it wants the oauth works across both.
Full-stack. Production is Node.js (not serverless) and I use it as a big ol monolithic web server.
As far as I am concerned you probably don’t need a separate backend unless some of the following are true:
- You have a separate backend team that refuses to work with Node.js
- Your backend is doing something that absolutely cannot be part of your Node.js server and you absolutely cannot split it out into a worker or a dedicated service
- You’re using some package (some kind of Swagger or OpenAPI library maybe?) that is totally incompatible with Next.js
- You want to build a REST API first, you want that API to be a separate product, and the front-end benefits of Next.js are secondary or at least of equal importance
- You really just hate Next.js approach to API routes
This is my off the cuff list. There’s probably some extra special cases but, respectfully, if you have those you’re probably not asking this question to begin with.
Beyond that, just keep it in one place and don’t overcomplicate it.
Take a look at Adonis JS for backend if u prefer separate your back and your front, i fint it way better than express ans nest Js
We just made the decision to switch to next for the frontend and Django for the backend.
It's been quite lovely so far.
Both my favourite too
Any reason why you chose Django vs using a js backend? Isit much more complicated? I'm guessing Django handles your authentication and everything backend related?
Curious as I'm really considering Django/flask too.
Well we mostly choose it because of our different expertises as a team. I am our only frontend developer, while we have 2 backend Devs.
I come from next and love it, while my colleagues are really good at python.
I can't really tell you anything about Django, as i only interact with the API. All I can say is that we have been way more productive, and we are building way better pieces of software, since switching.
Yes... is the answer.
Overall it depends on your project and the systems needed for it. NextJS is a blend of both frontend and backend. Though to functionalize the backend portions you'll rely on APIs.
Also Express is the backend for NodeJS.
Also Express is the backend for NodeJS.
I am sorry I am not really familiar with the Node world. What do you mean by this? isn't express just a framework that makes it easier to write node js apps? I thought Node is the backend.
Tonclarify, node is the runtime while express is the backend web framework to write apps. You could write a server in node but express makes it much easier.
I use it for my backend.
However I’m using DDD so should I need to migrate away from next I can just copy/paste the majority of my directories and only change the small amount of code that exported from each api route.
I’d start any project using api routes first and only migrate away when the need arises
So your backend logic is just services written in js/ts with connecting to some DB instance and performing operations and in general you can move them in a separate module and reuse for different controllers (for example if you decide to go to the classic nodejs/express backend app) ?
Yeah exactly I just split it all in to domains, each of which is pure ts/node. Then I have a very thin layer on top which deals with next specifics on the way in/out.
If I wanted to switch to expresss I could copy the whole server directory, then just write a routes file for the express server to expose stuff, and delete the api routes.
tell me some project to make my backend skill strong
Both. Why overcomplicate things?
Definitely both
I've been using trpc with nextjs API routes to build huge typescript applications and it's great. Its built so I can easily break the backend into fastify or express later if I need but I don't really see the point. The structure of the code basically makes it look like it's its own server as there is minimal code in the API route file (we just have 1 dynamic file in there that creates the endpoints). It scales well we have 10,000+ daily active users, hundreds of endpoints, etc and nextjs is doing fine. We might trade in vercel for Google cloud run though as it allows the nodejs event loop to handle some of the concurrency instead of the lambda architecture and is therefore more cost efficient at scale. For stuff like crons, redis, files, just host in seperate services and let them worry about scaling. Haven't run into any issues yet.
It's always good to keep them separate. The other backend can be built using anything like Express, Springboot, etc
Just note that if you're using Route handlers/server actions as a middleware between the frontend and an external backend, the time it takes to make the call to the Next.js' BFF also goes into your billed time.
I use it mainly for frontend as it can interface nicely with different arrays of backends with some configuration. However the ability to have it becoming both a frontend & backend framework means more options ultimately.
I directly query my database in nextjs using functions I defined and then I can make rest api if I need to from those functions.
Things like server side rendering, API routes to communicate with backend apis, authentication on server side etc... Was actually considered as backend features you have to implement on backend. But nextjs makes implementing these much easier.
You can use nextjs for backend as well but separating the front and the backend is always good.
If it's any heavier use, always external API. Something like nextjs is not good for high-performance apis.
Can you please elaborate on this? What specifically makes Next.js less suitable for high-performance APIs than any other Node.js web server package?
JavaScript in general is not the best language for high-performance backend server. Nothing new in that. Extracting apis can help a bit, otherwise there is very significant overhead. I don't think there's anything that's news or unexpected here.
My recommendation: use go, good performance and low memory usage with relatively easy development
This is incorrect and mainly just your opinion. Lots of large companies with highly performative backbends use node. Companies like Netflix, Uber, Walmart, LinkedIn, and Nasa all use node to some capacity. Also the ease of sharing JavaScript/typescript from frontend to backend is an amazing DX.
Go and Node.js optimize for very different things. You are right about some of Go’s strengths but very very different package/library ecosystems, language ergonomics and therefore developer experiences, opinions about and opportunities for reuse, types of problems/scenarios where they excel or have weaknesses. Go would never be my pick unless I had a task that was VERY well-suited to its strengths, never my first pick.
Netflix used JavaScript. You can do a whole lot with just javascript.
We should stop with the performance talk, is not always is as easy as "just choose the fastest thing", there are million of services running on PHP, Python and JS which are not really the most performant languages.
We use next.js for the front-end. But we use the API feature of next.js to build BFF (backend for front end). We use the BFFs to communicate with APIs built in nest.js. The javascript code in the browser never talks directly to our APIs in nest.js, the only talk to the BFFs.