Event driven paradigms and needed for following reasons
A client wants to check status of resource. It will have to make regular request to API until it gets desired resource status. This is highly inefficient design.
The client regularly polls to check the status of the resource at defined intervals.
A lot of resources will be wasted both at client side and server side if the delay in changing status is too long.
Event driven API’s help in solving this kind of inefficiency.
There are three ways of building event driven Apis.
Web Hooks.
The client registers with web hook, API Provider.
Client provides The Events which it is interested to listen too and callback url which the provider sends updates too.
The URL is an end point, that the client exposes to the web hook provider on which it can provide updates too.
Whenever the event occurs, the provider sends a post request on the URL, exposed by client along with relevant information.
For examples, we can register to email event Web hook of Send Grid mailing system and get information of events like mail Bounce etc.
So instead of polling for status of each email, we can specify a web hook where send-grid can send us failure updates.
Challenges
Ensure delivery of success of event through retries at endpoint.
Apps, running behind, firewall can send, but receiving can be tricky.
Typically each web hook represents a single event. Many events in a short time can be noisy.
Trigger the server to send an Events to predefined client endpoints.
Building a web hooks system.
We can integrate or call external services or systems using this.
This allows us to decouple and make our system more resilient.
For example, we can have a separate system for placing an order and a separate system for changing its state.
Web hook adds an extensibility point to integrate with consumers.
We have producer of events and a consumers of events.
Now, if any one of the consumer fails or there is a delay in HTTP response then there will be latency in all the services as same process is sending to all.
We can solve this By fanning out the response from message Broker.
We can push the message received from Queue back to Another queue/queues based on the subscribers of the message.
We can independently consume each of those messages from respective queues and send them to respective consumers.
In AWS we can use a Web-hook service to Poll messages from SQS and then send them back to SNS topics based on subscribers from where it can be sent to subscribers subscribed to topic.
Web sockets
Web socket is a full duplex communication channel over creating an interactive web applications.
HTTP are Unidirectional channel comparatively.
Used basically in applications like life feeds, scores which required bidirectional communication.
We use web circuits over STORM.
STORM is, simple or streaming text oriented message Protocol.
Provides us with basic functionalities like connect, send, subscribe, etc.
We can connect to server send messages and subscribe to messages.
Client sends handshake http request to server.
Server acknowledges HTTP request and sends a upgrade response.
Client wants to access the web socket API of server.
The server responds yes lets communicate through Web sockets.
The client and server, then upgrade their communication to a long lived. TCP communication.
With this communication, both client and server can communicate bidirectionally.
Chat, communication, application uses web sockets where the client sends messages at Will and the server updates all the other members involved in a chat.
Building a chat application, using request/response APIs would be highly inefficient.
Benefits.
By directional low latency communication.
Reduced overhead of HTTP requests.
Cons
Clients are responsible for connections.
Scalability challenges.
Bidirectional communication between clients and servers.
Http Streaming.
In a regular request the server returns, a HTTP response of finite length. It is possible to make it definite.
The server continues to push data in a single long lived environment.
Client send the request to server and cyber response indefinitely so that server can send more and more data.
There are two ways in which server can send data.
Send transfer encoding header to chunked, this indicates that the client date will be arriving in chunks. This option can be used. By non-browsing clients so essentially communication between two micro services can use this.
Stream data via server sent events. Good for clients using browser they can use the standard event source API web interface example Twitter.
No comments:
Post a Comment