Month: May 2016

Ember rails developer

Background

Since April this year, I essentially transitioned from an application developer to a web developer. Full stack.  It’s quite exciting! There are some who perceive web development as an inferior choice of work, but I have to disagree. In an era where mom and pop shops have websites, not having a webpage front for your business essentially means you don’t exist. Because having a webpage allows you to reach a greater audience. So, I see it as a very powerful leverage.

I have a little background developing for Ruby on Rails, from my Dotabuff scraper project. Now that I look at it, my understanding of rails is fairly incomplete. Rails, and Ember alike, are scaffolding heavy. The intuition is that as the creators of the web framework, they are more knowledgable about how you should go about designing the architecture than you are. Consequently, it means transitioning from one Ember/Rails project to another means very little time is required.

What is Rails/Ember

Rails is a complete web framework. It handles the entire web pipeline. From

  1. routing a URI,
  2. to finding the controller for the page,
  3. who translates the URI to some requests on the data model and accessing the database,
  4. to finally rendering the web page template.

Rails 5 (which should come out of beta this year) has an API-only mode. That means it doesn’t template web pages (no step #4). Rather, it replies with the data directly in JSON format.

Ember is like Rails, but it’s designed to handle the frontend, leaving the backend architecture up to the user. It means the focus of this framework is on rendering web page template. Any dynamic data that needs to be displayed gets translated to an API call to go fetch the data. Then it converts the response into an ember-data model, and finally fills in the template to display it.

Why make it more complicated by using yet another framework just for the frontend?

So at this point, you’re probably wondering why the additional complexity? Why not just use Rails since it supports the entire process?

Well, you see, it’s about speed and responsiveness. Every time you visit a different web page on Rails, an entire html file is rendered for you by the Rails server and sent to you. 

Think about that. What does it mean? It means it’s slow. Unresponsive.

Rendering pages cost time. Sending the rendered page across the network also cost time. The larger the rendered file size, the longer it takes. And this is not cheap, you notice the web page flashing when you visit different pages.

So that begs the question of how do we avoid sending out rendered pages from the server? Rendering could be done on the client, rather by the server. This is where frontend frameworks come in. Rather than requesting entire web pages all the time, just request the data the page needs as an API call, and render it on the client. In between visiting different pages, data that was available before is put into client’s local storage, for faster access via the cache.

Frontend frameworks

Ember is one of three popular frameworks. It’s also the most complete framework, as in the most to learn. In terms of scaffolding and complexity, they rank like this:

  1. Ember. The framework for ambitious projects.
  2. Angular. Somewhere in-between.
  3. React. So lightweight, it can hardly be considered a framework.

Any of these would be fine. Indeed, as with any beginner, I did some digging. And discovered that the bigger I dig, the more mess I got myself into. As a rule of thumb, I certainly knew I had no clue what I’m doing with a frontend framework. So if I’m to learn a frontend framework, I might as well learn from what are the best practices, the most scaffolding frameworks. For the same reasons why I prefer Rails as well.

My project

Currently I am building an internal project for Apple, and I (obviously) can’t disclose what it is. But it uses Ember and Rails 5 API-only mode.

I setup both Ember and Rails to use web-sockets, but not really hooking them up at the moment, because I’m working on getting out a functional demo website. When the time comes, this website will not only be responsive, but updates in real-time.

See you at my next blog post folks!