Ask HN: Next.js and Python Backend?
Given that python is leading the charge in terms of ML/LLMs, I still want modern react features ( next.js) - what are best practices around combining the two?
9 comments
I’m doing this with Quart on the python side and prisma for both (there’s a python prisma adapter! Crazy world) and I’ve been enjoying it. Biggest framework hurdle so far has been that next.js doesn’t have native support for Websockets, which is something you’re pretty likely to want if you’re bothering to run two full server processes. It’s not hard to implement them manually, but it isn’t as nice as just sticking everything on Socket.io.
Also, obviously, you should only do this if you have a really solid architectural vision for separating concerns; any requests that need to hit python naturally loose all of Next’s fancy optimizations for server<->client data passing, other than basic caching I guess. If you just want react itself, I’m pretty sure there are less framework/resource intensive ways to deliver SPAs and cut out the node server altogether - but that’s something of a guess.
Best of luck! The hardest part is remembering to switch between typescriptSyntax and python_syntax ;)
Also, obviously, you should only do this if you have a really solid architectural vision for separating concerns; any requests that need to hit python naturally loose all of Next’s fancy optimizations for server<->client data passing, other than basic caching I guess. If you just want react itself, I’m pretty sure there are less framework/resource intensive ways to deliver SPAs and cut out the node server altogether - but that’s something of a guess.
Best of luck! The hardest part is remembering to switch between typescriptSyntax and python_syntax ;)
Using next strictly for the front-end feels like a slight miss. It works fine to do so, but its strong suit is being a full stack react framework. If your app needs a server and you opt out of next, you sacrifice the common config model, isomorphic pages and data loading patterns, integrated api routes, optimized route/path browser bundles, …more. I get that folks like python, but if you’re already paying the cost of one major tech framework in your project, you should seriously consider if you really want to pay for two (pay used loosely for cost of tech ownership). Next can and will do support your BE needs, presuming you’re not deeply reliant on some biz value from company python packages
I think it depends on your needs. Any time I've tried to use an "all-in-one" full-stack solution I've quickly run into limitations, whether it's task running, authentication, web sockets, load balancing, redirects. Many of the platforms have limitations that you only run into once you're deeply committed and you've then got to find all sorts of hacks to fill in the blanks. Not saying Next and Vercel is like that per-se, but there is a lot more control when running your own backend services.
I disagree very strongly. Next is great for just front-end. I use Next with the static export.
- Next does a good job as a React framework (ie CRA alternative) - Next does a great job with code bundling and splitting out of the box - Next's static build system makes it easy to query your backend statically at build time to generate things like blogs, SEO pages, etc.
- Next does a good job as a React framework (ie CRA alternative) - Next does a great job with code bundling and splitting out of the box - Next's static build system makes it easy to query your backend statically at build time to generate things like blogs, SEO pages, etc.
I use Next.js with Django regularly. Just set up Django as a REST API only. Have Next.js talk to the API either at build-time or run-time, whichever suits your use-case. You could even proxy calls to your backend server via Next.js server-side functions if needs be.
I find the full-stack-in-one-codebase approach that Next.js takes very hard to work with. It becomes hard to know what is "frontend" and what is "backend". Mixing server-side components with client-side components is a mess. So I stick to a traditional SPA approach: front-end static site and back-end REST API server.
I find the full-stack-in-one-codebase approach that Next.js takes very hard to work with. It becomes hard to know what is "frontend" and what is "backend". Mixing server-side components with client-side components is a mess. So I stick to a traditional SPA approach: front-end static site and back-end REST API server.
Don’t listen to the lovers of Next saying you need both.
Bundle the client and serve it from Python. Use Python for APIs that you call from the client. You can bundle a server and client bundle optimally, do SSR within Python and hydrate the client with the client bundle.
Bundle the client and serve it from Python. Use Python for APIs that you call from the client. You can bundle a server and client bundle optimally, do SSR within Python and hydrate the client with the client bundle.
Python on backend is not in any way superior to node (the opposite if anything) — then isn't it better and cleaner to isolate all AI python bells and whistles inside some sort of a balck box API?
Currently doing a poc with NextJS frontend and Python Flask backend. Doing it all through vercel makes it pretty easy. If I was self deploying, I'd probably do FastAPI instead.
Why do you need Next.js compared to a static web app with React+Vite ?
Do you care about SEO & serve-side features ? If you already have a backend with Python, then maybe Next.js is redundant
Do you care about SEO & serve-side features ? If you already have a backend with Python, then maybe Next.js is redundant