Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Breaking changes are sad. We’ve all been there; someone else changes their API in a way you weren’t expecting, and now you have a live-ops incident you need to fix urgently to get your software working again. Of course, many of us are on the other side too: we build APIs that other people’s software relies on. This talk will cover how you can: (a) Get really good at identifying what changes might break someone’s integration (b) Help your API consumers to build integrations that are resilient to these kinds of changes (c) Release potentially breaking changes as safely as possible
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 her talk at RubyConf 2021, Lisa Karlin Curtis addresses the crucial topic of minimizing disruptions to integrators by effectively managing API changes. She begins with a cautionary tale illustrating the unintended consequences of a well-intentioned update that ultimately caused a significant issue for another developer within the ecosystem. Lisa emphasizes that developers must recognize the delicate balance they must maintain between enhancing their systems and considering the potential impacts on those using their APIs. The key points discussed include: - **Understanding Breaking Changes**: A breaking change occurs when an API alteration invalidates an integrator's assumptions, leading to unexpected errors or failures. Lisa encourages developers to view potential changes through the lens of how likely they are to disrupt existing integrations. - **Common Sources of Issues**: Several typical adjustments are flagged as causing issues, such as modifying endpoint structures, altering rate limits, and changing response formats. For instance, she shares a story about how a seemingly harmless fix to reduce endpoint latency inadvertently drove another integrator's system into a crash. - **Identifying Assumptions**: Assumptions made by integrators can be explicit (through documentation) or implicit (based on industry standards), and understanding these assumptions is critical for minimizing the risk of breaking changes. - **Best Practices for API Maintenance**: To bolster integration reliability, Lisa outlines strategies, including: - Comprehensive and clear documentation of APIs, highlighting edge cases and potential issues. - Effective communication of changes through different channels, transitioning from passive documentation updates (pull communication) to proactive alerts (push communication). - Utilizing versioning systems like semantic versioning judiciously to signal potential breaking changes. - Engaging with integrators to keep abreast of their assumptions and usage patterns. - **Mitigation Strategies**: Implementing gradual changes, providing sandbox environments for testing, and maintaining rollback capabilities can greatly reduce the impact of any breaking changes. In conclusion, while completely avoiding disruptions in integrations may be unrealistic, Lisa advocates for a proactive approach in managing APIs, enhancing communication, and fostering a relationship based on trust with integrators to mitigate the impact of potential breaks. This structured approach can lead to a smoother evolution of APIs without sacrificing the reliability that integrators depend on.
Suggest modifications
Cancel
