API and backend development · Build
APIs your apps can rely on while the backend changes
Every call has a typed request and response, and permissions are checked on the server. One US marketplace API we built has 506 routes in public and admin sets.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackNode.js · NestJS · Express
Proof4 case studies
The service in 4 parts
01 · Who it’s for
Your frontend, mobile app or partners depend on an API that has to stay predictable, and that API often has to grow, or be replaced, while it is live.
02 · What we’ve built
- 506 API routes for a US marketplace with five kinds of user, kept in two separate sets for public and admin use. The API checks permissions itself and leaves none of that to the interface.Case study 08 →
- A backend with 100 data models and 194 migrations, moved from PHP to Node.js and later to a typed framework while the product stayed live, with zero outages.Case study 04 →
- A permission model stored as a graph, so a question like “may this person open this file?” is answered by traversing it, however long the chain of links behind the answer.Case study 15 →
- Calls from our backend to a national registry in West Africa, protected by keys, digest authentication, single-use tokens and an IP allow-list. A stolen key on its own opens nothing.Case study 09 →
We also built a NestJS ERP that runs next to SAP and exchanges customer, item, order, invoice, stock and finance data with it.
03 · How we work
01 · REQUEST AND RESPONSE TYPESEvery call has a request type and a response type. A call without them stops the commit, and CI checks the same thing again.
02 · CHECKS ON THE SERVERPermissions are checked in the API itself, because a check that exists only in the interface can be bypassed by anyone who calls the API directly.
04 · Stack
Node.jsNestJSExpressTypeScriptPostgreSQLMySQLRedisSQSAWS
Proof
Where we’ve done this before
Case study 08 · Marketplace506 routes506 API routes for a US marketplace with five kinds of user, kept in two separate sets for public and admin use. The API checks permissions itself and leaves none of that to the interface.Read the case study →Case study 04 · MarketplaceZero outagesA backend with 100 data models and 194 migrations, moved from PHP to Node.js and later to a typed framework while the product stayed live, with zero outages.Read the case study →Case study 15 · Business systemsSoldA permission model stored as a graph, so a question like “may this person open this file?” is answered by traversing it, however long the chain of links behind the answer.Read the case study →Case study 09 · Identity1 working dayCalls from our backend to a national registry in West Africa, protected by keys, digest authentication, single-use tokens and an IP allow-list. A stolen key on its own opens nothing.Read the case study →
FAQ
Questions about this service
Yes, and that is usually the hardest part. When we replaced the marketplace backend, the old one kept running beside the new one, synced in both directions, until measurements showed that the last old app had stopped calling it.
Mainly in the code. The build enforces the request and response types, so the documented contract and what the service actually does can’t drift apart unnoticed.
As few as the work allows, with the code they share kept in a shared package. That package should exist by the fifth service, and the marketplace still had none after the fifteenth. It grew to nineteen repositories, and the same queue helper ended up copied into seven of them.
Yes. The ERP mentioned above runs next to SAP. Most of the effort goes into making both systems show the same customers, orders and stock, because people act on whichever screen they have open.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.