Backend Development with GitScrum | API & Database Tasks
Organize API development, database migrations, and service architecture tasks. Structure backend work with clear contracts, dependencies, and rollback plans.
8 min read
Backend development involves APIs, databases, and services that power applications. GitScrum helps teams organize backend work with clear technical requirements and dependencies.
Backend Task Structure
API Development Tasks
API ENDPOINT TASK STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WELL-STRUCTURED API TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Create User Export Endpoint ││
│ │ ││
│ │ ENDPOINT: ││
│ │ POST /api/v1/exports/users ││
│ │ ││
│ │ REQUEST: ││
│ │ { ││
│ │ "format": "csv" | "xlsx", ││
│ │ "filters": { ││
│ │ "created_after": "ISO date", ││
│ │ "status": "active" | "inactive" ││
│ │ } ││
│ │ } ││
│ │ ││
│ │ RESPONSE (202): ││
│ │ { ││
│ │ "export_id": "uuid", ││
│ │ "status": "processing", ││
│ │ "estimated_seconds": 30 ││
│ │ } ││
│ │ ││
│ │ ERRORS: ││
│ │ 400: Invalid format or filters ││
│ │ 403: No export permission ││
│ │ 429: Too many pending exports ││
│ │ ││
│ │ IMPLEMENTATION: ││
│ │ ☐ Validate request ││
│ │ ☐ Queue background job ││
│ │ ☐ Create export record ││
│ │ ☐ Return async response ││
│ │ ││
│ │ TESTING: ││
│ │ ☐ Unit tests for validation ││
│ │ ☐ Integration test for full flow ││
│ │ ☐ Rate limit test ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ KEY ELEMENTS: │
│ ✅ Full API contract (request/response) │
│ ✅ Error cases documented │
│ ✅ Implementation checklist │
│ ✅ Testing requirements │
└─────────────────────────────────────────────────────────────┘
Database Work
DATABASE TASK STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MIGRATION TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-150: Add exports table ││
│ │ ││
│ │ SCHEMA: ││
│ │ ┌─────────────────────────────────────────────────────┐││
│ │ │ exports │││
│ │ ├─────────────────────────────────────────────────────┤││
│ │ │ id: UUID (PK) │││
│ │ │ user_id: UUID (FK → users) │││
│ │ │ type: VARCHAR(50) │││
│ │ │ format: VARCHAR(10) │││
│ │ │ status: VARCHAR(20) [pending, processing, done] │││
│ │ │ file_url: TEXT (nullable) │││
│ │ │ error_message: TEXT (nullable) │││
│ │ │ expires_at: TIMESTAMP │││
│ │ │ created_at: TIMESTAMP │││
│ │ │ updated_at: TIMESTAMP │││
│ │ └─────────────────────────────────────────────────────┘││
│ │ ││
│ │ INDEXES: ││
│ │ ☐ user_id (filter by user) ││
│ │ ☐ status (process pending) ││
│ │ ☐ expires_at (cleanup job) ││
│ │ ││
│ │ ROLLBACK: ││
│ │ DROP TABLE exports; ││
│ │ ││
│ │ DEPLOYMENT NOTES: ││
│ │ • No downtime expected (new table) ││
│ │ • Run in staging first ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MIGRATION CHECKLIST: │
│ ☐ Migration file created │
│ ☐ Rollback tested │
│ ☐ Staging deployment verified │
│ ☐ Production deployment planned │
└─────────────────────────────────────────────────────────────┘
API Design
API Contracts First
CONTRACT-FIRST DEVELOPMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WORKFLOW: │
│ │
│ 1. DESIGN API CONTRACT │
│ Frontend + Backend agree on shape │
│ Document in OpenAPI/Swagger │
│ │
│ 2. PARALLEL DEVELOPMENT │
│ Frontend: Build against mock API │
│ Backend: Implement real API │
│ │
│ 3. INTEGRATION │
│ Connect real API │
│ Fix edge cases │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CONTRACT DESIGN TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ API-001: Design Export API Contract ││
│ │ ││
│ │ Attendees: FE lead, BE lead, PM ││
│ │ ││
│ │ Deliverables: ││
│ │ ☐ OpenAPI spec for export endpoints ││
│ │ ☐ Request/response examples ││
│ │ ☐ Error responses documented ││
│ │ ☐ Pagination approach (if needed) ││
│ │ ││
│ │ Decisions needed: ││
│ │ ☐ Async vs sync for large exports ││
│ │ ☐ File storage approach ││
│ │ ☐ Rate limiting strategy ││
│ │ ││
│ │ Output: Approved API spec ││
│ │ Enables: BE-100, FE-200 to start ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFITS: │
│ ✅ Teams work in parallel │
│ ✅ Contract disagreements caught early │
│ ✅ Frontend can use generated mocks │
│ ✅ API documentation as byproduct │
└─────────────────────────────────────────────────────────────┘
Service Development
Service Architecture Work
SERVICE-LEVEL WORK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NEW SERVICE TASK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-200: Create Export Worker Service ││
│ │ ││
│ │ PURPOSE: ││
│ │ Background worker that processes export jobs ││
│ │ ││
│ │ ARCHITECTURE: ││
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││
│ │ │ API │───>│ Queue │───>│ Worker │ ││
│ │ │ │ │ (Redis) │ │ │ ││
│ │ └─────────┘ └─────────┘ └────┬────┘ ││
│ │ │ ││
│ │ ┌─────▼─────┐ ││
│ │ │ S3 │ ││
│ │ └───────────┘ ││
│ │ ││
│ │ IMPLEMENTATION: ││
│ │ ☐ Job processor class ││
│ │ ☐ Database query for export ││
│ │ ☐ CSV/XLSX generation ││
│ │ ☐ S3 upload ││
│ │ ☐ Status updates ││
│ │ ☐ Error handling ││
│ │ ☐ Retry logic ││
│ │ ││
│ │ SCALING: ││
│ │ • Multiple workers can process in parallel ││
│ │ • Jobs are idempotent ││
│ │ • Timeout: 10 minutes per job ││
│ │ ││
│ │ MONITORING: ││
│ │ ☐ Job success/failure metrics ││
│ │ ☐ Processing time histogram ││
│ │ ☐ Queue depth alerting ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Testing Backend
Test Requirements
BACKEND TESTING STRATEGY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEST LEVELS: │
│ │
│ UNIT TESTS: │
│ • Business logic │
│ • Validation │
│ • Utilities │
│ • Fast, isolated │
│ │
│ INTEGRATION TESTS: │
│ • API endpoints │
│ • Database operations │
│ • External service calls (mocked) │
│ • Test database, real queries │
│ │
│ E2E TESTS: │
│ • Critical flows │
│ • Real services (staging) │
│ • Fewer, more expensive │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TASK TESTING REQUIREMENTS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Create User Export Endpoint ││
│ │ ││
│ │ UNIT TESTS: ││
│ │ ☐ Request validation ││
│ │ ☐ Filter building ││
│ │ ☐ Export job creation ││
│ │ ││
│ │ INTEGRATION TESTS: ││
│ │ ☐ POST /api/v1/exports/users (happy path) ││
│ │ ☐ Invalid format returns 400 ││
│ │ ☐ Missing permission returns 403 ││
│ │ ☐ Rate limit exceeded returns 429 ││
│ │ ☐ Job queued correctly ││
│ │ ││
│ │ TEST COVERAGE: ││
│ │ Minimum: 80% for new code ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINITION OF DONE: │
│ ☐ Unit tests pass │
│ ☐ Integration tests pass │
│ ☐ Coverage meets minimum │
│ ☐ CI pipeline green │
└─────────────────────────────────────────────────────────────┘
Error Handling
Error Strategy
ERROR HANDLING REQUIREMENTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ERROR RESPONSE STRUCTURE: │
│ { │
│ "error": { │
│ "code": "VALIDATION_ERROR", │
│ "message": "Invalid export format", │
│ "details": { │
│ "field": "format", │
│ "allowed": ["csv", "xlsx"] │
│ } │
│ } │
│ } │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERROR HANDLING IN TASKS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Error Handling ││
│ │ ││
│ │ Validation errors (400): ││
│ │ ☐ Return field-level errors ││
│ │ ☐ Include allowed values ││
│ │ ││
│ │ Auth errors (401/403): ││
│ │ ☐ Clear message about what's needed ││
│ │ ☐ Don't leak internal info ││
│ │ ││
│ │ Rate limit (429): ││
│ │ ☐ Include retry-after header ││
│ │ ☐ Explain limit ││
│ │ ││
│ │ Server errors (500): ││
│ │ ☐ Log full error internally ││
│ │ ☐ Return generic message to client ││
│ │ ☐ Include request ID for debugging ││
│ │ ││
│ │ Timeout handling: ││
│ │ ☐ Set reasonable timeouts ││
│ │ ☐ Return 504 if exceeded ││
│ │ ☐ Make operations resumable where possible ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ LOGGING: │
│ • Structured logs (JSON) │
│ • Request ID in all logs │
│ • User context (who, what, when) │
│ • Performance metrics (duration) │
└─────────────────────────────────────────────────────────────┘