Large scale rails applications

I started using Rails in 2007 on version 1.2.3. Since that time I've noticed that, whatever version of Rails we're using, things end up pretty complex and messy as soon as the application scope is reaching a decent size.
In this talk, we try to identify why this always happen and give some leads on how to avoid that.

Transcript

1. Large scale Rails applications Florian Dutey
2. www.strikingly.com
3. www.sxl.cn
4. 2007 1.2.3
5. Fat Models Skinny Controllers
6. If it’s not a controller job, leave it to the model.
9. If it’s not a controller screwdriver job, leave it to the model hammer.
13. User specs (1) • User can signup through site / API • When a user signup, we send an email to confirm it’s email address
15. User specs (2) • Admins can create users through admin tool • When admin create a user, we auto-generate the password and send it through email
17. User specs (3) • We have a partnership with another solution (A) and we need to share our users • We will consume A’s API to collect users and insert them in our DB • When we register a new user this, we don’t send any email (email is assumed confirmed already and we can grab their password from API).
21. Rails doesn't scale!
22. Rails is NOT an application framework
23. Rails is a web framework!
24. Application Http Request Response
25. Request Router Controller Response View Models
26. Request Router Controller Response View Models Business logic
27. Request Router Controller Response View Business logic ? ? ? ? ? Models
28. Services Business logic Forms Policies Queries Adapters Models
29. Services Forms Policies Queries Adapters Models Business logic
30. Services (1) Describe processes
31. Services (2)
32. Services (3)
33. Services (4) Create != Signup
34. Services (5)
35. Services (6)
36. Services (7)
37. Services (8) User::SignupService Payment::SignupService user/signup_service_spec Payment::SignupService payment/signup_service_spec
38. Services Forms Policies Queries Adapters Models Business logic
39. Forms (1) Convert inputs in Domain language
40. Forms (2) USER email password
41. Forms (3)
42. Forms (4)
43. Forms (5)
44. Forms (6) User email password User::Profile user_id first_name last_name User email password first_name last_name
45. Forms (7) accepts_nested_attributes_for
46. Forms (8)
47. Forms (9)
48. Forms (10)
49. Services Forms Policies Queries Adapters Models Business logic
50. Policies (1) Describe permissions
51. Policies (2)
52. Policies (3)
53. Policies (4)
54. Services Forms Policies Queries Adapters Models Business logic
55. Queries (1) Describe how to access data
56. Queries (2)
57. Queries (3)
58. Services Forms Policies Queries Adapters Models Business logic
59. Adapters (1) Translate DSL into another
60. Adapters (2) User email password first_name last_name Recurly
61. Adapters (3)
62. Adapters (4) It’s about languages
63. Adapters (5) 3rd party API language Client Http request Ruby method
64. Adapters (6) Client API Language Adapter DSL Application
65. Adapters (7)
66. Adapters (8) PaymentManager RecurlyAdapter StripeAdapter RecurlyClient StripeClient
67. Benefits • Easy to test (mock client responses) • New provider => new adapter • Easy to migrate • Fake adapters for integration servers
68. Services Forms Policies Queries Adapters Models Business logic
69. Models (1) Data (& persistency)
70. Models (2) If it doesn’t fit in models …
71. Models (3) Then it doesn’t fit in models!
72. Models (4)
73. What if it doesn’t fit anywhere?
74. It’s not a perfect solution, just a guide
75. Principles • Single Responsibility Object • Plain Old Ruby Objects • Inversion Of Control • Stateless Objects • Domain Specific Modeling
76. Single Responsibility Principle (SRP)
77. Not SRP
78. SRP
79. User email password first_name last_name address_1 address_2 zip_code city country
80. User email password User::Profile user_id first_name last_name User::Address user_id address_1 address_2 zip_code city country
81. “Make everything as simple as possible, but not simpler.” Albert Einstein
82. Plain Old Ruby Objects (PORO)
83. PORO
85. Not PORO
86. Inversion of controls
87. Separate what and when
90. Why? • Separate responsibilities (SPR) • Remove strong dependencies • Easier to test and debug
91. Stateless objects
92. Stateless
93. Statefull
94. Statefull Stateless
95. Domain Specific Modeling
96. Router Controller Domain API language Domain Specific Modeling View API language
97. Conclusion
98. Rails is a prototyping framework!
99. Pros • Easier to browse and discover • More flexible • Easier to test • Easier to debug • Agnostic (from Rails)
100. Cons • Harder to design • More time spent on code architecture • Write more code, more tests • Write integration tests (IOC)
101. Small apps
102. Soft transition • Code convention • Focus on data and API • Express everything in Domain Language • Write adapters early • Prepare to drop Rails prototyping tools ASAP
103. Big apps
104. 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
105. Thank you!
106. Q & A