Tell us about your feature request
I work on projects that require pretty high security standards, and I have yet to get Node.Js pushed through (maybe Deno in the future??). Has anyone tried deploying go-blueprint with React and without Node - letting Golang serve the frontend assets instead?
This would be similar to the official React + ASP.NET or Vue + ASP.NET templates. Vite becomes a proxy server during development for DX reasons (HMR, tailwind, etc.). When it's time to deploy, Vite builds the frontend assets into a public folder, which Golang picks up and serves. All API endpoints will get served through 'https://example.com/api/' (it would feel kinda like Next.Js).
It could simplify the deployment story because you wouldn't necessarily need docker-compose just to serve HTML/CSS/JS assets. One Golang server would do all the work, and latency could be reduced (depending on how the project is deployed).
Deploying without Node means you can't deploy any server-side JS packages. But go-blueprint is a Golang backend project - if you're deploying backend JS, you're probably doing it wrong.
If this seems interesting, I am happy to tinker and create a PR, but I don't want to expand this project's scope because of a specific deployment opinion or security need.
Any thoughts?
Huge fan!! Go Blueprint is incredible!!
Disclaimer
Tell us about your feature request
I work on projects that require pretty high security standards, and I have yet to get Node.Js pushed through (maybe Deno in the future??). Has anyone tried deploying go-blueprint with React and without Node - letting Golang serve the frontend assets instead?
This would be similar to the official React + ASP.NET or Vue + ASP.NET templates. Vite becomes a proxy server during development for DX reasons (HMR, tailwind, etc.). When it's time to deploy, Vite builds the frontend assets into a public folder, which Golang picks up and serves. All API endpoints will get served through 'https://example.com/api/' (it would feel kinda like Next.Js).
It could simplify the deployment story because you wouldn't necessarily need docker-compose just to serve HTML/CSS/JS assets. One Golang server would do all the work, and latency could be reduced (depending on how the project is deployed).
Deploying without Node means you can't deploy any server-side JS packages. But go-blueprint is a Golang backend project - if you're deploying backend JS, you're probably doing it wrong.
If this seems interesting, I am happy to tinker and create a PR, but I don't want to expand this project's scope because of a specific deployment opinion or security need.
Any thoughts?
Huge fan!! Go Blueprint is incredible!!
Disclaimer