Wedding Ready

Engineering

Architecture

I adopted a layered architecture for Wedding Ready so each part of the stack owns a clear concern: UI rendering, request boundaries, business operations, and data access/definitions. The goal is to keep ownership boundaries explicit as the product grew, so complexity stays manageable.

The /feed route shows how this works in practice:

• Proxy gate: JWT-based authentication is enforced before route rendering, so unauthenticated users are redirected before the server loads /feed.

• Server-rendered route shell (RSC): /feed uses React Server Components, handles Suspense and error boundaries around the interactive feed client.

• UI components (tiles): tile cards stay presentational ('dumb') with no business logic, so they remain reusable across different contexts.

• Client boundary (feed client + useFeed): owns interaction state and client orchestration, not business rules.

• Server boundary (API endpoint): handles authentication, request parsing/validation, and invokes operations.

• Operations layer: enforces authorization and maps raw model/database outputs into safe response DTOs before returning data to the client.

• Data layer: performs typed retrieval using precomputed ranking signals (recency, quality, social) and updates delivery/view state so duplicate tiles are not returned to the feed.

This separation lets me change ranking logic or retrieval strategy without rewriting UI components. On /feed, the API returns ranked tiles and the client pre-hydrates save-state cache entries in the same pass, avoiding N+1 per-tile save-state requests while preserving isolated save/unsave mutations.

The Problem

Wedding Ready depends on fresh tiles from suppliers, and tiles are most useful if credited accurately. The original one-step upload had a poor UX for supplier crediting and would be a bottleneck for planned features. I also wanted to avoid a naive implementation that would cause unnecessary re-renders and make typing/search feel laggy once there are several tiles in the batch.

What I Built

A client-side refactor of the supplier upload flow at /suppliers/[handle]/new:

• Batch add up to ~10 images into a single upload session

• Configure each tile in two steps: basic details -> crediting suppliers

• Upload and delete per tile (no draft persistence; safe to lose state on refresh)

Separation of Concerns

The core design goal was clear ownership. Each layer owns a narrow responsibility:

• UploadProvider owns the batch file list, stable uploadIds, and object URL lifecycle (add/remove/cleanup). It does not own form state or mutations.

• UploadPreviewItem owns one tile's lifecycle: build payload, run the upload mutation, show progress, and remove the item from the batch on success.

• UploadPreviewForm owns form state (React Hook Form), step state, and credit rows via useFieldArray.

• Each credit row owns its own supplier search input (debounced query + shared cache by search term).

Preventing Unnecessary Re-renders

I treated re-render strategy as a first-class requirement:

• Stable keys: `uploadId` per tile card and `field.id` per credit row keep component identity stable.

• High-frequency actions (typing, supplier search) stay local to a single card/row.

• List-level updates only happen on low-frequency events (add/remove/clear files).

Outcome

• Suppliers can batch upload multiple tiles and credit other suppliers without a clunky, error-prone form.

• Each tile upload is isolated: one failing tile does not break the entire batch.

• The flow stays extensible as requirements grow (more metadata, moderation, ranking signals).