As a ruby on rails consulting company most of our technology stack for new projects starts with that platform. In most cases, our base stack, consisting of Ruby, Rails, Mysql and Jquery works well to fulfill most of our client requirements. To satisfy evolving requirements over time, we’ve consistently added different components built with other languages and frameworks to accomplish tasks where Ruby on Rails alone wasn’t enough.
We have built APIs using the evented NodeJS framework, switched to the high speed Redis data stores to perform complex in memory calculations and speed up critical tasks. We did this purely because Redis made it easier to perform complex data computations without having to frequently query the database. We built our APIs with NodeJS because it was easier to work with than the Ruby’s Eventmachine library for new programmers.
Why we choose Ruby and Rails
In most scenarios the considerations for the starting stack is familiarity with the language, the frameworks and the ecosystem. The reason we choose Ruby and Rails for most tasks is because Ruby is a concise language that enabled us to do more and Rails helps us prototype and get features out of the door faster. The excellent Ruby community is another important factor and an important consideration in choosing the base stack for any project. Here is short discussion by Adam D’Angelo, founder of Quora on how they chose their starting stack.
Don’t Drink the Kool Aid
While we’d advocate the use of Ruby on Rails as the primary/starting stack for most projects, and strongly believe that it should be more than adequate to handle the requirements of these projects, we don’t particularly love the way its sold.
Being Agile and TDD friendly
We don’t believe that software engineering is an art, and we recommend you don’t buy into it either. It’s a practice – and almost a science. So saying that “Rails is Agile” and “Spring or Play does not aid in quick prototyping” make us cringe. Being able to be Agile or practice TDD depends largely on having a team of competent and well-rounded developers who understand the need to adhere to well-defined processes and ignore them when needed. The tools being used do affect this but only in a very small way. Test-driven development was in practice long before Ruby or Rails became mainstream. Your team is capable of NOT being Agile even while using Ruby on Rails and equally capable of not following TDD while using Rails.
So a capable and experienced Java team could turn out to be more productive than a team of average Ruby programmers.
Can you build a team?
Great products have great teams behind them. One of the biggest problems in building good resilient software has been the ability to find a team of good developers who can guide you to a successful launch. Though Ruby has made inroads into the enterprise world, it’s still largely a niche skill, and finding great developers hasn’t been easy. So establishing a team of good developers should be a greater concern than finding a team of programmers who can implement Ruby on Rails. If you have an excellent team of Java programmers, start with Java and Play.
If you are looking to partner up with an offshore team, here are some tips to help you choose the right partner.
While Ruby on Rails will still be our first choice, we acknowledge that the JVM based language frameworks and Erlang frameworks have significantly evolved too. Play and Lift have grown increasingly popular along with their new JVM languages like Scala and Clojure. Companies like LivingSocial and Stripe actively choose Scala, Clojure and Java to do accomplish tasks they feel are better done on the JVM. Watch Xavier Shay talking about JRuby at Square and the use of JVM based languages. Erlang and its OTP frameworks have grown increasingly popular because they work well in building real time systems, which need high availability.
Knowing the benefits of each framework, we have grown accustomed to starting small and shipping quickly. It has helped us validate our business, technology and features quicker. It has worked well for us to iterate and improvise on popular features, and delete stuff that gets in the way. A small stack with a small code base works really well, so we prefer to partition our systems into well-defined logical components that speak to each other, rather than deal with one giant system.
Smaller logical components allow us to isolate problems and are easy to decouple. They give us the freedom to use different technologies that work well for the given problem. And our entire systems then comes together as components that talk to each other.
How do I know if Rails is not right for my project? How do I build a polyglot platform for my application?
That is where we can help! Give us a call or drop us an email, and we’ll help you evaluate your technology needs.