Smash the Monolith: Refactoring Rails Apps with Services and APIs

Transcript

1. Smash the Monolith Refactoring Rails Applications
2. The ‘A’ Word
3. The definition, composition, and interactions of parts of a system. Software architecture is...
4. A compromise between viability and perfection. Software architecture is...
5. Tempered by the need to deliver a solution. Software architecture is...
6. Some science. Lots of aesthetics. Software architecture is...
7. Software architecture is...
8. vs. An age-old conflict... Big Up-Front Design Cowboy Coding
9. Then: Big Up-Front Design
10. Advantages Long-term product roadmaps Rich design artifacts Guided evolution Predictability
11. Disadvantages Slow implementation Resistance to change New feature friction No room for mistakes
12. Now: Ad-Hoc Architecture
13. Guiding Principles Convention over configuration Discrete MVC layers Good separation of concerns RESTful and resourceful
14. The Best Intentions Test-driven development + pair programming + pull requests + code reviews = emergent design
15. The Best Intentions
16. Non-CRUD controller methods. The Road to Hell
17. Logic leaking into controllers and views. The Road to Hell
18. Complex object graphs. The Road to Hell
19. /lib/ becomes a junk drawer. The Road to Hell
20. Undocumented gem dependencies. The Road to Hell
21. Bloated user model. The Road to Hell
22. Signs of a Degraded Design Rigidity
23. Signs of a Degraded Design Fragility
24. Signs of a Degraded Design Immobility
25. Signs of a Degraded Design Feature friction
26. Change Gets Harder Over Time Relatively Easy Delegate If Possible Take a Sick Day KILL IT WITH FIRE Difficulty of Change Time
27. How did we get here?
28. How did we get here? Dozens of hands on the code.
29. How did we get here? Classes naturally attract new methods.
30. How did we get here? Increasingly slow test suite.
31. How did we get here? Entropy.
32. How did we get here? One line of code at a time.
33. “Most software eventually degrades to the point where someone will declare the design to be unsound.” Uncle Bob Martin
34. Values-Driven Development
35. Things We Value Fresh ideas combined with best practices.
36. Things We Value Solid design principles applied in novel ways.
37. A Values-Based Approach Culture of innovation + best practices + solid design principles = better architecture?
38. Hexagonal Design
39. Theoretical Backing Layered architectures break down in practice.
40. Domain Objects HTTP Command Line Testing Messaging Persistence Monitoring Sinatra Cron Test Unit Beanstalkd Postgres Honey Badger Rails Rake RSpec Rabbit MongoDB New Relic
41. Design Considerations Design for all of your users, not just the obvious ones.
42. Design Considerations Give every class its own distinct API.
43. Design Considerations Write your application in pure Ruby.
44. Theoretical Backing Achieve framework independence.
45. Using APIs & Messages
46. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Doug McIlroy, Bell Labs CSRC HTTP
47. Design Considerations Implement an ecosystem of small applications.
48. Design Considerations Divide models between the applications.
49. Design Considerations Persistence is a service.
50. Design Considerations Bind applications together using APIs and messaging.
51. Design Considerations Determine a caching strategy.
52. Design Considerations Pick a messaging solution.
53. Rethinking Architecture
54. Roots Rock.
55. A Sudden Revelation What if we think of an application... ...as just another object?
56. Object-Oriented Architecture
57. Theoretical Backing Apply OO design principles to the architecture itself.
58. Classes communicating via messages Applications communicating via APIs & queues ! Theoretical Backing
59. Applying OO Principles An application is a group of components that perform tasks on the same data.
60. Applying OO Principles An application should do one well-defined thing.
61. Applying OO Principles APIs allow us to easily extend our interfaces.
62. Applying OO Principles It doesn’t matter what application sends, receives or processes our messages.
63. Applying OO Principles APIs and presenters allow us to easily create client-specific interfaces.
64. Legacy Applications
65. What is a legacy app? Age is not measured in months or years or versions.
66. What is a legacy app? Legacy code is not broken.
67. What is a legacy app? Don’t git blame.
68. What is a legacy app? A storehouse of information about a problem space.
69. Refactoring Tactics Dismantle god classes.
70. Refactoring Tactics Extract behaviors into modules.
71. Refactoring Tactics Extract models and business logic into engines.
72. Refactoring Tactics Migrate engines into discrete applications.
73. Refactoring Tactics Implement observers using a messaging service.
74. Refactoring Tactics Provide persistence through asynchronous services.
75. Refactoring Tactics Direct calls between applications rely on a good set of APIs.
76. Refactoring Tactics Use your API as a guide to refactoring your models.
77. Synchronous Calls via APIs Credentials Auth Token Auth Service Client App
78. Asynchronous Calls via Message Queues Prefs Update Client App Attr Change Persistence Service
79. Refactoring Tactics Find functional edges and refactor them into services.
80. Refactoring Tactics Make liberal use of the presenter pattern.
81. A declarative framework useful for building APIs. faceted.rb
82. On the Other Side of Refactoring
83. A Small App Ecosystem Consumer App Internal App 1 Internal App 2 Persistence API Messaging API Reporting API Dashboard App
84. Reap the Benefits Reduced cost of change.
85. Reap the Benefits Support for unexpected and novel use cases.
86. Reap the Benefits Reduction of ceremony around releases.
87. Reap the Benefits Low-impact downtime.
88. Reap the Benefits Short ramp-up time for new developers.
89. Reap the Benefits Increased performance of test suites.
90. Reap the Benefits A/B testing on applications and infrastructure.
91. Reap the Benefits Greater flexibility.
92. Reap the Benefits Democratization of application architecture.
93. Go smash your monolith.
94. smashthemonolith.com Corey Ehmke @bantik