Leveraging Asynchronous APIs to deliver
cross domain agile collaboration
September 2021
Nuwan Dias
Hello!
Nuwan Dias
VP and deputy CTO - WSO2
@nuwandias
Co-Author of Microservices Security in Action
● Synchronous vs Asynchronous APIs.
● Asynchronous API usages and applications.
● The AsyncAPI spec.
● Challenges faced by users of Asynchronous APIs.
● Management of Asynchronous APIs.
3
Agenda
4
Synchronous Communication
5
REST APIs
Client Server
Request
Response
● View your account balance.
● Transfer money from your account using your mobile app.
● Place an order through an e-commerce application.
● Web search.
● Upload your picture to social media.
“Synchronous APIs are great for getting things done on demand, not but so much
for reacting to events as they happen.”
6
Usages of synchronous APIs
● An alternative to synchronous communication to get data in near real time.
● Results in excessive processing for both client and server.
● <5% actual updates.
● Results in a poor user experience.
● Workarounds such as E-tags only solves part of the problem.
7
Polling
Client Server
Any update?
No
Any update?
Yes
● Provides a mechanism of being notified upon events.
● No polling required.
● Subscriber requires a method of being called.
● Enables limitless collaboration across systems.
8
Asynchronous Communication
Client
(Subscriber)
Server
(Publisher)
Subscribe to events with a callback
endpoint
Notify client through callback endpoint
Event
occurred.
● The broker pattern is a common mechanism of implementing asynchronous
communication.
● No client-server communication.
● Decouples the subscriber from the publisher.
● Allows publisher to focus on its business logic.
● Broker takes on responsibility of message delivery.
⦿ Ex: WebSub: Intent verification, partial updates, message redistribution. 9
Asynchronous Communication: Broker Pattern
Subscriber Publisher
Subscribe
Receive events
Event
occurred.
Broker
Publish
● Push Notifications
⦿ Notifications received on your mobile device.
⦿ Real time updates on apps.
● Automation Tasks.
⦿ Business automation tasks.
⦾ Ex: IFTTT, Zapier, Tray.io
⦿ Engineering process automation.
⦾ Ex: Github.
● Systems integration
⦿ Event driven architecture in Microservices.
10
Usages of Asynchronous APIs.
● HTTP Based
⦿ WebSockets: client-server, bidirectional
⦿ WebHooks: server-server, unidirectional
⦿ WebSub: server-servers, unidirectional
⦿ Server Sent Events (SSE): client-server, unidirectional (server push)
⦿ GraphQL subscriptions: client-server, unidirectional
● gRPC: server-server, bidirectional
● Kafka: server-server, bidirectional
● AMQP: server-sever, bidirectional
● MQTT: client-server, bidirectional
11
Technologies being used to implement Asynchronous APIs
● Used to describe Asynchronous
APIs from a client’s perspective.
● A “client” can be either a publisher
or a subscriber.
● Highly influenced by the OpenAPI
specification.
● https://www.asyncapi.com/
● Describes channels, messages and
brokers.
12
The #AsyncAPI Specification
● By Consumers
⦿ Discovery of all triggers in an organization.
⦿ Lack of a uniform subscription experience.
⦾ Caused by lack of adherence to a standard.
⦿ Unsupported protocol supported by Publisher.
● By Providers/Facilitators (not Publishers)
⦿ Securing Asynchronous APIs.
⦿ Rate limiting.
⦿ Ensuring adherence to contract.
⦿ Message processing/enrichment.
⦿ Monitoring and alerting.
⦿ Business insights.
13
Challenges faced when adopting Asynchronous APIs
14
Have a Developer Portal for discovering events used by an
organization
Subscribers
External Event Publishers
Internal Event Publishers
Register
Register
Developer Portal
Discover
● For HTTP based asynchronous APIs a
hub architecture can be used to unify
subscriptions.
● API providers subscribe the hub with
the API.
● API consumers subscribe with the
hub when/if they want to get notified
on events.
● The hub redistributes events to
everyone subscribed on the hub.
15
Using a Hub architecture for unifying subscriptions
Subscriber 1
Subscriber 2
Portal
Hub
Events from the API received
on the Hub
Hub redistributes events to
subscribers
Subscribers discover APIs on
the portal and subscribe at
the hub
● In certain use cases the clients wants
to use a protocol that is not
supported by the API.
● A hub can be used to convert the
protocol to the requested type. This
mostly works with HTTP based
protocols.
● This also allows the client to use an
appropriate security type for the
protocol.
16
Protocol conversion and security
Subscriber Hub
Publisher sends events on a
Kafka topic
Subscriber uses appropriate
security protocol supported
by the hub.
Subscriber receives events
on a WebSocket
Hub does a conversion from
Kafka event to WebSocket
frame
● An API always has a contract/spec.
● Subscribers expect event producers
to send events that adhere to the
contract.
● Subscribers would fail to process
messages that do not conform to the
contract.
● The Hub can be used as an enforcer
of the contract.
17
Ensuring adherence to contract
Subscriber Hub
Different versions of the API
submit events to the hub
Hub only delivers messages
that adhere to the contract
Hub inspects message to check
for conformance
v1.0
v1.1
● Subscribers may not be interested in
receiving all events published by a
producer.
● They may want to know about events
when certain conditions are met.
⦿ When the average temperature goes
beyond 70 degrees.
⦿ When a bid value goes beyond a
limit.
● Hubs may support message
aggregations, summarizations and
processing.
18
Message processing and Enrichment
Subscriber Hub
Notify whenever someone
places a bid on an item.
Notify subscriber only if
condition is met.
Check if bid goes beyond $50.
● Certain event producers may be too
chatty for the liking of the subscriber.
● The could expose these APIs over
rate limit plans that suit the
subscriber.
● These can be used as a way of
monetizing APIs as well.
19
Rate limiting for reducing chattiness and monetization of APIs
Subscriber Hub
Producers sends all events to
the Hub.
Subscriber only receives
events based on the usage
plan.
Hub rate limits based on
subscribers usage plan.
● Provides organizations insights on
Asynchronous APIs.
● Capture protocol specific usage attributes
⦿ Ex: WebSockets: Bandwidth, SSE: #events,
WebHooks: Active Users.
● Detection of abnormalities and usage
patterns.
20
Monitoring & Alerting
wso2.com
Thanks!
Contact: @nuwandias

