5 ms·

Honestly, I don't know enough Clojure to understand the proposal, and all the explanations are centered around it. My current understanding is that what you pro

Honestly, I don't know enough Clojure to understand the proposal, and all the explanations are centered around it. My current understanding is that what you propose is an ascribed way of doing things by mixing several pre-existing concepts, like mono-repo, convention over configuration, and some generic dev principles that are universally desirable, like components "ensure encapsulation and composability but at the same time they are simple, easy to reason about, and flexible" - nothing wrong in that, all good principles, but I fail to understand how you enforce it. Because usually every monolith or micro-service out there starts with that in mind, and ends with spaghetti, because dev happens. At least that's my experience with Elixir/Phoenix umbrella apps, which, as per my current understanding, is the closest thing I see to Polylith. However, I would be very curious about your traffic lights evaluation. Generally, I would consider a "large" app something like 200+ microservices (yes, I'm biased towards that). In your FAQ, you describe and app that needs 4 services. Sorry, that doesn't qualify as a large distributed system. First, I would really doubt you can find a monorepo which is one language only (sorry, I didn't understood how Polylith would work if I have a codebase that's Scala, Elixir, Rust and Python, by example). Second, I don't understand how you handle builds. Third, I don't understand how you handle deployments and other operational concerns.

logarhythm 5y ago
Your understanding of Polylith is essentially correct. It is a combination of existing ideas, such as monorepos, convention, components, interfaces, encapsulation, and static code analysis. However, I'd argue that what emerged in Polylith from those ingredients was more than the sum of its parts - due to how those particular concepts resonate with each other. For example, because of the forced conventions, it's trivial for the Polylith Tool to perform static code analysis on a Polylith codebase. This means that the tool can identify the subset of tests to run, based on the components that have changed since the last run. Which leads to a fast-feedback loop, and encourages both good testing practices and fine-grained component modularity. Polylith gives you a system-level architectural building block; the component, which encourages a modular design and separation of concerns. However, you're right that it's still possible to create spaghetti code with Polylith. All it would take is poorly designed components, with bad names, multiple reasons to change, and exposing their state everywhere. However, I'd argue that when you give someone a well designed tool (like Polylith), then they're more likely to craft a well designed product with it. To understand how builds and deployments work with Polylith, I'd recommend reading the "Workflow" section in the Polylith Tool's documentation: https://polylith.gitbook.io/poly/workflow/shell https://polylith.gitbook.io/poly/workflow/shell (especially "Build", "Git", "Continuous Integration", and "Testing").
- riwsky 5y ago
  Large monorepos tend to already support such analysis via tools like Bazel.
- mst 5y ago
  It feels like what you're going to get out of using it is basically a set of conventions, best practices, rules and tooling support that make doing the right thing (for some specific opinions of right, but I think I share enough of the opinions to leave it at that caveat) the natural and obvious thing to do. I'm sort of reminded of adopting a formatting and linting stack across a codebase - so long as it mostly makes mostly good choices, the shared conventions are usually a net win overall just because it (a) makes code more accessible across the team (b) gives you a solid default way to resolve a lot of choices. The whole "can -reliably- figure out which tests need to be re-run" part specifically sounds like it would be a very nice thing to have. I suspect your biggest challenge in terms of adoption will be the requirement for development group wide buy in to get the full benefits, but that's a problem that's kind of inherent to the goals you're trying to achieve here and so I shall simply wish you good luck with that part.
  - logarhythm 5y ago
    That's right, it's a highly opinionated approach to building software, which comes with a host of benefits. Including my favourite; a complete untangling of your development and production environments. With Polylith you always develop your system as a monolith (because that's the most effective way to build software), but you're able to deploy it as multiple services (because that's sometimes the most effective way to run software). It turns out that separating deployment complexity from development complexity is a game-changer, and something that I haven't come across from other architectures. It's true that you don't reap all the benefits of Polylith until your entire codebase uses the same structure, which feels a bit like "all or nothing". However, many of the benefits are unlocked "as you go", so even converting one or two existing microservices to Polylith will feel like a nicer codebase to work with. > so I shall simply wish you good luck with that part Thanks!
    - 5y ago

logarhythm 5y ago

Your understanding of Polylith is essentially correct. It is a combination of existing ideas, such as monorepos, convention, components, interfaces, encapsulation, and static code analysis. However, I'd argue that what emerged in Polylith from those ingredients was more than the sum of its parts - due to how those particular concepts resonate with each other. For example, because of the forced conventions, it's trivial for the Polylith Tool to perform static code analysis on a Polylith codebase. This means that the tool can identify the subset of tests to run, based on the components that have changed since the last run. Which leads to a fast-feedback loop, and encourages both good testing practices and fine-grained component modularity. Polylith gives you a system-level architectural building block; the component, which encourages a modular design and separation of concerns. However, you're right that it's still possible to create spaghetti code with Polylith. All it would take is poorly designed components, with bad names, multiple reasons to change, and exposing their state everywhere. However, I'd argue that when you give someone a well designed tool (like Polylith), then they're more likely to craft a well designed product with it. To understand how builds and deployments work with Polylith, I'd recommend reading the "Workflow" section in the Polylith Tool's documentation: https://polylith.gitbook.io/poly/workflow/shell https://polylith.gitbook.io/poly/workflow/shell (especially "Build", "Git", "Continuous Integration", and "Testing").

riwsky 5y ago
Large monorepos tend to already support such analysis via tools like Bazel.
mst 5y ago
It feels like what you're going to get out of using it is basically a set of conventions, best practices, rules and tooling support that make doing the right thing (for some specific opinions of right, but I think I share enough of the opinions to leave it at that caveat) the natural and obvious thing to do. I'm sort of reminded of adopting a formatting and linting stack across a codebase - so long as it mostly makes mostly good choices, the shared conventions are usually a net win overall just because it (a) makes code more accessible across the team (b) gives you a solid default way to resolve a lot of choices. The whole "can -reliably- figure out which tests need to be re-run" part specifically sounds like it would be a very nice thing to have. I suspect your biggest challenge in terms of adoption will be the requirement for development group wide buy in to get the full benefits, but that's a problem that's kind of inherent to the goals you're trying to achieve here and so I shall simply wish you good luck with that part.
- logarhythm 5y ago
  That's right, it's a highly opinionated approach to building software, which comes with a host of benefits. Including my favourite; a complete untangling of your development and production environments. With Polylith you always develop your system as a monolith (because that's the most effective way to build software), but you're able to deploy it as multiple services (because that's sometimes the most effective way to run software). It turns out that separating deployment complexity from development complexity is a game-changer, and something that I haven't come across from other architectures. It's true that you don't reap all the benefits of Polylith until your entire codebase uses the same structure, which feels a bit like "all or nothing". However, many of the benefits are unlocked "as you go", so even converting one or two existing microservices to Polylith will feel like a nicer codebase to work with. > so I shall simply wish you good luck with that part Thanks!
  - 5y ago