Prototyping Serverless Applications
When starting a prototype, it’s easy to get lost in the weeds before anything is built. What helps me before writing code is to outline a build plan that clarifies: What is the simplest approach to build an initial concept? What valuable features reach beyond the basics? How can they be progressively implemented? What architectural resources will be required for each stage?
For instance, I’m building a prototype for a browser-based multiplayer game that tracks player connections, turns, and scores in realtime. To initialize the game, a url will be generated by the “host” player, which will open a socket connection scoped to the url’s unique path. The url serves as the entry point for other players to join the game. A socket connection will enable bi-directional messages to be sent and received between client and server when a new player joins, a player takes their turn, or the game ends. I scoped three build strategies, from feature-light to most-robust – using Stackery to prototype, simplify, and expedite the heavy-lifting.
The next strategy adds data persistence, beyond localStorage capabilities, that can store user data (profiles), joinable game urls (lobby), and game scores (leaderboards). To quickly prototype these features without much overhead (especially for a frontender like me), it’s Stackery to the rescue. It’s quick to spin-up a Rest Api that will receive user and game data, then send it to a Function node that will pipe it into a Table.
The third, and most robust, implementation adds another Function node to the pipeline above to enable a multitude of user notification potential. When a Table connects its output to a Function, changes in state can be detected by the Function using the transaction events it receives from the Table. The Function can then notify users accordingly, in various ways:
- Email an invite for another player to join a game
- Notify a player when it’s their turn
- Email a player when their highest score is defeated on the leaderboard