Posted on 19 Oct 2014
Over the past month I have had the pleasure of working on the Notice project with two of my peers at Oregon State. Being the sole technical side of the project, I’ve had my pick of the latest and greatest tech to use and ultimately settled on a combination of Rails, Postgres and Ember.js.
While I’m very new to both, it’s been a joy working with them; however it hasn’t been without its struggles. The lack of high quality guides and lax documentation for Ember has been frustrating while the “Rails way” mantra makes straying from the flock, in terms of functionality, difficult. Ultimately I’m happy with the results that these tools have provided for me on such short notice, but there is definite room for improvement.
Besides implementation details, another issue I found was finding a decent way to deploy Rails. After experimenting with Heroku, I had fallen in love with the idea of push to deploy but their ridiculous pricing model made me look for other options. AWS Beanstalk seemed like a decent alternative; however, the difficulty of starting and stopping background workers (a crucial part of the application) also was a deal breaker.
Having seen that AWS Beanstalk deploys with Puma as its rack server, I began looking into using it instead of Unicorn. Seeing that it work best with a multithreaded language, I made a quick attempt of porting the app to jRuby but ended up stopping due to jdbc compatibility issues (Primarily getting rake tasks to use an active-record odbc adapter). I’ve ultimately settled on using a standard Amazon EC2 instance with Ruby MRI and Puma. I know this is not the best setup but it works for the time being. Future plans will take me with either porting the app to jRuby or using Unicorn / Nginx as the web server.
That’s all for now.