NextJs Developer for Stream Chat

We need an experienced Next.js developer to build the frontend for real-time 1:1 messaging in Talynto, a contractor-hiring platform. Clients message contractors, contractors message clients, and admins message either. **The backend is finished, tested, and documented** — Stream Chat is fully integrated server-side, and the API contract is stable. This engagement is frontend only. The UI is also already built: the messages screen exists as pixel-faithful, mockup-matched components (contact list, conversation panel, message bubbles, composer, date dividers). **It is currently wired to hardcoded placeholder data.** Your job is to make it real, without changing how it looks. ## Stack | | | |---|---| | Framework | Next.js 16 (App Router), React 19 | | Language | TypeScript, `strict: true` | | Styling | Tailwind v4 (CSS-first config, no `tailwind.config`) | | Validation | Zod — every API response is schema-parsed, no `as` casts | | Chat SDK | `stream-chat` (headless JS client) — **not** `stream-chat-react` | | Backend | .NET API (separate repo, no changes needed) | ## The core challenge This codebase is **100% server-first**. There is no SWR, no react-query, no axios, and no client-side `fetch` anywhere today. Data is loaded in Server Components, mutations go through Server Actions, and the auth token lives in an httpOnly cookie that browser code cannot read. Real-time chat is inherently a stateful, long-lived client connection. **You will be introducing the first genuine client-side data layer into this codebase**, and the main thing we care about is that you do it without eroding the existing architecture — server-rendered where it can be, client-side only where realtime genuinely requires it. We deliberately chose the **headless** Stream SDK over the prebuilt React UI kit so the existing design survives exactly as-is. The trade-off is that message paging, unread counts, read state and presence are yours to implement rather than getting them from vendor components. If you'd rather drop in `stream-chat-react` and restyle it, this isn't the right engagement. ## Scope of work 1. **Connection layer** — a session-gated Route Handler that proxies the backend's chat-token endpoint, plus a client provider that connects to Stream and holds the connection. Tokens expire, so it needs a `tokenProvider` that refreshes cleanly. Must be safe under React 19 StrictMode (double-invoked effects must not open duplicate connections). 2. **Contact list** — server-rendered from the API for names/avatars/roles, with realtime overlay from Stream for last-message previews, unread badges and online presence. 3. **Conversation** — live message history with scrollback paging, realtime receive, send with optimistic rendering and a failed-send state, and marking the channel read. 4. **Entry points** — roughly 13 "Chat Contractor" / "Chat with Client" buttons across the app currently go nowhere useful. Wire them so they open the right conversation, project-scoped where a project is in context. 5. **Admin messaging** — an admin-facing messages screen, replacing the current "coming soon" placeholder. Reuses the same components. 6. **Notification integration** — clear a sender's unread message notifications when their conversation is opened. 7. **Bug fixes** — a handful of small, already-diagnosed schema and routing defects (documented). ## Explicitly out of scope File attachments · typing indicators · message reactions · threads · message search · group channels · any backend or .NET work · any redesign (the visual design is fixed and must be matched). ## Required experience - **Next.js App Router, in depth.** Server vs Client Component boundaries, Server Actions, Route Handlers, `revalidatePath`. This is the single most important skill — a candidate who treats it like a plain React SPA will produce the wrong architecture. - **TypeScript under `strict`**, comfortable with Zod-validated boundaries. - **A realtime/WebSocket SDK in production** — Stream Chat ideal, but Ably, Pusher, Firebase or socket.io experience transfers. Specifically: connection lifecycle, reconnection, event subscriptions, and cleanup. - **Tailwind**, and the discipline to match an existing design precisely rather than reinventing it. - Understanding of why an auth token stays in an httpOnly cookie and never reaches client JS. **Nice to have:** prior Stream Chat work; experience retrofitting realtime into a server-rendered app; React 19 / RSC familiarity.