Hacker News Reader

Comment by kubota | Hacker News Reader

Bazel isn't about a particular language needing its build facilities - its about ALL of your organizations languages being built with one tool, ideally in one monorepository. Its very attractive when you have lots of microservices that would otherwise live in disparate repositories. Using a monorepo and Bazel allows you to share api definitions (proto files) across your entire code base (rules_proto, rules_grpc) , so you see immediately what api changes impact existing code across your entire organization, regardless of what languages each component is coded in.It allows you to containerize (rules_docker) and deploy (rules_k8s) only the components that need to be redeployed with every commit. It allows your entire development team to live, code, test, build, and deploy in harmony.

View on HN

My problem with Bazel - at least based on my understanding when I evaluated it - is that you can't use the language-specific package managers for each module in your monorepo, so it's all or nothing. I'd prefer a tool that makes it much easier to defer build tasks to my package manager of choice in each project (eg Yarn for TS, Poetry for Python, etc.) and that lets me define rules at one level of abstraction above this.

In our monorepo, we ended up just using a Makefile, since it basically does that. Of course the Makefile is now a few hundred lines and we have about 60 *.compose.yml files, but that's another story.

Our current solution still uses the Makefile, but we basically split the monorepo into a Python part and a TypeScript part, and each of those has its own monorepo build system (Yarn workspaces for TS, and Poetry with Pants for Python).

This was my main gripe with bazel. It's the worst build tool for any individual language but the best (only?) that can do all of them.

Other big complaints were:

- big CPU hog

- bad IDE integration (esp scala/java for intelliJ)

- it lets people write i-cant-believe-its-not-python, which is far too much rope to hang yourself with. I've seen horrors.

> its about ALL of your organizations languages being built with one tool,

Yeah, that's an effective way to sell someone's promotion, but it's always a promise that is never met and instead it's a constant source of problems.

Sometimes reinventing the wheel just buys you a wobbly, squeaky wheel.

When I was at a large money center bank a constant source of problems was trying to deploy the 70+ microservices backing our business unit's main application during "release weekend", or for ad-hoc reasons like the log4shell vulnerability patch. It was very frustrating for our build pipelines to compile / test / static scan the entire millions of lines codebase when only a few libraries have changed. This build often took a few hours for our largest application and at least 10 minutes for each microservice. A few times we ran into breaking api changes and only realized it after it was deployed to production. This is the use case Bazel is serving - god like observability across your organizations code base, quickly compiled.

Reply on news.ycombinator.com