RubyConf Taiwan 2016 - Large scale Rails applications
Report
Share
•0 likes•520 views
RubyConf Taiwan 2016 - Large scale Rails applications
•0 likes•520 views
Report
Share
Download to read offline
Rails application have this tendency of becoming super messy and hard to maintain very quickly. This talk covers simple principles that you can apply to avoid traps. Rails is at best a Web framework, maybe a prototyping framework but not an application framework. Stop using it this way
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