Hacker News new | ask | show | jobs
by emperorcezar 1550 days ago
Cool. A way for me to "market" good software design to others without them realizing it's just normal modular design with reasonable best practices. Sadly most people need a fancy name and slide deck for this.
1 comments

"Normal" good software design takes you a bit, but it doesn't give you LEGO-like building blocks, and it will still be hard to share code between services. Polylith gives you a single development experience that you would not otherwise get. Take a look here to see what I mean: https://polylith.gitbook.io/polylith/architecture/bring-it-a...
Is there tooling or something special around this? I'm not trying to be a curmudgeon, but I'm having a hard time seeing what is novel here other than applying a name to component based modular software design.
Have you read the "Advantages of Polylith" page? https://polylith.gitbook.io/polylith/conclusion/advantages-o... It tries to summarise the benefits from both a development and deployment perspective.
That page doesn't clarify much to me. How exactly do you deploy pieces of the app as different services, while keeping it a monolith in development? Especially this thing not being a framework. Standard go/node modules give you "lego-like" pieces too. The real world example only has one "base" that puts everything together under a single API, so doesn't help understanding how this would be deployed as multiple services.
You can get an idea by looking at the Production systems page (https://polylith.gitbook.io/polylith/conclusion/production-s...) where each column in the first diagram is a project (deployable artifact / service). All components are specified in a single file, like the configuration file for the poly tool itself: (https://github.com/polyfy/polylith/blob/master/projects/poly...).

I try to explain it in the "Bring it all together" section also: https://polylith.gitbook.io/polylith/architecture/bring-it-a...

Those examples don't really tell much more. I'm guessing there are a lot of assumptions about how Clojure projects are structured.

How exactly are these deployed? Does it use k8s, Docker? Does it integrate with some particular CI setup? How can this be language agnostic? How can a single codebase be separated into multiple running http services without some kind of overarching routing framework? How do services communicate?

> It tries to summarise the benefits from both a development and deployment perspective.

Call me a pessimist, but I'm not convinced. It seems a bit hand-wavey to me.