Save 37% off PRO during our Black Friday Sale! »

Large scale rails applications

0b2656e3a8d8a51209f60e609c3e9392?s=47 Flo
December 20, 2016

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.

0b2656e3a8d8a51209f60e609c3e9392?s=128

Flo

December 20, 2016
Tweet

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.
  7. None
  8. None
  9. If it’s not a controller screwdriver job, leave it to

    the model hammer.
  10. None
  11. None
  12. None
  13. User specs (1) • User can signup through site /

    API • When a user signup, we send an email to confirm it’s email address
  14. None
  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
  16. None
  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).
  18. None
  19. None
  20. None
  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

  84. None
  85. Not PORO

  86. Inversion of controls

  87. Separate what and when

  88. None
  89. None
  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