I see this criticism of libraries from monolith fans a lot, and it confuses me. That would be true anyway - you cannot use code until you've built it (unless it's in a language which is interpreted/unbuilt/uncompiled etc.). This would be true if the code lived in a separate repo or in the same monorepo.
I suspect what they really mean is "you can't consume a new version of a library until that new version has been built _and pushed to a package registry_ from which it can then be referenced", which is just false in any language I have any familiarity with - Yarn Workspaces[1] allows the "live" use of Typescript libraries in a local development environment, Python has plenty of solutions[2], even the minimalist GoLang has Workspaces[3]. What am I missing? Is there some language which lacks this Workspaces support for "depending on local versions of dependencies" that is driving all this monolith-fever?
[0] https://polylith.gitbook.io/polylith/introduction/sharing-co... [1] https://yarnpkg.com/features/workspaces [2] https://stackoverflow.com/questions/1112618/import-python-pa... [3] https://go.dev/doc/tutorial/workspaces
In the NPM/Yarn world at least this was something we encountered recently. Python has matured here but can also sometimes have weird edge cases.
Ah - this highlights that I have misunderstood something, then - because, to my mind, a workspace _is_ multiple repositories, which are siblings within a directory. Something like:
.
└── Root of the workspace/
├── repository-1/
│ ├── src
│ ├── tst
│ ├── Dockerfile
│ └── ...
└── repository-2/
├── src
├── tst
└── ...
But it sounds like you're saying that that's not the case, and that your mental model of a workspace _is_ just a single repo? Am I understanding that right?
During development, `pip install -e .` can be used to get installation from the local directory (changes are available immediately).
A monorepo with strong boundaries between components is ideal, as opposed to a monorepo-monolith, where everything depends on everything. I think it'd be far easier to explain and justify this polylith pattern if you approached it from that angle - rather than pitching it as some unique new thing.
This way, if any one service changes its API, the developer can just see what breaks and change all dependents. API changes are atomic, so we don't need any API migrations or versioning, and it's much, much easier to document API functions that are strongly typed with the appropriate types than HTTP calls.
The tooling is also great, to deploy a new application you just run the Django `startapp` command and that's it. You get authentication, background processes, events, linters, etc for free. It's very convenient, you don't even need to talk to infra.
So far so good.
Understanding Polylith through the lens of Hexagonal architecture - https://news.ycombinator.com/item?id=38109928 - Nov 2023 (2 comments)
Polylith is a functional software architecture at the system scale - https://news.ycombinator.com/item?id=30697724 - March 2022 (82 comments)
Show HN: Polylith – the last architecture you will ever need? - https://news.ycombinator.com/item?id=25253731 - Nov 2020 (10 comments)
Show HN: Polylith – A software architecture based on Lego-like blocks - https://news.ycombinator.com/item?id=18123996 - Oct 2018 (5 comments)
As for Polylith itself, it seems to have some fairly sensible non-controversial ideas like building atop a foundation of pure functions, building up shared libraries, separating code by component instead of layer, etc.
I'm curious as to what has been built (by yourselves or others) in the 4 (?) years since its release. Have the experiences held up to the initial goals and designs?
It seems to be a way to arrange your source code in a monorepo? Is there a core API? Are there servers?
Nobody "just" refactors their monolithic code into a new architecture.
Any sufficiently advanced organization with a microservices architecture has a platform team helping to standardize applications and build out shared tooling that's already being used across multiple services.
It seems like there's plenty of room for an architecture like this, but that maybe it's closer to what already exists in practice at the places where it will work, and doesn't exist at organizations where it won't work for good reason.
It doesn't _really_ solve python dependency/import issues. Instead, it helps to you keep your project in discrete chunks and well-organized. It also makes it easy to package up the separate projects as artifacts.
I've run into some issues with versioning separate projects but I suspect that is a matter of bandwidth rather than an actual, insoluble issue.
I'd use it again at a startup or on project where you need to ship a bunch of artifacts but don't have a lot of bandwidth.