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.

1. Large scale Rails
applications
Florian Dutey

2. www.strikingly.com

3. We hire!

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 the screwdriver can’t solve it,
use the hammer.

13. Business complexity

14. Technical complexity

15. Solution = Complexity²

16. Rails doesn't scale!

17. NOT Rails!

18. Application
Http
Request
Response

19. Request Router Controller
ResponseView
Models

20. Request Router Controller
ResponseView
Models
Application

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
• …

24. Single Responsibility Principle
(SRP)

25. Not SRP

26. SRP

27. User
email
password
first_name
last_name
address_1
address_2
zip_code
city
country

28. User
email
password
User::Profile
user_id
first_name
last_name
User::Address
user_id
address_1
address_2
zip_code
city
country

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

35. Inversion of controls

36. Separate what
and when

39. Why?
• Separate responsibilities
• Remove strong dependencies
• Easier to test
• Write highly abstract processes

40. Stateless objects

41. Stateless

42. Statefull

43. Why?
• No setup
• Predictable

44. Domain Specific Language

45. Router Controller
Domain
API language
Domain Specific Language
View API language

46. Break down

47. Request Router Controller
ResponseView
Application
?
??
??
Models

48. Services
Application
Forms Policies
Queries Adapters Models

49. Services Forms Policies
Queries Adapters Models
Application

50. Services (1)
Describe processes

51. Services (2)

52. Services (3)

53. Services (4)
Create != Signup

54. Services (5)

55. Services (6)

56. Services (7)

57. Services (8)
User::SignupService
Payment::SignupService
user/signup_service_spec
Payment::SignupService
payment/signup_service_spec

58. Services Forms Policies
Queries Adapters Models
Application

59. Forms (1)
Convert inputs in
Domain language

60. Forms (2)
USER
email
password

61. Forms (3)

62. Forms (4)

63. Forms (5)

64. Forms (6)
User
email
password
User::Profile
user_id
first_name
last_name
User
email
password
first_name
last_name

65. Forms (7)
accepts_nested_attributes_for

66. Forms (8)

67. Forms (9)

68. Forms (10)

69. Services Forms Policies
Queries Adapters Models
Application

70. Policies (1)
Describe permissions

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

80. Adapters (2)
User
email
password
first_name
last_name
Recurly

81. Adapters (3)

82. Adapters (4)
It’s about languages

83. Adapters (5)
3rd party
API language
Client
Http request
Ruby method

84. Adapters (6)
Client
API Language
Adapter
DSL
Application

85. Adapters (7)

86. Adapters (8)
PaymentManager
RecurlyAdapter StripeAdapter

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

89. Models (1)
Data
(& persistency)

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