With the exponential rise in online communication and collaboration demand, many entrepreneurs and business teams are seeking to develop software applications that have some sort of real-time component.
Those same teams are increasingly moving to the cloud.
You can’t discuss the cloud without discussing AWS, the worldwide leader in cloud service providers, and you can’t discuss real-time applications that need to scale without considering Websockets (a preferred communication protocol).
But when you consider AWS Scaled Systems and Websockets together things get complicated.
We’ll dig in, but first let’s get some context out of the way: What are some practical uses for real-time applications? What factors should I consider when thinking about the scalability of my application idea? Why host my application in AWS? What are Websockets and why should I care?
And for the more technical-minded among us: When should I use Websockets vs. HTTP? How do I get websockets to work in a scaled system in AWS?
Practical uses for Real-Time Applications
If your application or software idea relies on instantaneous communication, visualization, and/or the need to sense, analyze, and act on data as it happens, then you need real-time.
- Chat Functionality
- Calendar, Appointment Scheduling
- Location-based tools
- Collaboration
- Real-time Feeds – likes, shares, notifications, etc.
- Data Visualization
- Multiplayer Games
- User Data – ie Click stream, error reporting
- Sports Updates
- Multimedia Chat
- Online Education
What factors should I consider when thinking about the scalability of my application idea?
- Usage
- Amount of Stored Data
- Required Speed
- Anticipated Demand Load Spikes
- User Experience
- Developer Hand-off
Why host in AWS?
While cloud-hosting provider choice depends on the project, for the sake of this conversation we’ll focus on AWS. Based on AWS’s size, power, flexibility, and that there is tons of customization and support for many third-party integrations it is often one of the main choices. Its also pretty cost-competitive, you pay for what you use. And, importantly, auto-scaling comes “out-of-the-box” in a way that requires less custom configuration, saving you time in the development phase of your project.
What are Websockets – and why should I care?
As discussed, the demand for real-time information – the millisecond it becomes available – has hit critical mass. If you have to refresh the page to get new information or the connection is slow, it’s already too late. Your user bails. In laymen’s terms, websockets is a web-based communication protocol that allows for two-way interactive communication session between the user’s browser/application and the server where the information/data is stored. Basic communication protocols, such as HTTP, technically only allow for one-way communication.
Example:
You are trying to build an app for restaurant reservations. Your developer uses HTTP, not Websockets. Both User A and User B are searching availability for a table at 7:00pm on Saturday, and there is just one table left.
Using an http communication protocol the flow would look something like this:
User A –> table available > books the table at 6:00:01 > success > connects to server for confirmation (pause to wait for response from server) > success
User B –> table available > books the table at 6:00:012 > success > connect to server for confirmation (pause to wait for response from server) > failure
Both users experience “success” booking the table because there is a lag between User A booking the table and User B finding out the table isn’t available. User B thought they had secured the reservation, only to find out they actually didn’t after the fact, leading to poor user experience with the app.
Using websockets it would look like this:
User A –> table available > books the table at 6:00:01 > success
User B –> table available > attempts to book the table at 6:00:012 > Sorry, table no longer available
User B finds out instantaneously that the table is no longer available, and can proceed with searching for other available tables versus thinking they have the reservation and waiting to find out they actually don’t. This is a more gratifying user experience.
While this is an overly simplified example, it illustrates how the bi-directional communication using websockets for 2 users attempting to secure the reservation for the same table from the server allows the user to see true real-time availability.
Determining whether to use WebSockets vs HTTP:
- Does your app involve multiple users who need to communicate with each other?
- Does your app need to work with server-side data that’s constantly changing?
If you answered yes to either of these questions, consider using WebSockets.
Image Source
How do get websockets to work in a scaled system in AWS?
While building a mobile app for a health startup who required real-time messaging and notifications in a multi-server AWS cloud environment we discovered that “out of the box” the AWS load balancer would not maintain websocket connections from several clients to multiple servers simultaneously. The app would communicate with the load balancer, but the default AWS load balancer wouldn’t communicate with the servers via websocket protocol. Instead of leaving our client hanging and passing it off to a network administrator to deal with the deployment concerns, we engineered a solution that we feel may assist many other devops teams when running into this issue. View the documentation here.