bb-graphql-pothos

Standardize GraphQL endpoint construction with thin resolvers delegating to services.

Updated Apr 16, 2026

Search Tags:#architecture #graphql #yoga #resolver #service-layer #pothos

Ready to run

npx skills add https://github.com/valentinmathey/Skills-Back-Automation --skill bb-graphql-pothos

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: bb-graphql-pothos
Source: https://github.com/valentinmathey/Skills-Back-Automation/tree/main/skills/bb-graphql-pothos
Command: npx skills add https://github.com/valentinmathey/Skills-Back-Automation --skill bb-graphql-pothos

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

GraphQL endpoints often become bloated when resolvers mix business logic with data access. This skill provides rules for building GraphQL queries and mutations using Yoga and Pothos, with thin resolvers that delegate all logic to dedicated services and keep inputs and types outside the resolver code.

Core Features & Use Cases

Thin resolvers: Resolvers only map HTTP/GQL parameters and return results; no business logic is executed here.
Clear separation of concerns: Services handle the core logic; resolvers delegate to services, avoiding direct DB access.
Cross-API guidance: Applies when adding or updating Queries/Mutations or Type definitions across APIs like bruno-brown-bk, internal-api, and orders-api.

Quick Start

Define your GraphQL endpoints using Pothos and Yoga while ensuring all business logic resides in services and the GraphQL layer remains thin.

Frequently Asked Questions about bb-graphql-pothos

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

FAQPage Schema

How do I keep GraphQL resolvers thin and separate business logic from data access?▼

To keep GraphQL resolvers thin, standardize endpoint construction by ensuring resolvers only map parameters and return results while delegating all business logic to a dedicated service layer.

What is the best way to structure GraphQL queries and mutations with Pothos and Yoga?▼

The best way to structure GraphQL queries and mutations with Pothos and Yoga is to enforce a clear separation of concerns, keeping inputs and type definitions outside resolver logic and delegating execution to services.

Can I use this architecture to update Type definitions across multiple internal APIs?▼

Yes, you can use this architecture to add or update Queries, Mutations, and Type definitions across multiple APIs, specifically including bruno-brown-bk, internal-api, and orders-api.

Why should GraphQL resolvers avoid direct database access?▼

GraphQL resolvers should avoid direct database access to prevent endpoints from becoming bloated, ensuring that services handle the core logic and resolvers remain focused on parameter mapping.

When do I need a service layer for my GraphQL endpoint construction?▼

You need a service layer for GraphQL endpoint construction when resolvers begin mixing business logic with data access, requiring services to handle the core logic while resolvers strictly delegate execution.