CtrlK
BlogDocsLog inGet started
Tessl Logo

simon/fastify-best-practices

Fastify best practices skill

93

1.37x
Quality

97%

Does it follow best practices?

Impact

85%

1.37x

Average score across 4 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

task.mdevals/scenario-4/

Product Catalog REST API

Problem/Feature Description

An online marketplace is building a new product catalog service. The backend team is working in TypeScript and wants the Fastify API to have strong type guarantees that flow through the entire request/response cycle — from incoming request validation all the way to the serialized response. They've had bugs in production where unvalidated fields leaked into responses and where optional fields caused TypeScript errors that only surfaced at runtime.

The team has three specific pain points they want addressed:

  1. Schema definitions that produce actual TypeScript types without manually duplicating interface definitions
  2. Response types that are enforced at compile time, not just at runtime
  3. Reusable schema definitions that can be referenced across multiple routes

The service manages a product catalog for the marketplace. Products have required and optional fields, and the API must support creating, listing, and retrieving products.

Output Specification

Build a TypeScript Fastify application in src/ with the following:

Routes:

  • POST /products — create a product, returns 201 with the created product
  • GET /products — list products with optional pagination query params (page, limit), returns 200
  • GET /products/:id — get a product by ID, returns 200 or 404

Product shape:

  • id — string (UUID format)
  • name — string (required, minimum 1 character)
  • description — optional string
  • price — number, must be greater than 0
  • category — string (required)
  • inStock — boolean

Files to produce:

  • src/app.ts — Fastify app builder
  • src/routes/products.ts — route definitions
  • src/schemas/ — shared schema definitions (if using shared/reusable schemas)
  • package.json — with dependencies

The app does not need a real database — an in-memory store is sufficient. Focus on the schema definitions, type safety, and response contracts.

evals

tile.json