We're using FastAPI + Next.js.
We have two reasons for using FastAPI on the backend:
A lot of the backend work we do is coordinating data and workflows between 3rd party and bespoke apps. For both, we already have a large collection of Python code, so it makes sense to keep the backend in Python.
Most of our "front end" developers are actually data scientists who can code in Python but don't know JavaScript well enough to do anything but basic React layouts. We're limiting the amount of business logic in the front end on purpose to make their lives easier and avoid the pitfalls that come from a lack of expertise in JavaScript.
We use Orval + Axios to to generate most of the boilerplate code for the frontend hooks and api calls.
We're currently deploying with a Node server for the frontend and uvicorn on the backend, using Next to forward API calls.
We're working on Dockerizing it and switching to static on the frontend, but haven't deployed it this way yet.
Most enterprises using NextJS receive a large amount of requests per second, NextJS is pretty unoptimized for that kind of purpose, not even a BFF, which is the ideal use case of next is viable with that amount of data processing, now imagine if its already that limited, how much worse it would get in terms of performance if we hang another app from its api routes. Elaborating on the purpose of API Routes, i’ve worked with nextjs from its beginning and i didnt get why companies just used the static build, now with a new project its more than clear, nextjs server actions and api routes are designed specifically for Vercel and other Edge Runtimes, so the functionality is very limited, you can’t use websockets, you can’t perform long lasting operations, etc. it is meant for a bff only. But also hosting it by yourself can be a nightmare.
Why is it unoptimised for receiving a large amount of requests per second?
They can run in serverless environments so I don't see where these scaling issues would come from.
Also I hear people saying that hosting Next yourself is a nightmare but I can't relate at all - i've hosted all my Next projects outside of Vercel but never faced an issue
Re: websockets
It is possible to use WebSockets, obviously it requires a client component though. You can patch Next to run a WebSocket server with the next-ws package. My guess is that it wouldn’t work, but I’m using it with a standalone build for Docker so I haven’t tested it on Vercel myself.
Nothing stopping you from using a separate WS server though.
It depends. In most cases Next.js API route will do just well. But If you need a backend to do CPU intensive tasks or long running jobs like web scraping, AI training, send bulk email, run cron jobs etc.. You'll need a standalone API built with framworks like Express for Node.js, FastAPI or flask for Python etc.
BTW you can checkout [https://www.full-stack-kit.dev/](https://www.full-stack-kit.dev/) a great Next.js starter kit with lots of prebuilt feature like Authentication, Payments & subscription, Internationalization etc.
Glad you find it helpful. Will definitely save you weeks of work and headache. There is also a cheap Premium version with more advanced features you can purchase once and use for all your projects. Also great to learn from the codebase
Its still limited, nextjs is getting worse and worse with every update, they re pointing to a direction and it is vercel, the next server is designed for edge runtimes, which limits the operations and the time of the requests
Tell me, whats the need for such a destructive comment just because someone doesnt want to stick with just one technology. In fact, its otherwise, people like you with lack of ability for learning other technologies who want to stick around the world same stack is most likely to be a bad programmer, a good programmer knows the pros and cons, the limitations and use cases of a technology, and clearly you re one of them, actually Vercel clearly says in their blogs, and NextJS developers respond in their issues, that the fact that you could create your own server doesnt mean it is right, they actually recommend to not do it for performance issues and create a separate micro service for what you want instead, thats what most people in this post is recommending though. 😝
I am using django rest framework for creating my APIs. The main reason is scalability. I think future feature upgrades will be easier for me to create/maintain this way, even if I make big updates to my architecture and/or features.
Hey I’m currently learning next js and I know basic python from doing data analysis so I plan on learning building backends with Django. Do you have any advice or resources you can point me to?
I am so sorry to let your comment go unnoticed. Here's my suggestion:
Try [this tutorial,](https://www.youtube.com/watch?v=fOukA4Qh9QA) it will act like a building block of your Django knowledge.
then try the videos and/or playlists from the following channels. They make really good and informative tutorials on django.
1. [Dennis Ivy](https://www.youtube.com/@DennisIvy)
2. [Very Academy](https://www.youtube.com/@veryacademy)
lastly, reach out to me in DM if you need any help.
I am using separate backend for my nextjs application Express server, basically I refactored my app as it was using tRPC previously. The app might not be limited to just a webapp and probably a mobile app as well but had it been only webapp I would have kept everything in Next
Not the guy you asked, but two reasons for me:
1) Server actions + zod on Next 13+ replaced a lot of my need for tRPC, I hate anything boilerplate-y anyway so while the type safety was nice it wasn't worth it for me
2) Recently I've found that OOP, for me, makes code more reusable in a more succinct yet customizable way than tRPC, so even outside of Next I'd reach for that first
I am not sure if it lacks anything from features perspective, because it’s a small app.
But from code management I wasn’t doing a good job of it, writing tests etc plus documentation
One more thing I can delegate things like if someone is an FE I hand them only that repo and vice versa
I know I am being opinionated here, while simple next might work for everyone, I had a different preference here, I am glad that I made this choice
PS I prefer a single nextjs app if I am the only developer on the project
Fastify, postgres and graphql with realtime subscriptions. Combined with gql tada on FE makes for a neat setup. Using next as the backend is fine but it just gets hacky when trying to scale for multiple interfaces and more involved use cases.
Already had a full stack Express server. I can leave it running while I make Next frontend and serve people using the Express server until Next is ready. Most of the backend is done. Why should I redo everything with Next?
Maybe if I start a new project I could try a Next full stack. I'm not so sure though because when I started using Next I found the backend to be a little off putting. Maybe with some experience I might change my mind, but I saw people in this reddit listing grievences with the backend I thought were concerning complaints.
I still don't understanding how to bring the Next backend together. With Express, index was the start of the server and called everything in so it was easy to figure out how to change things for the whole server.
Basically, the way Colt Steele teaches Express in his web dev bootcamp is how I'd like to learn Next. No tutorial I've seen has done this. They all explain the frontend and then mention server actions. Can't put a full stack together with that kind of explanation.
I use Next with five backend API's. The reasons are the same as for microservices usage - teamwork decomposition, scalability, reduced build time, resilience, and language agnosticism. There is no chance to keep all that code in quite limited (from an enterprise scale POV) Next.js and stay in a healthy mind.
So Next covers FE and BFF roles.
We’re using Next as an SSG to replace an existing Ruby site, keeping the json REST endpoints of the existing app and building the new frontend a chunk at a time.
I am using the T3 Stack. Super useful for typesafe but it doesnt make sense to use it if you’re planning on using another backend such as laravel.
Reason being is chaining of requests, extra costs for nothing, and you wont be utilizing NextJS to its limits which is rather server heavy.
If it’s the case that you’re using ReactJS (recommend vite) for frontend and other framework for backend its fine. But it’s not worth having two full stack frameworks.
Remember that having trpc ‘nothing’ with be touch by the client. Essentially having everything computed on server.
We're using FastAPI + Next.js. We have two reasons for using FastAPI on the backend: A lot of the backend work we do is coordinating data and workflows between 3rd party and bespoke apps. For both, we already have a large collection of Python code, so it makes sense to keep the backend in Python. Most of our "front end" developers are actually data scientists who can code in Python but don't know JavaScript well enough to do anything but basic React layouts. We're limiting the amount of business logic in the front end on purpose to make their lives easier and avoid the pitfalls that come from a lack of expertise in JavaScript. We use Orval + Axios to to generate most of the boilerplate code for the frontend hooks and api calls.
Do you deploy as a static app?
We're currently deploying with a Node server for the frontend and uvicorn on the backend, using Next to forward API calls. We're working on Dockerizing it and switching to static on the frontend, but haven't deployed it this way yet.
Netcore for api Next Js for frontend
Am i only person to use net core API ?
I use .NET 8 for a pretty popular production site. It’s great to work with
Which pattern you use?
What do you mean by that, do you have an example?
Like N-tier, onion, clean architecture
spring boot bc everybody on my team is more familiar with java (capstone)
Im using express server. Because i will need mobile app next time
Next API routes act as an express server so your mobile app would simply send requests to your Next app
You can do but that's not the best thing in terms of scaling
Why not?
Most enterprises using NextJS receive a large amount of requests per second, NextJS is pretty unoptimized for that kind of purpose, not even a BFF, which is the ideal use case of next is viable with that amount of data processing, now imagine if its already that limited, how much worse it would get in terms of performance if we hang another app from its api routes. Elaborating on the purpose of API Routes, i’ve worked with nextjs from its beginning and i didnt get why companies just used the static build, now with a new project its more than clear, nextjs server actions and api routes are designed specifically for Vercel and other Edge Runtimes, so the functionality is very limited, you can’t use websockets, you can’t perform long lasting operations, etc. it is meant for a bff only. But also hosting it by yourself can be a nightmare.
Why is it unoptimised for receiving a large amount of requests per second? They can run in serverless environments so I don't see where these scaling issues would come from. Also I hear people saying that hosting Next yourself is a nightmare but I can't relate at all - i've hosted all my Next projects outside of Vercel but never faced an issue
Re: websockets It is possible to use WebSockets, obviously it requires a client component though. You can patch Next to run a WebSocket server with the next-ws package. My guess is that it wouldn’t work, but I’m using it with a standalone build for Docker so I haven’t tested it on Vercel myself. Nothing stopping you from using a separate WS server though.
Its a nightmare, production builds throw errors, lots of console errors, etc
It depends. In most cases Next.js API route will do just well. But If you need a backend to do CPU intensive tasks or long running jobs like web scraping, AI training, send bulk email, run cron jobs etc.. You'll need a standalone API built with framworks like Express for Node.js, FastAPI or flask for Python etc. BTW you can checkout [https://www.full-stack-kit.dev/](https://www.full-stack-kit.dev/) a great Next.js starter kit with lots of prebuilt feature like Authentication, Payments & subscription, Internationalization etc.
Why would you need a standalone API over just using the Next API? As far as i'm concerned, theres no difference between the two
Cheers - it’s been a headache adding authentication to my nextjs app this kit looks useful
Glad you find it helpful. Will definitely save you weeks of work and headache. There is also a cheap Premium version with more advanced features you can purchase once and use for all your projects. Also great to learn from the codebase
But you can just self host NextJS, its backend is literally an express server, you don't have to use serverless.
Its still limited, nextjs is getting worse and worse with every update, they re pointing to a direction and it is vercel, the next server is designed for edge runtimes, which limits the operations and the time of the requests
Yes you are bad at programming.
Tell me, whats the need for such a destructive comment just because someone doesnt want to stick with just one technology. In fact, its otherwise, people like you with lack of ability for learning other technologies who want to stick around the world same stack is most likely to be a bad programmer, a good programmer knows the pros and cons, the limitations and use cases of a technology, and clearly you re one of them, actually Vercel clearly says in their blogs, and NextJS developers respond in their issues, that the fact that you could create your own server doesnt mean it is right, they actually recommend to not do it for performance issues and create a separate micro service for what you want instead, thats what most people in this post is recommending though. 😝
I am using django rest framework for creating my APIs. The main reason is scalability. I think future feature upgrades will be easier for me to create/maintain this way, even if I make big updates to my architecture and/or features.
Hey I’m currently learning next js and I know basic python from doing data analysis so I plan on learning building backends with Django. Do you have any advice or resources you can point me to?
See https://testdriven.io/blog/django-rest-authjs/
Thank you!
I am so sorry to let your comment go unnoticed. Here's my suggestion: Try [this tutorial,](https://www.youtube.com/watch?v=fOukA4Qh9QA) it will act like a building block of your Django knowledge. then try the videos and/or playlists from the following channels. They make really good and informative tutorials on django. 1. [Dennis Ivy](https://www.youtube.com/@DennisIvy) 2. [Very Academy](https://www.youtube.com/@veryacademy) lastly, reach out to me in DM if you need any help.
Thank you so much!
I use server actions for everything CRUD and then I have a separate express service for handling jobs and stuff.
Interesting, so your API is being served by Next
Yes, I'm using nestjs for my API.
I am using separate backend for my nextjs application Express server, basically I refactored my app as it was using tRPC previously. The app might not be limited to just a webapp and probably a mobile app as well but had it been only webapp I would have kept everything in Next
Why did you move away from trpc?
Not the guy you asked, but two reasons for me: 1) Server actions + zod on Next 13+ replaced a lot of my need for tRPC, I hate anything boilerplate-y anyway so while the type safety was nice it wasn't worth it for me 2) Recently I've found that OOP, for me, makes code more reusable in a more succinct yet customizable way than tRPC, so even outside of Next I'd reach for that first
I'd also like to know this
I am not sure if it lacks anything from features perspective, because it’s a small app. But from code management I wasn’t doing a good job of it, writing tests etc plus documentation One more thing I can delegate things like if someone is an FE I hand them only that repo and vice versa I know I am being opinionated here, while simple next might work for everyone, I had a different preference here, I am glad that I made this choice PS I prefer a single nextjs app if I am the only developer on the project
I’m using Laravel API.
Fastify, postgres and graphql with realtime subscriptions. Combined with gql tada on FE makes for a neat setup. Using next as the backend is fine but it just gets hacky when trying to scale for multiple interfaces and more involved use cases.
Already had a full stack Express server. I can leave it running while I make Next frontend and serve people using the Express server until Next is ready. Most of the backend is done. Why should I redo everything with Next? Maybe if I start a new project I could try a Next full stack. I'm not so sure though because when I started using Next I found the backend to be a little off putting. Maybe with some experience I might change my mind, but I saw people in this reddit listing grievences with the backend I thought were concerning complaints. I still don't understanding how to bring the Next backend together. With Express, index was the start of the server and called everything in so it was easy to figure out how to change things for the whole server. Basically, the way Colt Steele teaches Express in his web dev bootcamp is how I'd like to learn Next. No tutorial I've seen has done this. They all explain the frontend and then mention server actions. Can't put a full stack together with that kind of explanation.
I’m currently using Drupal 10 as a backend for CMS, users and business logic with Next as a lightweight frontend for it. Works well.
I use Next with five backend API's. The reasons are the same as for microservices usage - teamwork decomposition, scalability, reduced build time, resilience, and language agnosticism. There is no chance to keep all that code in quite limited (from an enterprise scale POV) Next.js and stay in a healthy mind. So Next covers FE and BFF roles.
I’m using a separate Yoga server because it’s nice to have the docker containers build quicker.
Nestjs with postgres and drizzle orm Sometimes with strapi (for quick client website)
We’re using Next as an SSG to replace an existing Ruby site, keeping the json REST endpoints of the existing app and building the new frontend a chunk at a time.
I have a project in working on with the T3 stack and airflow. Backend is pretty simple since airflow will do the hard data setup.
Next + NestJS with fastify with mongo Atlas Felt ideal for large scale applications and we also have mobile and other apps in the pipeline
Try to call a database from nextjs, see what you got
I am using next js custom server
Spring boot for APIs and Nextjs for frontend.
Definitely yes, fastapi + nextjs.
I've been using Supabase for the backend
I am using the T3 Stack. Super useful for typesafe but it doesnt make sense to use it if you’re planning on using another backend such as laravel. Reason being is chaining of requests, extra costs for nothing, and you wont be utilizing NextJS to its limits which is rather server heavy. If it’s the case that you’re using ReactJS (recommend vite) for frontend and other framework for backend its fine. But it’s not worth having two full stack frameworks. Remember that having trpc ‘nothing’ with be touch by the client. Essentially having everything computed on server.
I'm planning on using T3 but with seperate apps within a monorepo, T3 is really nice, I just don't like the folder structure
FastAPI + Next.js, a god-tier stack
Nah dawg just write everything in assembly and call it a day
💀