Downloaded 83 times
Uploaded byApigee | Google Cloud
Huge: Running an API at Scale
1. The document discusses running an API at scale and some of the challenges that arise. It notes that running a huge API product is different than running a web product. 2. Managing application developers and the relationships between their apps and users becomes more complex at scale. Techniques like OAuth and caching can help reduce load on APIs and internal systems. 3. As APIs and applications grow, aspects like chatty applications, application versioning, testing, and geo-distributed caching take on increased importance for managing scale and complexity. The key is to continually improve while avoiding getting stuck.
More Related Content
Similar to Huge: Running an API at Scale
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Huge: Running an API at Scale
- 1. HUGE: Running an APIat Scale Sam Ramji @sramji Brian Pagano @brianpagano Ed Anuff @edanuff Apigee @apigee
- 2.
- 3.
- 4. “ People will do stuff with our API we never imagined. -VP of Marketing “ People will do stuff with our API we never imagined. -CTO
- 5. 80 Now What?
- 6. “ The constructionist hypothesis breaks down when confronted with the twin difficulties of scale and complexity. -P.W. Anderson More is Different
- 7. Web Value Chain Control Web Web Web Web Internal User Browsers Application Team Systems <HTML> <SCRIPT>
- 8. API Value Chain Control App App API Internal App API User Developer Team Systems
- 9. Running a hugeweb product and running a huge API product are different endeavors.
- 10. “ Running a platform is like running a town. -Ryan Sarver Director Twitter API
- 11.
- 12.
- 13. From Direct toIndirect Indirect App App API User App Developer Team
- 14. Manage application developers& applications
- 15. Manage relationships betweendevelopers’ apps and our users.
- 16. OAuth App API token token token App API App User Team Developer
- 17. All applications arenot created equal.
- 18. Chatty Applications –Application Developer’s POV App Developer App API
- 19. Chatty Applications –API Team’s POV API Team App API
- 20. More moving parts,but you can’t stand still.
- 21. Versioning App v1 API v1 App v2 API v2 App v3 API v3
- 22. Pro Tip: DoThe Good Stuff • Test Driven Development • Continuous Integration • QA
- 23.
- 24. Scale Doesn’t HappenWhen You Expect It
- 25. APIs Ask Moreof Internal Systems Internal API Systems
- 26. Ask Less ofthe API - Cache Internal App Web Cach API Systems e
- 27. Ask Even Lessof the API – Geo Distributed Cache Euro Web Cach App e Internal Americas Web Cach Web API Systems App e Asia Web Cach App e
- 28. THANK YOU Subscribe toAPI webinars at: youtube.com/apigee
- 29. THANK YOU Questions andideas to: groups.google.com/group/api-craft
- 30. THANK YOU Contact usat: @sramji sramji@apigee.com @brianpagano bpagano@apigee.com @edanuff ed@apigee.com
Editor's Notes
- #2 Creative Commons Attribution-Share Alike 3.0 United States License
- #5 == ED ==at 6 apart when opening the API: New UI Paradigm - continuous scrolling vs the page load paradigm. 1 to 2 orders of magnitude more content. * you wouldn't have predicted it - new reader application launched on TechCrunch
- #7 There is a big difference between running a prototype and running a big API product.
- #8 In the world of web products there’s variation in browsers. And they can be super wonky. But nowadays those variations are known and predictable.We control everything else. And importantly we control all the code that calls our servers.SAM: trivial complexity because it’s homogenous. There’s variety but the complexity is trivial. You can rely on :BroadbandPC CPUs
- #9 In the API world we control much less. The variation is much greater. And we can predict very little.Importantly, we don’t control any of the code that hits our servers.
- #11 CC photoshttp://www.flickr.com/photos/peopleforcherry/3427058289/ http://www.flickr.com/photos/ifmuth/606128545/If running a big web product is like running a big building then running an API is like running a city. Building/Web: linear, rational, predictable. It’s about the technology.City/API: non linear, irrational, unpredictable, its about the people.SAM: Chaos is another way of thinking about complexityFirst responsersJitters in the systemDifferent patterns of behaviourHard to predict
- #12 What drives complexity?
- #13 Sam
- #14 The first driver is going from direct to indirect
- #15 This is like the role of mayor.Track them: register developers and their appsMake sure they adhere to terms of useCut off violatorsPromote their applicationsKeep them happyCommunicate with themBring them usersSAM: as the API team your attitude has to be permeable. Allow the developers in your community to help you help them. Let’s the citizens be activists.
- #16 This is totally different than the web and very complex:track our usersTrack the relationships between the apps, developers and our usersThis isn’t just password resetThis is authorizing on behalf of the user which parts of their data that we store that the apps can use
- #17 What does this mean in terms of scaling up requests and responses?Between any two requests the user might revoke privileges from the appSo we must check every response against the wishes of our users. OAuth increases the number of API calls necessary to get a new client up and running on the API, although if your API is successful then that will average out to not too much. OAuth also means that you have a whole bunch of tokens to maintain -- one per end user, per device, per app -- for a big API that's easily millions. You need them to be available at all times, and in fact you need to be able to write to that database at all times, not just read from it, so that you can issue new tokens whenever new end users appear or whenever they get a new device. So that's a lot of tokens. We're finding that databases like Cassandra and Riak that are eventually consistent and let you write from anywhere are much more effective for this problem than databases that rely on master-slave replication.ED: you’ll be using muscles you’ve never had to use before.
- #18 You don’t
- #19 Bad developersDevelopers in a hurryOur API is not clear to themClient-side cachingiOS has restkit which uses Core Data to store data locallyAndroid has restlet for caching and some folks use squid on the client side as a reverse proxy
- #20 Your API docs might be unclearYou might not be offering guidance on best practicesAPI design might be terribleBut if we do the above correct there are still 2 key considerations:Publish SDK/Libraries or not?With an SDK you can package up your API usage best practices that developers will adoptBut it’s a lot more work: you are now in the software distribution business. At least follow the OSS model: githubetcThe big dog debate: resource-oriented API design or UI-oriented “shortcut” API designProbably do both: resource first as the baseline, then shortcuts as needed by UI
- #22 You have to version
- #25 Innovation happens on someone else’s schedule and not yours.
- #26 You don’t
- #27 You don’t
- #28 You don’t