What I found was 10 minutes of LEGO-bricks analogies.
What I didn't find, is an answer how this is supposed to be that much different from Microservices or libraries.
https://polylith.gitbook.io/polylith/
Polylith addresses these challenges by introducing simple,
composable, LEGO-like bricks, which can easily be shared across
teams and services. The choice of bricks determines what each
artifact does and how it's exposed.
Okay, sounds neat, but ... doesn't that pretty much describe a Microservice? A somewhat-self-contained building block that exposes an interface?And if it doesn't, isn't this just describing a module/package/library?
Sure, I mean, the idea of having all these libraries in one repository is neat, but...where is the difference from having all of them externally, in their own repos, and leaving the rest to the build pipeline?
Again, this is just based on what I found in 10 minutes of lazy skimming, so if anyone wants to point out something important I overlooked or didn't understand, I'm happy to be corrected.
Typically not the most ideal option either.
Microservice is a particular interface. If you have GRPC or REST errors being thrown from a function, you're probably letting the interface leak into your program. .
Happy to be corrected, I hope I'm wrong.
With Polylith, all of that code lives in the same git repo, and you don't publish them to a repository because you have it "right there". For Python, you reference the reusable code just as any other Python namespace package. Basically the same thing for a Clojure namespace.
Everything isn't sharing everything, but several different services or apps could be using one and the same brick (as it is called in Polylith). A brick is a small isolated part of the code (usually much smaller than a library, that is an entire feature). I hope this has cleared some things up!
Yes, Microservices is about boundaries, data and the organizational structure. But there is code that makes these things happen and much of that can be reused.
- How many deployment artifacts do we have? How many nodes/machines running different processes?
- How do we ensure clear separation of domain boundaries (something which microservices excel at) while still staying flexible when those boundaries change (something which a monolith excels at)? Essentially: How do we prevent chaos?
- When changing one of the LEGO bricks, who is responsible for updating their usage downstream? What is the contract here?
I’ve found Polylith a wonderful way of structuring projects over the years. One of the things I really enjoy is having “interfaces” again, instead of relying on anonymous/private functions (in eg clojure) to hide implementation.
After many clicks i found this https://davidvujic.github.io/python-polylith-docs/examples/ which does not help me
Just a before and after example with online comments of the advantages or something
But poly- or monolithic is a way to describe how the code is organized. It must never be an end goal in itself. That way lies madness.
Most monorepos I work with do not use a single language but many. It's pointless to use multiple tools for the same thing instead of one that works with all languages, like nx for example.
I though the point of microservices was mainly that they could be developed and deployed completely independently (in different repos, by different teams, in different languages, with different dependencies).
(Also you can scale them independently, I guess, but you can often do that just by changing the config of your database or app server.)