jbmsf

There's a lot to unpack here, but I'll focus on #2, specifically the client dependency.

My approach is to assign projects to teams with members who can work on both the client and server layers so that the question is less of client blocking on server and more of client and server working together.

In addition, I like an "API first" approach, which in this case means building the signature of the API functions (e.g with mock data) before finishing the implementation.

That is: client is still blocked on server to define the API, but they are not blocked on implementing the API and client works closely enough with server (or is able to do both) such that they aren't blocked on the definition.

As always, many software problems devolve into people problems once you stare at them hard enough.

It's always a bit risky to document contracts with the left hand and implement them with the right. The best case to me is a framework that serves both functions at once.

I built something like this at my last job by having an opinionated layer on top of Flask in Python. The idea was to have a small set of standard operation types (think:create, retrieve, update) and choices as to input/output types (via the marshmallow library ) and the function to process the route. This turns out to be enough to generate both the api contract and the boilerplate for routing, (un)marshalling, etc.

You can find the implementation in this repo: https://github.com/globality-corp/microcosm-flask

Also: set PIP_REQUIRE_VIRTUALENV=true

You won't be able to install with pip unless you are in a virtualenv.

In general, I believe in this kind of system. I've long been a fan of public engineering ladders (see: Rent the Runway) and create a real career path for non-managers.

But... I see a lot of companies hiring at the senior end of the management track (Directors, VPs, etc.) and not so much on the non-management side (usually tops out a senior engineer).

I think that if companies are serious about non-managerial tracks, they need to hire for such roles more seriously.

Excellent post, thank you.

I've run into similar challenges in a number of (mostly microservice) systems that also avoided monorepos (for various practical and philosophical reasons). Parts of the solution space here are very familiar, especially relating to dependency management and "goldilocks" framework infrastructure.

I've especially found that most cloud CI tools (e.g. Circleci) fall flat here without a lot of additional work. Those ecosystems seem designed for a single repo; there's a big opportunity for someone to get CI right for non-trivial, multi-repo projects.

Until/unless we find some solution for regulatory capture, this direction is a lot less appealing to me. I hardly think the current regulation of telecoms is a good example of what's best for the public.

Rings true to me.

re: why review; I commented about this above, but:

1. We prefer to be able to say that everything is reviewed, but that in this particular case the review works automatically. Requiring a PR review is important to our security model (and therefore, our business). Skipping review, especially in a library that contains both these definitions and the code that leverages them would be too cavalier for us. 2. We want to give developers control over when these changes are merged. Many API changes are coordinated with other changes (e.g. in integrating services). We _could_ require backwards compatibility, but we find this too onerous in this layer of our stack.

re: test first; we have a very thorough process for qualifying releases:

- As much as we like continuous deployment, our (enterprise) customers aren't particularly interested in continuous changes to their experience and the $VALUE of a customer to us is far to high to take that kind of risk. - Practically speaking, we adopt the git-flow model and have separate deployment environments for integration (`develop` branch), QA (`release/` branch), staging (`tags/`) and then promote changes out to production, subject to suitable approvals/controls. I'm fully aware that this approach may sound cumbersome, but it's not in our line of business.

I don't agree at all. (Aside: I work with the author, so I am biased. We all are.)

Some relevant context: - Despite your interpretation, we believe strongly in PR review outside of this narrow area. In our business, security and appropriate controls are a $BIG_DEAL and being able to say that every PR goes through a well-defined approval process (even if part of that process is automated) carries infinitely more weight than "developers force push whenever they feel like it." - One of the benefits of auto-approval is that developers control when these kinds of changes are integrated. We thought about having a fully-automated process where changes in services automatically update this library and decided that this behavior wasn't desirable because many API changes need to be _coordinated_ with other changes. We want developers to be able to decide when to merge this kind of PR in conjuction with other PRs. (The alternative is a strong commitment to backwards compatibility at all times, which is not a constraint we're willing to impose on every developer at this time in our business. YMMV.) - I honestly don't understand your comment around re-implementing a monolith, but I'd love to talk about it more since this is a topic I have many opinions about. My take is that micro-services should interoperate via HTTP APIs and that these APIs should be automated as much as possible. We do this by having our code generate Open API (aka Swagger) definitions based on our code and publishing the resulting schema at `/api/v[N]/swagger` in a deployed service. However, we still need a way for other services to to integrate with these APIs. So far, a "monolith" client library, updated in the way this post describes, has worked quite well. I am eager to hear about alternatives.

We also try to avoid the you/they dichotomy. It's bad culture.

Who's ready to buy Behemoth?