FAQ

Question: Are there any plans to add support for cljs/cljc projects, components and bases?

Answer: There are several reasons why we don’t support Polylith for the frontend at the moment. One of them is that frontend development has other needs than backend development. For example, we often get instant feedback already when we work with the code in a frontend project. The tooling support to solve that is already there to give us fast feedback. The languages are also more dynamic, and can work with “living code” directly instead of using “frozen” libraries. It’s also common to put all frontend code into a single repository, because the UI is often built as a SPA, which solves much of the sharing problem. Another aspect of it is that frontend code is quite messy and entangled, which is a hard problem to solve. Different UI frameworks and libraries have their own solutions to reuse parts of the code by supporting UI components. It’s possible that Polylith could be a good fit for the frontend too, but we need to try it out more to see if it adds enough value.

​

Question: Why not only use components and skip the bases?

Answer: They have different responsibilities. If you start to mix the two, you also lose something. A component has an interface, and is composable. A base has no interface but instead it exposes a public API. The base is the “base” of your projects/artefacts while the components implements the functionality. This makes it easier to reason about our software.

​

Question: How is Polylith different than Spring Framework or any other Java framework?

Answer: The two are so different so it’s almost hard to know where to start, but here are the main differences:

1. Spring is based on an object oriented language that encourages the use of mutable state. Polylith uses stateless functions and encourages the use of immutable state.

2. Spring uses dependency injection in combination with annotations or a configuration file to “glue” the “building blocks” (objects) together at runtime. Polylith doesn’t use any magic at all, and the way it “glues” the “building blocks” (components and bases) is to specify the source directories for all components and bases in a single file at compile time.

3. Spring is a framework with a lot of ready-to-use functionality. Polylith is much simpler and doesn’t provide any ready-to-use functionality, but instead it helps us structure the code in a way that we can postpone decisions on how to run our code in production, while maximizing the productivity in our development environment by letting us work with all the code as if it was a single codebase.

​

Question: Polylith feels a bit like how node modules work in combination with module bundlers like webpack.

Answer: Although it might sound similar to a library (or dependency) solution, such as node modules, Polylith is way more than that. First of all, in contrast to libraries, you are the owner of the Polylith components, they live in the same place as the rest of your (living) code, and they are not frozen as libraries are. They ensure encapsulation and composability but at the same time they are simple, easy to reason about, and flexible. Together with the other concepts introduced with Polylith, it is an opinionated way of architecting software, rather than a dependency system or bundler.

​

Question: What's your experience of working with Polylith in practice? I would like to hear/read more opinions on Polylith, like from people that have used it in production.

Answer: I (Furkan) am one of the contributors to the Polylith project and I would like to elaborate a little on this. So far, I’ve been involved in four medium-large scale projects that have used Polylith. I’ve recently co-founded a new startup called Scrintal and we’ve written its backend using Polylith. I know that there is a little bit of a learning curve to get used to the Polylith way of thinking. You can think of it like coming to functional programming from OO. However, once you pass that learning phase, you just start focusing on your development, your components specifically, rather than thinking about deployment strategies or architectures. I believe staying productive but at the same time following the current “best practices'' of the software industry is really hard today. It’s mostly because we need to think about how to deploy what we create, before we create it, rather than focusing on being productive. At Scrintal, we are using Clojure and Datomic, which may be considered against the so called best practice, but it boosts our productivity quite a lot. Having a single REPL where we can try out ideas is great, especially for a startup. You have to move fast and pivot easily. However, you shouldn’t be in a position where you write crap code and once the business takes off, you need to re-think the whole architecture and re-write most of the code. Polylith comes to the rescue. From day one, by creating small building blocks, you can start testing out ideas in your REPL. You can grow your building blocks and add new ones, and grow your codebase that way, but at the same time Polylith will make sure to keep it simple and untangled. Having small and isolated building blocks ensures that you don’t create a mess in the end. Later on, you can combine all those building blocks in any combination and choose any deployment strategy your product needs. For example, we just had a couple of components in the beginning to test the idea. Later on we added a simple REST api to deploy it as a single service. After a while, we hit some performance issues, and took a couple of components out of the main service to create another service. Still all the code lived in one single repository and was shared across all services. Polylith allows us to postpone decisions on how to execute our code in production. Instead of making those decisions early when we know the least, we can make them when we hit a problem in production, a non-functional requirement that needs to be fulfilled. Finally, to give a little more context, our backend at Scrintal has around 50 components which are deployed as 4 different services. The very first commit was in December 2019 and we released the first version in July.

​

Question: Isn't this the Emperor's new clothes in fresh summer styles? I can't see anything new here except that you propose using "libraries"!

Answer: Using libraries was actually how it all began. That was a real pain, because it slowed us down significantly. Instead of being able to change the code and getting instant feedback from the REPL, we now had to switch between projects, build a snapshot library and restart the REPL. When you do that hundred times per day, it really starts to slow you down. With components, you can work with all your code from one place, without restarting the REPL. If you zoom in to the different solutions, you will not find anything new here, but when you start working with Polylith, you realize that the separation between development and production actually is a new idea, that components and bases are valuable new concepts and that being able to combine blocks of code in a Lego-like way is very powerful, simple, and makes you more productive in the end. I try to explain all of this in this video: https://youtu.be/We5qocYJAtM​

​

Question: What's the point of an interface if you can't (or can you? how?) swap out the implementation? (see: OCaml's modules)

Answer: Each component contains its own interface file/namespace. If two components are using the same interface, the contract of the interface is the combined set of def/defn/defmacro definitions for both components. If any of them don’t implement the full set, then the tool will complain when running the check, info or test command.

We have an example in the Profile section of the tool documentation, where both the user and user-remote components implement the user interface. The components live in two separate directories, under the components directory, and both use the se.example.user namespace but with different implementations in their core namespace:

▾ workspace
  ▾ components
    ▾ user
        interface.clj
        core.clj
    ▾ user-remote
        interface.clj
        core.clj

The example starts with a command-line project that contains the user component, but then we “swap” (at compile time) to the user-remote component, by specifying the source directory of user-remote instead of user in ‘projects/command-line/deps.edn’. This is described in detail in the Profile section of the tool documentation.

​

Question: If I have two bases (say http-api and mq-api), can I easily configure the build to produce a single artifact, that includes both bases?

Answer: Yes, you specify the source directories for both bases in your deps.edn configuration file for the project, e.g.: {:paths [“../../bases/http-api/src” “../../bases/mq-api/src”] ... }. You can put any combination of components and bases in a project and build a single artifact out of it. We don’t support switching components at run-time. If you need polymorphism, then you can solve it by using multi-methods to switch between two different components. In this case they need to live in two different namespaces and be included in the project they live in.

​

Question: Aren't "pass-through" functions used in the interfaces kinda stupid, when you instead can use import-vars (https://github.com/aleph-io/potemkin#import-vars) to "import" them?

Answer: The 'import-vars' macro is kind of cool, but we have decided to keep it as it is. The main reason is that consistency and simplicity has a great value to us. Using a macro could have been an alternative if it solved the whole problem, but unfortunately, we will end up with a mix of this macro and explicitly declared functions, which is less consistent and adds complexity. By making the def/defn/defmacro statements explicit in the interface namespace(s) we also get a lot of flexibility, see the end if the interface section of the tool documentation.