How I ended up choosing Clojure and Google App Engine for developing web applications

Due to my ambitions as an entrepreneur, I’ve recently been searching for some appealing infrastructure for hosting web based services / applications. There are several general requirements for me that need to be fulfilled:

  • I don’t want to be forced into having to mess with infrastructural issues, i.e.
    I don’t want to host any hardware myself,
    I don’t wanna have to keep any software up to date,
    I don’t want to have to mess with OS-level or networking stuff,
    I don’t want to have to scale the infrastructure myself.
    The essence of all this is somewhat obvious: Use some kind of PaaS, as IaaS is too low level and renting/hosting my own server doesn’t meet these needs either.
  • I need to be able to host my apps on infrastructure located in Europe, as the EU and especially the German law are quite restrictive about customer data and data privacy (which I like and support).
  • The hosting should not be too expensive in the beginning. I want to be able to try out things, leave services running without having to worry too much about initial costs, while working on the next service while the first one is running along. Once a service kicks off and earns money, it’ll of course be okay to pay a reasonable amount of money for having it hosted.

Then, for the Clojure part:

  • I love Lisp syntax: I’ve had my tries with meteor.js, and it sure has quite a few benefits and removes a lot of work from a developer’s shoulders, but I’d really love to use a “lispy” programming language. Lisp syntax may still seem awkward to many, if not most software developers, but I love it and I believe very much in the power of functional programming, the handiness of homoiconicity, the Lisp/Clojure macro system and many more advantages of these kinds of programming languages that allow you to build your language up towards your application, instead of only having to break down your application into pieces until you can express them in the programming language that you are using.
  • I’ve been using Clojure quite some years ago and when I recently looked into it again it seemed to me that not only Clojure itself, but the whole ecosystem have evolved a lot since when I’ve been using it back in 2008/2009 or whenever it was. So the whole thing seems to flourish and obviously has gained and maintained a lot of traction.
  • Clojure is a JVM language. For me, this is both an advantage and a disadvantage.
    It’s an advantage because it means you can use it wherever you can use Java, including Google App Engine.
    The disadvantage is… well it’s the Java ecosystem. Big, bloated and ugly. However, as I will be using Clojure, I will usually not have to mess with the common Java stumbling blocks and verboseness too often.
    Most importantly, Clojure features REPL-based development which takes away a very annoying Java disadvantage: Having to start a JVM after making a change in your code. Instead, using Clojure, you change your code and try it out in the REPL immediately – still in the same JVM session that you had before making your changes.
  • Oh, and not to forget of course, as this is also one really important aspect for me: I can use Clojure on the server side as well as on the client side (in form of ClojureScript). So it’s possible to build something like meteor.js where you can write code that runs on server side as well as on client side.
    There are already solutions for this – take a look at . However, I’ve not managed to get this running on App Engine and am not sure if it’s worth to put more effort in trying it, as I think there hasn’t been too much activity in that project recently, although the project itself seems to have reached a quite complete and stable state.
    (I’ll present more details on that in a later post.)

Now for the Google App Engine part:

  • It offers a free quota, which means it’s affordable – especially helpful for when your app does not earn any money yet.
  • It scales automatically and there’s no need to manage any kind of infrastructure (hardware or software) myself.
  • It supports the JVM, which means you can use Clojure.
    Well, it takes some effort to be able to develop interactively in the REPL locally, as we need to hook into the App Engine dev server that Google provides for local development.
    (More on that in an upcoming post as well.)
  • Google Cloud Platform offers quite some features as of today. So, might it be necessary to make use of any of these, I will be able to integrate them into the App Engine app.
  • Building your app on a App Engine comes at a cost: You sacrifice some portability as you build your application against specific Google services (like the Datastore).
    I will of course create an abstraction layer for that in my application, but nice to know is:
    Should it – for whatever reason – become necessary to move away from App Engine one day (or have the application running on, let’s say AWS in parallel, so I am not dependent on only one or another), there is AppScale, an open source App Engine abstraction layer that lets you deploy your App Engine app on various kinds of infrastructures.
  • Another sacrifice for building your app on App Engine is that you can’t use all features of the Java world. You for example can’t use multithreading or read/write files on the filesystem. However, for webapps this should not be an issue. The only thing that might harass you is when you try to use a library that itself makes use of any of the blacklisted Java packages you can’t use on App Engine. We’ll see.

However, all these aspects combined eventually lead me to the conclusion that I’ll use the Clojure & App Engine combo for my work (at least that kind of work that is related to creating web applications). I’ll of course let you know how it goes and already have two more posts in mind (see above). I’ll hopefully follow up soon 😉 .