I can already hear the Go purists sharpening their pitchforks. “Use the standard library,” they chant. “Frameworks are anti-pattern,” they scream.
I don’t care.
I am not using Fiber because I am lazy. I am not using it because it looks like Express.js. I am using it because I have a pathological addiction to speed, and net/http, bless its safe, compatible heart, is simply too polite for the violence I want to inflict on my CPU.
I need to get something off my chest. Something that has been festering in my soul since the first time I joined a project mid-development and asked the fateful question: “Where is the API documentation?”
The answer, invariably, was one of the following:
“Check the Postman collection.” (Translation: a graveyard of 200 requests, half of which are outdated, named things like GET users FINAL v2 (copy))
“Just look at the code.” (Translation: reverse-engineer our spaghetti and good luck)
“We’ll document it later.” (Translation: we will never document it)
I’ll start this post with a confession that might earn me some enemies: I hate JSON.
It’s not an irrational hate, the kind that appears out of nowhere. It’s a hate built, brick by brick, over years of debugging malformed payloads, fields that should have been numbers but arrived as strings, and that classic null where you expected an empty array. JSON is the digital equivalent of a phone conversation with your grandmother: you think you understood what she said, but when you get there, the carrot cake didn’t have that expected chocolate frosting (Brazilians will understand).
For those who skipped the Starfleet Academy lectures, the Kobayashi Maru is a training exercise designed as a “no-win scenario.” The goal isn’t to win, it’s to see how you handle inevitable failure. In the world of Backend Engineering, our no-win scenario is the Unhandled Exception.
You spend weeks architecting a beautiful, clean service. You use Records, you optimize your SQL queries, you apply SOLID principles. And then, on production day, a user sends a malformed JSON, and your API vomits a 50-line Stack Trace directly into their browser console. It’s ugly, it’s unprofessional, and it exposes your internal logic to the world.
If you are a developer who has handled payroll processing or bank/financial reconciliation at a company that uses Spring, you have likely worked with Spring Batch. I confess I’m not a huge fan; it has that characteristic verbosity and overhead of the Java ecosystem, making it feel like even the simplest job requires far more structure than necessary. But what good is complaining? The technology your company uses is what ensures your survival (housing, food, clothing). So, whining isn’t the topic for today.