Clojurians Log v2

Each component has an interface that it exposes, which is a namespace that exposes a set of functions. If you create a component 'a' then it will automatically get a an interface with the name 'a' by default. Other components can now only access 'a' via that interface namespace. We can create another component 'a-remote' (or choose another name) that uses the 'a' interface (but lives in 'a-remote') that calls a service that contains 'a'. This allows us to have e.g. two services in production where one of them uses 'a-remote' and the other one uses 'a', while in the development environment, all our components can talk to 'a' using direct function calls, as if we had just a single codebase.

Hi, Thanks for bringing polylith to life 😉 I'm working on a fullstack project, that may hopefully grow a lot. What I wanted to do to organise the system in a modular way is to split major parts of the system in many independently deployable fullstack 'artifacts' (to reduce coupling between the many parts of the system, and favor team autonomy from end-to-end). The idea is to leverage micro-services in the backend and micro-frontends in the front, but to group both backend and frontend by 'Product Oriented Bounded Context'. Let say that my app has 3 features and each feature needs a database, a front and a back. I would split the system in 4 parts : A module for each of the 3 features (each module contains submodules such as front-end server, a backend server, and a database) and a 'container' module that orchestrate every feature (a kind of applicative reverse proxy). It seems that the philosophy behind polylith match with this modular approach but i don't see how I could integrate the frontend part. Have you got any idea ?

Hi @lyderic.dutillieux, great question!

With Polylith you don’t use services to add modularity, as components already give us modularity and encapsulation (and more), with much less complexity. With Polylith, you only need to split out your backend into multiple services/artifacts if you have non-functional requirements (performance or scalability) that aren’t being met with a single backend service. For your “3 feature” example, you’d probably start by building one frontend (using whatever technology you’re comfortable with), and connect it to a single backend Polylith service via its single base, which exposes the end-points your frontend needs via an API (again, whichever API technolgy you choose). The base would delegate the business logic into your components, which would probably map to your domain, features, and infrastructure needs. I’m guessing you’d end up with 4-6 components in a small system like this. Hope that helps!

@lyderic.dutillieux I’m one of the contributors of Polylith and I’ve been working with Polylith in 4 different projects over the last 3 years. If you want, you can reach out to me over a direct message and we can setup a call where I can walk you through one of my projects and how we structured it. I believe it would help you visualize what @james explained above and give you an idea of deciding your own structure with Polylith. We can discuss your requirements further also.

Ok, I see what you mean. By relying on many backends or many front-ends, I may make things more complex than they need to be, especially if there aren't any legitimate non-functional requirements. I should KISS a bit more for now, and postpone the introduction of avoidable complexity for now. Thanks for your help

Sure, I'll dm you then, Thanks !

Exactly! The beauty of Polylith is that it helps teams put off the introduction of complexity (i.e. multiple services) until the last possible moment. And even when that complexity has to be introduced, Polylith’s separation of the development experience from the deployment experience means that you still have a delightful time in working in your development project with all your building blocks, whilst easily being able to deploy subsets of your components and bases into multiple services. Truly the best of both worlds.

I got TOGAF Level 1 certified a few months ago, and can relate Entreprise Architecture with a lot of ressources I read on Polylith. It's really interesting.

as a meta-point, looking at my own and others' questions here, it might make sense to have a little cluster of example diagrams, a kind of cookbook. I don't mean full code examples, though that might be valuable too. I just think it helps contextualize the pattern a lot to see a half-dozen different setups, like Lyderic's "handful of FE + BE + DB verticals" style, or my question about microservices and where the communication layer fits in.

Hi! Good idea, to have some example diagrams of possible designs. I will take that idea back to the team and hopefully come back with something useful. In the meantime I think having a look at the “Transitioning to Polylith” section (https://polylith.gitbook.io/polylith/conclusion/should-you-convert-your-system) could be helpful, to give you an idea of how to think at a higher level. The Polylith codebase is itself written as a Polylith and in the beginning of https://github.com/polyfy/polylith you can see a big picture with all its components, bases, and projects.

Also, there is an example project you can find here: https://github.com/furkan3ayraktar/clojure-polylith-realworld-example-app