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 first, most feature-light, approach can be achieved using only javascript on the client and server with Express (a node.js application framework) and socket.io (send/receive messages in realtime). When a player creates a new game, a unique game url path will be provided to Express as the endpoint to open a scoped socket connection. The game client will send and receive messages as players join, take turns, and score/win/lose. For lightweight data persistence, localStorage can be used to store game and player data so a game can be rejoined and resumed after a broken connection, by reloading the url. At this point, it would be helpful to test the game on a remote domain. To do this, I'll create a simple stack with an ObjectStore and a CDN which will provide access to a stackery-stacks.io domain.

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

A solid starting point is the first approach -- relying solely on javascript and the browser for a simple and useable multiplayer experience. From there, advanced features can be prototyped and implemented without too much architectural sweat. Depending on desired behavior (e.g. varying responses to state changes), the Function code will require a range of effort but that's what's great about Stackery -- when architectural complexity becomes trivial, building behavior becomes central.