from Hacker News

Ask HN: Next.js and Python Backend?

by funerr on 10/17/24, 4:14 AM with 9 comments

• by bbor on 10/17/24, 4:29 AM

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

• by cdaringe on 10/17/24, 3:06 PM

  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

• by aosaigh on 10/17/24, 9:35 PM

  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.

• by siamese_puff on 10/18/24, 3:18 AM

  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.

• by aristofun on 10/17/24, 7:25 PM

  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?

• by datadrivenangel on 10/17/24, 1:33 PM

  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.

• by Raed667 on 10/17/24, 10:24 AM

  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