After spending several days experimenting with both Dropwizard and Rails, our Engineering team put the two frameworks to a democratic vote. Dropwizard emerged as the winner, mainly due the Java heavy skill set we currently possess.
However Rails does also offer alot of advantages and interesting solutions to traditional problems. I personally really like Active Records and in an ideal Microservices world, both Dropwizard and Rails should be used side by side. They in fact share many design parallels, and Yammer sums up the two frameworks very well in “Dropping Rails for Dropwizard?”. The answer is “No”, use the right tool for the right job.
As a result of the spike, we found several useful shortcuts which I’ve compiled into gists for future reference:
- Serving Static Assets on “/” and API on “/api” - fix documented in the following thread but quite easy to get it wrong.
- Dropwizard JDBI Unit Test and Dropwizard JDBI Integration Test
- Using Governator with Dropwizard Guice - result of a pull request I submitted to Dropwizard-Guice which resolves the painful injection issue with Environment dependent Singletons
I’m also quite glad with the team in reaching a consensus on using gradle, which is something I’ve been also pushing for, ever since my original code interview. With the help of a few diplomatic team members, most of my ideas for the backend API architecture have been realised. It’s now a good time to shift focus towards our new exciting frontend stack consisting of AngularJS and Node.