Solving the "application state" in Clojure, where an application is not a tool or a library, but a product that has lots of state to deal with, is not a trivial task. The Component framework is a solution that has been gaining popularity:
I think all agreed that Component is the industry standard for managing lifecycle of Clojure applications. If you are a Java developer you may think of it as a Spring (DI) replacement – you declare dependencies between “components” which are resolved on “system” startup. So you just say “my component needs a repository/database pool” and component library “injects” it for you.
While this is a common understanding, the Component is far from being Spring, in a good sense:
- its codebase is fairly small
- it aims to solve one thing and one thing only: manage application state via inversion of control
The not so hidden benefit is REPL time reloadability that it brings to the table with component/start and component/stop
mount was created after using Component for several projects.
While Component is an interesting way to manage state, it has its limitations that prevented us from having the ultimate super power of Clojure: fun working with it. Plus several other disadvantages that we wanted to "fix".
One thing that feels a bit "unClojure" about Component is "Objects". Objects everywhere, and Objects for everything. This is how Component "separates explicit dependencies" and "clears the bounaries".
This is also how an Object Oriented language does it, which does not leave a lot of room for functions: with Component most of the functions are methods which is an important distinction.
Mount relies on Clojure namespaces to clear the boundaries. No change from Clojure here: defstate in one namespace
can be easily :required in another.
Component relies on a cool dependency library to build a graph of dependencies, and start/stop them via topological sort based on the dependencies in this graph.
Since Mount relies on Clojure namespaces and :require/:use, the order of states
and their dependencies are revealed by the Clojure Compiler itself. Mount just records that order and replays
it back and forth on stop and start.
Component really only works if you build your entire app around its model: application is fully based on Components where every Component is an Object.
Mount does not require you to "buy anything at all", it is free :) Just create a defstate whenever/whereever
you need it and use it.
This one was a big deal for all the projects we used Component with, "the whole app buy in" converts an "open" application of Namespaces and Functions to a "closed" application of Objects and Methods. "open" and "close" here are rather feelings, but it is way easier and more natural to
- go to a namespace to see this function than to
- go to a namespace, go to a component, go to another component that this function maybe using/referenced at via a component key, to get the full view of the function.
Again this is mostly a personal preference: the code works in both cases.
Since to get the most benefits of Component the approach is "all or nothing", to rewrite an existing application in Component, depending on the application size, is daunting at best.
Mount allows adding defstates incrementally, the same way you would add functions to an application.
Navigation between functions in Component can't really be done without Components themselves. Since in Component
a function usually references another function via a map lookup: (:function component). This is not a big deal, but
it changes the way IDE / editors are used to navigate the code by adding that extra step.
Since Mount relies on Clojure namespaces and :require/:use, the navigation accorss functions / states is exactly
the same with or without Mount: there are no extra click/mental steps.
Component can't really start and stop parts of an application within the same "system". Other sub systems can be created from scratch or by dissoc'ing / merging with existing systems, but it is usually not all that flexible in terms of REPL sessions where lots of time is spent.
Mount can start and stop parts of an application via given states with their namespaces:
dev=> (mount/start #'app.config/app-config #'app.nyse/conn)
11:35:06.753 [nREPL-worker-1] INFO mount - >> starting.. app-config
11:35:06.756 [nREPL-worker-1] INFO mount - >> starting.. conn
:started
dev=>Component does not require a whole lot of "extra" code but:
- a system with dependencies
- components as records
- with optional constructors
- and a Lifecycle/start Lifecycle/stop implementations
- destructuring component maps
Depending on the number of application components the "extra" size may vary.
Mount is pretty much:
(defstate name :start (fn)
:stop (fn))no "ceremony".
This is someting that is very useful for testing and is very easy to do in Component by simply assoc'ing onto a map. In Mount you can redef the state, but it is not as elegant and decoupled as it is in Component.
Since Component fully controls the system where the whole application lives, it is quite simple
to start an application from anywhere including a -main function of the uberjar.
In order to start the whole system in development, Mount just needs (mount/start) or (reset)
it's simple.
However there is no "tools.namespaces"/REPL at a "stand alone jar runtime" and in order for Mount to start / stop
the app, states need to be :require/:used, which is usually done within the same namespace as -main.
Depending on app dependencies, it could only require a few states to be :require/:used, others
will be brought transitively.
Component keeps an actual graph which can be visualized with great libraries like loom. Having this visualization is really helpful, especially during code discusions between multiple developers.
Mount does not have this at the moment. It does have all the data to create such a visualization, perhaps even by building a graph out of the data it has just for this purpose.