01 · Enterprise procurement
A bid comparison you can trust
A NestJS backend-for-frontend that turns supplier and proposal data from several services into one reliable view — and refuses to present an incomplete comparison as valid.
- Company
- Stratesys
- Role
- Senior Full Stack Developer
- Period
- 2026 — present
- Stack
- NestJS
- Next.js
- TypeScript
- Server Actions
- Jest
01 · The problem
In enterprise procurement, buyers compare supplier proposals side by side before awarding a contract. The data behind that view lives in separate services: proposals in one place, supplier information in another, process rules and permissions in a third. A comparison that silently drops a supplier — or shows proposals without the right supplier attached — isn’t just a bug. It can lead to the wrong commercial decision.
02 · What I did
- Built the backend-for-frontend endpoint, controller, and service layer in NestJS. It checks that the purchasing process exists and that the user can access it, fetches proposals and their suppliers, and returns a contract shaped for the interface.
- Handled incomplete proposals and different negotiation states in the transformation layer, so React components don’t need to know how each upstream service behaves.
- Treated failures and timeouts of essential dependencies as controlled errors, with structured logs and correlation IDs for troubleshooting, and a clear error state with a retry option in the interface.
- Implemented award-confirmation flows in React and Next.js, mapping typed form data to API contracts for standard and approval-routing scenarios, with Server Actions centralizing service calls and error handling.
- Wrote unit tests for the transformations and for upstream errors and timeouts — including a check that an inconsistent comparison is never presented as valid.
03 · The key decision
Fail clearly instead of comparing partial data.
Proposals and suppliers only make sense together. When an essential dependency fails, the BFF returns a controlled error instead of rendering whatever arrived. That trades the temporary unavailability of one view for the integrity of the decision it supports — the right trade for this workflow, not a rule for every API.
04 · Interactive diagram
Original illustration of the engineering idea — not a product screenshot.
How the comparison is composed
All essential data arrived. The BFF validates access, joins each proposal with its supplier, and returns one typed contract to the interface.
05 · What changed
Data composition now lives in one place on the backend. The interface stays focused on presentation and interaction, contracts are easier to evolve, and failure states keep their meaning: if a comparison is on screen, its essential data is complete.
06 · Scope, honestly
My contribution: the BFF endpoint, its service integrations, transformations, error handling, and tests; the award-confirmation interface and its API mapping. The award API and the wider platform are team efforts. No SLA or incident-rate metric is claimed.