Tip:
Highlight text to annotate it
X
So let’s touch on the performance of Rails. So for example, I guess a few years ago, I’m
thinking four or five years ago, Rails had a bit of a reputation for being not well suited
to high traffic transactional sites or applications. That’s changed a fair bit now hasn’t it,
because we know a lot more about scaling horizontally, not just throwing more grunt at a box?
That’s right; I mean scaling is not a problem that’s unique to Rails. Every application
needs to be architected well for it to scale. And there has been improvements to the Rails
stack, particularly around Active Record recently that’s made it much more performant with
its ORM queries that get it but Rails can scale to the point where your contention is
going to be around the database which most applications will suffer the same problem.
But yeah, Amazon has certainly taught us a lot around design for failure and that actually
applies really well when you’re deploying rails applications. Designing for the fact
that at any time you could lose an instance so you need to recover from it, kind of makes
your applications scale anyway just by deploying more nodes.
So is there anything, in your experience, that you wouldn’t use a Rails stack for?
I would probably use Rails for every new project I worked on, if possible. I think particularly
around the web space but you know now we’re seeing Rails as really good service that provides
data to presentation tiers and mobile. So, Rails has many uses, particularly in mobile
and with the likes of frameworks from backbone which make it very versatile for most applications.
And one of the things that I’ve always liked about Rails is how easy it is to come up with
a nice clean REST API service layer. And I think the interesting thing about some of
the recent stuff we’ve been doing with Backbone is it really taps into that. Is that ...
Yes, we’ve had a lot of success with Backbone recently; it’s that nice separation of concerns.
It’s a really good framework for the presentation tier; it allows you to write much nicer than
modular javascript, easier to test, just results in a cleaner, more elegant solution.
So I think what we’ve been finding is that it gives you a lot more productivity with
a Rails back end than say Jquery on the front end. Is that what you’ve found too?
Yeah, particularly for richer web applications with Ajax and it provides a much better user
experience when written in Backbone. Models automatically update. It just results in more
cleaner, maintainable code. So Steve, you’ve come from a Java background
into Rails and I know one of the things that you’ve talked about is the benefits in terms
of code size and understandability of Rails versus the Java world. And one of the things
you’ve found, I think, wasn’t it, that less code means concentrating on the business
problem rather than the glue in the Java world which has benefits when people are reading
code that they’re not used to perhaps? Absolutely, so looking at a Java project,
as I’ve done recently, there is much more code to read, it’s much harder to get to
the heart of the problem when looking at Java code. I found myself just looking at reams
and reams of code that looked like it was - and XML - that was designed for a computer
to read, not necessarily for a human to read. So looking at it, looking at it, comparing
it to Rails which is much more terse, much more descriptive over the domain problem that
we’re providing a solution to. Noticed a big difference there, less code, less code
to test, more readable. So, they’re some of the benefits of working in Ruby and Rails.
I guess there’s that mental shift too isn’t there? So, when you’re looking at Rails
code, say at a model, you’re focusing on what’s the business objective of this model,
whereas when you’re looking at, say a Spring configuration for a Java app, your mind’s
filtering between OK that’s business, that’s glue, that’s business, that’s glue. So
you’re sort of trying to think on two different levels at the same time aren’t you?
That’s right, yeah, there seems to be a lot more noise in models that are around JPA.
There’s more annotations to look at and there’s more boilerplate that Java mandates
so Rails you lose a lot of that so you see really the domain logic a lot clearer. And
that’s nice. I can understand the app much quicker, especially for new people looking
at code. So you’re only thinking on one level, the
solution level, you’ve got less code to write and debug and there’s less code to
test. Yeah.