I read every tutorial. Every "how to build a REST API in 10 minutes" post. Every framework documentation page. I thought I had it figured out.

Then I got a job and realized I knew nothing.

Nothing about the real shit. The pagination that your frontend team needs but nobody tells you how to do right. The type safety that saves you from debugging hell at 2am. The migrations that don't fuck up production. The architecture that doesn't collapse when you add more than three endpoints.

Tutorials teach you how to make a toy. They don't teach you how to build something that works when people actually use it.

The Lie They Tell You

You know the articles I'm talking about:

"Build a REST API in 15 minutes!" - Yeah, if you ignore authentication, error handling, validation, testing, logging, and everything else that matters.

"Master TypeORM in One Day!" - Here's how to connect to a database. Good luck figuring out migrations, query optimization, and why your queries are slow in production.

"Authentication Made Easy!" - Just add this middleware. Don't worry about token refresh, security headers, rate limiting, or the thousand edge cases that will bite you later.

I'm not saying these are useless. They got me started. But they're like learning to drive in a parking lot—you can steer, but you have no idea what to do when you hit real traffic.

Why I'm Writing This

I wanted someone to tell me the truth. The real stuff. The things you learn when your API crashes in production and you're debugging at 3am. The patterns that actually work when you have real users. The decisions that matter when your system needs to scale.

I wanted someone to skip the corporate bullshit and the "10 tips to become a better developer" and just tell me: here's the problem, here's how I solved it, here's why it works, and here's what I fucked up along the way.

That's what this blog is. No fluff. No "hello world" examples. Just real code from real projects solving real problems.

What I Actually Built

I just finished building my portfolio. Nuxt 3 frontend. NestJS backend. TypeORM. MySQL. Sounds simple, right?

It wasn't.

Not because the tech is hard. Because the decisions are hard. How do you structure pagination so it doesn't break when you add filtering? How do you keep types in sync between frontend and backend without going insane? How do you design an API that doesn't feel like it was built by someone who just discovered REST yesterday?

These aren't tutorial problems. These are the problems you solve when you build something real. When it has to work. When breaking changes cost you hours of debugging.

What's Next: Tacoview

Now I'm building Tacoview. It's a restaurant review platform, but that's not the point. The point is it's event-driven. It uses Kafka. It's built with microservices. It's the kind of system that separates developers who can build APIs from developers who can build systems.

I'm learning as I build. Event-driven architecture. Eventual consistency. Distributed systems that don't fall apart. The kind of stuff that matters when you have real users and real data and real problems.

I'll write about all of it. The good decisions and the bad ones. What works and what doesn't. The patterns that scale and the ones that don't.

What You'll Get Here

I'm not going to write "Getting Started with NestJS" tutorials. There are a thousand of those already, and they all say the same thing.

Instead, I'll write about:

The Real Basics

  • Error handling that doesn't suck
  • API design that doesn't make your frontend team hate you
  • Database migrations that don't break production
  • Types that actually prevent bugs instead of just looking pretty
  • Auth patterns that work when you have more than one user

The Hard Stuff

  • Microservices that don't create more problems than they solve
  • Event-driven systems that are actually reliable
  • Caching strategies that make things faster instead of breaking everything
  • Database queries that don't slow down when you have real data
  • Testing distributed systems without losing your mind

The Advanced Shit

  • System design that scales beyond your laptop
  • Event sourcing when you need it (and when you don't)
  • Patterns that work in the real world, not just in architecture diagrams
  • Performance that matters when users are waiting
  • Observability that helps you debug instead of drowning you in metrics

Every post will have real code. Real problems. Real solutions. Real mistakes. The kind of stuff that actually helps you build better systems.

The Real World Shit

  • How to actually communicate with non-technical people without losing your mind
  • Dealing with "can we ship it by Friday?" when it's Wednesday and you haven't started
  • Code reviews that don't turn into ego battles
  • Documentation that people actually read (and how to write it)
  • When to push back and when to just ship the thing
  • Debugging with other developers who think their code is perfect
  • On-call rotations and the art of not losing sleep over alerts
  • Technical debt: when to fix it, when to leave it, and how to explain why
  • Working with frontend teams without throwing things
  • Prioritization when everything is "urgent"

Because let's be honest: half the job is code. The other half is dealing with people, deadlines, and reality. Tutorials don't teach you how to tell your PM that their feature will take two weeks, not two days. They don't teach you how to write a PR description that actually explains what you did. They don't teach you how to stay sane when the entire system is on fire and your manager is asking for status updates every five minutes.

How I Write

I'm not going to give you the answer and call it a day. I'll walk you through:

  1. The problem - What actually needs to be solved
  2. The constraints - What's actually limiting us
  3. The options - What we could actually do
  4. The decision - Why we chose this path (and what we gave up)
  5. The code - How we built it (with all the messy parts)
  6. The lessons - What we learned (including the failures)

Because understanding why something works is more important than knowing that it does.

Let's Build Real Shit

If you're tired of tutorials that teach you how to build toys and want to learn how to build systems that actually work, you're in the right place.

I'll share what I learn as I build. Real projects. Real problems. Real solutions. No bullshit.

Let's build backend systems that don't suck.

Got questions? Hit me up. I'm always interested in hearing about the problems you're actually solving.