1. 7

    This post doesn’t say anything useful. The meat of it appears to be:

    To avoid future pain architect the monolith into modules with strict APIs between them. This will make it much easier to split it up into microservices later if you need to scale out. But for now you still get the benefits of being able to easily change the APIs in a single commit and push a single binary to prod.

    But…everyone I’ve worked with already knows that advice or can parrot it back to me. People don’t really know what “strict APIs between them” translates into. They also don’t know how to balance making a strict boundary with delivery pressure. This post doesn’t give any insight into addressing that.

    1. 2

      What I found useful about is is when to split the monolith into modules. He says to do it when the team cannot fit in one room anymore, and after achieving product/market fit and experimenting quick user growth.

      1. 4

        What exactly is useful about that? I can make any claim about when is best to break up a monolith. I could say “never” and some people will think I’m great for it.

        1. 1

          It seemed like useful guidelines to me.

      2. 1

        I agree. The recommendations are general and common. It could be better if he went into more detail on each point with examples.

        1. 1

          Thanks for the feedback. Many programming languages allow you to selectively export/expose functionality from a module to other modules. Applying the principle of least privilege to this means that you only expose what is actually needed by another module. At this point you should write unit tests for it and add a comment to the code describing what the exported functionality promises to do. Better still, have an architecture diagram showing dependencies b/w modules and update this every time a new dep is added. This will help warn the team when the dependencies are starting to look like a fully connected graph.

          You can still change this but you’ll need to update the test and the callers when you do it. You’ll know it’s stable when you haven’t had to change it in a while. You’ll know a module has a stable API when you haven’t had to change any of the functionality it exports for a while.

          Lastly, if you discover that 2 modules are tightly interconnected, that’s a signal that they may need to be merged.

          If this is helpful, I can add it to the post itself.

          1. 3

            I still find this advice far too generic. A good API boundary is more than just which functions the API exposes and decent documentation.

        1. 1

          The article admits the uncanny valley is at play. I suspect such videos won’t get much play once the curiosity/novelty factor runs out because of this.

          1. 3

            The uncanny valley will disappear though, just give it 2-5 years in software + hardware evolution…