fn(args, deps) and Hexagonal Architecture

Hexagonal architecture often gets introduced with a lot of diagrams, vocabulary, and ceremony.

Ports. Adapters. Application core. Inbound and outbound boundaries.

That framing is useful, but it can also make the idea feel more abstract than it really is.

A simpler way to understand it is this:

Hexagonal architecture is mostly about keeping business logic independent from delivery and infrastructure details.

One practical way to do that in plain TypeScript is this shape:

fn(args, deps);

Where args is the input for this use case, and deps is the set of external capabilities it needs. You can read that as: data in, capabilities in.

In plain TypeScript, fn(args, deps) is a simple way to implement the core idea of hexagonal architecture without turning the pattern into ceremony.

Composition Roots and fn(args, deps)

A lot of developers hear "dependency injection" and immediately think of containers, decorators, registration APIs, lifecycle scopes, and framework magic.

That reaction is understandable.

But that association often leads people to overcomplicate a problem that has a much simpler starting point.

At its core, dependency injection just means this:

Pass collaborators in explicitly instead of reaching for them implicitly.

One of the simplest ways to do that in plain TypeScript is this shape:

fn(args, deps)

Where args is call-specific input and deps is the set of collaborators the function needs.

You can read that as: data in, capabilities in.

fn(args, deps) is flexible enough to support composition, testing, and clean application wiring without forcing you into a DI framework.

AI Makes It Easy to Build. That Doesn’t Mean We Should Ship More

Dax is spot on.

sent this to the team today

everything great comes from being able to delay gratification for as long as possible

and it feels like we're collectively losing our ability to do that pic.twitter.com/HlIpY86eJn

— dax (@thdxr) March 10, 2026

When it comes to using AI, be like Luke

I love using AI coding tools. As someone who definitely gets their money’s worth, I feel more productive than ever.

But sometimes, just like Obi-Wan told Luke, you need to let go.

Control the instinct to reach for AI all the time.

Trust yourself.

Why Matt Pocock Is Right About Making Codebases AI Agents Love

Matt Pocock is once again on the money in his video “How To Make Codebases AI Agents Love”.

Here's why I agree with him.

If You Only Enforce One Rule for AI Code, Make It fn(args, deps)

AI coding agents can generate code faster than you can reason about it.

There is one pattern that works for both new and legacy codebases because you can adopt it as a non-breaking change.

Every function has exactly two inputs: data (args) and capabilities (deps).

Without a clear constraint, generated code becomes the wild west, you can't reliably reason about what a function depends on, what it does, or how to compose it.

fn(args, deps) is that constraint

For existing code, start with:

functionName(args, deps = defaultDeps)

Dependencies are visible, not implicit.

There’s no framework and no package to install.

Visualising Awaitly Workflows with awaitly-visualizer

You have an Awaitly workflow: a few steps, some dependencies, typed results. It works. When someone asks "what does this do?" or you need to debug a run, you're left tracing through code.

What if you could see the same workflow as a diagram? awaitly-visualizer plugs into your workflow's events and turns them into that picture. For a checkout that runs fetchCart, validateCart, processPayment, then completeOrder, you get output like this:

┌── checkout ────┐
│  ✓ fetchCart   │
│  ✓ validateCart│
│  ✓ processPayment
│  ✓ completeOrder
│  Completed     │
└────────────────┘

Same idea as Mermaid flowcharts: steps, order, success and failure. This post walks through adding it step by step. All of the code below lives in a test in the repo so you can run it yourself.

No, the sun does not shine out of Claude’s backside

As of today, Opus 4.5 is the best coding model I've used. That is not praise by vibes. That is, after building libraries and utilities that fixed problems I could not solve with the tools I was using before.

The progress is impressive.

However, it’s not all sunshine and rainbows, as people on social media and YouTube claim.

Stop Throwing Errors. Awaitly Makes Async Error Handling Actually Work

We've all written this code:

const lambdaHandler = async () => {
  try {
    const db = await connectToDb();
    const result = await errorHandler({ taskId, error }, { db });
    return { statusCode: 200, body: { message: 'Success', task: result } };
  } catch (error) {
    return { statusCode: 500, body: { message: 'Error' } };
  }
}

That catch (error) swallows everything. Was it a "task not found"? A database connection failure? A permissions issue? Who knows.

Throwing exceptions for expected failures is like using GOTO. You lose the thread.

Awaitly fixes this by treating errors as data, not explosions. This guide teaches the patterns one concept at a time.

Instrumenting Message Queues? Autotel Handles the Ceremony

The OneUptime team is spot on in their Instrument Message Queues with OpenTelemetry post.

Inject trace context on the producer, extract on the consumer; use PRODUCER and CONSUMER span kinds; set semantic conventions (messaging.system, messaging.destination.name, messaging.operation, Kafka partition/offset/consumer group).

They show the raw OpenTelemetry code. It's comprehensive. It's also verbose. Every team ends up re-implementing the same patterns: inject, extract, span kinds, semantic attributes, error handling.

We've all been there: copying "best practice" code from blog posts and adapting it for our broker.

Their key insight:

For batch processing, use a batch span with links or child spans to contributing traces.

But there's still a gap...