Real-time communication between services or people is tricky to implement.
Thankfully, in the day and age of cloud computing, we have multiple options that one might use to implement reliable WebSocket-based communication.
In this blog post, I will be talking about WebSockets in the context of AWS. What are the options? What are their pros and cons? What kind of architectures could I deploy with each?
Let us find out.
Amazon API Gateway WebSockets
In the December of 2018, AWS announced a new capability of Amazon API Gateway – WebSockets support.
I remember being pretty excited about the addition. Since my go-to for learning a new programming language is a chat application (I find the TODO style applications a bit boring), I immediately jumped into the service documentation to learn more.
Cons
My enthusiasm quickly faded after reading the documentation.
Very sub-optimal support for broadcast behavior. To my best knowledge, there is no way to natively send a message to multiple connections with a single API call. The lack of native support for topics or rooms makes Amazon API Gateway WebSockets a lesser choice when a broadcast functionality is required.
The state of individual connections needs to be somehow tracked. Usually, in my experience, developers tend to use Amazon DynamoDB to do so. If you are on the lookout for a completely managed solution, you might be a bit disappointed.
Pros
It is not all bad, though.
Since you most likely already take advantage of Amazon API Gateway, the complexity of adding WebSockets to your architecture is greatly reduced.
With the Amazon API Gateway direct integrations capabilities, one might create elaborate and resilient WebSocket backend without needing AWS Lambda functions. I took on that challenge myself. Here is the result.
The capability has relatively few moving parts and, in my opinion, is very approachable and a blast to learn.
Architectures
I would argue that the Amazon API Gateway WebSockets is an excellent alternative to pooling. Depending on the traffic your service gets, it might be cheaper to maintain a WebSocket connection rather than making periodic requests to the API. Here is an excellent resource on this subject.
AWS AppSync GraphQL subscriptions
AWS AppSync is a service that enables you to create managed GraphQL APIs. The service is rapidly gaining popularity as GraphQL enters the engineering mainstream.
The real-time functionality is exposed through GraphQL subscriptions. Since explaining what GraphQL subscriptions is out of scope for this article, I encourage you to do some exploration on your own if you are not familiar with the term.
Cons
In my humble opinion, there are a lot of gotchas that you might encounter on your implementation journey. Here is a great article that touches on this subject.
On the frontend side of things, you might encounter issues with integrating the AWS AppSync JavaScript client with one of your GraphQL client libraries. As of writing this, there is a lot of issues on GitHub related to integration with my favorite GraphQL client – the apollo-client.
This might be obvious at this point, but I still want to bring it up. To my best knowledge, the functionality is only available in the context of GraphQL. It would be very nice to have a non-GraphQL specific version of AWS AppSync subscriptions. On the other hand, maybe such a service already exists? Read on to find out!
Pros
Holy moly, you can get a lot done with AWS AppSync. If things work, the service will save you a lot of time. In my humble opinion, the basics are easy to grasp, and if you are familiar with GraphQL already, you should have an easy time grasping how AppSync subscriptions work.
The AWS AppSync subscriptions scale very well. According to AWS you should have no problems scaling to millions of connections. Speaking from my experience, I was able to push the service to about 500k connections without any issues.
Architectures
There are so many choices when it comes to AWS AppSync. The service lends itself very well to almost, if not all, situations where GraphQL subscriptions are a requirement.
My advice would be to get acquainted with AWS AppSync use cases section of the service page.
AWS IoT Core MQTT
When I first heard about the AWS IoT suite of services, the last thing that came to my mind was rich and extensible support for WebSockets. Learning more, I was pleasantly surprised to discover that the service exposes completely managed MQTT topics.
Cons
To understand the WebSockets capabilities fully, one needs to get familiar with many service-specific moving parts. What is a device shadow? Do I need some kind of certificate for authentication purposes? What is data endpoint? These are some of the questions I asked myself while trying to figure out how the service works.
It might be that I live in my own "community bubble", but I have not seen a lot of teaching materials regarding utilizing WebSockets using AWS IoT Core. You might find it challenging to find answers to your questions. Here is the blog post I was referring to while playing with the service.
Pros
WebSockets via AWS IoT Core MQTT are independent of API architecture. Are you rocking your own GraphQL server? or maybe you prefer REST APIs? In either case, it is possible to integrate with IoT Core MQTT. Remember me alluding to non-GraphQL specific service for handling WebSockets? This is the service I was referring to.
Architectures
Anything related to IoT is not my area of expertise. That did not stop me with experiments, though.
I believe that AWS IoT Core MQTT could be used for real-time frontend feature toggles. Integrating your frontend with the service should be hassle-free because of the AWS Amplify plugin. Here is my attempt at building real-time frontend feature toggles with AWS IoT Core.
Conclusions
Developers have many options when it comes to serverless WebSockets on AWS – from GraphQL specific service to arguably surprising usage of AWS IoT Core MQTT topics.
I hope that by reading this article, you have learned something new. I intended to provide basic information about each service and encourage you to explore further on your own.
Comments