Coder Legion - Recent posts tagged dx

TypeScript DeepPath: Achieving Indestructible Types in Nested Objects

Tue, 28 Apr 2026 18:02:12 +0000

If you're writing TypeScript code but still using string to reference keys in nested objects (like translation files or configurations), you're missing out on half of the compiler's power.

Mastering Recursive Template Literal Types allows you to create strict accesses that the IDE understands perfectly, rooting out silent "undefined" errors at runtime. It's not about over-typing; it's about designing a developer experience (DX) where the editor won't let you make mistakes.

Why you need DeepPath

Real Validation: "api.endpionts.users" stops compiling automatically.
Full path autocompletion: The IDE natively suggests all possible combinations.
Maintenance: If you change a key in the config, the compiler breaks wherever it's used.

The silent bug

Before looking at the solution, let's see the problem. Using string to access deep properties hides bugs that TypeScript should easily catch:

// Typical in i18n or configs
function getConfig(path: string) { /* ... */ }

// Compiles perfectly, fails in production
const userUrl = getConfig("api.enpoints.users");
// The error? You wrote "enpoints" instead of "endpoints". 
// TS doesn't warn you, and your app returns undefined at runtime.

The pattern: Recursive DeepPath

The secret lies in combining recursion with Template Literal Types. See how we can extract all possible paths from an object as if they were a dot-joined string:

type DeepPath<T> = T extends object
  ? {
      [K in keyof T & string]: T[K] extends object
        ? `${K}` | `${K}.${DeepPath<T[K]>}`
        : `${K}`;
    }[keyof T & string]
  : never;

// Usage example:
interface AppConfig {
  api: {
    endpoints: {
      users: string;
      posts: string;
    };
    timeout: number;
  };
  theme: "dark" | "light";
}

type ConfigPaths = DeepPath<AppConfig>;
// Result: "api" | "theme" | "api.endpoints" | "api.timeout" | "api.endpoints.users" | "api.endpoints.posts"

Developer Evolution: Using `satisfies`

I often see configurations annotated manually (const config: AppConfig = ...). This "flattens" the type and erases the specific inference of your actual data.

For DeepPath<T> to work perfectly, it needs to know the exact literal structure. That's where the satisfies operator comes in: it validates that you meet the interface but keeps the literals intact.

// The "Wizard" Path
const config = {
  api: {
    endpoints: {
      users: "/users",
      posts: "/posts"
    },
    timeout: 5000
  },
  theme: "dark"
} satisfies AppConfig;

// 'config.theme' remains as the literal "dark"
// and we can navigate any path with full safety:
function getProp(path: DeepPath<AppConfig>) {
  // implementation logic...
}

Bonus Track: Return Type Inference (DeepValue)

Validating the input string is great, but true level 500 is inferring the exact return type based on that string. If I request "api.timeout", TypeScript should know it returns a number.

We combine DeepPath with another recursive type called DeepValue:

type DeepValue<T, P> = P extends `${infer K}.${infer Rest}`
  ? K extends keyof T
    ? DeepValue<T[K], Rest>
    : never
  : P extends keyof T
    ? T[P]
    : never;

// Pure magic:
function getConfig<P extends DeepPath<AppConfig>>(path: P): DeepValue<AppConfig, P> {
  // implementation (e.g., using lodash/get)
  return {} as any; 
}

const url = getConfig("api.endpoints.users"); // inferred as string
const timeout = getConfig("api.timeout"); // inferred as number

The cost of magic (Trade-offs)

No advanced pattern comes for free. In production, abusing this recursion has real technical limits that will hit you if the object grows too large.

Pros	Cons
Zero typo-related runtime errors.	Compiler performance: generates massive unions that can slow down the IDE.
100% safe and traceable refactoring.	Recursion limits: TS might halt if the object is excessively deep.
Native autocompletion without extra plugins.	Complexity: Dynamic arrays make inference much harder.

Conclusion

This technique drastically reduces headaches. By implementing these types, you force the compiler to validate the actual structure of your data before the build. If you work on mid-sized projects with predictable configurations or i18n systems, this pattern saves you hours of debugging.

If you're interested in taking type safety to the next level, check out my other posts on campa.dev.

Too Many Chefs, One Kitchen

Sun, 26 Oct 2025 07:20:05 +0000

Most teams don’t start with architecture problems. They start by building. Fast. A small product, a tight team, a system that does just enough. And for a while, that’s the right choice. You’re shipping. You’re learning. You’re moving.

