RubyConf Taiwan 2016 - Large scale Rails applications
•
0 likes•520 views
This document discusses strategies for scaling large Rails applications. It advocates separating applications into thin controllers, fat models, and following principles like single responsibility and stateless objects. The document also recommends separating applications into layers like services, forms, policies, queries, adapters, and models. Services describe processes, forms convert inputs, policies describe permissions, queries access data, adapters translate between languages, and models manage data. It argues this architecture makes applications more flexible, testable, and debuggable while allowing for easier migration between providers.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to RubyConf Taiwan 2016 - Large scale Rails applications
Similar to RubyConf Taiwan 2016 - Large scale Rails applications (20)
Recently uploaded
Recently uploaded (20)
RubyConf Taiwan 2016 - Large scale Rails applications
- 3. We hire!
- 4. 2007 1.2.3
- 6. If it’s not a controller job, leave it to the model.
- 9. If the screwdriver can’t solve it, use the hammer.
- 17. NOT Rails!
- 21. Principles • Modularity • Single Responsibility Object • Plain Old Ruby Objects • Inversion Of Control • Stateless Objects • Domain Specific Language
- 22. Modularity
- 23. • Controller • Test • Rake tasks • Jobs • Daemons • …
- 25. Not SRP
- 26. SRP
- 29. Break things down minimalist objects
- 30. “Make everything as simple as possible, but not simpler.” Albert Einstein
- 31. Plain Old Ruby Objects (PORO)
- 32. PORO
- 34. Not PORO
- 39. Why? • Separate responsibilities • Remove strong dependencies • Easier to test • Write highly abstract processes
- 41. Stateless
- 42. Statefull
- 43. Why? • No setup • Predictable
- 45. Router Controller Domain API language Domain Specific Language View API language
- 46. Break down
- 49. Services Forms Policies Queries Adapters Models Application
- 51. Services (2)
- 52. Services (3)
- 53. Services (4) Create != Signup
- 54. Services (5)
- 55. Services (6)
- 56. Services (7)
- 58. Services Forms Policies Queries Adapters Models Application
- 59. Forms (1) Convert inputs in Domain language
- 61. Forms (3)
- 62. Forms (4)
- 63. Forms (5)
- 66. Forms (8)
- 67. Forms (9)
- 68. Forms (10)
- 69. Services Forms Policies Queries Adapters Models Application
- 71. Policies (2)
- 72. Policies (3)
- 73. Policies (4)
- 74. Services Forms Policies Queries Adapters Models Application
- 75. Queries (1) Describe how to access data
- 76. Queries (2)
- 77. Queries (3)
- 78. Services Forms Policies Queries Adapters Models Application
- 79. Adapters (1) Translate DSL into another
- 81. Adapters (3)
- 82. Adapters (4) It’s about languages
- 83. Adapters (5) 3rd party API language Client Http request Ruby method
- 85. Adapters (7)
- 87. Benefits • Easy to test (mock client responses) • New provider => new adapter • Easy to migrate • Fake adapters for integration servers
- 88. Services Forms Policies Queries Adapters Models Application
- 90. Models (2) If it doesn’t fit in models …
- 91. Models (3) Then it doesn’t fit in models!
- 92. Models (4)
- 93. Conclusion
- 94. It’s not a perfect solution, just a guide
- 95. Pros • Easier to browse and discover • More flexible • Easier to test • Easier to debug • Agnostic (from ActiveRecord)
- 96. after_commit
- 97. Cons • Harder to design • More time on code architecture • Write more code, more tests • Write integration tests (IOC)
- 98. Small apps
- 99. Soft transition • Code convention • Focus on data and API • Express everything in DSL • Write adapters early • Drop assets pipeline • Split FE / BE in different projects
- 100. Big apps
- 101. More tips • If it doesn’t fit anywhere, think twice • If it still doesn’t fit anywhere, you need a new layer • Check what Java / React community does
- 102. Rails is a fantastic prototyping tool!
- 103. Rails is NOT an application framework
- 104. Rails is a fantastic web framework!
- 105. Thank you!
- 106. Q & A