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