Yeah, having that sort of framework is essential. It is enough work to add all the instrumentation (and ancillary concerns, like authorization/ACLs) that peopl

Yeah, having that sort of framework is essential. It is enough work to add all the instrumentation (and ancillary concerns, like authorization/ACLs) that people will not do it if there isn't a framework for it, and of course the interesting bug will be in the component that wasn't instrumented. Easier to get it right once, and then everyone at your org gets it for free. I haven't really found a way of doing dependency injection that I like. I did a lot of Java in a past life, and the dependency injection framework made it too easy to give unrelated components data they shouldn't have had access to, which ends up making testing (and debugging) a nightmare. (But, I don't miss all those functions that injected a clock instead of calling time.Now. Much easier to test!) Ultimately, I decided to just "manually" do it every time, which is tedious but easy to read. In the future, I may explore codegen on top of gRPC (to unpack things from the context, like the authenticated user, logger, etc. and pass those to handlers that take those as explicit parameters, so tests need less work to setup.) As for monorepos, I am upset whenever I don't have one. For example, I hate that my open source projects are all in separate repositories -- it means there are n places to collect bug reports, n places to write CI rules, n places to write release scripts, etc. As a result, things get missed, and some things fall out of sync with whatever my current "best practices" are. (Sometimes I fear that we have created a new class of software engineer to manage all these concerns, when the computer could be doing it for us with just a little extra tooling.) The actual code is easy to share, but all those ancillary concerns are a huge time sink.