AsyncAPI Governance the easy way

A presentation at APIDays London in September 2024 in London, UK by Lorna Jane Mitchell

Slide 1

Slide 1

API Governance for AsyncAPI Lorna Mitchell, Redocly @redocly ~ @lornajane

Slide 2

Slide 2

API governance Good API governance is invisible Without it: •designing changes is more difficult •changes get rejected and need repeat work •APIs become inconsistent •more difficult to adopt an API @redocly ~ @lornajane

Slide 3

Slide 3

@redocly ~ @lornajane

Slide 4

Slide 4

AsyncAPI and Governance AsyncAPI is complex! (it’s a feature, not a bug) •Many protocols •Often multiple API descriptions •Multiple tech stacks @redocly ~ @lornajane

Slide 5

Slide 5

Start with standards Written standards define your API identity. @redocly ~ @lornajane

Slide 6

Slide 6

Design good governance Start small, and formalise existing practices. Outputs are a written standards set, and linting rules. One size does not fit all! Consider mulitple standards and apply as appropriate @redocly ~ @lornajane

Slide 7

Slide 7

Designing rulesets •Level 0: Valid •Level 1: Compliant •Level 2: Consistent •Level 3: Delightful @redocly ~ @lornajane

Slide 8

Slide 8

Level 0: Valid Syntax is good and meets the AsyncAPI specification. •sounds basic •genuinely a good starting point •start here for winning workflows! @redocly ~ @lornajane

Slide 9

Slide 9

Level 1: Compliant Meets agreed API governance standards. •basic service design •metadata requirements (license, contact) •security is required •basic data types and formats, ISO standards @redocly ~ @lornajane

Slide 10

Slide 10

Level 2: Consistent Rigid rules about naming make healthy boundaries. •camelCase or kebab-case? •all plural, or all singlular •glossary for consistent naming @redocly ~ @lornajane

Slide 11

Slide 11

Level 3: Delightful Now add the rules that make things better! •examples required and useful •descriptions include rich explanations and links @redocly ~ @lornajane

Slide 12

Slide 12

Governance processes Change management, done well @redocly ~ @lornajane

Slide 13

Slide 13

Non-lintable standards The machines cannot do everything * Humans must review changes too •would you want to use this API? •is the naming sensible and intuitive? •is the change consistent with the existing API? * Try asking an AI “does this naming make sense?” @redocly ~ @lornajane

Slide 14

Slide 14

Reviews matter In software we can iterate. In published interfaces, that’s harder. Build an API council •Product specialists •Technical experts •Customer advocates (UX, tech writers, DevRel) @redocly ~ @lornajane

Slide 15

Slide 15

Tools for API Governance https://www.asyncapi.com/tools @redocly ~ @lornajane

Slide 16

Slide 16

Redocly CLI: AsyncAPI Redocly CLI •lint and bundle AsyncAPI descriptions •custom rules and plugins, including transform steps •support for AsyncAPI 2.6 and 3.0 @redocly ~ @lornajane

Slide 17

Slide 17

Good API governance (without tears) @redocly ~ @lornajane

Slide 18

Slide 18

Resources •https://redocly.com/docs/cli/guides/lint-asyncapi/ •https://lornajane.net •https://redocly.com •https://www.asyncapi.com/tools @redocly ~ @lornajane