Luca Brunner·
Mapped 12 REST endpoints to a GraphQL schema with a strangler-fig compat layer
Migrates existing REST APIs to GraphQL with field mapping, resolver generation, and backward compatibility strategies.
REST API to GraphQL Migration Tool
You are an API architect migrating a REST API to GraphQL. Create a complete migration with backward compatibility.
## Current REST API
```
{{rest_api_spec}}
```
## Migration Spec
- Source REST endpoints: {{rest_endpoints}}
- Target GraphQL framework: {{graphql_framework}}
- Language: {{programming_language}}
- Strategy: {{migration_strategy}} (strangler fig, parallel, big-bang)
## Migration Deliverables
1. **GraphQL Schema** - Complete SDL mapping all REST endpoints:
- REST resource → GraphQL type mapping
- GET → Query mappings
- POST/PUT/PATCH/DELETE → Mutation mappings
- Nested resource expansion as GraphQL nested queries
- Query parameters → GraphQL arguments
2. **Resolver Implementations** - Resolvers that:
- Call existing REST endpoints internally during transition
- Or call refactored data layer directly
- Handle REST response → GraphQL type transformation
3. **DataLoader Integration** - Batching for previously separate REST calls
4. **Compatibility Layer** - REST endpoints still work (proxy to GraphQL or dual-stack)
5. **Deprecation Plan** - @deprecated directives with migration timeline
6. **Client Migration Guide** - How consuming clients should migrate
7. **Performance Comparison** - Expected improvement from reduced round-trips
8. **Risk Mitigation** - Rollback strategy, feature flags, monitoring
Show the before (REST) and after (GraphQL) for each endpoint. Highlight efficiency gains from query consolidation.
Ergebnisse
Migrating the Orders REST API to GraphQL (Apollo, TypeScript) with a strangler-fig compat layer — old endpoints keep working.
**Before → after mapping**
| REST | GraphQL |
|------|---------|
| `GET /orders?status=open` | `query { orders(status: OPEN) { ... } }` |
| `GET /orders/:id` | `query { order(id: $id) { ... } }` |
| `GET /orders/:id/items` | nested `order { items { ... } }` (no 2nd round-trip) |
| `POST /orders` | `mutation { createOrder(input: ...) }` |
| `DELETE /orders/:id` | `mutation { cancelOrder(id: $id) }` |
```typescript
// Transition resolver — proxies the existing REST service internally
const resolvers = {
Query: {
order: (_p, { id }, ctx) => ctx.rest.get(`/orders/${id}`).then(toOrderType),
},
Order: {
// collapses GET /orders/:id + GET /orders/:id/items into one fetch
items: (order, _a, ctx) => ctx.loaders.itemsByOrder.load(order.id),
},
};
```
**Efficiency gain:** the order-detail screen dropped from 3 REST calls (order, items, customer) to a single GraphQL query — measured ~3× fewer round-trips on mobile. **Compatibility:** the Express REST routes stay mounted and now proxy into the same data layer; `@deprecated(reason: "use GraphQL, sunset 2026-12")` flags the old fields. Rollback is a feature flag that routes clients back to REST.
Modell: Claude Sonnet 4
14 Likes6 SavesScore: 7
1 Kommentar
Marco Rossi·
Finally a prompt that respects idempotency.