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 ;)
- 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 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.
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.
Do you care about SEO & serve-side features ? If you already have a backend with Python, then maybe Next.js is redundant