The Next Five Years of Rails

2,437 views

Published on

Yehuda Katz - "The Nex Five Years"

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,437
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
12
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

The Next Five Years of Rails

  1. 1. RAILSThe Next Five Years
  2. 2. THE LASTFIVE YEARS
  3. 3. WHY DO WELIKE RAILS?
  4. 4. "CONVENTION OVERCONFIGURATION"
  5. 5. TRIVIAL CHOICES. When we say "convention over configuration", we mostly mean eliminating trivial choices.
  6. 6. TRIVIAL CHOICES.■ Naming■ Asset compilation■ To test or not to test■ Routing HTTP to controllers■ File structure and architecture
  7. 7. MORE COMMONCONCERNS REQUIREFEWER DECISIONS.
  8. 8. Rails takes a very hard line onconventions, which forces us to solveproblems very completely. Theres littleroom for us to punt problems onto Railsusers.
  9. 9. CSRF PROTECTION
  10. 10. 100% MANUAL.
  11. 11. SEMIAUTOMATIC.<form action="/cash_transfer">{% csrf_token %}
  12. 12. AUTOMATIC.<%= form_for @cash_transfer do |f| %> <%= f.text_field :from %> <%= f.text_field :to %> <%= f.text_field :amount %> <%= button "Transfer!" %><% end %> Enter Text here
  13. 13. Conventions Tools Hand-RolledConventions allow you to avoidthinking about the problem at all whileworking on features.Tools make the problem easier to solve,but still make you think about it.When we dont have a convention forsomething, we end up forcing thedeveloper to learn about the problemand choose a solution, which is most ofthe cognitive overhead of solving ityourself. Cognitive Overhead
  14. 14. The common conventions of Railsapplications provide a foundation foradditional abstractions.
  15. 15. COURSE CORRECTIONSNo interest in cosmetic, no time forrefactoring.Interested in figuring out why myclients dont want me to use Rails.
  16. 16. MANY PEOPLE HAVE A PROBLEM.Criteria for course corrections
  17. 17. MANY PARTS OF THESOLUTION ARETRIVIAL.REST: What HTTP structure should I use? What names should I give my methods? How should I generate URLs?
  18. 18. THERE IS BENEFIT IN ASHARED SOLUTION. Asset pipeline: * Works out of the box * Reduces cost of entering a project * Concept of "Rails asset processor"
  19. 19. LEARNING ABOUTTHE PROBLEM ISHARD. Encodings, Security, ETags
  20. 20. FAILURE TO SOLVEIN RAILS CORE. What are the problems for failing to provide solutions in Rails core. Flip side of what I just said.
  21. 21. CRITICAL MASS. Having multiple competing solutions robs any one solution of the critical mass it needs to rapidly improve. No initial implementation is perfect, and Rails provides eyeballs and hands.
  22. 22. Its tempting to say "let this feature be a plugin, and well let our users flesh it out before we include it"USAGE. This often results in several competing solutions, each languishing with few users, all of which have major issues. The lack of usage can also hide conceptual problems with an approach (heroku deployment?)
  23. 23. INTEGRATION. When users pick a solution on their own, they are willing to put up with a lot of manual work. The process of integrating a feature into Rails to automate it often brings fundamental problems to light.
  24. 24. ECHO CHAMBER.The people most likely to choose a plugin solution to aproblem also understand it the most. This means thatthere is little impetus to provide completely transparentsolutions that work without complete (or any) knowledgeof the underlying problems. By making something a Railsconcern, it immediately busts the echo chamber of thosewho already understand the problem.
  25. 25. TECHNICAL DEBT. As Aaron said yesterday, when solving these larger issues, we have a larger tolerance for technical debt. That said, we shouldnt throw caution to the wind and take on unlimited debt. At this point, were still paying back our last emergency loan, so lets be more prudent now.
  26. 26. GOOD ARCHITECTUREENABLES FUTUREFEATURES. Architecting well means that we can easily improve the feature in the future. Many of the good things in the Rails 3 architecture (notifications) have only come to fruition now.
  27. 27. FEATURES NOW + FEATURES LATER ÷ COST NOW + MAINTENANCE
  28. 28. FEATURES NOW + FEATURES LATER ÷ COST NOW + MAINTENANCE Building a feature right lets us extend it easily in the future with lower maintenance costs. This allows us to make necessary investments more easily in the future.
  29. 29. BETSWhen we correct course, we areplacing a bet about the future of ourindustry.
  30. 30. BETTING ON REST.
  31. 31. WINS OF REST.■ Early support for rich HTTP semantics ■ Powerful router (request constraints, ...) ■ Content negotiation (Accept, $.getJSON) ■ Baked-in MIME types ■ HTTP caching ("Conditional GET") ■ JSON parameters ■ Security (e.g. IP spoofing)
  32. 32. RAILS HAS A GREATHTTP FOUNDATION.
  33. 33. BUT...
  34. 34. DATATRANSPORT
  35. 35. SQL DATABASE
  36. 36. BEFORE RAILS.■ Primary key: chosen per table■ Table name: chosen per table■ Timestamps: chosen per timestamp■ Polymorphic tables: ad hoc setup■ Foreign keys: chosen per relationship■ Camel/Underscore: chosen per field
  37. 37. Because of all of these discrepancies,you end up needing to build a map ofyour database for your application.
  38. 38. "DATABASES ARETOO DIFFERENT" In the early days of Rails, we heard a lot of arguments that databases were simply too different for AR to be more than just a toy. We hear similar arguments today with APIs.
  39. 39. JSON APIS.
  40. 40. JSON APIS.■ Should responses include a root?■ How to embed associations?■ Include the identifier? In what form? ■ id or href?■ Include additional/associated resources?■ How to update in bulk?■ Primary key defined on server or client?■ Moving a belongs_to record? Just like there were questions in SQL, there are questions in JSON APIs.
  41. 41. STANDARDIZEDCLIENT CODE. Without standardization, we cannot easily build standardized code on the client.
  42. 42. Were also back to making the sametrivial decisions over and over again,if we even realize that we aremaking decisions.
  43. 43. And because were not taking on theproblem, were pushing the concernsonto every client.
  44. 44. Since Rails doesnt provide these conventions, people are asking "Is Rails the right tool for the job" Even though other tools dont provide conventions, Rails is all about CoC, so the lack of conventions makes *Rails* feel like the wrong tool for the job, even though much of Rails is still useful.IS RAILS WORTH IT? Rails starts feeling more like a very polished library and less like a framework.
  45. 45. ACTIVEMODELSERIALIZERS.
  46. 46. What to Serialize How to Serialize• Which attributes • Include a root?• Which associations • Associations? • Extra data? • Avoid duplication!
  47. 47. WHAT TO SERIALIZE.class PostSerializer < ApplicationSerializer  attributes :title, :body  belongs_to :author  has_many :commentsend
  48. 48. CUSTOMIZE.class PostSerializer < ApplicationSerializer  attributes :title, :body  belongs_to :author  has_many :comments   def comments    comments = post.comments    return comments if scope.admin?     comments.where(hidden: false)  endend
  49. 49. HOW TO SERIALIZE.class ApplicationController  embed :ids, include: trueend
  50. 50. AVOID DUPLICATION.{  posts: [    { "id": 1, "title": "First", "person_id": 1 },    { "id": 2, "title": "Next", "person_id": 1 },    { "id": 3, "title": "More!", "person_id": 1 }  ],  people: [    { "id": 1, "name": "Yehuda Katz" }  ]}
  51. 51. ANY CONVENTION ISBETTER THAN NOCONVENTION.
  52. 52. DEMO.
  53. 53. The advantage of serializers is that it avoids mixing the common (representation) with the unique (attributes, associations)AVOID MIXINGCOMMON ANDUNCOMMON. This is in contrast with builders, which put the common and unique things in one place, so we have no place for conventions.
  54. 54. CONFIGURABLE. Especially for authorization, there is a need to be able to poke under the declarative hood. Its not all documented, but it works.
  55. 55. AUTHORIZATION.class PostSerializer < ApplicationSerializer  attributes :title, :body  has_many :comments  has_many :troll_ratings # override just default association inclusion  def include_associations!    comments = post.comments     unless scope.can(:see_hidden, post)      comments = comments.where(visible: true)    end     # override default value, but not embedding rules, etc.    include! :comments, value: comments     # conditionally include an association    include! :troll_ratings if scope.can(:troll_rate, post)  endend
  56. 56. WAS IN RAILS.
  57. 57. REVERTED. WHY?
  58. 58. EMBER-RAILS. ember-rails was trying to build a transparent data transport and it was hard for arbitrary Rails applications.
  59. 59. GENERATE A MODEL,GET A SERIALIZERAND EMBER-DATAMODEL.
  60. 60. REST ADAPTER.
  61. 61. REST ADAPTER.App.store = DS.Store.create({ revision: 4,  adapter: "DS.RESTAdapter"});
  62. 62. MODELS.App.Post = DS.Model.extend({  title: DS.attr(string),  body: DS.attr(string),   comments: DS.hasMany(App.Comment) }); App.Comment = DS.Model.extend({  body: DS.attr(string),  post: DS.belongsTo(App.Post) });
  63. 63. TRANSPARENT.var people = App.Person.all();/* GET /people */ // later...var first = people.objectAt(0);first.set(firstName, "Brohuda"); App.store.commit();/* POST /person/1 { ... } */
  64. 64. Transport SerializationAMo::Serializers solve serialization, but Ithink we need a general solution for allthree. Client Side
  65. 65. BULK. Serializers doesnt solve this, but there is a need to define conventions around bulk updates. ember-data defines conventions that, if implemented in Rails, "just work"
  66. 66. OTHER DATAFEATURES. Identity map; data binding to the view; associations (including create parent=>child=>persist)
  67. 67. CONVENTIONS FORAPPLICATIONSTRUCTURE. Beyond "put your JS here"
  68. 68. TRIVIAL CHOICES ARETHE ENEMY.
  69. 69. NODE?
  70. 70. “ Back in 1995, we knew something that I dont think our competitors understood, and few understand even now: when youre writing software that only has to run on your own servers, you can use any language you want. When youre writing desktop software, theres a strong bias toward writing applications in the same language as the operating system. But with Web-based software, you can use whatever language you want.PAUL GRAHAM
  71. 71. “ This new freedom is a double-edged sword, however. Now that you can use any language, you have to think about which one to use. Companies that try to pretend nothing has changed risk finding that their competitors do not.PAUL GRAHAM
  72. 72. TRANSPORT. Standards and Same Language Conventions Everywhere• HTML • JMS• ActiveRecord • DRb Thinking "I need to talk with JS, therefore I need to write JS on the ser ver" is pretty lazy thinking. We can get seamlessness without insisting on the same language everywhere.
  73. 73. TRANSPORT. Standards and Same Language > Conventions Everywhere• HTML • JMS• ActiveRecord • DRb Thinking "I need to talk with JS, therefore I need to write JS on the ser ver" is pretty lazy thinking. We can get seamlessness without insisting on the same language everywhere.
  74. 74. RECAP
  75. 75. RECAP.■ Good conventions save developers from having to agonize over common problems.■ Rails bet on REST gave it a leg up in many areas that are relevant to rich client apps.■ There is still room for improvement: we can make APIs as transparent as ActiveRecord.■ ActiveModel::Serializers is one approach we are looking at to get us there.■ We can also make browser frameworks better through the same conventions.
  76. 76. THANKS!@WYCATS

×