i build my frontends as SPAs with Vite inside a Bazel workspace alongside Go backends. bazel build //... builds everything. The output is one JS bundle, one CSS file, and an index.html. The Go server serves it as static files, with index.html returned for any path that doesn’t match a file on disk (so client-side routing works on refresh). i don’t use Next.js or any SSR framework. Why Vite, not Next.js# The frontend runs in the browser. The browser runs JavaScript. So you write JavaScript for the browser and ship it as static files. The backend is Go, serving APIs over ConnectRPC or plain HTTP. Clean separation. The Go server serves the SPA as static files. Done. Read more

i use nogo instead of golangci-lint for Go linting in Bazel. nogo is a rules_go feature that compiles Go analyzers into the build. Lint errors become build errors. Bazel caches results per package, so incremental builds only re-lint what changed. golangci-lint has its own cache, but it doesn’t share between CI and local, so you duplicate work. Setup# You enable nogo in MODULE.bazel by pointing go_sdk.nogo at a nogo() target: 1 2 3 go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk") go_sdk.from_file(go_mod = "//:go.mod") go_sdk.nogo(nogo = "//:nogo") go_sdk.from_file reads the Go version from your go.mod, so you don’t duplicate it. You can also use go_sdk.download(version = "1.24.5") if you want to pin it explicitly. Read more

Buf is the best tool to manage protobufs. One of the biggest pain points of protobuf is the management of protoc plugins. You need to manage them, and make them available to other engineers working on the same repository/project. Versions need to be centrally managed, code generation must produce the same result, no matter if it happens on an engineer A or B’s machine, or in CI. This becomes even more challenging, as protoc plugins are written in different programming languages. Go protoc plugins are written in Go, and are therefore compiling to a single binary without dependencies. Easy. However, other plugins are more difficult to manage. Typescript plugins like protoc-gen-es are written in Typescript, and therefore do not compile to a single binary. Read more