Inspiration
Before backend development, I worked in warehouse and logistics operations, where the same problem kept coming up: a part has multiple suppliers with different lead times, certifications, and prices, but that relationship lives in a spreadsheet instead of the system tracking receiving. When a shipment is short or late, nobody can quickly answer "who else can supply this, at what lead time."
What it does
supplier-order-adapter is a Django REST Framework service with three pieces: a supplier knowledge graph (GET /api/parts/<sku>/suppliers/ — who else can supply this part, with lead time/cert/price), a receiving workflow that recomputes an order line's status transactionally as shipments come in, and a webhook dispatcher that POSTs an HMAC-SHA256-signed event after each receiving event commits — outside the transaction, so a slow subscriber never holds a lock open. A demo page at /demo/ ties all three together live.
How we built it
Built in phases — data model, receiving workflow, webhook dispatcher, knowledge-graph queries, demo UI — and after each one I traced it end-to-end with Hunter to confirm what the code actually does, not just what it returns. In particular, to verify the supplier-lookup queries produce one SQL JOIN via select_related() rather than an N+1.
Challenges we ran into
Getting webhook dispatch to fire only after the DB transaction commits, without blocking on a slow subscriber, took a few iterations to get right and verify by trace rather than assumption.
Accomplishments that we're proud of
Every phase has a paired execution trace behind it, so the N+1-avoidance and transaction-ordering claims above are verified, not asserted.
What we learned
Watching an unguarded query fan out into dozens of SELECTs in a trace, then collapse to one JOIN after adding select_related(), made the N+1 problem concrete in a way reading about it never did.
What's next for supplier-order-adapter
Authentication (everything is currently AllowAny, intentionally, as this is a working prototype) and certification expiry, since cert level is currently static per supplier/part rather than something that lapses and needs re-verification.
Log in or sign up for Devpost to join the conversation.