HTTP Server: Why Hunchentoot instead of Clack?

When you do not use a framework for web application development, one of the first choices to make is to select an HTTP server.

Many web frameworks are built on Clack/Lack. It provides a unified interface to the major CL web server implementations. If you need the ability to easily switch between different web servers without having to change application code, for example you are worried that your chosen HTTP server becomes unsupported, then using such a unified interface is a sensible idea.

On the downside, to achieve such a unified interface, Clack has to limit itself to the lowest common denominator. All the available web servers have some particular strong feature which is usually the reason why one would pick a specific library. Clack removes this distinction between them and makes them all appear the same. It also forces Clack to then replace many of the features already provided by some libraries with its own implementation, like for example sending large files or handling static files.

Clack does have some features not provided by any web server which may be a good reason to consider its use. One such feature is custom middleware. Middleware are functions that automatically run before or after every request handler without the handler having to make the function calls. Things like cookie handling or CSRF prevention. While it may be possible to extend the web servers with middleware-like functionality it is a core feature of Clack.

If Clack-specific features are not relevant and you are not worried that your chosen HTTP server will vanish into thin air then there is not much reason to use it, especially if you need a specific web server’s distinguishing feature.

I have used Clack before and it did not properly support some Hunchentoot features that I needed. While I like the middleware concept a lot I decided to use the web server directly to avoid running into similar issues again.

I considered some of the more mature webservers and settled on Hunchentoot. My reasons are:

The learning curve is smaller because I have used it before. It is probably the most used and most mature web server project so I expect it to have the least bugs. It is slow compared to other web servers but there are enough other places to optimise for speed to make up for it. If it ever becomes a problem. I don’t need any of the defining features of the other web servers.

When selecting an HTTP server Clack should be considered just as seriously as any of the web servers because it does provide some useful features. However, it should not be taken for granted that Clack is the best choice in all situations. There are times and reasons why a specific web server may be a better choice.