| HN Mirror

The idea with that part of the video was to couch the new concept (components) within the framework of existing concepts (functions, objects, layers, etc.) to try to help people connect the new concept at the right place in their knowledge graph. Though your feedback makes me think it didn't work as well as I hoped.

Components do have attributes in common with microservices and with stateless objects (e.g. a public interface and encapsulated implementation).

Where components differ from microservices is that a component's interface is simply a collection of functions, rather than network-facing endpoints. This means that multiple components can be deployed into a single artefact, keeping deployment complexity and cost down.

Where components differ from objects is that a component is a higher-level abstraction, closer in scope to a microservice.

However, we think that Polylith's biggest differentiator is the separation it gives between development and production. Let's say you have a Polylith project with 100 components, that you deploy in production across 10 services. You can work with all 100 components in a single development environment, and test them as though they're a monolith, even though they're not deployed that way in production. It's a lot like building systems with LEGO, and we think its just as fun!

>"Where components differ from microservices is that a component's interface is simply a collection of functions"

Is this a "collection of functions" or "collection of function declarations"? If you want to communicate concepts this is not the best example. And for either case many languages already have the solutions.

Technically, a Polylith interface is a collection of "pass-through" functions, each of which delegate their function call to an "implementation" function within the component.

I agree with you that many languages have syntax to support building interfaces. However, I've yet to come across one that offers all the benefits of Polylith's approach with components.

>"Before you completely give up on understanding the concept, I would like to suggest you try the 10-minute "Polylith in a Nutshell" video"

My lines about the video part was exactly about this particular video.

I was confused because you were replying to a comment which mentioned the "long video", so I assumed you were both talking about the forty-minute one on the homepage of the documentation. My mistake.

Did my response to `cjg` in this thread help to clarify anything for you?

Not really. I suspect that you might have done something that has value in Clojure ecosystem (keep in mind that I do not program in Lisp).

In my ecosystem I simply do not really have problems that you suggest we do and the functionality that you relegate to that "component" idea is not something new and unavailable.

Which ecosystem do you work with? How does it solve the problem of sharing code across service boundaries?

You've answered this question yourself - "Technically, a Polylith interface is a collection of "pass-through" functions, each of which delegate their function call to an "implementation" function within the component."

I work mainly in C++, Delphi/Lazarus, JavaScript. Many others as well but not very often. C++ and Delphi handle the domain just fine. Javascript - bit less convenient still easy.

I'm not sure we're understanding each other. When I asked "How does it solve the problem of sharing code across service boundaries?", I meant how does your language or architecture enable you to share code across separately deployed artefacts, for example across two microservices.

There are three approaches that I'm aware of for solving this problem: 1) copy/paste the shared code between the two repositories, 2) freeze the code into a library that both services depend on, 3) keep both services in one repository, extract the shared code into a module or component, both services depend on the shared module, deploy the services as separate artefacts.

1) is bad for obvious reasons, 2) adds unnecessary friction to the development process, and 3) is how Polylith solves it.

I was wondering if you've come across another way to achieve 3), or perhaps a fourth approach?