Is Ruby on Rails Not Enough? Incrementally Update Your Technology Stack
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.
Frameworks evolve
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.
While its no secret that Ruby on Rails aids in quick prototyping and fast turnaround times, we’ve grown fond of some the new and traditional platforms like Javascript and NodeJS, JVM and C when the need to build evented, concurrent or faster systems arises. Though we hate to admit it but Ruby on Rails have their limitations, and a lot of companies have grown to accept this and embraced polyglot platforms, which enable them to use different languages and frameworks for their strengths in a single application.
Start Simple?
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. If you are planning to offshore, here is a complete guide on choosing the right offshore partner.