API Driven Design
•Download as PPTX, PDF•
4 likes•941 views
Lessons learned while transitioning to an API company - how to structure applications in a sane way and use modern tools to make and maintain a codebase you won't hate.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to API Driven Design
Similar to API Driven Design (20)
Recently uploaded
Recently uploaded (20)
API Driven Design
- 1. API DRIVEN DESIGN How to build things you won’t hate
- 2. 6 THINGS I WISH I HAD KNOWN 1. MVC frameworks aren’t designed for APIs 2. Modern tools are awesome; use them 3. Write testable code 4. Make deployment easy & scalable 5. Make your infrastructure work for you 6. Break down app into smaller services
- 4. MVC FRAMEWORKS • Popularized by Ruby on Rails • Opinionated design optimized for building quickly • Convention over configuration
- 5. ✅ Fast prototyping ✅ Reasonably sane architecture ❌ Inflexible structure ❌ Tightly coupled ❌ Unsuitable for non-web tasks 💣 Active Record pattern
- 7. –Benjamin Franklin* “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” * Martin Golding
- 8. 3rd Party API JSON View
- 9. 3rd Party API JSON View CDN
- 10. MVC
- 11. CODE IS (FINALLY) CHEAP Add libraries: require Update: update Deploy: install
- 12. Most common problems are already solved Focus on using libraries …but build them independently when necessary Contribute fixes back upstream if possible
- 13. WHAT DOES EVERY API NEED? Authentication Request & Response formats Documentation
- 15. THINK IN LIBRARIES Put SDKs and interfaces in own repositories Import as needed - avoid huge frameworks Develop independently
- 17. TESTS …you have some, right? …please?
- 20. GOALS • Inputs and outputs match spec • Data calculated, modified and returned correctly • Adheres to interfaces • Interface makes sense
- 21. DO YOU… • Connect to DB? • Make API calls? • Use internal services?
- 22. TESTABLE CODE Support DI; hint interfaces, not classes Red flags: “new”, “and”, “::”, “instance”, “->->->” More small classes & methods Make tests reusable Write tests first! (TDD)
- 24. TESTING SERVICES • Mock response from service w/ different results • Test output formats • Trust required
- 25. DEPLOYMENT 101
- 27. Get deployments working! Rollbacks too… Doesn’t matter how, but make it one-click DeployBot
- 29. 1. Install dependencies 2. Compile & compress 3. Run tests 4. Push the build 5. Flip it live composerinstall less,jsx,jsmin phpunit tar-c,scp tar-x;ln-s;mv-T
- 31. WHEN TO SHIP? • Announcement-based • Scheduled (monthly, weekly, etc) • As-needed • Continuously
- 35. INPUT VALIDATION
- 39. GOOD FIRST CANDIDATES • Simple tasks (notifications) • Slow processes (analysis, reporting) • High-security operations (involving hashed or encrypted data)
- 40. WHY SECURITY OPERATIONS? • Network segregation • Least-privilege principle • Improve access controls • Keep sensitive info off front-end servers
- 42. 6 THINGS I WISH I HAD KNOWN 1. MVC frameworks aren’t designed for APIs 2. Modern tools are awesome; use them 3. Write testable code 4. Make deployment easy & scalable 5. Make your infrastructure work for you 6. Break down app into smaller services
Editor's Notes
- MVC frameworks aren’t designed for APIs poll audience about age of main codebase
- NOT optimized for reading or maintenance If lucky, you’ll only spend 2/3 of your time maintaining existing code
- probably true before coffee
- next: point 2: modern tools are awesome & how we can use them
- Modern tools are awesome; use them This works for other languages (ruby: gem; python: pip)
- put “sane defaults” traits in repo as well next: 3/writing testable code
- Write testable code
- next: 4/ make deployment easy & scalable
- Make deployment easy and scalable
- Poll audience about their deployment system FTP — git pull — code directly on prod?
- nex
- code deployment
- next: 5/ make infrastructure work for you
- Make your infrastructure work for you
- 6/ tying together and break down your app
- Break down your application into smaller services
- More frequent deploys are less scary