Fetching Specific Products

Lesson: Fetching Specific Products

Welcome back! 👋 Up to now, you’ve built the products collection endpoint : GET /api/products for listing/search with pagination, and POST /api/products for creating products with careful validation and conflict handling. In this lesson, we add the next essential building block: fetching one specific product by ID . This is the endpoint a product details page relies on—when someone clicks a product in a catalog view, the client needs a precise, predictable way to fetch that single record. Even though this endpoint is “small,” it forces you to be very clear about input validation, not-found semantics, and consistent envelopes across every response. Previously\dots Previously, you implemented app/routes/api.products.ts, where the route validates query parameters, delegates real work to the service layer, and returns a consistent success(...) or error(...) envelope. That same architecture continues here: the route module is still a thin HTTP boundary, and the service layer is where “domain meaning” lives (like “this product doesn’t exist”).

The Contract of GET /api/products/:id

When a client requests /api/products/:id, there are only a few meaningful outcomes, and each one matters: Invalid ID format \to 400 (VALIDATION_ERROR) The request itself is malformed. We should reject it quickly without touching the database. Valid ID format, but no product exists \to 404 (NOT_FOUND) The request is well-formed, but the resource doesn’t exist. This is not the client “formatting something wrong”—it’s simply missing data. Valid ID and product exists \to 200 (success envelope with the Product) The happy path: return the product in the same consistent response envelope used everywhere else. This endpoint is where you learn to clearly separate bad input from missing data —and that distinction will matter even more when you build updates, deletes/archives, carts, and orders later.

Dynamic Product Route: app/routes/api.products.$id.ts

In Remix, a file name like api.products.$id.ts creates a dynamic segment, so /api/products/<something> becomes /api/products/:id . Remix passes the value of that dynamic segment through the params object inside your loader arguments. This route does three key things in order: reads params.id from Remix validates that the ID is a UUID before doing any work calls the service layer to fetch the product, then returns either a success or error envelope

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Calling the service and forwarding structured outcomes

Once the ID is confirmed valid, we delegate to the service layer. This section is still in app/routes/api.products.$id.ts, and it demonstrates a key pattern in this codebase: services return ServiceResult objects, and routes translate them into envelopes.

TypeScript

// app/routes/api.products.$id.ts

    const product = await getProductService(id);
    if (!product.ok) {
      return error(
        product.error.code,
        product.error.message,
        product.error.details,
        product.error.httpStatus
      );
    }

    return success(product.value);
  } catch (e: unknown) {
    return error('INTERNAL_ERROR', e instanceof Error ? e.message : 'Internal error', undefined, 500);
  }
}

// app/routes/api.products.$id.ts

    const product = await getProductService(id);
    if (!product.ok) {
      return error(
        product.error.code,
        product.error.message,
        product.error.details,
        product.error.httpStatus
      );
    }

    return success(product.value);
  } catch (e: unknown) {
    return error('INTERNAL_ERROR', e instanceof Error ? e.message : 'Internal error', undefined, 500);
  }
}

getProductService(id) returns a ServiceResult<Product>, which means the “normal” not-found case is not handled by throwing—it’s handled by a structured { ok: false, error: ... } result.
When product.ok is false, the loader doesn’t invent HTTP behavior. It simply forwards the service’s code, message, optional details, and httpStatus into the standard error(...) response helper.
On success, success(product.value) returns { data: <Product>, meta: { timestamp } } automatically. This keeps the response shape consistent with /api/products and the rest of the API.
The try/catch is reserved for truly unexpected failures (bugs, infrastructure issues, unexpected exceptions). When that happens, we still return a stable envelope using INTERNAL_ERROR instead of crashing or returning an unstructured response.

Lesson: Fetching Specific Products

The Contract of GET /api/products/:id

Dynamic Product Route: app/routes/api.products.$id.ts

Join the 1M+ learners on CodeSignal

Reading and validating the id path parameter

Calling the service and forwarding structured outcomes

Service Logic: getProductService in src/lib/services/productsService.ts

Turning repository results into a clean outcome

Repository Logic: `getProductById` and row mapping in `src/lib/repositories/productsRepo.ts`

Fetching a row by ID

Mapping rows safely into the domain model

Why ID Validation Happens in the Route (Not the Service)

Recap