<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Api-Design on Saurabh Kumar</title><link>https://saurabh-kumar.com/articles/api-design/</link><description>Recent content in Api-Design on Saurabh Kumar</description><generator>Hugo</generator><language>en-US</language><copyright>Copyright © 2025, Saurabh Kumar.</copyright><lastBuildDate>Fri, 24 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://saurabh-kumar.com/articles/api-design/index.xml" rel="self" type="application/rss+xml"/><item><title>Three Things That Bite You When You Ship gRPC to Production</title><link>https://saurabh-kumar.com/articles/2026/07/three-things-that-bite-you-when-you-ship-grpc-to-production/</link><pubDate>Fri, 24 Jul 2026 00:00:00 +0000</pubDate><guid>https://saurabh-kumar.com/articles/2026/07/three-things-that-bite-you-when-you-ship-grpc-to-production/</guid><description>&lt;p&gt;I recently spent some time going deeper into gRPC, past the quickstart and into HTTP/2 framing, Protobuf encoding, and the parts of the system that sit around the service itself. I came away liking it. Contract-first APIs are useful, generated clients remove an entire class of mistakes, and streaming is part of the protocol rather than something attached later.&lt;/p&gt;
&lt;p&gt;I also came away with a list of things I wish the quickstart had made harder to miss. They are not obscure bugs, and they are not arguments against gRPC. They are direct consequences of the choices that make it good.&lt;/p&gt;</description></item></channel></rss>