The first software architecture book (Garlan & Shaw 1996) already talked about components and connectors, but even if you're only restating some of the golden rules here, what matters is more people using a similar vocabulary. Cheers.
I struggle to understand the difference between this and Port/Adapters + Packages. Do you have some material to show some comparison between, maybe port/adapters, onion, or hexa?
That's a good question to add to the FAQ (polylith.gitbook.io/polylith/conclusion/faq), thanks! 🙂 The extremely short answer is that Polylith's component interfaces are analogous to ports, and base APIs are analogous to adapters. Polylith components aren't arranged into layers like in onion architecture, so you should think of them more as a "bucket of bricks" which can be assembled into services.
That's great to hear! Feel. free to give us any feedback you come up with (positive or negative) in the #polylith channel in Clojurians (clojurians.slack.com)
@@Misophistful Hi! I saw the word 'graph' mentioned in some part of the documentation - how can I explore the DAG that polylith maintains, such that I might reason about a polylith component?
@@stiiffyrabbit Hi! You can view the dependencies between components using the `poly deps` command (polylith.gitbook.io/poly/workflow/dependencies). Does that get you what you're looking for?
In terms of abstraction level, components lie somewhere between a class and a microservice. i.e. It's not unusual for components to have more functionality than you'd normally put in a single class, and you almost always build your services with several components. Because components can also be thought of as a "scaled up" function, we'd definitely recommend keeping them as pure as possible, as that makes testing easier. Avoiding mutable state (wherever that's possible with your performance constraints) is the right way to build software, so that's definitely recommended too.
Hi! The initial version of the Polylith Tool is written in Clojure and is a Polylith itself: github.com/polyfy/polylith , alternatively you can take a look at the Real World example: github.com/polyfy/polylith
"making code duplication a thing of the past" he says "a level of speed, fun & collaboration I've never come across before" he says man... all this deep, arcane, thoughtful philosophy to re-invent the wheel yet again: yes, components are the right abstraction level for building systems they are composable parts that clearly describe the solution they build up to and they enable rapid application development sound familiar? sound like the terminology of 2 decades ago? why the heck does every single language take so long to go thru the same motions and finally arrive at "components"? what's next? a never-before-seen, state-of-the-art, exciting new technology called wysiwyg??? ... thanks for the video btw, I'm gonna go cry in a corner for a bit
Thank you for taking the time to make a comment. Could you point me to a language, architecture, or framework, which uses "components" like the ones in Polylith? In other words, do their components separate interface from implementation? Do their components allow the separation of the development environment from your deployment configurations? Do their components allow for seamless code reuse across teams and services? If so, then I'd love to find out more about that approach!
@@Misophistful You forgot to mention about monorepo. And I would like to hear more about "seamless code reuse" across team and services whereas there lets say 50 teams in some common enterprise entity trying to use the one monorepo. As for the "In other words, do their components separate interface from implementation" well that's the part of a component definition. Have you heard about COM? Words like IDispatch/IUnknown bring any memories to you? Or dependncy injection pattern if you like - same thing open interface / closed implementation. As for "development environment from your deployment configurations", well, that primary reason people use monorepos.
@@MaximBazhenov Thank you for your comment, and I understand the instinct to question the innovation of an idea which is seemingly just a new arrangement of existing ideas. I think someone could use a similar argument to question how innovative the original iPhone was: "There were already phones with a touch screen, a web browser, general computing capabilities, a calendar, a clock - so what was the innovation, the map?" However, sometimes the whole is greater than the sum of its parts. I think the same is true with Polylith. Monorepos are an existing idea, but Polylith supercharges them by combining them with components and projects, giving us a new architectural-level building block and tool for combining those blocks into deployed services and applications. Components are an existing idea, but Polylith supercharges them by combining them with a functional-inspired interface, making it easy to compose them together and reuse them across projects. Projects are an existing idea, but Polylith supercharges them by letting you construct them out of a set of component building blocks - cleanly separating your development environment from your deployment configuration. Hopefully you understand my point. Polylith isn't innovative because it created lots of new ideas from scratch, it's innovative because it combined existing ideas in a new way. I'd argue that Polylith is one of those ideas that's greater than the sum of its parts.
@@MaximBazhenov > And I would like to hear more about "seamless code reuse" across team and services whereas there lets say 50 teams in some common enterprise entity trying to use the one monorepo. The more teams that are working on a single codebase, the more difficult it is to coordinate their activities, and the more likely it is that they will tread on each other's toes. Polylith doesn't solve that fundamental coordination challenge. However, Polylith does give teams some tools to help make that challenge slightly less daunting. Including: components that help to divide the domain cleanly and understandably, interfaces that give stability when working with each other's code, code pass-through that allows instant refactoring across the entire codebase, and projects that let teams coordinate with their deployed artefacts.
@@Misophistful I don't want to sound arrogant, but at the begining of every project there's a decision to make about how to structure its code base and build pipeline. Every software development shop has its own approaches to the task. Every lead developer has had to apply a known way or improve it or create his/her own. This "innovative" Polylith approach has been "invented" hundred of times, it's just it's so obvious that no other bothered to start hyping it as if it is some breakthrough in software development industry. Thanks for the presentation, but it made me to feel old ;), I've seen the same at least 3 times beforehand during my lifetime, every ~5 years the loop closes and another developer starts to describe this innovative approach again. p.s. It is possible that I've missed some crucial piece of the idea, I will read more about Polylith, but for now I don't see any innovation here.
Sorry, You lost me and probably every other competent Java developers ( or any other language ) at 1:07 when you presented the absolutely worst way to determine if a String or CharSequence contains no characters other than whitespace. This is very clear of its "intent" by the method name, the implementation is terrible.
Hi Jarrod, thank you for taking the time to make a comment, and I'm sorry to hear that I lost you so early in the video. It's interesting that you find the imperative Java example so terrible, as it's taken directly from the Apache Commons StringUtils class (github.com/apache/commons-lang/blob/c20dcdadd49bb8371dbcee6a955960760a239aca/src/main/java/org/apache/commons/lang3/StringUtils.java#L340) Let's put aside whether or not the StringUtils code is the worst way to determine if a String is blank, could I ask if you agree with my general assertion that it's better to program with abstractions that encourage us to create succinct and descriptive solutions?
@@Misophistful Great video, as this is in clojure, is there a reason stated somewhere why Components use no-op functions as interfaces instead of Protocols?
The first software architecture book (Garlan & Shaw 1996) already talked about components and connectors, but even if you're only restating some of the golden rules here, what matters is more people using a similar vocabulary. Cheers.
Components sound like Django Apps. This also reminds me of the Grug Brained developer and cut points.
Exactly!
I struggle to understand the difference between this and Port/Adapters + Packages. Do you have some material to show some comparison between, maybe port/adapters, onion, or hexa?
That's a good question to add to the FAQ (polylith.gitbook.io/polylith/conclusion/faq), thanks! 🙂
The extremely short answer is that Polylith's component interfaces are analogous to ports, and base APIs are analogous to adapters. Polylith components aren't arranged into layers like in onion architecture, so you should think of them more as a "bucket of bricks" which can be assembled into services.
@@Misophistfulthank you! I will check it!
This looks awesome! I'll try to use it in my next side-project
That's great to hear! Feel. free to give us any feedback you come up with (positive or negative) in the #polylith channel in Clojurians (clojurians.slack.com)
@@Misophistful Hi!
I saw the word 'graph' mentioned in some part of the documentation - how can I explore the DAG that polylith maintains, such that I might reason about a polylith component?
@@stiiffyrabbit Hi! You can view the dependencies between components using the `poly deps` command (polylith.gitbook.io/poly/workflow/dependencies). Does that get you what you're looking for?
What features/properties does a programming language need to have, or need to not have, to be able to build a Polylith architecture?
Any language that includes methods/functions and namespaces/packages/modules should allow a Polylith structure.
I'm a bit confused, so are components essentially just like OOP classes but without the internal mutable state?
In terms of abstraction level, components lie somewhere between a class and a microservice. i.e. It's not unusual for components to have more functionality than you'd normally put in a single class, and you almost always build your services with several components.
Because components can also be thought of as a "scaled up" function, we'd definitely recommend keeping them as pure as possible, as that makes testing easier. Avoiding mutable state (wherever that's possible with your performance constraints) is the right way to build software, so that's definitely recommended too.
I can see how this works with java but what about clojure, do you have an example?
Hi! The initial version of the Polylith Tool is written in Clojure and is a Polylith itself: github.com/polyfy/polylith , alternatively you can take a look at the Real World example: github.com/polyfy/polylith
The gitbook link is down :x
Thanks for letting us know! It looks like GitBook is back up now, if you want to check it again.
Nice!
"making code duplication a thing of the past" he says
"a level of speed, fun & collaboration I've never come across before" he says
man... all this deep, arcane, thoughtful philosophy to re-invent the wheel yet again:
yes, components are the right abstraction level for building systems
they are composable parts that clearly describe the solution they build up to
and they enable rapid application development
sound familiar? sound like the terminology of 2 decades ago?
why the heck does every single language take so long to go thru the same motions and finally arrive at "components"?
what's next? a never-before-seen, state-of-the-art, exciting new technology called wysiwyg???
...
thanks for the video btw, I'm gonna go cry in a corner for a bit
Thank you for taking the time to make a comment. Could you point me to a language, architecture, or framework, which uses "components" like the ones in Polylith? In other words, do their components separate interface from implementation? Do their components allow the separation of the development environment from your deployment configurations? Do their components allow for seamless code reuse across teams and services? If so, then I'd love to find out more about that approach!
@@Misophistful You forgot to mention about monorepo. And I would like to hear more about "seamless code reuse" across team and services whereas there lets say 50 teams in some common enterprise entity trying to use the one monorepo. As for the "In other words, do their components separate interface from implementation" well that's the part of a component definition. Have you heard about COM? Words like IDispatch/IUnknown bring any memories to you? Or dependncy injection pattern if you like - same thing open interface / closed implementation. As for "development environment from your deployment configurations", well, that primary reason people use monorepos.
@@MaximBazhenov Thank you for your comment, and I understand the instinct to question the innovation of an idea which is seemingly just a new arrangement of existing ideas.
I think someone could use a similar argument to question how innovative the original iPhone was: "There were already phones with a touch screen, a web browser, general computing capabilities, a calendar, a clock - so what was the innovation, the map?" However, sometimes the whole is greater than the sum of its parts. I think the same is true with Polylith.
Monorepos are an existing idea, but Polylith supercharges them by combining them with components and projects, giving us a new architectural-level building block and tool for combining those blocks into deployed services and applications. Components are an existing idea, but Polylith supercharges them by combining them with a functional-inspired interface, making it easy to compose them together and reuse them across projects. Projects are an existing idea, but Polylith supercharges them by letting you construct them out of a set of component building blocks - cleanly separating your development environment from your deployment configuration.
Hopefully you understand my point. Polylith isn't innovative because it created lots of new ideas from scratch, it's innovative because it combined existing ideas in a new way. I'd argue that Polylith is one of those ideas that's greater than the sum of its parts.
@@MaximBazhenov > And I would like to hear more about "seamless code reuse" across team and services whereas there lets say 50 teams in some common enterprise entity trying to use the one monorepo.
The more teams that are working on a single codebase, the more difficult it is to coordinate their activities, and the more likely it is that they will tread on each other's toes. Polylith doesn't solve that fundamental coordination challenge.
However, Polylith does give teams some tools to help make that challenge slightly less daunting. Including: components that help to divide the domain cleanly and understandably, interfaces that give stability when working with each other's code, code pass-through that allows instant refactoring across the entire codebase, and projects that let teams coordinate with their deployed artefacts.
@@Misophistful I don't want to sound arrogant, but at the begining of every project there's a decision to make about how to structure its code base and build pipeline. Every software development shop has its own approaches to the task. Every lead developer has had to apply a known way or improve it or create his/her own. This "innovative" Polylith approach has been "invented" hundred of times, it's just it's so obvious that no other bothered to start hyping it as if it is some breakthrough in software development industry. Thanks for the presentation, but it made me to feel old ;), I've seen the same at least 3 times beforehand during my lifetime, every ~5 years the loop closes and another developer starts to describe this innovative approach again.
p.s. It is possible that I've missed some crucial piece of the idea, I will read more about Polylith, but for now I don't see any innovation here.
Sorry, You lost me and probably every other competent Java developers ( or any other language ) at 1:07 when you presented the absolutely worst way to determine if a String or CharSequence contains no characters other than whitespace. This is very clear of its "intent" by the method name, the implementation is terrible.
Hi Jarrod, thank you for taking the time to make a comment, and I'm sorry to hear that I lost you so early in the video. It's interesting that you find the imperative Java example so terrible, as it's taken directly from the Apache Commons StringUtils class (github.com/apache/commons-lang/blob/c20dcdadd49bb8371dbcee6a955960760a239aca/src/main/java/org/apache/commons/lang3/StringUtils.java#L340)
Let's put aside whether or not the StringUtils code is the worst way to determine if a String is blank, could I ask if you agree with my general assertion that it's better to program with abstractions that encourage us to create succinct and descriptive solutions?
@@Misophistful Funny AF! #burn
@@Misophistful This comment is what made me subscribe. Thanks for the videos +1
@@mksybr Glad you enjoyed the comment, and thank you for subscribing!
@@Misophistful Great video, as this is in clojure, is there a reason stated somewhere why Components use no-op functions as interfaces instead of Protocols?