Use Protocols, Not Services: Why Your Code Needs a Diet

Imagine walking into a restaurant, and instead of a menu, the waiter hands you the full kitchen documentation: "Here's our ingredient delivery service, here's the vegetable chopping service..." That's what code looks like when you use bloated services instead of clear protocols. Developer Not Not P (yes, that's a pseudonym) proposes a cure for this architectural dyspnea.

The idea is as simple as a slap: agree on data formats and actions (protocol), don't drag an entire service with its methods everywhere. It's like switching from "I'll call Bob, he'll tell Alice" to a simple "send JSON to port 8080". Fewer middlemen — fewer headaches during deployment.

Sure, the world is full of hype architectures where microservices multiply like rabbits. But the author reminds us: if your service only knows "getUser" and "saveUser", maybe it's time to stop calling it a service? A protocol with two operations is not a service, it's a function. And there's no shame in a function; shame is 47 columns in JIRA for its sake.

Why It Works

• Flexibility: a protocol can be reused across different services without rewriting the API each time.
• Testability: it's easier to test a protocol than to mock an entire service with its dependencies.
• Evolution: a protocol outlives any specific implementation — change services without changing the contract.

METABYTE studio comment: We also love lean protocols — they're like a clear spec, but without extra pages. If your project has started resembling an elephant in a china shop, maybe it's time to go on a protocol diet?