search

Melkeydev / go-blueprint

Go-blueprint allows users to spin up a quick Go project using a popular framework
https://docs.go-blueprint.dev/
MIT License
5.42k stars 313 forks source link

[Feature Request] Golang to Serve Frontend Assets (like React) instead of Node.Js #339

Open EarliestFall988 opened 2 days ago

EarliestFall988 commented 2 days ago

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

Ujstor commented 10 hours ago

@EarliestFall988 I agree with you, the current implementation is not ideal. The use of serve for serving static content can be removed. Instead, we can adopt a more efficient approach. Nginx, for instance, is highly efficient, fast, secure, and production-ready.

Bundling the frontend and backend into one monolith is not something I favor. We should keep these two components separate. This separation aligns with cloud-native patterns.

If you are deploying into k8s, as most production apps are, you gain granular control over resources, autoscaling, rolling updates, and fault isolation. It also simplifies scaling specific components and removes the need to redeploy the backend if only the frontend changes, and vice versa.

The only remaining question is whether to serve the frontend using a Go or Nginx.