APIDays SF 2019: Managing multiple api stacks on serverless
1 like391 views
This document discusses managing multiple API stacks on serverless architectures. It recommends decoupling core data and processing from interface specifics as much as possible, and decoupling from the cloud platform. It also recommends using versioning independently of interfaces, aligning private and public interfaces conceptually, and getting insights before production. The document outlines an iterative process for interface development including conceptualizing, specifying, documenting, implementing, and demonstrating. It stresses respecting guidelines for specific interfaces and adopting standards.
APIDays SF 2019: Managing multiple api stacks on serverless
- 1. Managing Multiple API Stacks on Serverless Alexander Graebe, Head of Developer Experiences, HyperTrack
- 2. What is HyperTrack? A developer platform to track the movement of your business We empower developers through building blocks like SDKs, APIs, Webhooks, and Views
- 3. we did this ...
- 4. … so you can do this!
- 6. Learnings: Architecture ● Decouple core data and processing from interface specifics as much as possible ○ Accessing data and exposing it can happen in different ways - handle at the edge through transformations ● Decouple from the cloud platform as much as possible ○ Rely on software solutions that could be deployed across major cloud platforms ○ Evaluate developer adoption, documentation, and support ● Carefully evaluate cloud-specific limitations ○ AppSync is AWS’s full-managed GraphQL deployment but does not support custom scalar types, adds lambda resolver delays, has a steep learning curve (Apache VTL), and much more
- 7. Learnings: Development ● Use versioning, independent of the interface ○ Sometimes, interface-specific updates will reason version bumps. Don’t enforce interface-wide versions for the wrong reasons ○ Use Semantic Versioning across all interfaces and strive for feature parity - don’t force one interface to be used for a specific feature ● Align private and public interfaces conceptually ○ Internal engineers are just like your end developers, they need good interfaces ○ Oftentimes, private interfaces are considered for public releases later ● Get as many insights as possible before going into production ○ Get beta users and set expectations that interface is in development and might change ○ Battle-test implementation and roll out publicly with beta partners
- 8. Iterative interface development Demonstrate Im plem ent Docum ent Conceptualize Specify ● Conceptualize: Start with the why and what - independent of interfaces ● Specify: Detail out the how with consistent interface specs ● Document: API guides & references to be used by team and developers ● Implement: Use the documentation as blueprint and only release if spec tests pass ● Demonstrate: Implement sample apps and release to early adopters
- 9. Learnings: Developer Experience ● Respect existing guidelines for specific interfaces - don’t unify to make your life easier ○ Interfaces embody implied preferences for e.g. property naming, data structures, and more. Never just pass-through data from your pipeline ○ Security mechanisms are tailored towards the interface (e.g. Webhooks vs API) ● Adopt existing standards where possible ○ Standards like OpenAPI, OAuth, GeoJSON, etc have wide adoption and support across many languages through libraries - understand how developers use these ● Help developers understand what interface to use - and how ○ Everything that can be used unexpectedly, will be used unexpectedly ○ Lay out important architecture decisions (e.g. APIs vs Webhooks vs GraphQL vs SDKs vs Views)
- 10. … why bother, though?
- 11. Managing multiple API stacks is hard … but, developers need flexibility and deserve great APIs!
- 12. @agraebe: Thank you! Learn more at: www.hypertrack.com/blog