But at some point, usually when the business starts to grow, something shifts. Releases become slower. Teams start stepping on each other. And what once felt nimble now feels stuck.

Why?

The instinctive answer is technical debt — maybe the system just needs refactoring. Or maybe it’s a process problem. But often, the real issue is more structural.

Your architecture no longer matches your organization’s needs.

A common sign of this mismatch is deployment friction. One team wants to ship a small feature. But they have to wait. Wait for another team to finish testing. Wait for someone else’s changes to stabilize. Wait because even a tiny change means releasing everything.

The system works — technically. But it’s like sharing one kitchen with five different chefs.
One team’s baking. Another’s cleaning fish. Someone else just spilled oil on the floor.
You can coordinate. You can take turns. But you can’t move freely. And eventually, the kitchen becomes the bottleneck.

This is what monoliths often feel like: centralized, coupled, and fragile under pressure.

Microservices don’t solve everything, but they restructure the problem. By giving each team their own “station,” they reduce the coordination tax. Teams can deploy independently. They can fail independently. They can learn faster, without always waiting for the rest of the kitchen to finish cooking.

That doesn’t mean microservices are always better. Just that at a certain scale — of product, of people, of change — they become a way to align architecture with the shape of the organization.

What follows is a simple example — not to show how to “do microservices,” but to make clear what kind of friction they solve, and why it starts to matter more as teams grow. Think of it as a zoom-in on what happens when structure starts slowing teams down — not because of failure, but because of how things are bundled.

⸻

Imagine a SaaS platform offering payment processing and loyalty features for small businesses. It’s been growing steadily, and the codebase — a monolith — has carried the company through its early traction. Releases are coordinated, large, and slow, but manageable.

Then a new opportunity arises.

The product team identifies a small pricing optimization — tweaking loyalty point accrual rules to encourage repeat purchases. It only affects existing users. Forecast models suggest it could increase annual revenue by 2%. It’s a focused change, with minimal risk, and the team wants to run a fast A/B test to validate it.

But it can’t ship.

It’s bundled into the same release as a compliance update — one that applies exclusively to new customer onboarding and affects shared reporting logic. The loyalty change, meanwhile, is for existing users. The two have nothing to do with each other, but because they live in the same monolith, they move together. You just want to add a bit of seasoning and send the plate out. But the kitchen won’t let anything leave until the whole menu is rewritten.

So the loyalty experiment waits. And each day of delay costs more than just projected revenue — it delays validation. No test runs. No feedback arrives. The team can’t iterate. Momentum slows. The problem isn’t the work. It’s the structure that forces unrelated changes to move together.

Microservices would let the loyalty team ship on their own terms. They could release early, run the test, learn what works, and improve the feature before the week’s over. And perhaps more importantly — they’d own the outcome from end to end.

Architecture changes behavior.

When teams can move without waiting, they start testing more, listening sooner, and improving faster. Not because of a mandate — but because the system allows it.
But that freedom doesn’t come for free.

⸻

It’s easy to see microservices as the fix: split the kitchen, give each team their own space, and let them move fast. And when done right, it works.

But it also comes with a new kind of burden.

Every kitchen now needs its own tools, its own cleanup, its own supply of ingredients. And to make something great, those ingredients need to be fresh, high-quality, and well-managed — and that adds not just effort, but real operational cost.

Microservices give you autonomy — but only if you're mature enough to handle it.

That means good testing. Clear ownership. Reliable observability. Solid deployment pipelines. If any of those fall short, the service breaks — or worse, breaks others silently.

Monoliths concentrate complexity in one place. Microservices distribute it.
Which means you don’t reduce complexity — you just move it.

If the teams aren’t ready — if the ingredients aren’t right — you won’t get autonomy. You’ll get inconsistency. Drift. And a lot of mess to clean up.

And so the question becomes: when do you make the shift?

You don’t need five kitchens on day one.
A single shared space works just fine — until it doesn’t.

Microservices aren’t a milestone to reach.
They’re a response to something felt: friction, delays, coordination overhead that’s no longer manageable. If your teams are shipping smoothly, if ownership is clear, if feedback loops are tight — stay where you are.

But when the line to cook is longer than the cooking itself — when teams spend more time waiting than building — it’s worth asking whether the kitchen still fits.

Structure should serve the pace and shape of your product.
If it starts slowing you down, it’s time to reshape it.

The best teams aren’t just fast.
They’re intentional about the systems they build around them — not just in code, but in how they move.

Architecture is just one part of that system. But it’s powerful.
Because when it’s right, it doesn’t just unblock delivery.
It unlocks behavior.