4 ms·

Yea, but from the complexities of managing external facing libraries they do an extremely well job. As a former Googler I can jump into bazel, grpc projects or

by Narhem 2y ago

Yea, but from the complexities of managing external facing libraries they do an extremely well job. As a former Googler I can jump into bazel, grpc projects or start my own relatively easily. I tried making a few guides on a personal blog explaining how to use these tools but to be honest without seeing how they get used within Google it's relatively difficult to understand why they have some of the design decisions which may seem as clunky initially.

kelnos 2y ago
As a not-former-Googler, the last time I looked into Bazel I was confused and had no idea what I was looking at. The world is much much much bigger than Google's internal tooling. Even Google's internal tooling that they've made public.
marvin-hansen 2y ago
That is true. I am using Bazel daily with all deps vendored and proto defined as targets so there is really no need for these tools the author mentioned because with Bazel the underlying problems simply don't exist in the first place. It's worth pointing out that it takes a bit of time and pain to gronk the underlying rational for some of the less obvious design decisions. For example, Protos aren't versioned because you already version them with git. Releases usually some kind of hash, so you already have reliable dependencies with checksums. No point in versioning protos again. It's a mono repo, so why bother with distribution? Composition? Use proto lib target... Without Bazel, though, your basically totally lost and then these tools kinda make sense as a way out of the pain caused the lacking tool support you will face. That said, a lot of orgs have less then ideal IT for historical or whatever reasons so these problems are 100% real and these solutions exist for a reason.
- troupo 2y ago
  > For example, Protos aren't versioned because you already version them with git. Releases usually some kind of hash, so you already have reliable dependencies with checksums. Sorry, but this is such a stupid statement. You external service or client doesn't have access to your internal git hash > That said, a lot of orgs have less then ideal IT for historical or whatever reasons No. A lot of orgs don't require setting up Bazel to make simple things like generating code from protobufs work
  - crustycoder 2y ago
    It's a stupid statement internally as well. Unless you can freeze time itself, deploying new versions of stuff isn't instantaneous. And what happens if you need to do a rollback of a component?
    - SR2Z 2y ago
      > And what happens if you need to do a rollback of a component? You revert the offending commit. That triggers an automatic deploy (or, even more likely, your buggy change gets caught in the canary stage and automatically reverted for you). The Google philosophy is called "live at head" and it has a bunch of advantages, provided your engineers are disciplined enough to follow through.
      - troupo 2y ago
        Until you run into things like "your partners deploy once every two months" or "the team's deploy is delayed by X due to unforseen changes downstream" or ... Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
        lopkeny12ko 2y ago
        Well, the core problem is that you shouldn't be deploying as infrequently as every 2 months...you should spend engineering energy to fix that rather than on working around it.
        crustycoder 2y ago
        Must be nice not to have to live in the real world.
        SR2Z 2y ago
        Deploying every two months is not required to live in the real world.

by Narhem 2y ago

kelnos 2y ago

As a not-former-Googler, the last time I looked into Bazel I was confused and had no idea what I was looking at. The world is much much much bigger than Google's internal tooling. Even Google's internal tooling that they've made public.

marvin-hansen 2y ago

That is true. I am using Bazel daily with all deps vendored and proto defined as targets so there is really no need for these tools the author mentioned because with Bazel the underlying problems simply don't exist in the first place. It's worth pointing out that it takes a bit of time and pain to gronk the underlying rational for some of the less obvious design decisions. For example, Protos aren't versioned because you already version them with git. Releases usually some kind of hash, so you already have reliable dependencies with checksums. No point in versioning protos again. It's a mono repo, so why bother with distribution? Composition? Use proto lib target... Without Bazel, though, your basically totally lost and then these tools kinda make sense as a way out of the pain caused the lacking tool support you will face. That said, a lot of orgs have less then ideal IT for historical or whatever reasons so these problems are 100% real and these solutions exist for a reason.

troupo 2y ago
> For example, Protos aren't versioned because you already version them with git. Releases usually some kind of hash, so you already have reliable dependencies with checksums. Sorry, but this is such a stupid statement. You external service or client doesn't have access to your internal git hash > That said, a lot of orgs have less then ideal IT for historical or whatever reasons No. A lot of orgs don't require setting up Bazel to make simple things like generating code from protobufs work
- crustycoder 2y ago
  It's a stupid statement internally as well. Unless you can freeze time itself, deploying new versions of stuff isn't instantaneous. And what happens if you need to do a rollback of a component?
  - SR2Z 2y ago
    > And what happens if you need to do a rollback of a component? You revert the offending commit. That triggers an automatic deploy (or, even more likely, your buggy change gets caught in the canary stage and automatically reverted for you). The Google philosophy is called "live at head" and it has a bunch of advantages, provided your engineers are disciplined enough to follow through.
    - troupo 2y ago
      Until you run into things like "your partners deploy once every two months" or "the team's deploy is delayed by X due to unforseen changes downstream" or ... Protobuf is built specifically for Google and Google's way of doing things. Not everyone is built like Google.
      - lopkeny12ko 2y ago
        Well, the core problem is that you shouldn't be deploying as infrequently as every 2 months...you should spend engineering energy to fix that rather than on working around it.
        crustycoder 2y ago
        Must be nice not to have to live in the real world.
        SR2Z 2y ago
        Deploying every two months is not required to live in the real world.