Daniel Cohen·
Handed it our marketplace and got a GraphQL schema with DataLoader batching that killed the N+1
Designs a complete GraphQL API with schema definition, resolver architecture, N+1 query mitigation, federation strategy, and security considerations.
GraphQL Schema & API Architecture
You are a GraphQL architect who designed APIs at Meta and Apollo. Design a complete GraphQL API architecture for my domain.
**Domain**: {{domain}} (e.g., social network, e-commerce marketplace, SaaS platform)
**Data Sources**: {{data_sources}} (PostgreSQL, MongoDB, Redis, REST APIs, gRPC services)
**Client Types**: {{client_types}} (web SPA, mobile iOS/Android, public API consumers)
**Performance Requirements**: {{performance_requirements}} (p95 response times, query complexity limits)
Provide:
1. **Complete GraphQL Schema** - All types, queries, mutations, subscriptions with directives and custom scalars
2. **Schema Design Principles** - Why each type exists, naming conventions, and field deprecation strategy
3. **Resolver Architecture** - Resolver map with data loader patterns for N+1 elimination
4. **DataLoader Batching** - Specific batch loading functions for each entity type with caching strategies
5. **Query Complexity Analysis** - Cost analysis setup, max depth limits, and complexity scoring per field
6. **Federation Strategy** - If microservices, show subgraphs, @key directives, and gateway configuration
7. **Mutation Design** - Input types, validation, error handling, and atomic operation patterns
8. **Subscription Design** - Real-time event sources, WebSocket management, and backpressure handling
9. **Caching Strategy** - Query-level caching (Redis), CDN caching for queries, @cacheControl directives
10. **Security Checklist** - Query depth limiting, complexity limiting, introspection in production, persisted queries
11. **Monitoring & Observability** - Apollo Studio integration, resolver-level tracing, error tracking
12. **Migration from REST** - Step-by-step migration strategy if coming from REST endpoints
Include actual executable GraphQL schema code and example queries for the 5 most common operations.
Ergebnisse
GraphQL schema for an **e-commerce marketplace** (Postgres + Redis, web SPA + mobile, p95 < 200ms). The win is killing the N+1 with DataLoader and gating cost.
```graphql
scalar DateTime
directive @cacheControl(maxAge: Int) on FIELD_DEFINITION | OBJECT
type Product @cacheControl(maxAge: 60) {
id: ID!
title: String!
seller: Seller! # batched, never per-row
reviews(first: Int = 10, after: String): ReviewConnection!
price: Money!
}
type Query {
product(id: ID!): Product
search(q: String!, first: Int = 20, after: String): ProductConnection!
}
type Mutation { placeOrder(input: PlaceOrderInput!): OrderResult! }
type Subscription { orderStatusChanged(orderId: ID!): Order! }
```
```typescript
// Seller resolved via DataLoader — one SQL round-trip for N products
const sellerLoader = new DataLoader<string, Seller>(async (ids) => {
const rows = await db.seller.findMany({ where: { id: { in: [...ids] } } });
const byId = new Map(rows.map((s) => [s.id, s]));
return ids.map((id) => byId.get(id)!);
});
const resolvers = {
Product: { seller: (p, _a, ctx) => ctx.loaders.seller.load(p.sellerId) },
};
```
**Cost control:** every field carries a complexity weight; the gateway rejects queries above 1000 points and depth > 8 before execution. **Production hardening:** introspection disabled, persisted-query allowlist only, `@cacheControl` drives the Apollo CDN edge cache. Federation splits `Product`/`Order`/`User` into three subgraphs joined by `@key(fields: "id")`.
Modell: Claude Opus 4
17 Likes4 SavesScore: 15