For some reason the ven diagam of beer world and the programming community overlap significantly. Rob and I are programmers and beer lovers and we wanted to share some information about the new CellarHQ tech stack for other nerds.
One of the reasons we felt confident in taking over CellarHQ is that it was built on a familiar technology that we use daily at work. Our main objectives as we move forward are:
- Be fun and easy to work with. This is a side project for Rob and I, and one that (at best) breaks even. We want to be able to work with new, interesting languages and frameworks that we might not be able to use at work.
- Be fast. Performance is a feature and we want CellarHQ to run as fast as possible.
- Be low overhead. As mentioned this site breaks even at best and we want to reduce the monthly costs as much as possible.
We’re going to be getting all of this done on a different technology stack than what CellarHQ running right now, which is currently Tomcat, Grails and SimpleDB.
We’re replacing Tomcat and Grails with Ratpack, backed by Netty. The appeal here is that it’s much more performant than Grails and uses resources much more efficiently, so we’ll be able run the site on cheaper hardware. Furthermore, Ratpack is extremely fast and fun to develop with.
Replacing SimpleDB is PostgreSQL for the database layer. SimpleDB, despite being extremely cheap and simple to use, is profoundly neglected by Amazon and further didn’t offer a way to run locally, which meant we would be paying for our automated functional tests. PostgreSQL, on the other hand, is a fantastically powerful and stable relational database that we’re comfortable with. To interface with PostgreSQL, we’ll be using the Netty-backed ng-pgsql driver and Netflix’s RxJava, which is a natural fit for using PostgreSQL with Ratpack.
Data migrations and background jobs, depending on the task, will be done with either Groovy or Go. For jobs that require interaction with another website, such as Untappd, we’ll be writing Retrofit clients and open-sourcing them to the public.
We’re going to continue using Elastic Beanstalk for deployments for the time being. In order to do so, we’ve built Docker containers to deploy with. In the future, we’ll be choosing a provisioning tool and deploy onto CoreOS.