DEV Community: Gaston Herrlein

I chose the wrong architecture… on purpose

Gaston Herrlein — Fri, 27 Mar 2026 15:30:00 +0000

It was 2014. Paraná, Argentina. A free period at school, the World Cup just around the corner, and a group of friends who — with not much else to do — started talking about football.

At some point someone threw out the idea: what if we compete to see who actually knows more? The rules were simple. Everyone made their predictions before each match — exact score, winner, points. Three points if you nailed the exact result. One if you only got the winner right. Zero if you missed entirely.

What wasn't simple was what it created. Suddenly you found yourself watching matches you normally wouldn't care about — but now they mattered, because your prediction depended on them. There were laughs, arguments, jokes, small symbolic bets. And that hard-to-describe feeling of desperately wanting the game to end exactly the way you'd predicted.

We repeated it across Copa Américas, Euros, and other tournaments. Each time, the game was the same. And each time, it was worth it.

But years pass. Life changes. I ended up living on a different continent, far from many of those friends. And even though technology keeps us connected, it's not that easy to recreate that spontaneous dynamic we had when we were all together at school.

That was the starting point for this project.

A simple project… with a complicated decision

The idea was clear: build a small app that would let us play again. A place where everyone could submit their predictions, check the results, and follow an updated leaderboard.

Functionally, it's not complex. Any developer with some experience could build this in a weekend — a monolith, a database, done. That's the sensible choice. No question.

I didn't do that.

I decided to build it using a microservices architecture. Not because the project needed it. But because I did.

The gap between knowing and understanding

There's a reality many developers will recognize: there are technologies and architectures we hear about constantly — in articles, talks, conferences — but that we rarely get the chance to practice in any real depth.

Microservices are one of those cases. There's no shortage of content about them. Their advantages, their drawbacks, when to use them, when to avoid them. But there's an enormous gap between understanding a concept in theory and actually facing the real problems that surface when you implement it.

Reading about distributed systems is not the same as building one. Even a small one.

So I made a conscious decision to use this project as a learning lab. I knew exactly what I was doing: adding unnecessary complexity for an MVP, taking longer than I should, and exposing myself to problems that simply wouldn't exist in a monolith.

That's precisely why I did it.

What this kind of architecture forces you to think about

Designing the system this way wasn't just a theoretical exercise. Every architectural decision came with concrete questions I had to work through:

Real problems that came up

How do you separate responsibilities without services becoming tightly coupled?

How do you handle communication between services without creating a tangle of synchronous calls?

What happens when one service fails and others depend on it?

How do you deploy parts of the system independently without breaking everything else?

How do you reliably integrate an external sports results API across service boundaries?

Each of those problems is a piece of the puzzle that distributed systems really are. And even though my project is small, confronting those challenges gave me a much deeper understanding of how these architectures actually work in practice.

It wasn't the easiest path. But it was the most interesting one.

Where this is going

The project is close to its first working version. The goal is to have it ready before the next World Cup — using some league matches as a test run — so we can do what we used to do years ago: compete against each other, laugh at the predictions that aged poorly, and celebrate when someone calls an unlikely result.

In the next articles I'll dig into the concrete technical decisions: which services I defined, how they communicate, which tools I chose and why. But this first piece was necessary to set up something that technical blogs often skip: the personal why behind a technical decision.

A thought for anyone considering something similar

In software development, there's a lot of talk about avoiding overengineering. And in most cases, that advice is right — especially in professional contexts where time and resources matter.

But side projects have a huge advantage: they don't always have to optimize for speed of delivery or efficiency. Sometimes they can optimize for something more important: learning.

Building something that forces you out of your comfort zone, exploring technologies you don't get to touch in your day job, and wrestling with problems you don't yet know how to solve — that has a kind of value that no tutorial can give you.

And if that project is also connected to something personal — memories, friends, something that matters to you beyond the code — then the process becomes even more meaningful.

"Sometimes the best reason to build something isn't that it's the most efficient solution. It's that, in the process of building it, you'll learn something you couldn't have learned any other way."