Leveraging Async APIs to deliver cross domain agile collaboration

  • 1.
    Leveraging Asynchronous APIsto deliver cross domain agile collaboration September 2021 Nuwan Dias
  • 2.
    Hello! Nuwan Dias VP anddeputy CTO - WSO2 @nuwandias Co-Author of Microservices Security in Action
  • 3.
    ● Synchronous vsAsynchronous APIs. ● Asynchronous API usages and applications. ● The AsyncAPI spec. ● Challenges faced by users of Asynchronous APIs. ● Management of Asynchronous APIs. 3 Agenda
  • 4.
  • 5.
  • 6.
    ● View youraccount balance. ● Transfer money from your account using your mobile app. ● Place an order through an e-commerce application. ● Web search. ● Upload your picture to social media. “Synchronous APIs are great for getting things done on demand, not but so much for reacting to events as they happen.” 6 Usages of synchronous APIs
  • 7.
    ● An alternativeto synchronous communication to get data in near real time. ● Results in excessive processing for both client and server. ● <5% actual updates. ● Results in a poor user experience. ● Workarounds such as E-tags only solves part of the problem. 7 Polling Client Server Any update? No Any update? Yes
  • 8.
    ● Provides amechanism of being notified upon events. ● No polling required. ● Subscriber requires a method of being called. ● Enables limitless collaboration across systems. 8 Asynchronous Communication Client (Subscriber) Server (Publisher) Subscribe to events with a callback endpoint Notify client through callback endpoint Event occurred.
  • 9.
    ● The brokerpattern is a common mechanism of implementing asynchronous communication. ● No client-server communication. ● Decouples the subscriber from the publisher. ● Allows publisher to focus on its business logic. ● Broker takes on responsibility of message delivery. ⦿ Ex: WebSub: Intent verification, partial updates, message redistribution. 9 Asynchronous Communication: Broker Pattern Subscriber Publisher Subscribe Receive events Event occurred. Broker Publish
  • 10.
    ● Push Notifications ⦿Notifications received on your mobile device. ⦿ Real time updates on apps. ● Automation Tasks. ⦿ Business automation tasks. ⦾ Ex: IFTTT, Zapier, Tray.io ⦿ Engineering process automation. ⦾ Ex: Github. ● Systems integration ⦿ Event driven architecture in Microservices. 10 Usages of Asynchronous APIs.
  • 11.
    ● HTTP Based ⦿WebSockets: client-server, bidirectional ⦿ WebHooks: server-server, unidirectional ⦿ WebSub: server-servers, unidirectional ⦿ Server Sent Events (SSE): client-server, unidirectional (server push) ⦿ GraphQL subscriptions: client-server, unidirectional ● gRPC: server-server, bidirectional ● Kafka: server-server, bidirectional ● AMQP: server-sever, bidirectional ● MQTT: client-server, bidirectional 11 Technologies being used to implement Asynchronous APIs
  • 12.
    ● Used todescribe Asynchronous APIs from a client’s perspective. ● A “client” can be either a publisher or a subscriber. ● Highly influenced by the OpenAPI specification. ● https://www.asyncapi.com/ ● Describes channels, messages and brokers. 12 The #AsyncAPI Specification
  • 13.
    ● By Consumers ⦿Discovery of all triggers in an organization. ⦿ Lack of a uniform subscription experience. ⦾ Caused by lack of adherence to a standard. ⦿ Unsupported protocol supported by Publisher. ● By Providers/Facilitators (not Publishers) ⦿ Securing Asynchronous APIs. ⦿ Rate limiting. ⦿ Ensuring adherence to contract. ⦿ Message processing/enrichment. ⦿ Monitoring and alerting. ⦿ Business insights. 13 Challenges faced when adopting Asynchronous APIs
  • 14.
    14 Have a DeveloperPortal for discovering events used by an organization Subscribers External Event Publishers Internal Event Publishers Register Register Developer Portal Discover
  • 15.
    ● For HTTPbased asynchronous APIs a hub architecture can be used to unify subscriptions. ● API providers subscribe the hub with the API. ● API consumers subscribe with the hub when/if they want to get notified on events. ● The hub redistributes events to everyone subscribed on the hub. 15 Using a Hub architecture for unifying subscriptions Subscriber 1 Subscriber 2 Portal Hub Events from the API received on the Hub Hub redistributes events to subscribers Subscribers discover APIs on the portal and subscribe at the hub
  • 16.
    ● In certainuse cases the clients wants to use a protocol that is not supported by the API. ● A hub can be used to convert the protocol to the requested type. This mostly works with HTTP based protocols. ● This also allows the client to use an appropriate security type for the protocol. 16 Protocol conversion and security Subscriber Hub Publisher sends events on a Kafka topic Subscriber uses appropriate security protocol supported by the hub. Subscriber receives events on a WebSocket Hub does a conversion from Kafka event to WebSocket frame
  • 17.
    ● An APIalways has a contract/spec. ● Subscribers expect event producers to send events that adhere to the contract. ● Subscribers would fail to process messages that do not conform to the contract. ● The Hub can be used as an enforcer of the contract. 17 Ensuring adherence to contract Subscriber Hub Different versions of the API submit events to the hub Hub only delivers messages that adhere to the contract Hub inspects message to check for conformance v1.0 v1.1
  • 18.
    ● Subscribers maynot be interested in receiving all events published by a producer. ● They may want to know about events when certain conditions are met. ⦿ When the average temperature goes beyond 70 degrees. ⦿ When a bid value goes beyond a limit. ● Hubs may support message aggregations, summarizations and processing. 18 Message processing and Enrichment Subscriber Hub Notify whenever someone places a bid on an item. Notify subscriber only if condition is met. Check if bid goes beyond $50.
  • 19.
    ● Certain eventproducers may be too chatty for the liking of the subscriber. ● The could expose these APIs over rate limit plans that suit the subscriber. ● These can be used as a way of monetizing APIs as well. 19 Rate limiting for reducing chattiness and monetization of APIs Subscriber Hub Producers sends all events to the Hub. Subscriber only receives events based on the usage plan. Hub rate limits based on subscribers usage plan.
  • 20.
    ● Provides organizationsinsights on Asynchronous APIs. ● Capture protocol specific usage attributes ⦿ Ex: WebSockets: Bandwidth, SSE: #events, WebHooks: Active Users. ● Detection of abnormalities and usage patterns. 20 Monitoring & Alerting
  • 21.