What's new in Rails 4?

Security

Speed

Strong Parameters

Turbolinks

Russian Dolls Caching and Cache Digests

ActionController::Live

Upgrade from rails 3.2 to rails 4

Security

One major feature of rails 4 is security. Rails 4 applications are more secure than rails 3.x.x. There were some security issues in rails 3, to fix them different versions are available for these issues. Security is implemented by default to make rails 4 applications more secure than it was before.

Speed

Another feature of rails 4 is speed. Rails 4 required ruby 2.0, 1.9.3+. The reason behind that the ruby 2.0 is few times faster than ruby 1.9.3 or later. Rails 4 encourage to use ruby 2.0 to enhance the performance of applications.

Strong Parameters

Rails 4 tackles the mass assignment problem with the new Strong Parameters gem. A Rails 3 application might have a create action similar to the following example

Strong Parameters

class UsersController < ApplicationController

def create

@user = User.create(params[:user])

# ... check validity, redirect, etc.

end

end

Strong Parameters

You can protect against unexpected input with declarations in the model:

class User < ActiveRecord::Base

# Only allow the following attributes to be

# mass-assigned

attr_accessible :name, :email

end

Strong Parameters

class UsersController < ApplicationController

def create

@user = User.create(user_params)

# ... check validity, redirect, etc.

end

private

def user_params

params.require(:user).permit(:name, :email)

end

end

Strong Parameters

As you can see, the params hash in your controller is not a normal hash. Its actually an instance of ActionController::Parameters, which exposes the require and permit methods.

The require method ensures that the specified key is available in the params hash, and raises an ActionController::ParameterMissing exception if the key doesnt exist.

Turbolinks

A new feature in Rails 4 is Turbolinks, a GEM designed to make app navigation faster in the browser.

In browsers with pushState support, clicking a link causes the Turbolinks plug-in to kick in. It makes an Ajax request, updates the URL with pushState (so your back button works) and uses JavaScript to update the and in the DOM. The speed gains come from not having to download and re parse JavaScript and CSS assets.

Turbolinks

Turbolinks gracefully degrade for browsers which do not support pushState. In these situations, the pages links behave as normal, causing a full page refresh.Being included by default in Rails 4 is Turbolinks, a JavaScript plugin very similar to PJAX. PJAX (pushState+ AJAX) is a jQuery plugin created by Chris Wanstrath, which allows you to update a specific section of a page with an AJAX request without having to do a full HTTP request. By using pushState, PJAX updates the browser's current URL without reloading any page resources such as JavaScript or Stylesheets..

Turbolinks

Turbolinks also uses pushState and does the exact same thing as PJAX, except that it does not require a custom partial response from the server. Turbolinks will perform an HTTP Request just as the browser would, but then replaces the and currently loaded in the DOM with the response from the server. It is a more automatic solution, that removes the need to manage which sections of your page will be replaced.

Turbolinks

If a Turbolinks enabled web application is accessed from a browser that doesn't support pushState, the web application will degrade gracefully and do a complete HTTP request. Browsers that support pushState and all related APIs are:

Safari 6.0+IE10Chrome 5.0+Firefox 4.0+

Caching

Rails 4 brings an overhauled caching strategy. First, action and page caching, as you may know it from previous versions of Rails, have been removed and extracted to gems: action and page, respectively.

Russian Dolls

The technique of nesting fragment caches to maximize cache hits is known as Russian doll caching. By nesting fragment caches, it ensures that caches can be reused even when content changes. When a change occurs to the top-most fragment cache, only that cache must be expired. Every nested cache of the parent can be reused, which provides a significant performance increase. A change to the most nested fragment cache would start a chain reaction to expire all parent caches.

Russian Dolls

class Team < ActiveRecord::Base

has_many :members

end

class Member < ActiveRecord::Base

belongs_to :team, :touch => true

end

Russian Dolls

Russian Dolls

And in app/views/members/_member.html.erb:

Russian Dolls

if we had a team with two members, a total of of 3 fragment caches would be written:

views/members/1-20121220141922views/members/2-20121220141922views/teams/2-20121220141922

Russian Dolls

The above technique will work seamlessly until you have to modify the template of one of the fragments. Since the template is not taken into account in the fragment cache key, any changes to the template will not expire the cache. This quickly progresses in prefixing the fragment cache keys with a version, so that an expiration will be forced. A change in a nested fragment version, will result in all parent versions needing a version bump also.

Russian Dolls

Team:

Russian Dolls

The above version prefixing results in the following fragment caches:

views/v1/members/1-20121220141922views/v1/members/2-20121220141922views/v1/teams/2-20121220141922

Cache Digests

If someone forgets to change the version number of a template, and all its dependents, then the entire Russian doll caching technique breaks down quickly. This happens easily, as there is no visual reference of template dependencies.

For example, looking at the app/views/teams/show.html.erb template, there is no indication that each member has its own fragment cache.

Cache Digests

Rails 4 solves this problem with cache digests. A call to #cache in your views will now suffix a digest of the template and its dependencies. No longer will you need to worry about fragment cache dependencies and versioning!

Cache Digests

Team:

Cache Digests

This results in the following fragment caches, now suffixed with an MD5 of the template itself:

views/members/1-20121220141922/74865fcb3e2752a0928fa4f89b3e4426views/members/2-20121220141922/74865fcb3e2752a0928fa4f89b3e4426views/teams/2-20121220141922/4277f85c137009873c093088ef609e60

ActionController::Live

The new ActionController::Live module provides the ability to stream data to clients. Simply include the module into a controller to enable your app to send arbitrary streamed data. Youll have to use a threaded server, like thin and puma, in order to stream data; actions from streaming controllers run in a separate thread.

ActionController::Live

class MyController < ActionController::Base

include ActionController::Live

def stream

response.headers['Content-Type'] = 'text/event-stream'

100.times {

response.stream.write "hello world\n"

sleep 1

}

response.stream.close

#must close the stream

end

end

ActionController::Live

You must write any headers before you call write or close on the response stream.

You have to call close on the response stream when youre finished writing data.

Ensure that your actions are thread-safe, as they will run in a separate thread.

References

http://www.codeschool.com/courses/rails-4-zombie-outlaws

http://rails4.codeschool.com/videos

https://github.com/rails/strong_parameters

http://net.tutsplus.com/tutorials/ruby/digging-into-rails-4/

https://github.com/rails/cache_digests

https://github.com/rShetty/ActionController--Live

http://blog.remarkablelabs.com/2012/11/rails-4-countdown-to-2013

http://weblog.rubyonrails.org/2012/3/21/strong-parameters/

Click to edit the title text format

Click to edit the outline text formatSecond Outline LevelThird Outline LevelFourth Outline LevelFifth Outline LevelSixth Outline LevelSeventh Outline Level