Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
by Michael Ries Rails gives us great conventions for building an application, but what conventions should we use when we are building a whole system that encompasses multiple applications? How should we name things? What abstraction layers should we enforce? The MX team has been building a distributed system composed of Rails applications for the last 3 years. We’ll talk about failed ideas, conventions that have stood the test of time and some experiments that are underway. Help us caption & translate this video! http://amara.org/v/GVgq/
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 talk titled "Conventions Between Applications" presented by Michael Ries at the MountainWest RubyConf 2015, the focus is on building effective distributed systems using Ruby on Rails, drawing on the experiences of the MX team. The presentation emphasizes how to navigate the conventions required for developing a cohesive structure comprising multiple applications. Key points discussed include: - **Definition of Distributed Systems**: Ries describes distributed systems as multiple applications collaborating to achieve a shared goal. - **Sample Project**: The team illustrates their experiences by considering a typical task for new engineers, which involves cleaning up user data across 18 Rails applications. - **Documentation and Directory Structure**: A well-maintained directory is essential for identifying resources easily and managing documentation efficiently. The internal gem Atlas is proposed as a solution to handle Protocol Buffers definitions for better clarity in data management. - **Resource Responsibility**: Each application should manage designated resources to ease communication and clarity within the system. - **Implementing RPC Calls**: Establishing clear RPC (Remote Procedure Call) structures is vital. Each resource should have dedicated RPC calls defined to maintain structured communication. - **Versioning and Compatibility**: By applying semantic versioning to the Atlas gem, changes can be made with backward compatibility in mind, allowing continuity while upgrading. - **Event-Driven Architecture**: Ries highlights the importance of implementing an event system for handling user data deletions asynchronously. This design enhances independence among services and promotes a tolerant environment for changes. - **Using RabbitMQ**: For effective event messaging, RabbitMQ is suggested as a suitable tool to aid with load distribution, ensuring that applications receive relevant events without overwhelming noise. - **ActionSubscriber Gem**: An internal gem that simplifies communication with RabbitMQ from Rails applications, promoting an easier integration into existing systems. - **Developer Practices**: Encouragement of adopting patterns that feel natural to the existing technology stack and emphasize effective communication among teams, keeping changes at a small, manageable scale. In conclusion, Ries stresses the significance of creating a streamlined directory, publishing essential events for communication, and performing small deployments to mitigate risks. These practices can help developers transition effectively to distributed architectures, fostering collaboration and ongoing learning for sustained adaptability in their system designs.
Suggest modifications
Cancel
