Nothing here yet.
Nothing here yet.
Felipe, I love the idea of a monorepo, one thing that most definitely cannot happen is that a monorepo causes a monolithic build or monolithic deployment. At least on the build side of things, tools like Bazel helps a lot. I haven't heard of Polylith but it seems to solve the problem of monolithic deployment, so I'll check it out. One thing that I still find cumbersome to work with monorepo is implementing proper access control. Although I subscribe to the idea of giving as much access to developers as possible, being a Fintech means that we deal with a lot of sensitive data, so applying the principle of least privilege is very important to us. For now, we are adopting a model where one repository equals one unit of deployment. And to determine if something is a single unit of deployment is not only being a service but also if there are different roles that can perform that deployment, for example, devs that can perform changes to the production infrastructure. But rest assured that I'll explore this topic in more detail in one of the future posts of this series.
Hi Geison, so nice to hear from you. How are things in Germany? Coupling is an interesting question. The reality, in my opinion, is that you are always coupled to something. The moment you call into another piece of code, you are essentially coupled into that code. What you can do, however, is to choose what you are coupled to and control the degree of coupling you are to these things. Let me start defining the degree of coupling first. What I mean by the degree of coupling is essentially the number of places in your code base that you reference a dependency directly. For example, you can use the Redis client directly all over your codebase, or you can create an abstraction layer, and reference this abstraction layer around instead. In the first case, you have a high degree of coupling with the Redis client. In the second case, you have a high degree of coupling with your abstraction. In general, is better to have a high degree of coupling with things that you have control over or you better have a high degree of confidence that the thing you are depending on is really stable. However, if your abstraction layer is poorly designed, you may end up with the worst of both worlds: having to spend time to create and maintain the abstraction layer while still being coupled to Redis, for example. This happens in particular through leaky abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/ Now back into choosing what you're coupled to. The way I think about dependencies is just like marriage. Is this something that I'm confident that I'll be happy ever after, or should I have a prenup agreement (like an abstraction layer)? What if the dependency brings their family to live with us (the library dependencies)? As I mentioned before, at the end of the day, it is unavoidable that you are going to be coupled into something. The important thing is to choose carefully with whom you will have a high degree of coupling.