Morphisms All the Way Down: API Design as Arrow-First Thinking

“Arrows over boxes!” The article argues we should design software by defining the actions between things (the “arrows”), not obsessing over the services or databases (the “boxes”). Fans say this contract-first approach makes systems easier to test, swap, and grow. But the comments turned it into math class meets bar fight. One camp cheered the clarity: fewer ways services call each other means less mess. Another camp fired back that this “minimal arrows” mantra is just complexity cosplay. As one skeptic put it, you can’t hide the mess—somewhere it still lives.

The hottest pushback: “focus on both.” User znort_ says real systems need balance and calls the “tiny interface” promise naive—trimming endpoints may just stuff all the tricky bits into one mega-door. Confusion also spiked when the post invoked category theory and “hom-sets” (basically, the list of ways A talks to B). Y_Y bluntly said it “doesn’t make sense,” asking for plain-English examples. Meanwhile, jokesters memed the article’s “use anything—even carrier pigeons!” line, dubbing themselves “Senior PigeonOps Engineers.” Others quipped they’ll file a ticket to “reduce coupling by drawing fewer arrows.”

Net vibe: bold idea, spicy execution. The theory crowd is intrigued; the pragmatists want receipts—and maybe an OpenAPI example that doesn’t need a chalkboard.