Polling vs. WebSockets: Choosing with Amazon API Gateway โšก๏ธ


Hey Reader ๐Ÿ‘‹๐Ÿฝ

What would you use for quick and regular data updates inside your web app? Or let's phrase it another way: how would you choose between Polling and WebSockets? ๐Ÿ’ญ

Understanding the nuances between these two communication methods is important, as they both come with their own advantages, gotchas, and side effects that are not very obvious.

This issue aims to compare Polling and WebSockets, providing insights to help you decide which approach best suits your applicationโ€™s needs.

As always: weโ€™ve also provided a simple example app that you can deploy into your own AWS account with SST. It will bootstrap an Amazon API WebSockets Gateway, a few Lambda functions and a Next.js frontend to showcase real-time communication via WebSockets.

Now, letโ€™s dive deeper into the basics of Polling and WebSockets, how they work, and which solution is best for different approaches.

Understanding Polling

Polling is a technique where the client repeatedly requests data from the server at regular intervals. This method is often used to check for updates or changes in data.

There are two main types of Polling:

  1. โšก๏ธ Short Polling: The client sends requests to the server at fixed, short intervals. This can lead to unnecessary requests if the data hasnโ€™t changed, resulting in increased server load and bandwidth usage.
  2. ๐ŸŒ Long Polling: The client requests data from the server, and if no new data is available, the server holds the request open until new data is available or a timeout occurs. This reduces the number of requests compared to short polling and can be more efficient in terms of server load.

Both of these approaches can be used with SQS, for example, and can significantly affect your monthly charges.

Advantages of Polling include:

  • ๐Ÿ“š Simplicity: Polling is straightforward to implement and understand, making it accessible for developers. This is perhaps the most important advantage that should not be overlooked in any way, especially considering how complex distributed systems have become over the years.
  • ๐Ÿ”€ Compatibility: It works with any web technology or stack and does not require any special protocols or configurations.

But now to the drawbacks:

  • ๐Ÿ”ด Inefficiency: Short polling can cause many unnecessary requests, using up bandwidth and server capacity. For small-scale applications, this might not be important, but as the scale grows, it can become a real bottleneck.
  • ๐Ÿข Latency: There can be a delay in receiving updates, especially with short polling, as the client only checks for new data at set intervals. This can result in a less responsive user experience compared to real-time communication methods like WebSockets. From many case studies, weโ€™ve learned that the threshold for latency in customer satisfaction is very low. For more details, check out the DynamoDB whitepaper, where Amazon explains how even a small increase in latency can significantly impact sales.

In summary, polling is simple and easy to use, but it can create potential bottlenecks and does not provide real-time communication.

Exploring WebSockets

WebSockets are a communication protocol that provides full-duplex communication channels over a single, long-lived connection between a client and a server.

This means that both the client and server can send and receive messages simultaneously, allowing for real-time data exchange.

With WebSockets, data can flow freely in both directions without the need for repeated HTTP requests. This is achieved through a single handshake process, after which the connection remains open, enabling continuous data exchange.

Benefits of WebSockets include:

  • โšก๏ธ Real-time Data: WebSockets allow for instant data transmission, making them ideal for applications that require real-time updates, such as chat applications, live sports scores, or online gaming.
  • ๐ŸŸข Efficiency: By maintaining a single open connection, WebSockets reduce the overhead associated with establishing multiple HTTP connections, leading to more efficient use of resources and lower latency.

Potential challenges are mainly about ๐Ÿ“š Complexity. Implementing WebSockets is more complex than simple HTTP polling. It requires extra work for managing connections and handling errors. Even with helpful tools like Amazon API WebSocket Gateway, setting up WebSockets for real-time communication is not an easy task.

Very rarely you could potentially fight with Compatibility Issues. While WebSockets are widely supported in modern browsers, there may still be issues with very old browsers or certain network configurations that do not support WebSocket connections.

Amazon API Gateway Support

Amazon API Gateway supports both Polling (REST or HTTP Gateway) and WebSockets, so you can choose what fits best for you.

For Polling, API Gateway can be used to create RESTful APIs that clients can call at regular intervals to check for updates. This is suitable for applications where real-time updates are not critical, and the simplicity of implementation is a priority (that should always be a priority!). A common use case within AWS for polling is integrating with services like Amazon SQS, where a client periodically checks for new messages in a queue.

For WebSockets, API Gateway provides a WebSocket API that enables real-time, two-way communication between clients and servers. This is ideal for applications that require instant data updates, such as chat applications, live notifications, or collaborative tools.

Conclusion

Polling and WebSockets are two different ways to handle data exchange in web apps, each with its pros and cons.

Polling is straightforward and works with any web tech, making it easy to set up. However, it can be inefficient and cause delays, especially in big applications.

WebSockets, on the other hand, provide real-time data transfer and efficiency by keeping a single connection open, but they can be more complex to implement.

The right choice depends on what your app needs. If you need real-time updates, WebSockets might be the way to go. For simpler apps where real-time isnโ€™t a priority, Polling could work just fine.

Try both methods with Amazon API Gateway to see which suits your needs best!

P.S.: don't forget to jump into the actual code ๐Ÿ‘พ and try it out yourself โœŒ๏ธ

โ€‹

โ€‹

โ€‹Tobias Schmidt & Sandro Volpicella & from AWS Fundamentalsโ€‹
โ€‹
Cloud Engineers โ€ข Fullstack Developers โ€ข Educators

You're receiving this email because you're part of our awesome community!

If you'd prefer not to receive updates, you can easily unsubscribe anytime by clicking here: Unsubscribe

โ€‹

Our address: Dr.-Otto-BรถรŸner-Weg 7a, Ottobrunn, Bavaria 85521

AWS for the Real World

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

Hey Reader ๐Ÿ‘‹๐Ÿฝ This issue will be about a recent real-world experience that just went off right with the new year! ๐ŸŽ‰ Once upon a time... ๐Ÿฆ„ It all started in September 2024 where Edgio, the main CDN provider we used for one of my large enterprise projects, filed for bankruptcy. Edgio was natively integrated into Azure, allowing you to use it without leaving the Azure ecosystem. It also featured a powerful rules engine (allowing for all kinds of conditions, redirects and rewrites) and didnโ€™t...

โŒ› Reading time: 13 minutes ๐ŸŽ“ Main Learning: How to Run Apps on Fargate via ECS ๐Ÿ‘พ GitHub Repository โœ๏ธ Read the Full Post Online ๐Ÿ”— Hey Reader ๐Ÿ‘‹๐Ÿฝ When building applications on AWS, we need to run our code somewhere: a computation service. There are a lot of well-known and mature computation services on AWS. Youโ€™ll often find Lambda as the primary choice, as itโ€™s where you donโ€™t need to manage any infrastructure. You only need to bring your code - itโ€™s Serverless โšก๏ธ. However, more options can be...

โŒ› Reading time: 10 minutes ๐ŸŽ“ Main Learning: Running Postgres on Aurora DSQL with Drizzle ๐Ÿ‘พ GitHub Repository โœ๏ธ Read the Full Post Online ๐Ÿ”— Hey Reader ๐Ÿ‘‹๐Ÿฝ With re:Invent 2024, AWS finally came up with an answer to what many people (including us) asked for years: "What if there were something like DynamoDB but for SQL?" With Amazon Aurora DSQL, this is finally possible. Itโ€™s not just a โ€œscales-to-zeroโ€ solution like Aurora Serverless V2. It is a true distributed, serverless, pay-per-use...