Framework Choice Meets Problem Size
Jade Kharats is building a suite of self-hosted team tools under the banner of Happy. The project's core tenet is a deliberate departure from convention: each tool employs a distinct framework. The goal is to demonstrate that framework selection should be dictated by the specific problem's scale and requirements, not by developer habit or ecosystem inertia. The first tool to emerge from this experiment is Moving Motivators.
Moving Motivators is designed for facilitated team sessions. A facilitator initiates a session, and participants join using a short code. Crucially, each participant privately ranks ten motivation cards. Only when all participants are ready does the facilitator trigger a reveal, displaying all rankings side-by-side for group discussion. This interaction model highlights two critical properties: ephemerality and server-enforced privacy.
Ephemeral State, No Database
The Moving Motivators application eschews traditional persistence. Its state lives entirely in memory and is designed to be ephemeral. Sessions automatically expire after a few hours and are garbage collected. This design choice eliminates the need for a database, an Object-Relational Mapper (ORM), and database migrations. By keeping state in RAM, the application significantly reduces operational complexity and potential points of failure associated with persistent storage. This approach is akin to a highly organized assistant who remembers everything you told them during a specific meeting but forgets it all when the meeting concludes.
Privacy as a Server Invariant
The more compelling technical challenge lies in enforcing privacy. In Moving Motivators, a participant's rankings must remain hidden from other participants until the facilitator initiates the reveal. This is not a UI-level obfuscation; the server itself must never expose individual rankings to unauthorized parties. This architectural constraint transforms privacy from a client-side concern into a fundamental server invariant. The application must be architected such that the server inherently prevents the leakage of sensitive information before the designated reveal event.
The Role of Crystal and Kemal
To implement these properties, Kharats selected Crystal for the programming language and Kemal as the web framework. Crystal, known for its C-like performance and Ruby-like syntax, offers the speed and concurrency necessary for real-time applications without the garbage collection overhead of languages like Ruby or Python. Its static typing also aids in catching errors early in the development cycle.
Kemal, a minimalist and high-performance web framework for Crystal, provides the tools to build the web application efficiently. Its focus on performance and simplicity aligns well with the project's goals of creating lightweight, focused tools. For a real-time application like Moving Motivators, Kemal's ability to handle concurrent connections and manage WebSocket communication is essential. WebSockets enable the real-time updates required for participants to see the synchronized reveal of rankings without manual page refreshes.
Architecting for Server-Side Privacy
Implementing server-enforced privacy in a real-time application involves careful management of connection states and data access. Each user connection is associated with a specific session. When a user submits their rankings, this data is stored server-side, linked to their unique session ID and potentially a user token if authentication were involved (though for this ephemeral tool, session codes suffice). The server then acts as the gatekeeper. It only broadcasts aggregated or revealed data to all connected clients in a session when the facilitator triggers the reveal action. Individual client requests for ranking data before the reveal are met with an empty or placeholder response, ensuring the server never sends the sensitive information.
This approach contrasts sharply with systems that might rely on JavaScript on the client to hide data. In such scenarios, the data is already sent to the client, and a malicious user could potentially intercept or manipulate it. By contrast, the server in Moving Motivators simply does not possess the data in a broadcastable state until the reveal. This makes the privacy guarantee robust and independent of client-side security measures.
Implications for Real-Time Development
The Happy project, and Moving Motivators in particular, offers a compelling case study for developers building real-time, privacy-sensitive applications. It demonstrates that by carefully choosing the right tools—Crystal for performance and Kemal for efficient web development—and by architecting with core principles like ephemeral state and server-invariant privacy, complex features can be implemented with relative simplicity and high confidence.
What remains to be seen is how this philosophy scales to more complex tools within the Happy suite. If subsequent applications require more persistent data or intricate user management, the decision to forgo databases entirely might become a constraint rather than an advantage. However, for the specific problem of collaborative, time-bound, and privacy-critical activities like Moving Motivators, this approach offers a potent and elegant solution.