TypeScript for CLIs: why so many teams choose it (and why it's not what you think)

Gaston Herrlein — Mon, 23 Mar 2026 14:15:00 +0000

When Microsoft shipped the Azure CLI, or when Google chose TypeScript for Gemini CLI, the inevitable question surfaced in every forum: why TypeScript? Isn't it slow? The question itself reveals a misunderstanding worth unpacking fully.

TypeScript isn't chosen for CLIs because of its performance. It's chosen in spite of its performance not being best-in-class. And paradoxically, that's exactly what makes it the right call for many teams.

🏎️ The performance myth

Let's start with the most important point: TypeScript doesn't run. The code you write gets transpiled to plain JavaScript, which then executes on a runtime like Node.js (V8), Deno, or Bun. The end result at runtime is practically identical to writing JavaScript by hand.

If the goal were raw performance, the debate would be between Go, Rust, > and C++. TypeScript wouldn't even be in the conversation.

And yet, it is in the conversation. Constantly. Because performance is rarely the real bottleneck in a client tool. What actually is: the time it takes a team to build it, maintain it, and evolve it over years.

📈 The real argument: sustained productivity

TypeScript introduces static typing without giving up JavaScript's dynamism. For a CLI of any real complexity — with subcommands, flags, plugins, and external API calls — that translates into something very concrete: the compiler catches bugs before the user does.

Autocomplete actually works. Refactors don't turn into archaeological expeditions. Contracts between modules are written in the code itself, not in a Confluence doc nobody updates. As the project grows, that difference compounds.

The ecosystem as a competitive advantage

Perhaps the most underrated argument is the ecosystem. Node.js has been the backbone of the web for decades, and that has a very valuable side effect for people building CLI clients:

Everything you need already exists, is actively maintained, and works on Windows, Linux, and macOS without touching a single compiler flag. Libraries like commander, inquirer, chalk, or execa aren't experiments — they're battle-tested dependencies used across thousands of real projects.

Add to that the portability of distribution — a single npm install, or a standalone binary packaged with bun build or pkg — and you have an argument that's hard to dismiss when the goal is getting a client in front of users with as little friction as possible.

The team factor

There's one element benchmarks don't capture: the human cost. On a team where frontend and backend coexist, TypeScript allows sharing data models, validations, and HTTP clients between the web app and the CLI. Onboarding a new developer who already knows JS/TS takes hours, not weeks.

Companies like Microsoft or Google don't choose TypeScript because it's the most performant language available. They choose it because it shrinks the distance between an idea and a working client — and because that client can keep growing without breaking.

The verdict: why TypeScript wins (and why it doesn't)

🔴 Not for runtime performance
🟢 Yes, for productivity and developer experience (DX)
🟢 Yes, for a mature ecosystem and instant portability
🟢 Yes, for long-term maintainability
🟢 Yes, for reducing team cost and iteration speed

🛑 So when should you not use TypeScript?

TypeScript isn't universal. It occupies a very specific sweet spot, and knowing when to leave it is just as important as knowing when to lean in.

Every language choice should start by honestly answering six questions before committing to anything:

Ecosystem: Are there mature libraries for what you need?
Portability: Does it work smoothly on Windows, Linux, and macOS?
Performance: Do you need maximum speed or minimal resource usage?
Distribution: Standalone binary, script, or npm/pip package?
Team: What languages do your developers actually know well?
Evolution: Will this client grow significantly in complexity over time?

A language map: who wins in each scenario

Language	When to use it	Why not always
TypeScript	Interactive CLIs, evolving APIs, JS/TS teams, cross-platform distribution	Requires a runtime; not optimal for heavy computation
Go	Standalone binaries, infrastructure tooling, fast and simple CLIs	Rich interactivity takes more effort; more fragmented ecosystem
Rust	Performance-critical tools, intensive processing, memory safety requirements	Steep learning curve, slower development, costly builds
Python	Prototypes, automation scripts, AI/data integration	Distribution is painful, complex dependencies, runtime on the user's machine

🚀 A quick decision guide

TypeScript — Interactive cross-platform CLI with external APIs and a JS/TS team.
Go — Dependency-free binary anyone can run without installing anything.
Rust — Maximum performance or memory safety; development cost is acceptable.
Python — Quick prototype or internal tool where distribution doesn't matter.

"TypeScript isn't the best language for running code. It's one of the best for keeping software alive for years."