Show HN: Polylith – the last architecture you will ever need?
polylith.gitbook.io
Show HN: Polylith – the last architecture you will ever need?
1–10 of 11 posts
Re: Show HN: Polylith – the last architecture you will ever need?
#2Re: Show HN: Polylith – the last architecture you will ever need?
#3E.g. Development Tooling that lets you better manage different architecture patterns.
Re: Show HN: Polylith – the last architecture you will ever need?
#4I took me a while to understand what it is. I would wish we have more concise description and value proposition. E.g. Development Tooling that lets you better manage different architecture patterns.
Re: Show HN: Polylith – the last architecture you will ever need?
#5The Polylith team has just released a big update to the Polylith architecture. Now it's even simpler to grow software out of composable LEGO-like building blocks. The whole team is here to answer your questions.
I was really impressed with how it encouraged decoupling, and it has positively affected how I write code and think about dependencies.
Re: Show HN: Polylith – the last architecture you will ever need?
#6I took me a while to understand what it is. I would wish we have more concise description and value proposition. E.g. Development Tooling that lets you better manage different architecture patterns.
Thanks for your feedback. Did you see the sub-heading at the top of the first page: “Polylith is a software architecture that applies functional thinking at the system scale. It helps us build simple, maintainable, testable, and scalable backend systems.“? If so, how would you suggest we reword it to be clearer?
Is it?
- read through our book and you'll become better at designing great code
- read through our book and learn how to refactor your current codebase into a better codebase
- use our tools and you'll build better systems in less time
- use our libraries and you'll build better systems in less time
- buy into our ecosystem and get lots of pluggable components
- something else?
Conceptually, I get that better design can improve development workflows, but it's hard to tell where the rubber meets the road when it comes to polylith. When I read the transitioning to polylith, it sounds like I have to download some new tool, "import" all my code, and then I rewrite all the code? That sounds like a lot of work and I still don't know what the that means in practical terms.
Re: Show HN: Polylith – the last architecture you will ever need?
#7The Polylith team has just released a big update to the Polylith architecture. Now it's even simpler to grow software out of composable LEGO-like building blocks. The whole team is here to answer your questions.
Can you sum up what's new, or point me to a changelog? I took a serious dive into it in late 2019, but ended up pausing because of tooling deficiencies - mainly dealing with symlinks, iirc. I was really impressed with how it encouraged decoupling, and it has positively affected how I write code and think about dependencies.
The original version of the tool used: - Leiningen to compile and build the artefacts - symlinks to keep the code in one place (but allow for reuse in multiple artefacts) - "workspace interfaces" (empty component interfaces) to guarantee the decoupling between components
The new version of the tool uses: - tools.deps to build the artefacts and remove the need for symlinks - static code analysis to remove the need for "workspace components"
Re: Show HN: Polylith – the last architecture you will ever need?
#8Earlier quoted context omitted.
Thanks for your feedback. Did you see the sub-heading at the top of the first page: “Polylith is a software architecture that applies functional thinking at the system scale. It helps us build simple, maintainable, testable, and scalable backend systems.“? If so, how would you suggest we reword it to be clearer?
Every software architecture promises to make your software better and easier so the subheading is mostly buzzword "noise". It's unclear what makes polylith different other than it claims it's more functional. I've tried to click through to understand what Polylith means in practice. Is it? - read through our book and you'll become better at designing great code - read through our book and learn how to refactor your c…
One of the key benefits is how it separates development from deployment, giving you the freedom to work with your code as though it's a monolith, but choose to deploy it as any number of services.
To make the development experience even more delightful, we've also built a tool (currently only supporting Clojure, but with nothing stopping the development of tools for other languages) which gives instant creation of new components and bases, incremental tests (only test the code that's impacted by the last change), build support, and project visualisation.
So to answer your question, there's definitely some code rewriting involved to convert to Polylith from an existing codebase, but usually the steps involved are quite clear, and the outcome will be a codebase that we predict you'll be delighted to work with!
Re: Show HN: Polylith – the last architecture you will ever need?
#9Earlier quoted context omitted.
Can you sum up what's new, or point me to a changelog? I took a serious dive into it in late 2019, but ended up pausing because of tooling deficiencies - mainly dealing with symlinks, iirc. I was really impressed with how it encouraged decoupling, and it has positively affected how I write code and think about dependencies.
We've simplified the architecture, by reducing the number of concepts down to just three: components, bases, and projects. The tool is simpler, gives faster feedback, and a better visualisation of your projects, due to (amount other design changes) switching from Leiningen to tools.deps. The original version of the tool used: - Leiningen to compile and build the artefacts - symlinks to keep the code in one place (but…