Richard_TheDev2023_pattern.pptx.pdf
The presentation addresses the challenges developers face with APIs, such as the diversity in authentication methods, SDKs, and the steep learning curve for each new API. The key proposition is to approach API interactions through an ORM-like abstraction, treating APIs as databases to simplify CRUD operations and action commands. The core idea revolves around treating everything as a message, leveraging microservices as modular, independent components that communicate through these messages. This approach enables a uniform way to interact with various APIs by encapsulating the complexities behind simple, standardized message formats. The example provided illustrates how updating a GitHub repository's description can be abstracted into a message, streamlining the process. This methodology promotes a component-based architecture where microservices, defined by their ability to handle specific message patterns, can be composed to achieve more complex functionalities. The presentation outlines how this model can be applied to the GitHub API, transforming traditional API calls into message-driven interactions, thereby achieving a higher level of abstraction and simplicity. The benefits of this approach include a unified interface for API calls, reduction in the reliance on multiple SDKs, and the facilitation of "pure" business logic that focuses on entity manipulation rather than the intricacies of API communication. The presentation concludes with practical considerations for implementation, such as handling logistics and edge cases, and offers resources for further exploration, emphasizing the philosophy of reducing unnecessary complexity in software design.
More Related Content
Similar to Richard_TheDev2023_pattern.pptx.pdf (20)
More from Richard Rodger (20)
Recently uploaded (20)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
Richard_TheDev2023_pattern.pptx.pdf
- 2. one size fits all
- 3. too many APIs too many SDKs
- 5. APIs are all different Key Auth X X X X X X X "Fun" Auth X SDK X X X X X X Examples X X X X X Support X X "Weird” X X X
- 6. ouch ● need to learn the api ● hard to change provider ● is there an SDK?
- 7. just use AI?
- 9. 80% CRUD The API is a Database let myrepo = entity('github/repo') await myrepo.load$({owner:OWNER,repo:REPO}) myrepo.description = 'new desc' await myrepo.save$()
- 10. “Just” use an Object Relational Mapper!
- 11. ORMs are Simple
- 13. one size fits all
- 15. microservices (as components) to the rescue!
- 16. components are: ● independent & isolated ● modular with interfaces ● reusable & replaceable
- 18. composition $ cat logfile | grep ERROR
- 19. how?
- 21. pattern matching
- 24. pattern → service cmd:save -> entity-service
- 25. new user service! cmd:save -> generic-entity-service cmd:save,name:profile -> user-service cmd:save,name:user -> user-service
- 27. Let’s apply this to the Github API
- 28. Update a Repo await oktokit.repos.update({ owner: OWNER, repo: REPO, description: "new desc" })
- 29. Update a Repo …as a Message cmd: save, base: github, name: repo, ent: { owner: OWNER, repo: REPO, description: "new desc" }
- 30. our services cmd:save -> generic-entity-service cmd:save,name:profile -> user-service cmd:save,name:user -> user-service cmd:save,base:github -> github-service
- 32. ActiveRecord let myprofile = entity('profile') await myprofile.load$({user_id:ID}) // load a profile // cmd:load,name:profile,query:{user_id:...} myprofile.bio = 'new bio' await myprofile.save$() // save profile // cmd:save,name:profile,ent:{id:ID,bio:'new bio'}
- 33. Same for Github API! let myrepo = entity('github/repo') await myrepo.load$({owner:OWNER,repo:REPO}) // cmd:load,base:github,name:profile, // query:{owner:OWNER,repo:REPO} myrepo.description = 'new desc' await myrepo.save$() // cmd:save,base:github,name:profile, // ent:{owner:OWNER,repo:REPO,description:'new desc'}
- 34. same for all Github API Entities
- 35. what you get ● All API calls are the same ● Components over SDKs ● “Pure” business logic
- 36. “Pure” Business Logic ● Step 1: load some entities ● Step 2: modify them ● Step 3: save some entities
- 37. Implementation ● Solve ORM to message ● Write code for messages
- 38. Code for Message for Github // cmd:save,base:github,name:repo,ent:{...} async function saveRepo (msg) { await oktokit.repos.update({ ...msg.ent.data$() }) }
- 40. ORM to Message? some options: ● Your ORM is extensible (lucky!) ● Write a thin ORM wrapper ● No ORM? Just send Messages!
- 41. Logistics ● Setup code (keys etc) ● “Get out of jail” - for edge cases ● Round pegs, square holes
- 43. everything is a message entity operations are things => entity operations are messages
- 44. everything is a message API operations are things => API operations are messages
- 45. Philosophy "Pluralitas non est ponenda sine necessitate" William of Ockham, 14th-century English theologian
- 46. APIs are too “Hairy” Too much accidental complexity justifies an abstraction.
- 47. of course, there’s a book… https://www.manning. com/books/the-tao-of- microservices