1. Django for the backend. Nothing but an API (DRF, GraphQL, some custom views or whatever one fancies) and - if server-side rendering is not necessary - a catch-all view that spits out HTML file with the JS bundle. It either doesn't know anything about the frontend, or, possibly, can read Webpack stats file (using django-webpack-loader) to figure out correct bundle filename.
It may also run Django Admin Interface, independently from the SPA - as an almost independent "back office" site.
2. JS/TS/Elm/whatever and, probably, Webpack for the frontend/SPA itself. If server-side rendering is desirable, a Node-based server. All it knows about the backend is the API contract. Trying to somehow embed JS into Python/Django is not easy, error-prone, and I just don't see any benefits of doing so.
3. A router that sends requests to the correct piece. I've always used a simplest-possible nginx setup with location /api/ { ... } and location / { ... }.
1. Django for the backend. Nothing but an API (DRF, GraphQL, some custom views or whatever one fancies) and - if server-side rendering is not necessary - a catch-all view that spits out HTML file with the JS bundle. It either doesn't know anything about the frontend, or, possibly, can read Webpack stats file (using django-webpack-loader) to figure out correct bundle filename.
It may also run Django Admin Interface, independently from the SPA - as an almost independent "back office" site.
2. JS/TS/Elm/whatever and, probably, Webpack for the frontend/SPA itself. If server-side rendering is desirable, a Node-based server. All it knows about the backend is the API contract. Trying to somehow embed JS into Python/Django is not easy, error-prone, and I just don't see any benefits of doing so.
3. A router that sends requests to the correct piece. I've always used a simplest-possible nginx setup with location /api/ { ... } and location / { ... }.