Via various projects I've dabbled in over the years, I've become a bit of a package management nerd.
At the time (~2022) we were using Bazel as a build tool where I worked (Field 33), so when
Bazel announced its plans for bzlmod, its new package management solution I got quite excited.
I latently followed the bzlmod project for some time, and when I noticed that there were very little plans
regarding a website to present the registry contents, I was quite concerned.
In my opinion package managers are incredible force-multipliers for the work that individual contributors do. And while the heavy lifting is generally done by backend servers and CLIs, registry websites play a crucial role in shaping the ecosystem that the package manager is concerned with. When done correctly, they can aid significantly in understanding and exploring the ecosystem and make adopting changes a lot easier.
Additionally, from my perspective at a small startup (~7 engineers), while most Bazel-using-companies were 100+ engineer organizations,
bzlmod was an initiative that had the potential to make the Bazel ruleset ecosystem more agile. It can further decentralize
ruleset maintenance and break down larger slow-moving packages down into smaller packages that can be more approachable to small organizations.
So in an attempt to give back to the Bazel ecosystem and offer up an UI for the BCR (Bazel Central Registry), I
created a statically generated website with Next.js (which given the likely size of the BCR contents seemed viable).
After I posted about it the Bazel slack, I got an pretty amazing response to it.
I then joined the Bazel rules authors SIG,
and collaborated with the Bazel/bzlmod team to make the bcr-ui the official website for the BCR, which it now is! (https://registry.bazel.build).
A core challenging aspect of building the bcr-ui was and is finding inventive ways of how to gather metadata about the packaged bazel modules to display to the visitors.
The git repository backing the registry, mostly contains the bare minimum metadata required
to facilitate the technical aspects of a package manager like dependency resolution.
As many other registries (like e.g. Rust's crates.io) also involve a server component that can e.g. record the time of package publication,
they are usually in a position to better record interesting metadata. With bzlmod's git-backed registries, we are a bit more limited.
This leads the bcr-ui to e.g. infer time of publication from the git logs or deducing dependencies from parsing the MODULE.bazel file of a module.
All things considered, this works pretty well, but is also an ongoing process of finding new ways to extract and expose information for the website users (and piece-by-piece also evolving the registry format to hold more metadata).
Another challenging aspect is the static nature of the website. Rendering the whole website statically, and involving no dynamic parts was a design-decision
I made early on. This would make hosting easy, and also avoids a lot of governance headaches (e.g. who foots the hosting bill), but of course also comes
with quite a few technical limitations. E.g. by having to render a page for every module and module version and it's interdependencies, you have to analyze all
the data up-front (and do so inside the GitHub Actions deploy pipeline). Even with growing adoption of bzlmod the build as of today (November 2023) still happens
in a reasonable timeframe, though it will be interesting to see how far this approach can carry us.