AWS Case Study 6 - Serverless Realtime Chat App

From static web pages to realtime apps?

During the early years of the world wide web, people didn't expect too much from web pages they visited.

They were feeling happy after they had found a web page containing some interesting piece of information.

That was around the year 2000.

Now we are in 2021.?

Times have changed and now users expect much more from websites.

They don't just expect the web pages to look good, they expect them to be smart and interactive.

And that includes being realtime.

What is a real time web app?

Realtime web apps are nothing more than apps running on a web that can react to changes that happen anywhere in a connected application’s system — not just to actions initiated by the current user. One of such examples is an instant messaging app.

Instant messaging is in fact the most common type of realtime app that was ever created.

According to the Statista, the number of messaging app users is predicted to reach 3 billion in 2022.?

What does that mean?

It means that without a doubt, people love instant messaging a lot.?

So why not create our own instant messaging app?

To push or to pull?

Building your own instant messaging web app can become a challenge.

First, you need to carry out the technological decision.

You need to decide how you are going to send the data from the server to the client and back.

There are multiple options to choose from, but in general all options are based on using one of these two approaches:?

1. Client pull - a communication style where the initial request for data originates from the client and then is responded to by the server. Pull is used extensively on the Internet for HTTP page requests from websites.
2. Server push - a communication style where the request for a given transaction is initiated by the server (publisher). It is contrasted with pull/get, where the request for the transmission of information is initiated by the client (receiver).?

Which one is better?

There are many discussions going on internet about this topic.

If your criterion is efficiency, then you should go for server push approach as as it provides a higher amount of efficiency compared to the client pull in which there is much higher HTTP request/response overhead for each message that is sent and received.

Realtime Chat App in AWS serverless?

Good news it that AWS provides you serverless webservices that can be used to address both client pull and server push approaches.??

If you want to implement an instant messaging app based on the client pull mechanism, the core technology that you are going to use is the Amazon API Gateway's REST API Endpoint.

If you want to implement the server push mechanism, then you are going to need the Amazon API Gateway's Websocket API Endpoint.

Server push based AWS serverless architecture

This is the example of how realtime chat app AWS serverless architecture may look like.

/click here to display the scheme in bigger resolution/

It consists of 2 layers.

1. Presentation layer is nothing else than just a static HTML page hosted at AWS inside AWS Lambda function and accessible via API Gateway's REST endpoint and Amazon CloudFront. This HTML page contains javascript code that asks user to enter his name and then initiates a Websocket connection to the API Gateway's Websocket API endpoint which is actually a part of the Realtime communication layer.
2. Realtime communication layer handles all incoming and outgoing Websocket requests via the Websocket API endpoint. Its core is the Websocket API endpoint and 41 lines of source code long Lambda function written in Node.js 14:

Websocket API endpoint is integrated with AWS Lambda function on all of its 3 routes:

• $connect - Lambda function triggered from this route stores Websocket connectionId in the DynamoDB table,
• $disconnect - Lambda function triggered from this route removes Websocket connectionId from the DynamoDB table,
• message - Lambda function triggered from this route receives a chat message, retrieves all connectionIds from DynamoDB table and sends the chat message to all clients (all connectionIds). Should any connectionId be invalid, it is removed from the DynamoDB table immediately.?

Final note

As you can see, my Realtime Chat App is from the feature perspective rather simple app.

It doesn't store any chat message history so in order for others to see your chat messages you should ask them to join you to exchange messages in realtime.

Also what is needed to mention, that all users of chat share the same discussion room and chat mutually between themselves.?

But would it expect more from application created just during 1 single weekend?

You can still extend it by yourself - I enclose all of its source code, you can find the link below..

Frequently asked questions

1) Let's talk about the costs. How expensive is the usage of Websocket API endpoint?

Communication costs via the WebSocket API as of today are just 0.95 EUR per each 1 mil. of processed requests (sent/received messages) per month.??

2) Why is the presentation layer hosted at AWS Lambda and not e.g. at S3? S3 is perfectly suitable for hosting static HTML files.

You are right. Simple Storage Service (S3) can serve the same purpose here and even could make the overall architecture look even less complex.?

I chose AWS Lambda and API Gateway approach just to demonstrate 2 different types of API Gateway endpoints in 1 architecture and also to demonstrate the less common approach of hosting static files in AWS (internet is full of examples how to use S3 for hosting static content).??

3) What if some portion of my website visitors are using legacy internet browsers or are behind very restrictive firewalls that either block or make WebSocket communication unreliable? Such users won't be able to use my web app and chat in realtime.?

If this is your case and you want your realtime chat app be available to as many users as possible then you should consider implementing a fallback mechanism.?

Mechanism that upon detection of unreliable websocket connection automatically switches communication from server push to the client pull approach.

Sure, technologically it is much more difficult to implement - but definitely worth if you don't want to limit any of your users from chatting using your app.

4) Does any other cloud provider offer similar solution to the Amazon's API Gateway Websocket API???

Yes, for example, Microsoft Azure. You can use its service called SignalR.?

5) Can you provide full instructions including the source code how to setup and configure this Realtime Serverless Chat app on AWS?

Yes, feel free to download my instructions.

6. Can I contact you in case I have questions or get stuck with the solution implementation?

Don't hesitate and contact me. You can reach me via my LinkedIn profile - I accept all requests to connect and will be glad to discuss AWS architectures with you.