glapi-backend-guidelines

Codify TRPC, REST, Drizzle, and Clerk expectations for GLAPI backend development.

Updated May 10, 2025
One-click install
npx skills add https://github.com/adteco/glapi --skill glapi-backend-guidelines
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: glapi-backend-guidelines
Source: https://github.com/adteco/glapi/tree/main/.claude/skills/glapi-backend-guidelines
Command: npx skills add https://github.com/adteco/glapi --skill glapi-backend-guidelines

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This guide removes guesswork from GLAPI backend services by enforcing a dual TRPC/REST pattern, shared services, and consistent Drizzle plus Clerk usage so internal and external clients stay type-safe and secure.

Core Features & Use Cases

  • Dual API Architecture keeps internal TRPC procedures thin while REST routes reuse those procedures for external clients.
  • Layered Services & Drizzle Access centralize business logic in services that call PostgreSQL via Drizzle while routers handle Zod validation and Clerk authentication.
  • Checklists and Templates cover creating procedures, REST routes, services, testing, and OpenAPI documentation, with referenced examples under resources/ for quick reference.

Quick Start

Draft a TRPC procedure that delegates to a service, validates input with Zod, and exposes it via Clerk-protected REST per the GLAPI layered architecture.

Frequently Asked Questions about glapi-backend-guidelines

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

FAQPage Schema
How do I structure a Next.js API with both tRPC and REST endpoints?

Structure Next.js APIs using a dual tRPC and REST pattern where REST routes reuse thin tRPC procedures. This keeps internal and external clients type-safe while centralizing business logic in shared services.

What is the best way to share business logic between tRPC and REST routes in Next.js?

The best way to share logic is using layered services where routers handle Zod validation and Clerk authentication, then delegate to services that access PostgreSQL via Drizzle ORM.

Do I need Clerk authentication for both tRPC and REST APIs?

Yes, Clerk authentication is required for both tRPC and REST APIs. Routers must enforce Clerk protection before delegating to service-layer logic, ensuring internal and external endpoints remain secure.

How does Zod validation work with Drizzle ORM in a layered API architecture?

Zod validation works at the router level in a layered API architecture, validating inputs before procedures call services. Services then use Drizzle ORM for type-safe PostgreSQL data access.

Can I expose tRPC procedures as REST APIs for external clients?

Yes, you can expose tRPC procedures as REST APIs by having REST routes directly reuse tRPC procedures. This dual architecture maintains type safety for external clients without duplicating logic.

What documentation is needed when building dual tRPC and REST APIs with Drizzle?

Building dual tRPC and REST APIs requires dual-layer documentation covering procedures, REST routes, services, and OpenAPI specs. Checklists and templates under resources ensure consistent documentation.