dependencies
45
Back to Projects
Project Detail
SocialHub Frontend
A TypeScript Next.js (App Router) client application that provides a real-time social feed, commenting, reactions, and group/private messaging by consuming a GraphQL backend (queries, mutations, subscriptions). It offers file uploads (Clou...
Frontend EngineerDuration: 3 monthsType: platform
Key Achievement Metrics
Architecture View
Processing state: architecture signal graph is initializing...
Decision Log
Token Storage & Rotation (accessToken in client store, refreshToken in localStorage)
Simpler client-side logic, immediate access to the short-lived token for attaching to outgoing requests, and a persistent refresh token across page reloads.
Trade-off: LocalStorage exposes the refresh token to XSS risks and is less secure than HttpOnly cookies; however it simplifies WebSocket authentication and reconnection logic.
HTTP + WebSocket split link for GraphQL
Low-latency real-time events for chat; preserves existing query/mutation semantics and Apollo cache.
Trade-off: More complex client setup, need for client-only code (window access), and additional connection management.
Client-side direct uploads to Cloudinary (XHR + unsigned preset)
Faster UX, offloads file transfer to Cloudinary, enables client-side progress bars.
Trade-off: Exposes upload preset and requires careful preset configuration; server-side signed uploads would be more secure but require an extra signed endpoint.
Architecture Narrative
Challenge
Delivers a responsive, low-latency social UI that synchronizes user presence and messages in real time while keeping client state consistent across views and network transitions.
Solution
client-server single-page application with server-rendered entry points (Next.js App Router) and real-time event streaming via GraphQL subscriptions (WebSockets).
Result
Key measurable signals: dependencies (45).
Trade-off Matrix
| Dimension | Selected Option | Impact | Compromise |
|---|---|---|---|
| Token Persistence | accessToken in-memory (Zustand) + refreshToken in localStorage | Simple implementation; works with WS connectionParams and client reconnections | Higher XSS risk vs HttpOnly cookie approach |
| Realtime transport | graphql-ws (WebSocket) with Apollo split link | Low-latency bi-directional events for chat and presence | More operational complexity and scaling requirements vs polling or server-sent events |
What I'd Do Differently
+
Move refresh tokens to an HttpOnly, Secure, SameSite cookie and implement refresh-token rotation server-side to minimize XSS exposure and make token handling compatible with HTTP-only cookie semantics for WS (signed cookie exchange or short-lived access tokens).
+
Add centralized observability: integrate Sentry (error tracing) + Prometheus/Datadog for request/WS metrics and RUM to measure real user latency and error rates. Also add server-side rate-limiting for uploads and abusive patterns.