web-backend

Create static service classes with typed Supabase queries and Zod validation.

18|Updated Aug 27, 2022
One-click install
npx skills add https://github.com/flaming-codes/crane-app --skill web-backend
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: web-backend
Source: https://github.com/flaming-codes/crane-app/tree/main/.github/skills/web-backend
Command: npx skills add https://github.com/flaming-codes/crane-app --skill web-backend

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This guidance provides a structured approach to building backend services for the CRAN/E web project, enabling consistent data access, API routing, and scalable architecture.

Core Features & Use Cases

  • Service Layer Pattern: Organizes all data access into statically scoped services (e.g., PackageService, AuthorService, SearchService) to ensure reuse and testability.
  • Typed Data Access & Validation: Uses generated Supabase types and Zod schemas to enforce type safety and input validation across services.
  • Back-end Best Practices: Includes caching with TTLCache, server-only organization, error handling, and environment variable validation to support production-grade reliability.
  • Use Case: When adding a new backend feature, create a service class, wire it to routes, and validate inputs before database calls.

Quick Start Implement a new backend feature by adding a static service class in app/data, wiring it to a route in app/routes, and validating inputs with Zod.

Frequently Asked Questions about web-backend

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure TypeScript backend services for scalable API routes?

Structure TypeScript backend services using statically scoped service classes with typed Supabase queries and Zod validation. This service layer pattern organizes data access into reusable classes to ensure testability and consistent API routing. You wire these classes to routes and validate inputs before database calls.

What's the best way to validate Supabase queries in a TypeScript backend?

Validate Supabase queries in a TypeScript backend by applying generated Supabase types alongside Zod schemas. This enforces type safety and input validation across all service classes before executing database calls. You parse and validate inputs at the API route boundary to prevent invalid data from reaching the data access layer.

How does TTL caching work for backend data access layers?

TTL caching in backend data access layers stores query results with a set time-to-live to reduce redundant database calls. By implementing TTLCache within static service classes, you improve production-grade reliability and response times for repeated read operations. The cache automatically expires entries after their TTL elapses, ensuring data freshness without manual invalidation.

Do I need server-only architecture to use Supabase with TypeScript API routes?

Yes, you need server-only architecture when using Supabase with TypeScript API routes to protect environment variables and maintain production-grade reliability. This backend approach ensures database access and sensitive operations remain isolated from the client. It supports proper error handling and secure environment variable validation within static service classes.

Why should I use a service layer pattern instead of direct database calls in API routes?

Use a service layer pattern instead of direct database calls to ensure code reuse, testability, and consistent data access. By organizing logic into statically scoped services, you separate business logic from routing. This allows multiple API routes to share the same validated, typed Supabase queries without duplicating implementation details.

Can I use Zod schemas for environment variable validation in backend services?

Yes, you can use Zod schemas for environment variable validation in backend services to support production-grade reliability. Validating environment variables with Zod ensures the server-only architecture has correct configurations before starting. This prevents runtime errors by catching missing or malformed variables during the initial service setup phase.