Télécharger pour lire hors ligne
Téléchargé parapidays
apidays New York 2025 - Two tales of API Change Management by Eric Koleda (Coda)
Two tales of API Change Management from my time at Google Eric Koleda, Developer Advocate at Coda apidays New York 2025 API Management for Surfing the Next Innovation Waves: GenAI and Open Banking Convene 360 Madison, New York May 14 & 15, 2025 ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/
Contenu connexe
Similaire à apidays New York 2025 - Two tales of API Change Management by Eric Koleda (Coda)
apidays New York 2025 - Two tales of API Change Management by Eric Koleda (Coda)
- 1. A Tale ofTwo APIs Lessons on API change management from my time at Google by Eric Koleda
- 2. Two takeaways 1. Nevermake breaking changes 2. Constantly make breaking changes
- 3. A little aboutme • 16 years in Developer Relations roles • Worked at Google, Coda, and now Grammarly • Focus on productivity products and integration use cases • Collaborated with dozens of API teams
- 4. Change is inevitable Evolutionof the underlying product feature set • "Projects can now have multiple owners" • "Comments can no longer have attachments" Refactoring of the internal architecture • "Webhooks need to be pre-registered" • "We're moving to JSON-RPC" Adapting to the needs of the developer community • "That endpoint now supports the IDs shown in the UI" • "We're adding streaming support for LLMs"
- 5. Designing for change Buildinterfaces that are flexible • Use objects instead of primitive types, to allow for new fields to be added Break functionality into a granular set of endpoints (ex: /contact/{id}/addresses) But all designs have embedded assumptions • If relationships are one-to-one, one-to-many, or many-to-many • The hierarchy of different entities (ex: tasks belong to projects) Tradeoffs between flexibility and simplicity • Making it easier to extend in the future may make it more difficult to use in the present • Let's look at an example →
- 8. What do youprioritize? Existing developers or new developers? • Continuing to use outdated terminology • Requiring extra parameters to get the new behavior External stability or internal velocity? • Designing your API around your org chart • API sprawl vs managed growth
- 9.
- 10. Let's meet ourcharacters AdWords API • AdWords allows advertisers to run ads on Google.com and other properties • API was aimed at very large companies that need to automate bidding • SOAP API with tons of complexity with contributions from many dev teams Apps Script • Allows Google Workspace users to create scripts and macros (like VBA) • Primarily used by "spreadsheet wizards" that want to automate their work • Hosted JavaScript runtime with built-in libraries for Google products
- 11. Adwords API "Hamster wheel" •New version released approximately every 4 months • Only the newest three versions supported Required developers to do 1-2 migrations per-year • Breaking changes could be introduced in any release • Lots of effort required to communicate, educate, and validate developers on each new release
- 12. Apps Script "Frozen inamber" • The core libraries have no versioning, no releases • All changes are additive, with (almost) no breaking changes • Difficult engineering and design challenges when preserving backwards compatibility
- 13. Why did thesame company have such radically different approaches?
- 14. Audience Who are thedevelopers that used the API? AdWords API • Professional developers at large organizations • Familiar with software development best practices • Consistent engagement with the codebase Apps Script • "Citizen developers", who's main job was not programming • Often wrote throw-away, spaghetti code • No one paying attention to the code, no institutional knowledge
- 15. Relationship What does ourrelationship with those developers look like? AdWords API • Customers had strong business need behind the integration • Captive developer audience, as there was no alternative to using the API • Customer and partner managers maintained direct lines of communication Apps Script • Integrations were usually additive (automate some small task) and not business-critical • Lots of competing products for automation in the marketplace • No clear point-of-contact for a given integration, relied on broadcast channels (blog, etc)
- 16. Goals What do weget out of the relationship? AdWords API • Lots of spend passed through the API, important to the core business • Important that developer expose new product features to their users • New features aimed at boosting click through rate (CTR) and therefore revenue Apps Script • Integrations aimed at increasing customer happiness and stickiness • Important that automations and workflows keep running smoothly • Harder to churn to a competitor when lots of scripts power your business
- 17. What does thismean for your APIs? Not a playbook • These two APIs took extreme approaches that likely don't translate to many other scenarios • Each approach required a fair amount of effort Broaden your horizons • There is wide spectrum of options in front of you • You don't have to follow the same pattern as everyone else
- 18. Two Three takeaways 1.Some APIs never make breaking changes 2. Some APIs constantly make breaking changes 3. You should do what makes sense for your audience, relationships, and goals
- 19.
Notes de l'éditeur
- #1 Title: Two tales of API change management from my time at Google Abstract: Even the best-designed API will eventually have to adapt to the changing technology and business goals that underpin it, and how to handle that change can be the subject of much debate. During my time at Google, I worked on APIs that took polar opposite approaches to this challenge: a hamster wheel of releases vs. backward compatibility at all costs. In this talk, I’ll examine how those approaches worked for the company and the developers we served and share my thoughts on how to balance the tradeoffs. Outline: Hook Controversial statement Question Who am I? Brief bio Change is inevitable Underlying products or systems change Learn from the community What do you prioritize? Existing developers or new developers? External stability or internal velocity? Our characters Adwords API Who: Very large companies that need to automate ad bidding What: SOAP API with tons of complexity and many dev teams Apps Script Who: Spreadsheet wizards that want to automate their work What: JavaScript library and custom runtime How they handled change Adwords API: Hamster wheel New releases every X months, scheduled in advance Frequent, short deprecation timelines with strict enforcement Lots of effort required, both internally and externally Apps Script: Backwards compatibility at all costs The library has no versioning, no releases All changes are additive, with no* breaking changes Difficult engineering and design challenges when preserving backwards compatibility Why does the same company have such radically different approaches? Three reasons: the audience, the relationship, the goals Audience AdWords API: Professional developers at large organizations Apps Script: Citizen developers Relationship AdWords API: Captive developer base, strong business need with no other alternatives. Direct lines of communication. Apps Script: Lots of competing products for automation. Very difficult to determine POC, relying mostly on broad comms channels (blog, etc). Goals Adwords API: Developer adopting new features, which increase CTR and revenue Apps Script: Customer stickiness, harder to churn when lots of scripts power your business What does this mean for your APIs? Few would benefit from operating at either extreme. There is wide spectrum of of ways to handle changes, consider your options Think carefully about who your audience is, what's their relationship to you, and what your goals are with the API Thank you!