Introduction to rails 4 v1


Published on

Published in: Technology, Education
  • Be the first to comment

Introduction to rails 4 v1

  1. 1. 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
  2. 2. 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.
  3. 3. 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.
  4. 4. 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
  5. 5. Strong Parameters 1. class UsersController < ApplicationController 2. def create 3. @user = User.create(params[:user]) 4. # ... check validity, redirect, etc. 5. end 6. end
  6. 6. Strong Parameters ● You can protect against unexpected input with declarations in the model: 1. class User < ActiveRecord::Base 2. # Only allow the following attributes to be 3. # mass-assigned 4. attr_accessible :name, :email 5. end
  7. 7. Strong Parameters 1. class UsersController < ApplicationController 2. def create 3. @user = User.create(user_params) 4. # ... check validity, redirect, etc. 5. end 6. private 7. def user_params 8. 9. params.require(:user).permit(:name, :email) end 10.end
  8. 8. Strong Parameters ● ● As you can see, the params hash in your controller is not a normal hash. It’s 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 doesn’t exist.
  9. 9. 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 <title> and <body> in the DOM. The speed gains come from not having to download and re parse JavaScript and CSS assets.
  10. 10. Turbolinks Turbolinks gracefully degrade for browsers which do not support pushState. In these situations, the page’s 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..
  11. 11. 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 <title> and<body> 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.
  12. 12. 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+ IE10 Chrome 5.0+ Firefox 4.0+
  13. 13. 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.
  14. 14. 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.
  15. 15. Russian Dolls 1. class Team < ActiveRecord::Base 2. has_many :members 3. end 4. 5. class Member < ActiveRecord::Base 6. belongs_to :team, :touch => true 7. end
  16. 16. Russian Dolls 1. <% cache @team do %> 2. <h1><%= %></h1> 3. <ul class="members"> 4. <%= render @team.members %> 5. </ul> 6. <% end %>
  17. 17. Russian Dolls ● And in app/views/members/_member.html.erb: 1. <% cache member do %> 2. <li class="member"> 3. <%= %> 4. <span class="bio"> 5. 6. <%= %> </span> 7. </li> 8. <% end %>
  18. 18. Russian Dolls if we had a team with two members, a total of of 3 fragment caches would be written: views/members/1-20121220141922 views/members/2-20121220141922 views/teams/2-20121220141922
  19. 19. 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.
  20. 20. Russian Dolls <!-- app/views/teams/show.html.erb --> <% cache ["v1", @team] do%> <h1>Team: <%= %></h1> <%= render @team.members %> <% end %> <!-- app/views/members/_member.html.erb --> <% cache ["v1", member] do %> <div class='member'> <span><%= %></span> <p><%= %></p> </div> <% end %>
  21. 21. Russian Dolls The above version prefixing results in the following fragment caches: views/v1/members/1-20121220141922 views/v1/members/2-20121220141922 views/v1/teams/2-20121220141922
  22. 22. 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.
  23. 23. 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!
  24. 24. Cache Digests <!-- app/views/teams/show.html.erb --> <% cache @team do%> <h1>Team: <%= %></h1> <%= render @team.members %> <% end %> <!-- app/views/members/_member.html.erb --> <% cache member do %> <div class='member'> <span><%= %></span> <p><%= %></p> </div> <% end %>
  25. 25. Cache Digests This results in the following fragment caches, now suffixed with an MD5 of the template itself: views/members/120121220141922/74865fcb3e2752a0928fa4f89b3e4426 views/members/220121220141922/74865fcb3e2752a0928fa4f89b3e4426 views/teams/220121220141922/4277f85c137009873c093088ef609e60
  26. 26. 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. You’ll have to use a threaded server, like thin and puma, in order to stream data; actions from streaming controllers run in a separate thread.
  27. 27. ActionController::Live 1. class MyController < ActionController::Base 2. include ActionController::Live 3. def stream 4. response.headers['Content-Type'] = 'text/event-stream' 5. 100.times { 6. "hello worldn" 7. sleep 1 8. } 9. 10. #must close the stream 11. end 12.end
  28. 28. 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 you’re finished writing data. Ensure that your actions are thread-safe, as they will run in a separate thread.
  29. 29. References 1. 2. 3. 4. 5. 6. 7. 8.