Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
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! Help us caption & translate this video! http://amara.org/v/FG6l/
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 the video titled "How I architected my big Rails app for success!" Ben Smith shares insights from his experience architecting a complex Rail application at Pivotal Labs aimed at ensuring scalability, modularity, and maintainability. The project involved a significant team and a strategy focused on establishing a strong foundation from day one to alleviate issues that come with large codebases. Smith outlines several key points related to the architecture and organization of their Rails app: - **Understanding the Context**: The engagement was anticipated to last over eight months, necessitating thoughtful architecture to manage a large team while maintaining code quality and project scalability. - **Use of Rails Engines**: The team adopted Rails engines, which are mini Rails applications that can be packaged together but chose not to separately deploy them, keeping everything within a single Rails application for simplicity. - **Modularization**: By breaking down the app into distinct engines such as Admin, Social Network, and Scheduler, they emphasized the importance of managing dependencies efficiently. This modular approach aimed to avoid circular dependencies and keep the system organized. - **Refactoring for Clarity**: The team engaged in continual refactoring to minimize dependencies and properly categorize engines into 'web engines' and 'domain engines'. This structured approach made understanding dependencies easier and improved maintainability. - **Testing and Code Isolation**: They emphasized testing each engine in isolation, promoting self-contained engines that prevent cross-references unless explicitly defined. This practice streamlined testing and improved development speed over the project. - **Long-term Viability of Engines**: Despite some initial challenges with adopting engines, over time, their approach led to efficient parallel development and allowed for smoother scaling of individual components. Smith concludes by promoting the advantages of creating self-contained engines to align with project needs and encouraging developers to adopt these practices for their own Rails apps. He remarks on the value of using domain APIs to maintain separation of concerns, which further aids in preventing tightly coupled components. Overall, the key takeaway from this presentation is the importance of thoughtful architecture and modularity in Rails applications to ease future modifications and enhance scalability.
Suggest modifications
Cancel
