Thelegroum

A real-time messaging product experiment that separates durable conversation state from live delivery signals.

Role: Independent web product developer
Outcome: Delivered a public real-time messaging experiment with a live demo, source repository, and real product screen.
Status: Public real-time product experiment

This is an independent experiment, not a client case. No production reliability or usage metric is claimed.

Project access

Open live demo Inspect source

Outcome

Context and why it mattered

A messaging interface feels broken when a fast event cannot be reconciled with durable data or a responsive shell.

Outcome

Problem

Messaging needs both an authoritative conversation history and fast live updates across active clients.

Delivery detail

Constraints

Authentication, conversation membership, writes, reads, and live events must agree about the current user and conversation.

Authentication, conversation membership, writes, reads, and live events must agree about the current user and conversation.

Delivery detail

Role and scope

The live demo and public repository support independent implementation; no external team role is inferred.

Responsibilities

Authenticated conversation shell
Conversation and message persistence
Live Pusher event delivery
Responsive desktop and mobile navigation

Included in scope

Authenticated conversation shell
Conversation and message persistence
Live Pusher event delivery
Responsive desktop and mobile navigation

Outside scope

This is presented as a product experiment, not a client engagement.
No production load, delivery-latency, or active-user metric is published.
Only one registered product screen is available.

Delivery detail

Model users and conversations

The data model establishes durable users, conversations, messages, and membership relationships.

1
Model users and conversations
The data model establishes durable users, conversations, messages, and membership relationships.
- tg-schema
- tg-repository

Step outputs

tg-schema
tg-repository

Delivery detail

Resolve authenticated reads

Server-side actions load conversation state for the current authenticated context.

1
Resolve authenticated reads
Server-side actions load conversation state for the current authenticated context.
- tg-actions

Step outputs

tg-actions

Delivery detail

Persist before broadcasting

Message routes create durable records, then publish live events to subscribed clients.

1
Persist before broadcasting
Message routes create durable records, then publish live events to subscribed clients.
- tg-message-route
- tg-pusher

Step outputs

tg-message-route
tg-pusher

Delivery detail

Adapt the conversation shell

Desktop sidebars and mobile navigation keep the same conversation model usable across viewport sizes.

1
Adapt the conversation shell
Desktop sidebars and mobile navigation keep the same conversation model usable across viewport sizes.
- tg-screen

Step outputs

tg-screen

Delivery detail

Real messaging interface

Confirms the responsive product surface tied to the source.

Real messaging interface

Confirms the responsive product surface tied to the source.

Delivery detail

Public product source

Exposes the data, route, action, and live-event layers for technical review.

Public product source

Exposes the data, route, action, and live-event layers for technical review.

Delivery detail

Conversation data model

Defines the durable relationship between users, conversations, and messages.

Conversation data model

Defines the durable relationship between users, conversations, and messages.

Delivery detail

Server-side conversation reads

Keeps authenticated data loading close to the server context.

Server-side conversation reads

Keeps authenticated data loading close to the server context.

Delivery detail

Message write route

Shows the boundary where a message becomes durable state.

Message write route

Shows the boundary where a message becomes durable state.

Delivery detail

Live event adapter

Separates live notification transport from the persisted message record.

Live event adapter

Separates live notification transport from the persisted message record.

Engineering detail

Architecture

Next.js server actions and API routes use Prisma for durable conversation state and Pusher for live client updates.

Responsive client

other

Conversation UI

Next.js server

other

Actions, routes, auth

Prisma data layer

other

Durable messages

Pusher channels

other

Live delivery signal

client → next · read / write
next → database · persist
database → events · publish after write

Engineering detail

Keep persistence authoritative and events transient

Situation: A live event is fast but cannot be the only history of a conversation.
Decision: Write the message through Prisma, then notify subscribed clients with Pusher.
Reasoning: The database remains recoverable truth while Pusher improves immediacy.
Cost / trade-off: The application must reconcile event delivery with already-persisted state.

Alternatives considered

Event-only messaging
Polling persisted messages
Persist then publish a live event

Engineering detail

Use server actions for reads and routes for writes

Situation: Conversation pages need server-context reads while client interactions need explicit mutation endpoints.
Decision: Load authenticated conversation data through server actions and mutate through dedicated routes.
Reasoning: The boundary follows how each operation is consumed by the product shell.
Cost / trade-off: Data access conventions are split across two server patterns.

Alternatives considered

All client-side fetching
One generic API for reads and writes
Server actions for reads, API routes for mutations

Engineering detail

Adapt navigation without changing the conversation model

Situation: A sidebar-heavy messaging layout does not fit the same way on small screens.
Decision: Keep shared conversation content and adapt the surrounding navigation by viewport.
Reasoning: The same durable conversation model remains usable without duplicating product logic.
Cost / trade-off: Responsive state and navigation transitions add interface complexity.

Alternatives considered

Desktop-only shell
A separate mobile product tree
Responsive sidebar and mobile navigation around shared content

Outcome

Result

Delivered a public real-time messaging experiment with a live demo, source repository, and real product screen.

Engineering detail

Reflection

For real-time work, an architecture trace can be stronger proof than another uncaptioned screen.

Lessons

Real-time delivery should complement—not replace—durable product state.
Responsive messaging UX is a navigation problem as much as a layout problem.

Next steps

Add delivery-state and reconnect handling tests.
Instrument message latency before making any performance claim.
Document authorization checks at every conversation boundary.

Published content

Claim boundary

This is an independent experiment, not a client case. No production reliability or usage metric is claimed.