46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# API and Backend Work
|
|
|
|
## Purpose
|
|
|
|
Guide server-side, service, API, data, and integration changes with attention to contracts, compatibility, failure handling, and operational impact.
|
|
|
|
## When to use
|
|
|
|
- Modifying endpoints, handlers, services, jobs, or data flows
|
|
- Adding or changing schemas, persistence, or integration behavior
|
|
- Working on backend business logic or infrastructure-facing code
|
|
- Investigating performance, reliability, or contract issues on the server side
|
|
|
|
## Inputs to gather
|
|
|
|
- API contracts, schema, storage models, and service boundaries
|
|
- Existing validation, auth, error handling, and observability patterns
|
|
- Compatibility constraints for clients, data, and deployments
|
|
- Current tests and representative request or event flows
|
|
|
|
## How to work
|
|
|
|
- Trace the full request or job lifecycle before changing a boundary.
|
|
- Preserve compatibility intentionally or document the break clearly.
|
|
- Handle validation, authorization, error responses, and retries in line with existing system behavior.
|
|
- Consider migration, rollout, and operational visibility when data or contracts change.
|
|
- Add or update tests at the right layer for the change.
|
|
|
|
## Output expectations
|
|
|
|
- Working backend change with contract implications made explicit
|
|
- Notes on schema, config, data, or rollout impact
|
|
- Verification results covering the critical paths
|
|
|
|
## Quality checklist
|
|
|
|
- Inputs and outputs are validated appropriately.
|
|
- Failure handling is explicit and consistent.
|
|
- Compatibility and migration impact are understood.
|
|
- Logging, metrics, or observability concerns are addressed when relevant.
|
|
|
|
## Handoff notes
|
|
|
|
- Call out any required coordination with frontend, data migration, configuration, or deployment steps.
|
|
- Note backwards-incompatible changes clearly and early.
|