Categories: Programming, Java

I’ve recently been doing some maintenance work on an existing Java application (a server providing REST APIs to clients, and talking to a database). Two of the libraries used there (Dropwizard, Hystrix) were new to me, and interesting - worth a brief post at least.

Dropwizard is a framework which is useful when developing Java server applications which provide REST APIs to clients; it provides a standard set of libraries (including an embedded webserver) and a set of helpful APIs for parsing a configuration file, registering callbacks with the embedded webserver, basic statistics gathering and reporting, and related stuff.

There isn’t anything in Dropwizard that could not be done manually, but it is nice not to have to. It’s a fairly small amount of code, and gives a nice “standard pattern” to the resulting application, particularly when you are writing multiple such REST-based servers. It is also reasonably non-intrusive, ie little of the actual application code needs to use dropwizard-specific APIs.

Dropwizard is similar to Spring Boot; I’ve seen some comments that state that Spring Boot is actually better but have no experience with it and am generally happy with Dropwizard.

Hystrix is a library which is useful when writing a server application that provides an API to its clients, where those APIs depend upon services provided by other external applications - ie when writing “middleware”. The problem with such middleware is that when the external dependencies stop responding, or start reporting errors, then cascading effects can cause havoc in the middleware. Threadpools allocated by the middleware for serving a range of APIs can get filled up with requests that depend on a specific not-responding service, thus causing all services in the middleware to become unresponsive rather than just the ones that depend on the failing service. Service implementations which depend on multiple external services where one is not responding can also waste time performing (successfully) initial steps when it is known that a later step in the sequence will fail anyway. Hystrix can be used to track a “status” for external services, in order to immediately fail a middleware service implementation when a required external dependency is failing. The downstream service is periodically retried so that when it returns to functional status then uses of it within the middleware layer also resume (rather than reporting errors immediately).

The core concept of Hystrix is somewhat related to hysteresis which may explain the origin of the project name. When the frequency of errors rises above a threshold, the connection switches into a “disabled” state for a period of time before letting a single request through to see if it can switch back to “available”.

Unfortunately, Hystrix uses the template method anti-pattern - it provides base classes which application code must subclass, implementing abstract methods or overriding default implementations to add application-specific logic. The “template method” pattern was included in the classic Design Patterns book and was widely used for several years in the early 90s - for example in graphical APIs such as Java’s AWT. However this approach works very poorly with dependency-injection, unit-testing, aspect-oriented programming, and several other modern techniques - and in the case of Hystrix, complicates unit-testing significantly. In short - interfaces good, helper classes good, base classes bad. Despite this problem, Hystrix is still useful; hopefully a later version will provide the same functionality with a better API.