Wednesday, September 2, 2015

Going Off The Track On Rails

Hey, Doc, we better back up. We don't understand enough about Rails to get this project running.

...But we do need Rails. Because Rails is magic!

Well, OK, not exactly magic, but on first look Rails appears to be a very *magic code wand* style of framework for Ruby.

Rails (or Ruby on Rails) is a model–view–controller (MVC) framework, which provides default structures for database, web service, and web pages. It encourages and facilitates the use of web standards such as JSON or XML for data transfer, and HTML, CSS and JavaScript for display and user interfacing. All often from the input of one line of code. Magic!

Because of it's design, and its emphasis on the use of software engineering patterns and paradigms, Rails encourages you to build RESTful (Representational State Transfer, a software architecture style for building scalable web services) applications. So if you make use of the facilities inside of Rails, like Scaffolding which can automatically construct some of the models and views needed for a basic website, all the code generated in Rails is building a RESTful application. Rails has even been described as "REST out of the box".

We could look at Rails as being a little bit like the default factory settings offered to you when you install software. Of course you always have the option of picking and choosing which files you want, and manually configuring your install - but really, who has the time for that? So when it comes to setting up your new application Rails will do the job for you thanks to it's use of Convention over Configuration, this also means that generally Ruby on Rails conventions lead to less code and less repetition.

And that's gotta be good, right?

OK, so Rails has now set everything up for you nicely, let's take a look 'inside the box' and discover how Rails processes an incoming request.

We'll break it down into stages:
  1. The client requests the page.
  2. The request is parsed (divided into parts and analysed) by the router to identify a particular method (action) somewhere in the controller code.
    • The router takes the first part as a controller name.
    • The router takes the second part as a method name (action).
  3. The action might look at data in the request itself or interact with the model or may invoke another action. Eventually, the action prepares information for the view.
  4. The rendered view is sent to the client.
And voila, we have our request processed thanks to the *magic* of Rails.