What makes Polylith so simple, fast and fun to work with?
Let's compare Polylith with the three architectures we looked at earlier.
A Polylith project can be deployed as any artifact, like a service, toolor library. The most common usage is to deploy them as different kinds of services, which is what we will show in this example.
Polylith's single development project allows us to work with all of our building blocks in one place. This disconnects our development experience from our chosen deployment architecture.
Untangling development from deployment allows us to delay our deployment decisions until the last possible moment. This delay allows us to avoid "premature distribution" and keeps our systems as simple as possible, for as long as possible.
The simplicity, clarity, and maintainability of Polylith codebases, combined with its frictionless development experience, greatly increases team effectiveness which substantially reduces development cost.
All the code in a Polylith developmentproject can run within a single REPL, giving us a first-class REPL-driven development and debugging experience.
The Polylith Tool keeps track of which bases and components have changed since the last stable point in time and only tests those. This gives us lightning-fast feedback both in our local developmentenvironment and when we build and deploy in our Continuous Integration environment.
Components and bases are connected to components with simple function calls. This means that we can safely refactor the code with our editor/IDE.
Components are inherently reusable because they are encapsulated, stateless and composable. They can be reused within a single service and across multiple services (and other artifacts).
Polylith building blocks are just code; a collection of functions behind an interface. Interfaces guarantee encapsulation, which ensures our codebase remains untangled, leading to simpler services.
The encapsulated and functional nature of components makes them easy to test in isolation, and as complete services.
Not only does Polylith allow us to delay our deployment decisions, it also allows us to easily change our deployment architecture, when the need arises. That's because Polylith makes it easy to recombine our components into any number of services and deploy them to meet our performance needs.
Because Polylith allows us to keep our deployment architecture as simple as posslible as long as possible, it reduces costs by reducing the number of services we need to run in our test, staging, and production environments.
The Polylith Tool makes the build and deployment process simple and seamless, both locally and in our Continuous Integration environment.
When a Polylith service isn't achieving the performance/scalability we need, then Polylith makes it easy to create new services and scale our system horizontally. We can reuse existing components within each new service.
Seeing all these green traffic lights for Polylith probably looks too good to be true. The best way to find out is to try Polylith for yourself!