<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://harshityadav.github.io/</id><title>Harshit Yadav</title><subtitle>anything and everything from machine learning data sceince, projects &amp; progress, SolvePao Tron Legacy ,system design and maybe food ?</subtitle> <updated>2026-07-21T22:05:39+08:00</updated> <author> <name>Harshit Yadav</name> <uri>https://harshityadav.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://harshityadav.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://harshityadav.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Harshit Yadav </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>SSH Passkeys: One Public Identity, Many Devices</title><link href="https://harshityadav.github.io/posts/SSH-ID/" rel="alternate" type="text/html" title="SSH Passkeys: One Public Identity, Many Devices" /><published>2026-07-21T02:30:00+08:00</published> <updated>2026-07-21T22:04:51+08:00</updated> <id>https://harshityadav.github.io/posts/SSH-ID/</id> <content type="text/html" src="https://harshityadav.github.io/posts/SSH-ID/" /> <author> <name>harshityadav95</name> </author> <category term="Skynet System" /> <category term="Dev Kit" /> <summary>SSH ID SSH access has a deceptively simple problem. You own a laptop, a desktop, perhaps a work machine, a phone-connected terminal, and maybe a hardware security key. Every one of those devices can generate its own SSH key pair. That is good: private keys stay local. But it creates operational friction. Every server needs to know every public key you may use. SSH ID makes that public-key di...</summary> </entry> <entry><title>HTTP/2 over TCP vs HTTP/3 over QUIC</title><link href="https://harshityadav.github.io/posts/HTTP-2-over-TCP-vs-HTTP-3-over-QUIC/" rel="alternate" type="text/html" title="HTTP/2 over TCP vs HTTP/3 over QUIC" /><published>2026-07-20T02:30:00+08:00</published> <updated>2026-07-20T02:30:00+08:00</updated> <id>https://harshityadav.github.io/posts/HTTP-2-over-TCP-vs-HTTP-3-over-QUIC/</id> <content type="text/html" src="https://harshityadav.github.io/posts/HTTP-2-over-TCP-vs-HTTP-3-over-QUIC/" /> <author> <name>harshityadav95</name> </author> <category term="Backend Engineering" /> <summary>Greeting Users and programs today are diving deep into the plumbing of the internet. We are going to strip away the abstractions and look at the bare metal difference between HTTP/2 over TCP/TLS and HTTP/3 over QUIC. If you are building high-performance backends, designing APIs, or tuning reverse proxies like NGINX or Envoy, understanding this shift isn’t optional. It completely alters how you...</summary> </entry> <entry><title>Query Method in HTTP</title><link href="https://harshityadav.github.io/posts/Query-Method-in-HTTP/" rel="alternate" type="text/html" title="Query Method in HTTP" /><published>2026-07-08T00:00:00+08:00</published> <updated>2026-07-08T00:00:00+08:00</updated> <id>https://harshityadav.github.io/posts/Query-Method-in-HTTP/</id> <content type="text/html" src="https://harshityadav.github.io/posts/Query-Method-in-HTTP/" /> <author> <name>harshityadav95</name> </author> <category term="Backend Engineering" /> <summary>Recap Now, you might have heard engineers whispering about a new query parameter designed to fix our search API problems. what’s actually happening at the protocol layer right now is infinitely cooler. It’s not a parameter at all. The IETF just stepped in and dropped an entirely new HTTP Method called QUERY, officially standardized under RFC 10008 in June 2026. This is one of the most inte...</summary> </entry> <entry><title>Apple Containers: Docker, but Not Docker; VM, but Not Really a VM</title><link href="https://harshityadav.github.io/posts/apple-containers/" rel="alternate" type="text/html" title="Apple Containers: Docker, but Not Docker; VM, but Not Really a VM" /><published>2026-07-03T20:10:00+08:00</published> <updated>2026-07-03T20:25:01+08:00</updated> <id>https://harshityadav.github.io/posts/apple-containers/</id> <content type="text/html" src="https://harshityadav.github.io/posts/apple-containers/" /> <author> <name>harshityadav95</name> </author> <category term="Skynet System" /> <category term="Dev Kit" /> <summary>A pragmatic deep dive into Apple's native container runtime, comparing its one-VM-per-container virtualization model against Docker Desktop's shared VM architecture, including networking and security trade-offs.</summary> </entry> <entry><title>Why You Should Stop Creating Database Connections on Every Request</title><link href="https://harshityadav.github.io/posts/Connection-Pooling-in-PostgresSQL/" rel="alternate" type="text/html" title="Why You Should Stop Creating Database Connections on Every Request" /><published>2026-06-23T00:00:00+08:00</published> <updated>2026-06-23T03:01:22+08:00</updated> <id>https://harshityadav.github.io/posts/Connection-Pooling-in-PostgresSQL/</id> <content type="text/html" src="https://harshityadav.github.io/posts/Connection-Pooling-in-PostgresSQL/" /> <author> <name>harshityadav95</name> </author> <category term="Backend Engineering" /> <summary>Connection pooling is one of those foundational backend architecture patterns that sounds basic, but still gets ignored in many real-world systems. I still see applications that open a new database connection for every incoming HTTP request, run a query, and then immediately close the connection. It works. But it is incredibly expensive. If your application does this, you are paying the conne...</summary> </entry> </feed>
