Translating an enterprise Spring webapp to Clojure

In Spring you just annotate your constructors with @Autowired and it will magically inject all the services and repositories you need. While IoC is fine, I prefer to avoid magic and put my system together manually when feasible. I also think there is far less need for this in Clojure.

We need to step back and ask, why do we need IoC? Some possible answers:

There are perhaps other good reasons but I cannot think of any now.

So it appears to me that we use IoC to control configuration (real or fake service?) and state, especially for expensive-to-create objects. Both only make sense in relation to external effects of the system, i.e. when calling an external service or database. It doesn’t seem so useful for business logic, which doesn’t really change with the environment and does not depend on expensive stateful objects. It would also appear that the main reason for using IoC over singletons is testability. IoC also makes it possible to replace dependencies with mocks and thus test a (business logic) class in isolation. (Though many consider mocking to be an anti-pattern, see e.g. Testing Without Mocks, Kent Beck’s functional composition of the processing (#3), Mocking is a Code Smell.)

Martin Fowler justifies IoC with “so we can use different implementations in different deployments.” Another article claims an important benefit of IoC to be “Objects can be added and tested independently of other objects, because they don’t depend on anything other than what you pass them.” Also the discussion in Singleton: Anti-Pattern Or Not might be of interest.

Let’s change perspective and ask where - whether? - can this be useful in Clojure. There we have mostly pure functions calling other functions. Impure functions either expect to get the relevant state explicitly as a parameter - for example all java.jdbc functions take a db parameter - or depend on a global or thread-local state (an atom, a dynamic var). What solutions do we have?

So what would I do? I would mix and match #1 and #2 as fit, with a preference for the latter. So I might just set up a data source inside my db namespace, use it implicitly in all DB calls, and perhaps expose a set-db! function to make it possible to change it from my tests so that I can use a per test DB.

How do we address the concerns of IoC? To enable different implementations in different environments (test vs prod) we can simply use configuration - for example in our internal send-email function we can check (pseudocode) if (email service is configured) then (service/send ...) otherwise do nothing. This approach worked just fine in our JavaScript app. To enable testing when using namespace-local state such as a db instance, we can expose functions to change it for the sake of the test, as shown above.

AOP makes it possible to execute code around / instead of any method, using a pattern to find the methods to wrap. It is very powerful but it is black magic that makes your code hard to understand. You literally cannot see what is happening when reading the target code unless you also know to look at the AOP code. I prefer code that is obvious, even if it requires little more typing. Sometimes the benefits are worth it - but rarely. Also, as this StackOverflow discussion explains, Clojure doesn’t really need AOP.

In our Java app we use AOP f.ex. to set up “execution context” for our batch jobs. These are started automagically by Spring based on their @Scheduled annotation so we don’t really have any other good way to control their execution and do the set up. In Clojure I would forego auto-discovery and other magic and simply had a list of the batch job functions and schedule and run them manually. That would also give me control over their execution and enable me to set up whatever I want.

When AOP is really the best answer, you can use Clojure’s alter-var-root. Look at how clojure/tools.trace’ trace-ns does it. We use it often in development to automatically check that function arguments conform to their specs or during troubleshooting to automatically capture and print the arguments and return values of the relevant functions. To summarize:

We can use the same solution as Java, likely using Clojure’s facade tools.logging with an appropriate backend (Logback/…). Personally I really like Frankie Sardo’s approach from Logging: change your mind – The ultimate guide on modern logging where he explicitly passes a log “instance” to functions that need it (there aren’t that many, you typically only need it in the “Imperative Shell” layer) including whatever the current logging context is (instead of a global MDC.put(key, val)).

In our Java app we can annotate a controller method with its authorization requirements:

and there is a Spring HandlerInterceptor that checks for this annotation on the target method before allowing request processing to proceed.

There are multiple ways to implement it. We could use Ring middleware (similar to Servlet filters) to do similar magic to the Spring interceptors. However I prefer more explicit solutions as they are far easier to understand. Since a request handler in Ring is just a function of request map -> response map we could easily wrap it with another function that checks the authorization before invoking it:

So before we call get-devices, check-auth uses the auth requirements we pass it and user information in the request (prepared likely by a middleware) to decide whether to proceed or not. (BTW the #(..) produces an anonymous function of - in this case - 0 arguments that check-auth would explicitly invoke after it approves the request.)

What do you want to collect metrics for? For example:

To monitor a particular function, in Spring Boot we can just annotate it with @Timed(some settings...). Similarly to how we handled authorization, we can replace the annotation with a function call:

It is not more typing than with the annotation and you can much more easily see what is going on.

(monitor could be a macro to get control over the evaluation of its body or we could pass it the original code wrapped in a lambda. It could directly change some global state - the metrics registry - or just add monitoring information to the current “context” if we are passing that around.)

Replace

with

no big deal, huh?

Our Java app uses a ThreadLocal to store “unique request ID” so that we can trace a request across multiple systems. We could do the same in Clojure or pass it explicitly in our “context” argument. Thanks to Functional Core, Imperative Shell we need it only in the thin outer imperative layer so passing it around explicitly isn’t all that much work (and doesn’t break when you involve asynchronous code).

We have batch jobs like

that Spring runs automatically for us.

You wan’t to have e.g. a data source with a connection pool and use it in all DB calls or have a thread pool that you use for a particular subset of external service calls. The solution under “Inversion of Control” above applies.