Russ•Works

The Offical Weblog of Russell Jennings

Ruby on Rails Meets the Definition of a Silver Bullet

Silver Bullet
Something that provides an immediate and extremely effective solution to a given problem or difficulty, especially one that is normally very complex or hard to resolve.

This post is indirectly a response to SPA is not a silver bullet

Delivering applications to users has always been tough, especially if you try to keep them up to date with changes and improvements. Advances in the web allows companies to deliver the latest version of their software directly to users. It’s allowed for the creation of countless E-stores, games, and desktop publishing software. But even still, it is not without it’s complexities. There are ever evolving issues of complexity, maintainability, & security to account for; in addition to feature development and staying nimble.

Before Ruby on Rails, there was coldfusion, custom PHP incarnations, VB.net, java and all other manner of crazy. I remember One of the first codebases I saw; a custom PHP app a fellow student in highschool had created for our AV club. I still remember the hardcoded SQL calls, complete with hardcoded credentials, embedded throughout the pages. Oh, how far we have come!

Sure, these solutions all render out a web page - one of the great levelers of the web - but working on them was often nightmarish. There were no tests, no staging environments, all development was done on the server and backups were a file copy. Naturally, these codebases decayed and became neglected but still used; We’ve all seen the horrendously outdated sites we sometimes need to use when interacting with the government.

As an industry we’ve identified a lot of best practices to help a codebase to be maintainable. Patterns that appear over and over again, or best practices procedurally.

Users have also come to expect native applications for their platforms as well, which can mean feature development takes 3 times as long to complete if you have custom codebases for each platform.

And lastly, productivity and effectiveness matter. Squashing bugs and creating new features needs to keep happening when you’re business is software or runs on it.

Rails is good for all of that

Rails makes developing web applications faster and maintainable. It places emphasis on developer happiness, and using tools & solutions that enable effective feature development. Once you have the environment setup, going from nothing to a web application you can actually start using functionally can be done with a couple of command line incarnations if your needs are CRUD based (most are!). Additional libraries (gems) let you further expand your app behavior, and equally you can roll your own solutions when called for.

It’s also not afraid to break things for the sake of improvement. Backwards compatibility matters for some frameworks, but in the evolving web it’s best to stay with what’s current, secure or performant as browsers and technology evolve. This attitude is also what makes Rails secure: doing the “secure” thing is the default behavior, updates regularly include bugfixes or advisors to be aware of. Rails also request forgery protection, SQL sanitation, File upload and more right out of the box. An important caveat here is that updates often require (or at least encourage) changing your codebase is at each update - but that’s the trade off you make to keep up with best practices.

But perhaps importantly to the point of this post, is that Rails lets a small team ship web and native experiences to all major desktop and mobile platforms, reusing most of the code that’s already been written. By wrapping webviews in native navigation and using caching (also provided by Rails) you can create a seamless user experience - free of weird interface delays or screen flashes; while still doing most of your feature development in the Rails stack and instantly delivering updates to users for all platforms. Rails lets you optimize your app to create fast response times - as fast as 20ms (the fastest i’ve seen in production)

Rails is also quite flexible, featuring a set of very well thought opinions, but always have the option to do things differently. And if you need to start building out an API, or doing realtime websockets, or delivering more javascript-rich experiences, or scale up to support a lot of users; Rails can happily oblige.

Can Rails scale? Shopify handles over 80,000 requests per second riding on Rails

And those well thought out opinions, those sane defaults that Rails ships with? Makes for some highly maintainable codebases. Everything has a place, everyone knows and agrees (generally) where those places are and are not, and breaking the rules is easy unless it’s ill-advised (like strong parameter protections). Even code that you wrote years ago can still make sense - no small feat!

For Ruby on Rails to facilitate teams of all sizes such speedy delivery of tested & responsive applications across all major web/mobile/desktop platforms, makes it the silver bullet framework of development if there ever was one. The productivity, effectiveness and maintainability it enables remains unmatched in other development solutions in software.

Looking for help building out your application in Ruby on Rails? Lets Work Together

Web Analytics