small medium large xlarge

30 Oct 2013, 03:00
Alexis Gallagher (1 post)


This is a great book! I just bought the beta and read the whole thing, and I think it’s certainly the best all-around discussion for getting up and running with Clojure web development. What’s especially good is the pragmatic focus not just on easy things (like the concepts behind ring) but also stuff that’s more finicky or more tacitly understood (like typical organization of a noir app, typical deployment configurations, and tradeoffs around possible deployment configurations).

While this is where the book excels, it’s also where there’s opportunity to do even better. I think there a number of quite important topics that are neglected. Here’s my top list:

  1. Authentication. There is no discussion of libraries for handling HTTP Basic authentication, which is pretty standard for anyone building an API endpoint.

  2. HTTPS. There is no discussion of deployment configuration for using SSL/TLS, which is also pretty standard for any web app which handles passwords, including API endpoints.

Are they not mentioned because they’re hard to do given the current state of Clojure libraries? If so, that’s worth knowing! Or are they trivial? If so, then there should really be a paragraph or two to illustrate that. It’s certainly something that almost anyone building a real web app will need to know, unless they want passwords flying around in the clear.

  1. No discussions of pros/cons of ahead-of-time compilation, as regards web app deployment. As I understand it, settings in your project file affect whether your app is AOT compiled. This in turn affects responsiveness in some environments, like Google App Engine. At least, this was my experience a while ago. I suspect there are some lurking issues like this, where Clojure’s execution model with its embedded run-time does not play nicely with a hosting environment out of the box, but requires some savvy tweaking.

  2. Cloud deployments in general. Would be nice to see basic HelloWorld-level examples for Google App Engine, Amazone Elastic Beanstalk, etc.. Is Pallet or Jclouds worth a mention in this context?

  3. Debugging in development. What’s the setup for the best interactive development experience developing a web app?

  4. Debugging in production. Lisps are famous for offering you the ability to connect to a live system’s REPL and have a poke around to see what’s going on. It would be great if there were some discussion of (1) whether this is actually a useful/intelligent thing to do, (2) how to actually do it with the current Clojure web frameworks.

  5. Async-oriented development. Frameworks like Pedestal, technologies like WebSockets, comparison with node.js, etc..

The fact is, the existing standard frameworks for standard websites (Rails, Django) are incredibly mature. Clojure is a lovely language but it is likely to be seen as a—shall we say?—adventurous choice for that kind of development, for the foreseeable future.

However, where Clojure is a more plausible choice for web development is for systems that have slightly different requirements: pure API endpoints talking to compute-intensive or Java-only services, newer stuff like WebSockets or single-page apps that are not very well-served by the older, established frameworks. It would be great to get a pragmatic take on whether there areas like these where Clojure is indeed an especially strong choice, where it’s not playing catch-up.

I’m super glad I bought this book. I hope it might expand to cover some of these areas as well! :)


30 Oct 2013, 23:00
Dmitri Sotnikov (145 posts)

Hi Alexis,

First off, let me say I’m really glad that you liked the book overall. Being a first time author, I really didn’t know what kind of feedback to expect. :)

My original intention was to cover enough of the basics so that the readers would be comfortable to discover the missing pieces on their on. The topics you mentioned would certainly be a great addition to the core material. Unfortunately, the book is already going through the copy-edit process and I won’t be able to make any significant content changes from here on.

However, I will likely be doing a second edition next year where I’d like to build on the content in this revision and expand into more interesting topic. I’m very curious to see how the ecosystem evolves by then. That being said, I’d like to give some pointers regarding the points you’ve raised.

Currently, Friend is the most mature solution for dealing with authentication. I also implemented access rules in lib-noir for handling things like redirection and page restrictions.

HTTPS/TLS is generally handled by the container if you’re running on something like Tomcat or Glassfish, or by fronting the applications with an HTTP server like Nginx ( I didn’t go into this since there’s nothing Clojure specific about the topic, but it might be worth noting that it is something that should be done for any production deployments where private information is transferred.

With regards to AOT, the answer is that you should always use it when packaging for production. In fact, when you run the application as an uberjar it must be compiled in order to be runnable. The reason AOT is not used by libraries is due to the fact that it will compile the bytecode for the entire environment including the current version of the Clojure runtime. However, this is not a concern for a standalone application.

Cloud deployments would definitely be a good topic as there are quirks involved with each specific provider. Since my primary experience has been with Heroku, it’s the one I ended up covering. I’d have to do a bit of research on the topic to do it justice for other platforms.

In my experience the role of the debugger is generally handled by the REPL. I tried to give a feel for the REPL based development in the first chapter, where I emphasized the interactivity and trying things out on the fly.

My current setup for this is to use Intellij with the Cursive plugin. I start up the REPL before working with any code and test the functions as I’m writing them. When I work with an unfamiliar code base I use the REPL to discover what the functions do by running them with different inputs. The process is very similar to the one I discuss using Light Table in the book.

At this point there’s no standard way to debug code in production. It’s possible to embed nREPL in your application, but you would pretty much hand roll the whole setup from scratch. I would say that at this time it’s not really advisable and not widely done in the community.

I highly recommend HTTP Kit as the async server and there is a mention of it in the book. The main thing to be mindful about with async development is that you cannot have thread bound variables, such as an in-memory session. Another option to consider is Aleph, I only passing familiarity with it however. I also don’t have much experience using Pedestal, but from what I’ve seen of it I think it deserves a book all to itself. :)

I definitely agree with you that Clojure is currently much better positioned for creating services that are fronted by client-side frameworks like AngularJS. Although, it’s worth pointing out that some companies do use a full Clojure stack for their web applications. One notable mention is Prismatic who use a ClojureScript front-end coupled with the Clojure backend. They open sourced a few libraries and have some interesting discussions about their stack [here] ( and here.

Cheers, Dmitri

08 Nov 2013, 08:26
tutysara (2 posts)

Authentication/Authorization are the must haves tools for any developers doing webapp with users, some writeup on integrating Friend with luminous and how it plays with access rules in lib-noir can be very useful. Also some coverage of jig and how it can be used in the workflow can be included

As the time for including new content had already over, it would he even more helpful if we have them included as part of lunimous doc and later expand on them.

14 Dec 2013, 21:35
Dmitri Sotnikov (145 posts)

I’ll definitely take a look at adding docs on integrating Friend in Luminus.

19 Apr 2014, 18:59
Bruno Kim Medeiros Cesar (4 posts)

Another valuable and easy-to-address topic is XSS. In the guestbook application, the user input is displayed without concern. If you input either in the name or in the message field a script such as


an alert will be displayed. You may highlight how this can be useful to steal private informations from users, and that there’s a very basic protection by using HTML escaping. For example, my home.clj now looks

(ns guestbook.routes.home
  (:require ...
            [hiccup.core :refer [h]]))

(defn show-guests []
   (for [{:keys [message name timestamp]} (db/read-guests)]
      [:blockquote (h message)]
      [:p "~~~~" [:cite (h name)]]
      [:time (format-time timestamp)]])])
19 Apr 2014, 19:40
Dmitri Sotnikov (145 posts)

That’s a great point, I’ll definitely add something regarding XSS in a future revision.

My personal preference is to have the templating library escape by default. For example, Selmer will escape any dynamic content by default and you have to mark content explicitly as safe for it not to be escape. On the other hand, Hiccup will render content as is and you have to remember to use theescape-html utility function yourself.

You must be logged in to comment