5 ms·

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

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.

tengstrand 5y ago
"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-all-together https://polylith.gitbook.io/polylith/architecture/bring-it-a...
- emperorcezar 5y ago
  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.
  - logarhythm 5y ago
    Have you read the "Advantages of Polylith" page? https://polylith.gitbook.io/polylith/conclusion/advantages-of-polylith https://polylith.gitbook.io/polylith/conclusion/advantages-o... It tries to summarise the benefits from both a development and deployment perspective.
    - ricardobeat 4y ago
      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.
      - tengstrand 4y ago
        You can get an idea by looking at the Production systems page (https://polylith.gitbook.io/polylith/conclusion/production-systems 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/deps.edn 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-all-together https://polylith.gitbook.io/polylith/architecture/bring-it-a...
        ricardobeat 4y ago
        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?
        tengstrand 4y ago
        In Clojure you put your functions in namespaces (sometimes named modules or packages in other languages). In an object oriented language you put your classes in namespaces too, but the way you would implement Polylith in an OO language is to expose static methods in the component interfaces, which would have to live in a class with the same name as the Interface. Polylith doesn't help you with the deployment of the project, that code you have to write yourself, but it's possible to calculate if a project has been affected by the latest changes or not (the 'poly' tool that we have build for Clojure, supports that, but it can be implemented for other languages too, and what you get is support for incremental builds and tests = only build the project that are affected by the change and only run affected tests). Polylith is an idea about how to decouple and organise code, in the same way that FP and OO are ideas that can be materialsed in different computer languages. The whole codebase lives in a single repository, but all components (and bases) have their own src, test and resources directories. We then pick and choose from these sources to create projects from where we build artefacts. All projects live in the same repository in a workspace and if you structure the code the "normal" way, each project may live in its own repository with a single src directory (+ test and resources) but then you had to put all the code into that single src directory. What Polylith does, is to let each project specify (in a configuration file) which set of src directories it needs, instead of putting everything into a single src directory. This is supported out of the box in Clojure, but in e.g. Java, if you use Maven, you need a Maven plugin for that. The deployed services communicate with each other through their public API. No difference from what you would otherwise do.
    - celdon25 4y ago
      > 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.

tengstrand 5y ago

"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-all-together https://polylith.gitbook.io/polylith/architecture/bring-it-a...

emperorcezar 5y ago
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.
- logarhythm 5y ago
  Have you read the "Advantages of Polylith" page? https://polylith.gitbook.io/polylith/conclusion/advantages-of-polylith https://polylith.gitbook.io/polylith/conclusion/advantages-o... It tries to summarise the benefits from both a development and deployment perspective.
  - ricardobeat 4y ago
    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.
    - tengstrand 4y ago
      You can get an idea by looking at the Production systems page (https://polylith.gitbook.io/polylith/conclusion/production-systems 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/deps.edn 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-all-together https://polylith.gitbook.io/polylith/architecture/bring-it-a...
      - ricardobeat 4y ago
        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?
        tengstrand 4y ago
        In Clojure you put your functions in namespaces (sometimes named modules or packages in other languages). In an object oriented language you put your classes in namespaces too, but the way you would implement Polylith in an OO language is to expose static methods in the component interfaces, which would have to live in a class with the same name as the Interface. Polylith doesn't help you with the deployment of the project, that code you have to write yourself, but it's possible to calculate if a project has been affected by the latest changes or not (the 'poly' tool that we have build for Clojure, supports that, but it can be implemented for other languages too, and what you get is support for incremental builds and tests = only build the project that are affected by the change and only run affected tests). Polylith is an idea about how to decouple and organise code, in the same way that FP and OO are ideas that can be materialsed in different computer languages. The whole codebase lives in a single repository, but all components (and bases) have their own src, test and resources directories. We then pick and choose from these sources to create projects from where we build artefacts. All projects live in the same repository in a workspace and if you structure the code the "normal" way, each project may live in its own repository with a single src directory (+ test and resources) but then you had to put all the code into that single src directory. What Polylith does, is to let each project specify (in a configuration file) which set of src directories it needs, instead of putting everything into a single src directory. This is supported out of the box in Clojure, but in e.g. Java, if you use Maven, you need a Maven plugin for that. The deployed services communicate with each other through their public API. No difference from what you would otherwise do.
  - celdon25 4y ago
    > 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.