Real time API can be achieved by Event Driven architecture
Nowadays Software is becoming more and more interconnected via APIs.
Interconnected system or software should be talking to each other. Traditional request-request API does not support much of this kind communication.
Event driven API architecture approach can achieve this.
I would say that “Real-time” or event driven API is becoming an ubiquitous in the modern application stack. As API consumers demands are for frequent data and auto response , more companies accelerating their product architecture to real time data providers.
Though we’ve seen APIs become an very important to product companies, they are typically based on request-response style interactions, which limits their scope and effectiveness for the real time architecture.
How Event-Driven APIs are different than Request-Response APIs ?
Basically request-response is, in which a requestor sends a request to a server. The server receives and processes the request, and if all goes well, it returns a message in response. This exchange format works well for most of structured requests
In an event-driven API architecture, applications integrate multiple services and products as equals based on event-driven interactions. These interactions are driven by event consumers and event channels. The advantage is that an event subscribers does not need to know when the event occured. Event driven API will invoke subscriber’s services and let them know about events
Event driven API or Event Driven Architecture is a type of software architecture where Events are defined at technical level and business level.
Those events gets triggered by specific actions or API calls and can be subscribed to via Webhook ( there are different technology you can use for webhook , like SignalR ).
Technical Level Webhooks / events
For example let say you have an application which constantly update the database and it is running on server. Now you want to get alert whenever databases updated.
In that case you can expose webhooks ,which trigger whenever event ( database update ) happen. Now each of subscriber who has subscribed to this webhook will get an alert about event.
Meaning whenever database update , webhook will trigger your subscribed url / application and alert you.
Business Level Webhooks/events
Let’s say you are making a healthcare app for dental practice , veterinary practices etc.. (check https://api.sikkasoft.com for how to build health care app ) you are likely going to have a dozen of services/webhooks that need to subscribe and inform your app clone stuff like :
- Next appointment in 30 min
- New appointment has been scheduled
- New patient record created
- Payment has been posted on patient account
Those are “Business Events” they are events defined by the architects and the team that build the product.
Others services will subscribe to them , user actions will trigger them.
I will describe my webhook design architecture in next post