Going off the Rails
Do you believe in magic? Neither do I. Yet despite having worked on various Rails projects, I had to rely on it. Like a sick patient trusting a very reliable Witch Doctor, I didn’t have to question it’s methods or manners. All I had to do was trust that the right things done in the right order could produce the correct result. Just like that. Magic.
Yet, I had reached the point where the ‘sleight of hand’ of the ruby framework was getting old. It can reach down and pull coins out of my ears until I’m blue in the face, but I’m older and wiser and less naive. I know it’s not magic, it’s very clever, but it’s not magic.
So it was time to dive deep, be less hasty and pull things apart. Poke the system, hope it would unravel and see what I could learn from the entire process. I should warn the reader that if they are hoping for a high level, super complex explanation of the intricacies of Rails they will be sorely disappointed. This is just me making some relatively simple, but nevertheless useful discoveries while walking the path to programming progress.
Here we are then. The two main lessons that I have taken from this particular adventure down the the rabbit hole are as follows;
Rails is just a framework
At its’ core, rails is just a big piece of code that someone has written using ruby.
With rails though, you start to see the tell tale signs of good old ruby wearing the emperors new clothes. Be it the controller class(es) inheriting from the ApplicationController, or finding good old fashioned ruby code in the views, the ruby part of ruby on rails starts to shine through.
The confusing part then, or the ‘magic’ if you will, is the fact that there are invisible threads running from one thing to another tying it all together. Which leads me to my next point;
Everything is Rails is connected
Again, hardly surprising. Yet this was really the core of my lack of understanding. Rails embraces the MVC principal to such an extent it can be a bit of a straight jacket. From the moment you run rails new application in the terminal, a structure is built for you which is very difficult to escape. However, everything is tied together in a construction that once learnt can make it much easier to understand.
In essence rails provides a structure for the chain of events that is the request/response cycle that any server must go through. The config/routes.rb file allows you to set up the ‘routes’ for each object that exists within your web app.
These routes direct the various URI patterns to the correct ‘action’ (method) in the correct controller. In essence your request gets directed to the correct method in the correct controller in your program. In this case visiting the URI /restaurants will mean that your request gets directed to the index method in the restaurants controller. From there it’s all up to the controller.
The controller, having inherited a whole bunch of stuff from ApplicationController can then talk to both the model and the view. By using methods such as .all or .find, the controller can reach out to the model and ask for the relevant data. The model, in turn translates the ruby request into the database language of choice. Upon receiving the response, the model translates the database goodness back into ruby, where upon it passes it back to the controller. The controller can then save data to certain variables that then become available in the corresponding view page. Cue some poorly drawn diagrams;
It’s all very ingenious, logical and dare I say it, simple. It marries together several principles which are at the core of how the internet works today. Which leads me onto my final point;
REST and CRUD are everything
So the routes marry the right http verbs to the correct controller action(methods). The controller actions are themselves a ruby representation of the CRUD principle. Thus one thing flows neatly from one thing to the other. Cue last poorly drawn diagram;
So there we are. Rails. It’s not magic.