Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
RubyConf AU 2014: http://www.rubyconf.org.au Rails is a great framework for creating web apps… for awhile. What do you do when your codebase grows large? How do you handle large teams of developers? When performance becomes an issue, how do you scale? Most importantly, how do you write code which can easily be refactored later? This is a story of a real life project built from day 1 with all these questions in mind. Learn about the problems we solved and lessons we learned: how to partition your Rails app into distinct modular engines, how to speed up your test suite by only running code effected by your changes, how to add a layer on top of ActiveRecord to enforce loose coupling, and many other patterns that can be applied to your own Rails apps! slides here: speakerdeck.com/benjaminleesmith/how-i-architected-my-big-rails-app-for-success-rubyconfau-2014
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In his talk at RubyConf AU 2014, Benjamin Smith discusses the architectural strategies employed in building a large Rails application aimed at long-term maintainability and scalability. The central theme is how to effectively structure a codebase to handle an expanding team and ensure performance as the application grows. Key points of the talk include: - **Understanding Success**: Success for the project meant anticipating future scalability and handling a large codebase, given the client's needs for a complete rebuild of their existing application over an extended timeline. - **Utilizing Rails Engines**: Smith introduces the concept of Rails engines, which bundle an entire Rails app's components, enhancing modularity within the application. He explains how they opted for a unique approach by keeping engines within a single Rails app while avoiding versioning issues usually encountered in service-oriented architectures. - **Architecture Design**: The architecture consisted of multiple engines tailored to different functionalities, such as an admin engine for content creation and a social network engine for content presentation. This separation facilitated clearer dependencies and enhanced code organization. - **Patterns and Best Practices**: As development progressed, identifying functional patterns allowed the team to refine their approach. Smith emphasizes naming conventions for distinguishing between web engines (which handle routing) and domain engines (which contain pure logic). - **Avoiding Circular Dependencies**: To maintain flexibility during refactoring, the team implemented practices to prevent circular dependencies, creating a directed acyclic graph for engine interactions that simplify understanding and maintainability. - **Domain API Layer**: Smith introduced a domain API to act as a buffer between controllers and models, encouraging a loose coupling of components, which aids in independent development and testing. - **Testing**: By structuring tests within individual engines, the team ensured high confidence in the stability of each engine independently, reducing the overhead involved in comprehensive integration testing. - **Long-term Outcomes**: While the initial phase posed challenges, the architecture eventually led to enhanced parallel development, straightforward scaling, and improved testing capabilities. The conclusion drawn from Smith’s experiences is that although adopting such strategies can initially slow down development, the long-term advantages, including better maintainability and scalability, make them worthwhile. He encourages peers to experiment with engines and alternative structure approaches in their Rails applications.
Suggest modifications
Cancel
