Event Driven API paradigms

• 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.
• Pros
• Can stream over simple HTTP.
• Native browser for support.
• Cons.
• Bidirectional communication is challenging.
• Buffering.
• One way communication over HTTP.