The latest articles on DEV Community by barath nadar (@barath_nadar). https://dev.to/barath_nadar https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3975825%2Fcf9c92b3-10c3-4bbe-997f-efde23bfba03.jpg https://dev.to/barath_nadar en barath nadar Wed, 10 Jun 2026 11:53:21 +0000 https://dev.to/barath_nadar/4-years-in-ecommerce-infrastructure-here-are-the-problems-im-building-open-source-tools-to-solve-14bi https://dev.to/barath_nadar/4-years-in-ecommerce-infrastructure-here-are-the-problems-im-building-open-source-tools-to-solve-14bi <p>My typical week at Fynd looked like this: answer questions about infrastructure I'd built, work on whatever was assigned, help make architecture decisions, and spend 4 hours a day commuting. For 4 years.<br> I worked at the infrastructure layer — the stuff other engineers depend on to do their jobs. gRPC migrations, GraphQL federation, API contract tooling, marketplace integrations across Myntra, Amazon, Flipkart, Nykaa, and Tata Cliq. Not feature work. The plumbing.</p> <p>When I left, I had a list of problems I kept thinking about. I'm building open source tools for them.</p> <h2> The problem nobody talks about: API contracts drift and nobody notices </h2> <p>You build a new endpoint. You test it manually, it works. You ship it. Three weeks later someone notices the response shape doesn't match the OpenAPI spec. Or worse — a consumer breaks in production.<br> This happened constantly. Not because engineers were careless — because there was no feedback loop during development. By the time the drift was caught, it had already caused damage.</p> <p>The gap: there's no lightweight tool that sits in your local dev workflow and tells you in real time when your implementation drifts from your contract.</p> <p>That's what I'm building with api-watch. A local CLI proxy that sits between your HTTP client and your dev server, captures all traffic, validates it against your OpenAPI spec, and generates a report when you stop it.</p> <p>What the report gives you:<br> Every endpoint called but not documented in your spec<br> Every response that didn't match the schema<br> Auto-generated OpenAPI stubs for undocumented endpoints — ready to paste directly into your spec</p> <p>No config. No CI setup. No code changes to your server. Just point it at your local server and go.<br> → <a href="//github.com/barath121/api-watch">api-watch</a>— building in public</p> <h2> Other problems I'm solving </h2> <p>api-watch isn't the only thing I'm building.</p> <p>While migrating to gRPC at Fynd, we hit a production incident caused by protobuf field number shifting — a niche but painful problem if you're generating proto files from OpenAPI specs. I built proto-lock to solve it. Same concept as package-lock.json but for field numbers.<br> If that's relevant to you — check it out.<br> → <a href="//github.com/barath121/proto-lock">Proto-lock</a></p> <h2> Why open source </h2> <p>Both tools exist because I searched for them and couldn't find them. If you're hitting the same problems, I'd rather you have a working solution than spend a week building your own internal hack.<br> If either of these is useful — a star on GitHub goes a long way. And if you're working on similar infrastructure problems, follow along. There's more coming.</p> <p>Follow along: <a href="https://github.com/barath121" rel="noopener noreferrer">GitHub</a> · <a href="https://www.linkedin.com/in/barathnadar/" rel="noopener noreferrer">LinkedIn</a> · <a href="//barathnadar.dev">barathnadar.dev</a></p> api opensource backend webdev