API integration
Frontend and backend that agree on every request
Most integration bugs come from the frontend and backend disagreeing about the shape of data. We generate frontend types from your API contracts (OpenAPI, GraphQL schemas or Protobuf), validate responses at runtime, and run contract tests in CI. A backend change that would break the frontend fails the build instead of reaching users.
Types that stay in sync
- Client code and types are generated from the API contract, not written by hand.
- Responses are validated at runtime with schema libraries like Zod, so unexpected data is caught at the edge of the app.
- Contract tests run in CI against both sides.
- In a shared monorepo, the frontend and backend can import the same type definitions directly.
The right protocol for each job
| Protocol | Where we use it |
|---|---|
| REST | Standard resources and public APIs |
| GraphQL | Screens that combine data from many sources |
| gRPC-Web / Connect | Backends already on gRPC, high-volume or binary data |
| WebSockets / SSE | Live updates and streaming responses |
Images, files and binary data
Applications that move a lot of images or binary data need care. We use chunked, resumable uploads for large files and stream downloads instead of loading them whole. We avoid base64 encoding in transit, since it makes files about a third larger. Content types and character encoding are set correctly, so text and binary data arrive intact.
Failures, retries and memory
- Timeouts and cancellation on every request, so abandoned screens stop their requests.
- Retries with backoff for safe operations only.
- Fallbacks for when a service is down: cached data, a degraded view, or a clear message.
- Large responses are paginated or streamed, and memory budgets are enforced on data-heavy screens. This matters most for data-intensive applications.
FAQ
Frequently asked questions
01Our backend has no API spec. Can you still generate types?
We can help write an OpenAPI spec from the existing endpoints, then generate types from it. The spec then becomes useful documentation for your backend team as well.
Next step
Start with a review of what you have
Send us your repository or a staging link. We'll come back with the three changes that would make the biggest difference to your release speed, performance and reliability.