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.

2. one size fits all

3. too many APIs
too many SDKs

4. stripe docs
awesome
but: details!

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?

8. 80% CRUD
20% Actions

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

12. ORMs are
NOT Simple

13. one size fits all

14. everything
is a
message

15. microservices
(as components)
to the rescue!

16. components are:
● independent & isolated
● modular with interfaces
● reusable & replaceable

17. components
talk
messages

18. composition
$ cat logfile | grep ERROR

19. how?

20. transport
independence

21. pattern
matching

22. example
{
"cmd": "save",
"name": "profile",
"ent": { … }
}

23. example
cmd:save,name:profile,ent:{...}

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

26. composition
entity-service =
generic-entity-service
+
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

31. Object Relational
Mapper

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$()
})
}

39. Testing?
Mock Messages!

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

42. Real World Code
senecajs.org
github.com/senecajs/seneca-provider

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