Bazel is Google's open-source solution for building large multi-language software applications.
Here is why you should consider using Bob as a simpler and faster Bazel alternative instead of getting overwhelmed by Bazel's steep learning curve.
Bob vs. Bazel: What are the differences?
Simple vs. complex build tool
Bazel's complexity is directly related to it's out-of-tree target store. It stores targets like
node_modules , generated code or binaries inside a special directory in your home directory, namely
.cache/bazel . This breaks most developer tooling and also hot-reloading for frontend frameworks, as they require such targets to exist in the same location as your source code.
In contrast, Bob stores targets in the scope of the given repository, as you are used to from other build tools, and ensures that those targets are always up to date. Bob detects whether those targets were altered manually or by some process and regenerates them if necessary to ensure reproducible builds. This approach keeps IDE integrations and hot-reloading functional while making minor sacrifices on performance.
Migrating from Makefile and Shell Scripts
Due to Bazel's out-of-tree build, it's required to migrate your entire build process into Bazel before you can start using it in your project, which can be a big blocker on existing codebases.
In the case of Bob, the migration can be done gradually as it stores targets beside your source code and doesn't interfere with your existing build process.
The performance of both systems was measured on an incremental build graph which doesn't require any costly build operation. This gives us a baseline on how much additional time each system adds to the overall execution time of a build.
Specifically, the following chart displays the comparison of a monorepo containing between 10 and 5000 Golang projects on a Linux Ubuntu 20.04 machine with an AMD Ryzen 7 PRO 4750U CPU and 32GB of RAM.
As you can see, Bob is constantly faster, even when the number of components reach a FAANG-scale monorepo project size.
Some reasons on why Bob is faster:
- Bob is written in Golang which generates a single, optimized binary. Bazel is written in Java and uses the JVM which adds a fixed startup overhead.
- Bob uses a non cryptographic hash function to determine weather a file changed.
- Bob only needs to read a bob.yaml specification file. Bazel on the other hand needs to read a BUILD file for each binary or library.
To reproduce this benchmark, take a look at this repository.
...enables executing the same build pipeline on localhost and CI, in a deterministic manner. This creates faster feedback loops (shifting workflows left). It also makes on-boarding new developers easier and faster, as they don't have to manually install the appropriate tooling for each language and framework on their machines. It also enables to build entire projects from scratch more easily.
Bazel's build isolation requires 3rd Party integrations to make a programming language available inside the Bazel build system. It also requires to build the entire compiler toolchain from scratch if you don't define a remote cache.
Bob also uses a 3rd Party integration for build isolation, namely the Nix package manger. Nix is a cross-platform package manager and build system that can be used on Linux, macOS, and other Unix-like operating systems. This has the advantage of beeing able to use over 60.000 Software packages from the nix store which can be directly downloaded from a public remote cache. It also allows multiple versions of the same package to coexist on a system without conflicts. This makes it easy to jump between different versions of a programming language.
Mono- and Multi-Repos
Supported by both.