Building Real-Time Location Sharing with AWS AppSync Events
How I built a real-time location tracking app with AWS AppSync Events to help my pregnant wife know my whereabouts, using serverless WebSocket capabilities.
Published Jan 24, 2025
Ever had one of those moments where a personal need perfectly aligns with a new tech solution? That's exactly what happened to me recently. As an expectant father, I found myself in a situation many dads-to-be might recognize: my wife was anxious whenever I wasn't home, worried she might go into labor at any moment. "Where are you?" became the most frequently asked question in our household.
Instead of constantly sending "I'm here" messages, I thought, "Wouldn't it be great if she could just see where I am in real-time?" That's how Whubby (Where's my Hubby) was born – a real-simple, real-time location sharing app. And thanks to the newly launched AWS AppSync Events, building it was surprisingly straightforward.
AWS AppSync Events is a new AWS service that lets you create serverless WebSocket APIs for real-time data broadcasting. What caught my attention was its simplicity – a pure Pub/Sub functionality that scales automatically. Perfect for my use case where I needed reliable real-time communication without managing complex infrastructure.
A key architectural decision I made was to keep the solution completely stateless - no data persistence whatsoever. Why? Because for my use case, historical location data added no value. I only needed to know where someone was right now, not where they had been.
This "zero persistence" approach had several benefits:
- Eliminated the need for database resources
- Removed requirements for additional compute resources to manage data
- Reduced system complexity
- Improved performance by removing database operations
- Further lowered costs
The resulting architecture is impressively simple
The entire backend consists of a single AppSync Events API resource. Here's the complete SAM template:
This SAM template creates the AppSync Events API along with an API Key and a namespace. Namespaces define the capabilities of its channels. Our namespace defines the behavior of our Pub/Sub api when users publish messages or subscribe to channels through the
onPublish and onSubscribe event handler functions.The following code shows what happens when a user subscribes to or publishes an event to a channel.
A few things to note:
- I defined a function
isValidChannelto validate channels. For now, the validation is that the channel should start with the/track/namespace and that the trailing string should be 36 characters long, a very very rough approximation for it being a UUID V4. I kept it simple here for illustrative purposes of how you could authorize access to a channel. For production use-cases, you would off course want to improve upon that basic validation. - The
onSubscribefunction is used to check if the user is authorized to subscribe to a channel. This logic is encapsulated in a dedicated function. - The
onPublishfunction is used to both validate the payload and enrich it with additional data such as the current timestamp.
For the frontend, I used Nuxt3 hosted on AWS Amplify Hosting. I am leveraging the Amplify libraries to connect to my Pub/Sub API. First I needed to configure Amplify for it to work:
Subscribing to a channel on my frontend was as simple as:
In order to publish your location on your Pub/Sub API, the code is as follows:
That's it, I have now seamlessly integrated with my backend.
One of the beautiful aspects of this solution is its cost-effectiveness:
- $1.00 per million Event API operations
- $0.08 per million connection minutes
For context, if my wife and I used the app for 30 minutes every day for 1 full year, the solution would cost us less than 50 cents for the full year, this without even considering the free tier.
The serverless nature means you only pay for what you use, and with no persistent storage, there are no additional database or compute costs to consider.
Instead of implementing complex authentication, each trip generates a unique UUID V4. Unless someone has this UUID, they can't subscribe to the location updates. Since trips are short-lived and UUIDs are practically impossible to guess, this provides adequate security for our use case.
After deploying Whubby, my wife and I put it through its paces during those final weeks before our baby arrived. Here's a real screenshot from one of my trips back from the office:
In this screenshot, you can see my location (I have less hair than the cover image of this article suggested 😅) coming back from the office, while my wife (yellow marker) was at home. The real-time updates were smooth and reliable, with position updates every 5 seconds. The simplicity of the interface meant there was no learning curve - exactly what you want when dealing with pre-delivery stress!
What really struck me was how such a lightweight solution could provide such peace of mind. No complex features, no unnecessary bells and whistles - just a simple answer to the question "Where are you right now?"
Building Whubby taught me several valuable lessons:
- Sometimes the simplest solution is the best solution. No need for databases, complex authentication, or multiple services.
- Question every component in your architecture. Do you really need to persist that data? In my case, removing data persistence significantly simplified the solution.
- AWS AppSync Events is a game-changer for real-time applications. The ability to create scalable WebSocket APIs with minimal code is powerful.
- Ephemeral architectures can be perfect for real-time use cases where historical data isn't necessary.
- GenAI does not need to be part of every product, even in 2025 😁
- I could have used WhatsApp location sharing feature but it would have been less fun!
And most importantly, my wife felt much more at ease knowing exactly where her hubby was during those crucial final weeks. Sometimes, the best technical solutions come from solving personal problems with the simplest possible approach.