DEV Community: Christian Vasquez

How I finally understood the Dependency Inversion Principle

Christian Vasquez — Wed, 28 Oct 2026 15:59:12 +0000

The Intro

Last stop. We made it to the D: the Dependency Inversion Principle.

This one is special because the other four kind of lead here. SRP gave us small classes. OCP taught us to add instead of edit. LSP and ISP gave us honest, tiny interfaces. DIP is where we decide who points at whom.

Buckle up, it's the one that changes how your main.ts looks forever.

The What

The definition has two parts:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

Four sentences that use "depend" five times. Cool cool cool.

Plain version: your business logic should not import your database driver. The important stuff (orders, invoices, rules) should sit at the top and know nothing about the plumbing (Postgres, Stripe, the file system). The plumbing should plug into the business logic, not the other way around.

Let's build an order checkout and watch the arrows flip.

The How

Here is OrderService, the "high-level" part of our store. It's the thing that knows what placing an order means:

// src/order-service.ts
import { PostgresOrderRepository } from './postgres-order-repository.js'
import { StripeClient } from './stripe-client.js'

export class OrderService {
  private readonly orders = new PostgresOrderRepository('postgres://localhost/shop')
  private readonly stripe = new StripeClient(process.env.STRIPE_KEY!)

  async placeOrder(customerId: string, total: number) {
    await this.stripe.charge(customerId, total)
    const id = await this.orders.insert({ customerId, total })
    console.log(`🧾 order ${id} placed`)
    return id
  }
}

The two "low-level" pieces:

// src/postgres-order-repository.ts
export class PostgresOrderRepository {
  constructor(private readonly url: string) {}

  async insert(order: { customerId: string; total: number }) {
    console.log(`🐘 INSERT INTO orders ... (${this.url})`)
    return 'ord_123'
  }
}

// src/stripe-client.ts
export class StripeClient {
  constructor(private readonly apiKey: string) {}

  async charge(customerId: string, amount: number) {
    console.log(`💳 stripe charged ${customerId} $${amount}`)
  }
}

And main:

// src/main.ts
import { OrderService } from './order-service.js'

await new OrderService().placeOrder('cus_42', 99)

Run it, it works, everyone goes home. 🏠

Now draw the arrows. Who imports whom?

OrderService  ──▶  PostgresOrderRepository
OrderService  ──▶  StripeClient

The most important class in the app depends on the two most replaceable classes in the app. That's upside down. And here's how you feel it:

Want to write a test for placeOrder()? Congratulations, your test now needs a running Postgres and a Stripe API key. For a function with two lines of logic.
Marketing wants a free-trial checkout with no payment? You're going to put an if inside OrderService to skip Stripe. Then another for the sandbox. Then...
The database team migrates to MySQL? Open OrderService, the one file that should never care.
Running it locally charges a real card if STRIPE_KEY is a real key. Ask me how I know. 😬

The service news its own dependencies, so it is welded to them. Let's cut the welds.

Step 1: the high-level module describes what it needs

OrderService needs two things: somewhere to put orders, and something that can take money. It should describe those in its own words, not in Postgres or Stripe words:

// src/order-service.ts
export interface NewOrder {
  customerId: string
  total: number
}

export interface OrderRepository {
  insert(order: NewOrder): Promise<string>
}

export interface PaymentGateway {
  charge(customerId: string, amount: number): Promise<void>
}

export class OrderService {
  constructor(
    private readonly orders: OrderRepository,
    private readonly payments: PaymentGateway,
  ) {}

  async placeOrder(customerId: string, total: number) {
    await this.payments.charge(customerId, total)
    const id = await this.orders.insert({ customerId, total })
    console.log(`🧾 order ${id} placed`)
    return id
  }
}

Two things to notice:

The interfaces live next to the service, because the service owns them. It says "this is what I need". That's the "abstractions belong to the high level" part.
The dependencies come in through the constructor. The service doesn't build them anymore. That's the "dependency injection" part, which is the everyday tool we use to follow DIP.

Step 2: the details plug in

// src/postgres-order-repository.ts
import type { OrderRepository, NewOrder } from './order-service.js'

export class PostgresOrderRepository implements OrderRepository {
  constructor(private readonly url: string) {}

  async insert(order: NewOrder) {
    console.log(`🐘 INSERT INTO orders ... (${this.url})`)
    return 'ord_123'
  }
}

// src/stripe-payment-gateway.ts
import type { PaymentGateway } from './order-service.js'

export class StripePaymentGateway implements PaymentGateway {
  constructor(private readonly apiKey: string) {}

  async charge(customerId: string, amount: number) {
    console.log(`💳 stripe charged ${customerId} $${amount}`)
  }
}

Look at the imports now. The Postgres class imports from order-service.ts. The arrow flipped:

PostgresOrderRepository  ──▶  OrderRepository (owned by OrderService)
StripePaymentGateway     ──▶  PaymentGateway  (owned by OrderService)

The plumbing points at the business logic. That's the "inversion".

Step 3: `main.ts` becomes the only place that knows everything

// src/main.ts
import { OrderService } from './order-service.js'
import { PostgresOrderRepository } from './postgres-order-repository.js'
import { StripePaymentGateway } from './stripe-payment-gateway.js'

const service = new OrderService(
  new PostgresOrderRepository('postgres://localhost/shop'),
  new StripePaymentGateway(process.env.STRIPE_KEY!),
)

await service.placeOrder('cus_42', 99)

Same output as before. But now the big one: let's write that test.

Step 4: the test that used to be impossible

// src/order-service.test.ts
import { test, expect } from 'vitest'
import { OrderService, type OrderRepository, type PaymentGateway } from './order-service.js'

class InMemoryOrders implements OrderRepository {
  saved: unknown[] = []
  async insert(order: unknown) {
    this.saved.push(order)
    return 'ord_test'
  }
}

class FakePayments implements PaymentGateway {
  charged: number[] = []
  async charge(_customerId: string, amount: number) {
    this.charged.push(amount)
  }
}

test('placing an order charges and saves it', async () => {
  const orders = new InMemoryOrders()
  const payments = new FakePayments()
  const service = new OrderService(orders, payments)

  const id = await service.placeOrder('cus_42', 99)

  expect(id).toBe('ord_test')
  expect(payments.charged).toEqual([99])
  expect(orders.saved).toHaveLength(1)
})

No Postgres. No Stripe. No mocking library. Two tiny classes that implement the interfaces OrderService asked for, and a test that runs in a millisecond.

And the free-trial checkout from earlier? new OrderService(repo, new NoChargeGateway()). Zero ifs inside the service.

The Why

Let's land this plane:

Business logic is the stable part; vendors are the volatile part. Stable code should never import volatile code. DIP is just that sentence turned into a rule.
Interfaces belong to the consumer. OrderService wrote PaymentGateway in its own vocabulary. Stripe adapted to it, not the other way around. When you swap Stripe for something else, the interface doesn't move.
Construction happens at the edge. main.ts (or your DI container, or your framework's wiring) is the only place that says new PostgresOrderRepository(...). Everything inside is handed what it needs.
Testing is a side effect, not a goal. We didn't "design for testability". We pointed the arrows the right way and the tests became easy on their own.

If you read my loosely coupled modules post, this should feel familiar. Same move, now with a name and a letter.

The Goodbye

And that's SOLID, all five letters, five tiny projects, five things we broke on purpose. If I had to compress the series into one line:

Small honest pieces, pointed at abstractions, glued together at the front door.

Thanks for riding along. Now go find a new keyword inside a service class and ask it why it's there. Happy coding 🤝

How I finally understood the Interface Segregation Principle

Christian Vasquez — Tue, 27 Oct 2026 13:14:00 +0000

The Intro

Letter four of five. Last post we broke a fat PaymentMethod into PaymentMethod + Refundable and the compiler started catching our bugs. Today we take that idea and make it the whole show.

The I: Interface Segregation Principle. The one with the longest name and the shortest explanation.

The What

Official words:

No code should be forced to depend on methods it does not use.

That's... actually pretty readable for once. Let me still make it concrete.

An interface is a menu. ISP says: don't hand someone a 40-item menu when they came in for coffee. Give them the coffee menu.

Let's build a smart home to see what happens when the menu gets too big.

The How

We start with a lamp and a speaker. The team decides every device should implement one common interface so the app can treat them all the same. Reasonable!

// src/smart-device.ts
export interface SmartDevice {
  turnOn(): void
  turnOff(): void
  setTemperature(celsius: number): void
  play(track: string): void
  pause(): void
  setBrightness(percent: number): void
}

Now let's implement the lamp:

// src/lamp.ts
import type { SmartDevice } from './smart-device.js'

export class Lamp implements SmartDevice {
  private on = false

  turnOn() {
    this.on = true
    console.log('💡 lamp on')
  }

  turnOff() {
    this.on = false
    console.log('💡 lamp off')
  }

  setBrightness(percent: number) {
    console.log(`💡 brightness ${percent}%`)
  }

  setTemperature() {
    throw new Error('A lamp has no thermostat')
  }

  play() {
    throw new Error('A lamp cannot play music')
  }

  pause() {
    throw new Error('A lamp cannot pause music')
  }
}

Three real methods. Three methods that exist only to throw. The lamp is 50% apology.

The speaker is the same story in reverse: play() and pause() are real, setBrightness() and setTemperature() are throws. And the thermostat implements six methods to use one.

Now the app layer. We want a "good night" routine that turns everything off:

// src/routines.ts
import type { SmartDevice } from './smart-device.js'

export function goodNight(devices: SmartDevice[]) {
  for (const device of devices) {
    device.turnOff()
  }
}

Works. But then someone writes "movie mode":

export function movieMode(devices: SmartDevice[]) {
  for (const device of devices) {
    device.setBrightness(20)
    device.play('intro.mp3')
  }
}

Run it with a lamp in the list and play() throws. Run it with a speaker and setBrightness() throws. The function signature says "give me any SmartDevice" and that's a lie. If you read the last post, you just spotted a Liskov violation. ISP is how we stop creating them.

And one more pain you don't see until month three: add lockDoor() to SmartDevice for the new smart lock and every existing device, including the lamp, has to grow another throwing method. One interface change, twelve files touched. Ouch.

Step 1: split the menu by capability

What can devices actually do? Let's list the verbs and group them:

// src/capabilities.ts
export interface Switchable {
  turnOn(): void
  turnOff(): void
}

export interface Dimmable {
  setBrightness(percent: number): void
}

export interface Thermostat {
  setTemperature(celsius: number): void
}

export interface MediaPlayer {
  play(track: string): void
  pause(): void
}

Four tiny interfaces. Each one is a single idea.

Step 2: devices pick what they can honestly do

// src/lamp.ts
import type { Switchable, Dimmable } from './capabilities.js'

export class Lamp implements Switchable, Dimmable {
  turnOn() {
    console.log('💡 lamp on')
  }

  turnOff() {
    console.log('💡 lamp off')
  }

  setBrightness(percent: number) {
    console.log(`💡 brightness ${percent}%`)
  }
}

// src/speaker.ts
import type { Switchable, MediaPlayer } from './capabilities.js'

export class Speaker implements Switchable, MediaPlayer {
  turnOn() {
    console.log('🔊 speaker on')
  }

  turnOff() {
    console.log('🔊 speaker off')
  }

  play(track: string) {
    console.log(`🔊 playing ${track}`)
  }

  pause() {
    console.log('🔊 paused')
  }
}

Zero throws. The lamp is 100% lamp.

Step 3: routines ask for the capability they use

// src/routines.ts
import type { Switchable, Dimmable, MediaPlayer } from './capabilities.js'

export function goodNight(devices: Switchable[]) {
  for (const device of devices) {
    device.turnOff()
  }
}

export function movieMode(lights: Dimmable[], players: MediaPlayer[]) {
  for (const light of lights) {
    light.setBrightness(20)
  }
  for (const player of players) {
    player.play('intro.mp3')
  }
}

// src/main.ts
import { Lamp } from './lamp.js'
import { Speaker } from './speaker.js'
import { goodNight, movieMode } from './routines.js'

const lamp = new Lamp()
const speaker = new Speaker()

movieMode([lamp], [speaker])
goodNight([lamp, speaker])

Output:

💡 brightness 20%
🔊 playing intro.mp3
💡 lamp off
🔊 speaker off

Try to sneak the speaker into the lights array and TypeScript stops you before you even hit save. 🛑

Step 4: the smart lock test

New device, new capability:

// src/capabilities.ts
export interface Lockable {
  lock(): void
  unlock(): void
}

// src/door-lock.ts
import type { Lockable } from './capabilities.js'

export class DoorLock implements Lockable {
  lock() {
    console.log('🔒 locked')
  }

  unlock() {
    console.log('🔓 unlocked')
  }
}

Files touched besides the new ones: zero. The lamp didn't even blink.

The Why

No more apology methods. If a class throws "not supported", the interface was too fat. Split it until every implementation is honest.
Functions say exactly what they need. goodNight(devices: Switchable[]) tells you in the signature that it only flips switches. Documentation for free.
Adding a capability doesn't ripple. New interface, new class, done. Existing devices are untouched.
Tests get tiny. Want to test goodNight()? Pass an object with turnOn and turnOff. You don't need to fake six methods to test two.
It is cheap in TypeScript. Interfaces compile to nothing. Four small ones cost exactly as much as one big one: zero bytes.

Rule of thumb: if you can't describe an interface in one short sentence ("something you can switch on and off"), it's probably two interfaces.

The Goodbye

Four down. The final letter is the D, Dependency Inversion, and it's the one that ties the whole series together. If you've read my post about loosely coupled modules you already have a head start.

Until then: find an interface with more than five methods and ask it, politely, what it really wants to be. Happy coding 🤝

How I finally understood the Liskov Substitution Principle

Christian Vasquez — Mon, 26 Oct 2026 22:03:26 +0000

The Intro

Halfway through SOLID! We are at the L, the one with the scary name: the Liskov Substitution Principle.

If the previous two felt like common sense with fancy labels, this one is the first that usually catches people off guard. I have shipped the exact bug we are about to write. More than once. 🙃

The What

The original definition is a math paper from 1987 and reads like one:

If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

Let me translate: if your code works with the parent, it must also work with any child, without surprises. No instanceof checks, no "oh but not that one".

The usual example is squares and rectangles. I have never once had a square in production, so let's do something you will actually run into: payments and refunds.

The How

Our store accepts a few ways to pay. Each one can charge and refund:

// src/payment-method.ts
export abstract class PaymentMethod {
  abstract charge(amount: number): Promise<void>
  abstract refund(amount: number): Promise<void>
}

// src/card-payment.ts
import { PaymentMethod } from './payment-method.js'

export class CardPayment extends PaymentMethod {
  async charge(amount: number) {
    console.log(`💳 charged $${amount}`)
  }

  async refund(amount: number) {
    console.log(`💳 refunded $${amount}`)
  }
}

// src/paypal-payment.ts
import { PaymentMethod } from './payment-method.js'

export class PaypalPayment extends PaymentMethod {
  async charge(amount: number) {
    console.log(`🅿️ charged $${amount}`)
  }

  async refund(amount: number) {
    console.log(`🅿️ refunded $${amount}`)
  }
}

And the part that uses them never cares which one it got:

// src/refund-service.ts
import type { PaymentMethod } from './payment-method.js'

interface Order {
  id: string
  total: number
  paidWith: PaymentMethod
}

export class RefundService {
  async refundAll(orders: Order[]) {
    for (const order of orders) {
      await order.paidWith.refund(order.total)
      console.log(`✅ order ${order.id} refunded`)
    }
  }
}

Beautiful. Substitutable. Barbara Liskov would be proud.

Then product adds gift cards. Gift cards can be charged, obviously. But legal says gift cards can't be refunded to cash. So we write the "obvious" thing:

// src/gift-card-payment.ts
import { PaymentMethod } from './payment-method.js'

export class GiftCardPayment extends PaymentMethod {
  async charge(amount: number) {
    console.log(`🎁 charged $${amount}`)
  }

  async refund() {
    throw new Error('Gift cards cannot be refunded')
  }
}

It compiles. TypeScript is happy. The PR gets approved. 🚢

Three weeks later a product gets recalled and support runs the "refund everyone who bought it" script:

// src/main.ts
import { RefundService } from './refund-service.js'
import { CardPayment } from './card-payment.js'
import { GiftCardPayment } from './gift-card-payment.js'

const orders = [
  { id: 'A1', total: 40, paidWith: new CardPayment() },
  { id: 'A2', total: 25, paidWith: new GiftCardPayment() },
  { id: 'A3', total: 60, paidWith: new CardPayment() },
]

await new RefundService().refundAll(orders)

Output:

💳 refunded $40
✅ order A1 refunded
Error: Gift cards cannot be refunded

Order A1 refunded. Order A2 blew up. Order A3? Never happened. Customer A3 is now writing a one-star review.

That's a Liskov violation. RefundService was written against PaymentMethod, and the contract of PaymentMethod says "I can refund". GiftCardPayment said it was a PaymentMethod and then broke the promise at runtime.

The usual "fix" makes it worse:

if (order.paidWith instanceof GiftCardPayment) continue

Now RefundService knows about gift cards. Tomorrow it has to know about store credit. Then crypto. The whole point of the base class was to not know.

Step 1: stop lying in the type

The real problem is that the parent promised something not every child can keep. So let's make the promise smaller:

// src/payment-method.ts
export interface PaymentMethod {
  charge(amount: number): Promise<void>
}

export interface Refundable {
  refund(amount: number): Promise<void>
}

(Yes, we swapped the abstract class for interfaces. There was no shared code in the base anyway.)

Step 2: each method tells the truth

// src/card-payment.ts
import type { PaymentMethod, Refundable } from './payment-method.js'

export class CardPayment implements PaymentMethod, Refundable {
  async charge(amount: number) {
    console.log(`💳 charged $${amount}`)
  }

  async refund(amount: number) {
    console.log(`💳 refunded $${amount}`)
  }
}

// src/gift-card-payment.ts
import type { PaymentMethod } from './payment-method.js'

export class GiftCardPayment implements PaymentMethod {
  async charge(amount: number) {
    console.log(`🎁 charged $${amount}`)
  }
}

No refund() on the gift card. No throw. It just doesn't claim to be something it isn't.

Step 3: ask for exactly what you need

// src/refund-service.ts
import type { Refundable } from './payment-method.js'

interface RefundableOrder {
  id: string
  total: number
  paidWith: Refundable
}

export class RefundService {
  async refundAll(orders: RefundableOrder[]) {
    for (const order of orders) {
      await order.paidWith.refund(order.total)
      console.log(`✅ order ${order.id} refunded`)
    }
  }
}

And now the best part. Go back to main.ts and try to pass a gift card order into refundAll():

Type 'GiftCardPayment' is not assignable to type 'Refundable'.
  Property 'refund' is missing in type 'GiftCardPayment'.

The compiler caught it. At build time. Not at 2 PM on recall day.

Whoever writes the refund script now has to decide up front what to do with gift card orders (issue store credit, email the customer, whatever). The decision moved from "a crash in a loop" to "a red squiggle in the editor".

The Why

Let's be explicit about the lesson, because it is subtle:

Inheritance is a promise, not a shortcut. "GiftCard is a PaymentMethod" sounded right in English. In code, it meant "GiftCard can do everything PaymentMethod can do", and that was false.
A method that throws NotSupported is a red flag. If a child has to disable a parent's method, the parent's contract is too big. Shrink it.
Callers depend on the smallest thing they need. RefundService needs refunds, so it asks for Refundable. Not PaymentMethod. Not CardPayment.
The type system becomes your QA. Every wrong combination fails to compile instead of failing in production.

If you remember one sentence: a subclass may do more than its parent, never less.

The Goodbye

Did you notice that fixing the L made us split one fat interface into two thin ones? That's not a coincidence. That's the I (Interface Segregation) knocking on the door, and it's up next.

Go search your codebase for throw new Error('not supported'). I'll wait. Happy coding 🤝

How I finally understood the Open/Closed Principle

Christian Vasquez — Mon, 19 Oct 2026 13:30:00 +0000

The Intro

Part two of our SOLID road trip. Last time we took a class with three jobs and gave it two coworkers. Today we are going after a different kind of monster: the if/else chain that grows a new branch every sprint.

Letter O: the Open/Closed Principle. Sounds like a sign on a shop door. It kind of is.

The What

Textbook time:

Software entities (classes, modules, functions) should be open for extension, but closed for modification.

Open and closed at the same time? Thanks, Schrödinger.

Here's the plain-English version that made it click for me: you should be able to add a new behavior without editing the code that already works. Add a file, not an else.

To feel it, we are going to build a discount calculator for an online store. Business starts simple:

Students get 10% off.
That's it. One rule. Life is good.

The How

Version one, straight from the heart:

// src/discount.ts
export interface Customer {
  type: 'regular' | 'student'
}

export function discountFor(customer: Customer, subtotal: number): number {
  if (customer.type === 'student') {
    return subtotal * 0.1
  }
  return 0
}

// src/main.ts
import { discountFor } from './discount.js'

console.log(discountFor({ type: 'student' }, 100)) // 10
console.log(discountFor({ type: 'regular' }, 100)) // 0

Clean. Tiny. Everyone claps. 👏

Then marketing shows up. Every. Single. Week.

Week 2: "VIP members get 20%."
Week 3: "Orders over $200 get 5% extra, but only for regulars."
Week 4: "Black Friday! 30% for everyone, but just on the 28th."
Week 5: "Can students AND VIPs stack? No wait, only the biggest one. Actually, let's talk."

Watch what happens to our innocent function:

// src/discount.ts
export interface Customer {
  type: 'regular' | 'student' | 'vip'
}

export function discountFor(customer: Customer, subtotal: number, today = new Date()): number {
  let discount = 0

  if (customer.type === 'student') {
    discount = subtotal * 0.1
  } else if (customer.type === 'vip') {
    discount = subtotal * 0.2
  } else if (subtotal > 200) {
    discount = subtotal * 0.05
  }

  const isBlackFriday = today.getMonth() === 10 && today.getDate() === 28
  if (isBlackFriday) {
    discount = Math.max(discount, subtotal * 0.3)
  }

  return discount
}

Every new rule means:

Re-opening a function that was already working.
Re-reading the whole thing to make sure the new branch doesn't fight with the old ones.
Re-running every existing test because, let's be honest, you touched everything.

And the function knows about dates now. Why does a discount calculator know what day it is? 🤨

This is a function that is open for modification. Every change goes inside it. The principle says: let's flip that.

Step 1: describe what a rule looks like

All these rules have the same shape: "given a customer and a subtotal, how much do I knock off?". Let's write that down:

// src/discount-rule.ts
import type { Customer } from './customer.js'

export interface DiscountRule {
  apply(customer: Customer, subtotal: number): number
}

Step 2: one small class per rule

// src/rules/student-discount.ts
import type { DiscountRule } from '../discount-rule.js'
import type { Customer } from '../customer.js'

export class StudentDiscount implements DiscountRule {
  apply(customer: Customer, subtotal: number): number {
    return customer.type === 'student' ? subtotal * 0.1 : 0
  }
}

// src/rules/vip-discount.ts
import type { DiscountRule } from '../discount-rule.js'
import type { Customer } from '../customer.js'

export class VipDiscount implements DiscountRule {
  apply(customer: Customer, subtotal: number): number {
    return customer.type === 'vip' ? subtotal * 0.2 : 0
  }
}

// src/rules/big-order-discount.ts
import type { DiscountRule } from '../discount-rule.js'
import type { Customer } from '../customer.js'

export class BigOrderDiscount implements DiscountRule {
  apply(customer: Customer, subtotal: number): number {
    return customer.type === 'regular' && subtotal > 200 ? subtotal * 0.05 : 0
  }
}

Each file is boring on purpose. You can read one in five seconds and know exactly what it does.

Step 3: the calculator stops caring about rules

// src/discount-calculator.ts
import type { DiscountRule } from './discount-rule.js'
import type { Customer } from './customer.js'

export class DiscountCalculator {
  constructor(private readonly rules: DiscountRule[]) {}

  discountFor(customer: Customer, subtotal: number): number {
    const discounts = this.rules.map((rule) => rule.apply(customer, subtotal))
    return Math.max(0, ...discounts)
  }
}

Look at that. No if about students. No if about VIPs. It just asks every rule "what do you think?" and keeps the best answer. The business rule "customers get the biggest discount, no stacking" lives in one line.

Step 4: assemble at the front door

// src/main.ts
import { DiscountCalculator } from './discount-calculator.js'
import { StudentDiscount } from './rules/student-discount.js'
import { VipDiscount } from './rules/vip-discount.js'
import { BigOrderDiscount } from './rules/big-order-discount.js'

const calculator = new DiscountCalculator([
  new StudentDiscount(),
  new VipDiscount(),
  new BigOrderDiscount(),
])

console.log(calculator.discountFor({ type: 'student' }, 100)) // 10
console.log(calculator.discountFor({ type: 'regular' }, 250)) // 12.5

Step 5: the Black Friday test

Here comes the moment of truth. Marketing wants Black Friday. What do we touch?

// src/rules/black-friday-discount.ts
import type { DiscountRule } from '../discount-rule.js'
import type { Customer } from '../customer.js'

export class BlackFridayDiscount implements DiscountRule {
  constructor(private readonly today: () => Date = () => new Date()) {}

  apply(_customer: Customer, subtotal: number): number {
    const date = this.today()
    const isBlackFriday = date.getMonth() === 10 && date.getDate() === 28
    return isBlackFriday ? subtotal * 0.3 : 0
  }
}

And one line in main.ts:

new BlackFridayDiscount(),

That's the entire change. DiscountCalculator was not opened. StudentDiscount was not opened. Their tests didn't even notice something happened.

Closed for modification, open for extension. We extended the system by adding a file.

The Why

What did we actually gain?

New rules don't risk old rules. The student discount literally cannot break because you added Black Friday. They live in different files.
Each rule is testable alone. new StudentDiscount().apply({ type: 'student' }, 100) → 10. Done. No giant table of cases for one mega-function.
The date thing got cleaner by accident. Only BlackFridayDiscount cares about dates, and it takes a today() function so you can test it without changing your system clock.
Deleting a rule is a delete, not a surgery. Marketing cancels the VIP program? Remove one line from main.ts, delete one file. No else branches to re-balance.

Now, the honest caveat: you don't do this on day one with a single rule. The first version with one if was fine. The signal to refactor is the second time you open the same function to add a sibling branch. Once you see the pattern, pull the rules out before week five arrives.

The Goodbye

Two letters down, three to go. Next up is the L, Liskov Substitution, where we find out why a subclass that throws "not supported" is a trap, and what to do instead.

Go count the else if branches in your biggest function. If you need two hands, you know what to do. Happy coding 🤝

How I finally understood what idempotency is

Christian Vasquez — Sun, 18 Oct 2026 11:14:55 +0000

The Intro

Idempotency. Eight letters, five syllables, and a word I pretended to understand in meetings for an embarrassingly long time.

It kept showing up in API docs, in Stripe's dashboard, in that one coworker's code review comments. I nodded. I did not know.

So today we are going to build the bug that makes idempotency matter, charge a fake customer twice, and then fix it. By the end, "idempotent" will be a word you can use in a sentence without sweating.

The What

Here is the dictionary version:

An operation is idempotent if performing it multiple times has the same effect as performing it once.

That's it. No, really, that's the whole concept. The hard part is noticing where it matters.

My favorite non-code example: the elevator button. Press it once, the elevator comes. Press it twelve times because you are late... the elevator still comes once. The button is idempotent. Impatient people everywhere rely on this.

Now compare that to a vending machine button. Press it twice and you get two sodas and one empty wallet. Not idempotent.

Most of your app is an elevator button. Some of it is a vending machine. The trouble starts when a vending machine gets pressed twice by accident.

The How

Let's build a tiny "pay for an order" endpoint with Express and TypeScript. One route, one fake payment provider, zero databases:

// src/server.ts
import express from 'express'

const app = express()
app.use(express.json())

const orders = new Map<string, { total: number; paid: boolean }>()
orders.set('ord_1', { total: 50, paid: false })

async function chargeCard(amount: number) {
  console.log(`💳 charged $${amount}`)
  return `ch_${Math.random().toString(36).slice(2, 8)}`
}

app.post('/orders/:id/pay', async (req, res) => {
  const order = orders.get(req.params.id)
  if (!order) return res.status(404).json({ error: 'order not found' })

  const chargeId = await chargeCard(order.total)
  order.paid = true

  res.json({ chargeId })
})

app.listen(3000, () => console.log('listening on :3000'))

Start it with npx tsx src/server.ts and pay for the order:

curl -X POST localhost:3000/orders/ord_1/pay

💳 charged $50

Lovely. Fifty bucks, one charge, everyone's happy. 🎉

Now let's be realistic about the internet. Your frontend sends the request, the server charges the card, and then... the Wi-Fi hiccups. The response never arrives. The frontend (or the HTTP client, or the user mashing the button) does what every client does when it sees a timeout: it retries.

curl -X POST localhost:3000/orders/ord_1/pay
curl -X POST localhost:3000/orders/ord_1/pay

💳 charged $50
💳 charged $50

Two charges. One order. One customer opening a support ticket with a lot of capital letters. 😬

Our endpoint is a vending machine. Every press costs money. And notice that the client did nothing wrong, retrying on a timeout is the correct thing to do. The endpoint just wasn't ready for it.

Step 1: look before you charge

The cheapest fix is to make the endpoint check its own state first:

app.post('/orders/:id/pay', async (req, res) => {
  const order = orders.get(req.params.id)
  if (!order) return res.status(404).json({ error: 'order not found' })

  if (order.paid) {
    return res.json({ chargeId: order.chargeId, alreadyPaid: true })
  }

  const chargeId = await chargeCard(order.total)
  order.paid = true
  order.chargeId = chargeId

  res.json({ chargeId })
})

(Add chargeId?: string to the order type so TypeScript stops yelling.)

Run the double curl again:

💳 charged $50

One charge. The second request got a polite "yep, already done" with the same chargeId as the first. Press the elevator button all you want now.

That's idempotency in one if. The operation "pay order 1" now has the same result whether you call it once or five hundred times.

Step 2: the sneaky gap

Before you ship, let's be honest about a hole. What if the two requests arrive at the same time? Both read paid === false, both charge, both set paid = true. Our if didn't help.

In a real app with a real database you close that gap by making the "check and mark" step atomic. In Postgres that's something like:

UPDATE orders SET paid = true WHERE id = $1 AND paid = false

If that update touches one row, you won the race, go charge the card. If it touches zero rows, someone else got there first, return their result. Same idea as our if, just one that the database enforces so two requests can't both pass.

Step 3: idempotency keys (the grown-up version)

There's one more case the paid flag can't cover: what if the client legitimately wants to pay twice? Say, two different orders that happen to look identical, or a "buy again" button.

The industry answer is an idempotency key. The client generates a random ID per attempt and sends it in a header. The server remembers which keys it has seen:

const seen = new Map<string, unknown>()

app.post('/orders/:id/pay', async (req, res) => {
  const key = req.header('Idempotency-Key')
  if (!key) return res.status(400).json({ error: 'Idempotency-Key header required' })

  if (seen.has(key)) {
    return res.json(seen.get(key))
  }

  const order = orders.get(req.params.id)
  if (!order) return res.status(404).json({ error: 'order not found' })

  const chargeId = await chargeCard(order.total)
  order.paid = true

  const response = { chargeId }
  seen.set(key, response)
  res.json(response)
})

curl -X POST localhost:3000/orders/ord_1/pay -H "Idempotency-Key: abc-123"
curl -X POST localhost:3000/orders/ord_1/pay -H "Idempotency-Key: abc-123"

💳 charged $50

Same key, one charge, identical response both times. A retry is now safe by design: the client keeps the same key while retrying, and only generates a new one when it genuinely wants a new action.

This is exactly what Stripe, PayPal and friends ask you to send. Now you know why. 🧠

(In production, seen lives in your database or Redis with an expiry, not in a Map. But the shape is the same.)

Step 4: wait, we trust the client to pick the key?

Yep. And it has to be that way. Look at it from the server's side: two identical POST /orders/ord_1/pay requests show up. Is that a flaky network resending one payment, or a customer who genuinely wants to buy twice? The server has no idea. Only the thing that decided to pay knows if it's deciding again. So the client tags the decision, and retries carry the same tag.

What we don't do is trust the client blindly. The server adds a few guardrails:

Scope the key to the user. Look it up as (userId, key), not just key. Nobody can replay or collide with someone else's request.
Fingerprint the body. Store a hash of the request along with the key. Same key, different body? That's not a retry, that's someone being clever. Answer with a 422.
Expire keys. Keep them for a day or so, then forget them. A retry from last month is not a retry.
Lock while in flight. If a second request with the same key arrives while the first is still running, make it wait (or return a 409). That also closes the race from Step 2.

With those four, the client can only ever use a key to say "that same thing again, please". Which is exactly what we wanted.

The Why

Let's zoom out, because this is bigger than payments:

Retries are everywhere. HTTP clients retry. Message queues redeliver. Users double-click. Cron jobs overlap. If your operation isn't idempotent, every one of those is a bug waiting for a bad Wi-Fi day.
Idempotent code is restartable code. A script that imports 10,000 rows and crashes at row 7,000? If each row is an "insert or update", you just run it again. If it's "insert", you now have 7,000 duplicates and a long afternoon.
HTTP already has opinions. GET, PUT and DELETE are supposed to be idempotent. POST is not. That's why "create order" is a POST and "set order status" is a PUT. Delete something twice and the second call should say "fine, it's gone" rather than crash.
It's a design question, not a library. No package makes your code idempotent. You get it by asking, for every action: "what happens if this runs twice?" and making the answer "nothing new".

The one-sentence version to keep in your pocket: pressing it again should never make things worse.

The Goodbye

Next time someone drops "we should make that idempotent" in a review, you can nod and know. Even better, you can go find the endpoint in your app that charges, emails or creates something, run it twice, and see what happens.

Go press some elevator buttons. Happy coding 🤝

How I finally understood the Single Responsibility Principle

Christian Vasquez — Sat, 17 Oct 2026 23:26:26 +0000

The Intro

Welcome to the first stop of a five-part road trip through SOLID. Five letters, five principles, five posts, one tiny project per post that we break on purpose and then put back together.

If you have ever opened a file, scrolled, scrolled some more, and whispered "who hurt you?"... this one is for you.

Today's letter: S, the Single Responsibility Principle. Or, as I like to call it, "the one where your class has too many jobs".

The What

Let's get the textbook definition out of the way first:

A class should have only one reason to change.

Easy. Done. See you in the next post...

Okay, okay, I'll stop. That sentence is correct and also kind of useless when you are starting out, because nobody tells you what a "reason to change" even looks like.

So let's build something. We are going to write a small invoice feature for a coffee shop. It needs to:

Add up the items in the order.
Print a nice receipt as text.
Save the invoice so the owner can find it later.

Three tasks. Pay attention to that number.

The How

Here is how most of us (me included) would write it on day one:

// src/invoice.ts
import { writeFile } from 'node:fs/promises'

interface Item {
  name: string
  price: number
  quantity: number
}

export class Invoice {
  constructor(
    private readonly id: string,
    private readonly items: Item[],
  ) {}

  total(): number {
    return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0)
  }

  print(): string {
    const lines = this.items.map(
      (item) => `${item.quantity} x ${item.name} ... $${(item.price * item.quantity).toFixed(2)}`,
    )
    return [`Invoice #${this.id}`, ...lines, `TOTAL: $${this.total().toFixed(2)}`].join('\n')
  }

  async save(): Promise<void> {
    await writeFile(`./invoices/${this.id}.txt`, this.print())
  }
}

And the usual main:

// src/main.ts
import { Invoice } from './invoice.js'

const invoice = new Invoice('0001', [
  { name: 'Latte', price: 4.5, quantity: 2 },
  { name: 'Croissant', price: 3, quantity: 1 },
])

console.log(invoice.print())
await invoice.save()

Run it with npx tsx src/main.ts and you get a lovely receipt in the terminal and a file in ./invoices/0001.txt.

Works on my machine! 🙌

Now let's play a game called "what happens next week". Three tickets land on your desk:

Ticket 1: "Taxes! We need 10% tax on the total." (money logic)
Ticket 2: "Can the receipt be HTML so we can email it?" (formatting)
Ticket 3: "Let's store invoices in Postgres instead of text files." (storage)

Three completely different people asked for these: the accountant, the designer, and the backend lead. And every single one of them is going to make you open... invoice.ts.

That's the smell. Invoice has three reasons to change because it has three jobs: doing math, drawing text, and talking to the disk.

And it gets worse:

Want to test total()? Your test file now imports something that touches the file system. Fun.
The HTML ticket is going to add a second print() method, then a format flag, then an if...
The Postgres ticket drags a database driver into a class whose only real purpose was "add some numbers".

Let's untangle it.

Step 1: name the jobs

Before writing any code, say the responsibilities out loud:

Calculating what the customer owes.
Rendering the invoice for a human to read.
Persisting the invoice somewhere.

Three sentences, three classes. That's the whole trick, honestly.

Step 2: keep the data dumb

Invoice becomes a plain bag of data plus the math that belongs to it:

// src/invoice.ts
export interface Item {
  name: string
  price: number
  quantity: number
}

export class Invoice {
  constructor(
    readonly id: string,
    readonly items: Item[],
  ) {}

  total(): number {
    return this.items.reduce((sum, item) => sum + item.price * item.quantity, 0)
  }
}

No fs import. No formatting. Just an invoice being an invoice.

Step 3: one class to draw it

// src/invoice-printer.ts
import type { Invoice } from './invoice.js'

export class InvoicePrinter {
  printText(invoice: Invoice): string {
    const lines = invoice.items.map(
      (item) => `${item.quantity} x ${item.name} ... $${(item.price * item.quantity).toFixed(2)}`,
    )
    return [`Invoice #${invoice.id}`, ...lines, `TOTAL: $${invoice.total().toFixed(2)}`].join('\n')
  }
}

When the HTML ticket arrives, you add a printHtml() method right next to printText(). Invoice never hears about it.

Step 4: one class to store it

// src/invoice-repository.ts
import { writeFile } from 'node:fs/promises'
import type { Invoice } from './invoice.js'
import { InvoicePrinter } from './invoice-printer.js'

export class InvoiceRepository {
  private readonly printer = new InvoicePrinter()

  async saveToFile(invoice: Invoice): Promise<void> {
    await writeFile(`./invoices/${invoice.id}.txt`, this.printer.printText(invoice))
  }

  async saveToDatabase(invoice: Invoice): Promise<void> {
    // Pretend this is your favorite database client.
    // The point is: nobody outside this file needs to know how it's done.
    console.log(`INSERT INTO invoices (id, total) VALUES ('${invoice.id}', ${invoice.total()})`)
  }
}

The Postgres ticket? Open invoice-repository.ts, fill in saveToDatabase(). Nothing else in the project cares.

Step 5: wire it up

// src/main.ts
import { Invoice } from './invoice.js'
import { InvoicePrinter } from './invoice-printer.js'
import { InvoiceRepository } from './invoice-repository.js'

const invoice = new Invoice('0001', [
  { name: 'Latte', price: 4.5, quantity: 2 },
  { name: 'Croissant', price: 3, quantity: 1 },
])

console.log(new InvoicePrinter().printText(invoice))
await new InvoiceRepository().saveToFile(invoice)

Run it again. Same receipt, same file, zero drama.

(Yes, it's TypeScript again. Swap the syntax for your favorite language and nothing about the idea changes.)

The Why

Let's replay those three tickets with the new layout:

Taxes → open invoice.ts, touch total(). The printer and the repository don't care.
HTML receipt → open invoice-printer.ts, add printHtml(). The invoice math and the storage don't care.
Postgres → open invoice-repository.ts, touch saveToDatabase(). The math and the receipt don't care.

Each file has exactly one person who would ever ask you to edit it. That is what "one reason to change" means in practice: one stakeholder, one job, one file.

Some bonus points you get for free:

InvoiceRepository has two methods, but still one job: storing invoices. "Where" is a detail, "storing" is the responsibility. (In the last post of this series we'll see how to hide even that detail.)
Invoice is now trivial to unit test. No disk, no mocks, just numbers in and numbers out.
Code reviews get smaller because a tax change can't accidentally break the receipt layout.
Git blame stops looking like a crime scene with four people editing the same 200-line class.

One warning before you go wild: SRP is not "every class has one method". A class can have ten methods and still have one job. The question is always "who would ask me to change this?". If the answer is "several unrelated people", split it. If the answer is "one", leave it alone.

The Goodbye

That's the S. Next time we grab the O (Open/Closed) and find out why that if/else chain for discounts is about to become your least favorite part of the codebase.

Until then, go find a class with too many jobs and give it some coworkers. Happy coding 🤝

How I finally undestood what loosely coupled modules are

Christian Vasquez — Sat, 17 Oct 2026 15:18:49 +0000

Photo by Glen Carrie on Unsplash

The Intro

Here goes another one of those "it finally clicked" posts. This time it's about something you've probably heard a hundred times in code reviews, job interviews and conference talks: loosely coupled modules.

Everyone says it's good. Almost nobody shows you a case where you actually feel the difference.

So today we are going to build a tiny app that sends an email, break it, and then fix it in a way that will make you say "oh... that's why".

The What

First things first. If we ask Wikipedia, this is what we get:

In computing and systems design, a loosely coupled system is one in which components are weakly associated (have breakable relationships) with each other, and thus changes in one component least affect existence or performance of another component.

Crystal clear, right? Great, post over, go enjoy your day...

Nah, I'm messing with you. Definitions never clicked for me either.

Let's make it real instead. Picture this: we are building a web app with a "Sign up" form. When someone signs up, we want to send them a welcome email.

Simple, right?

To send real emails we are going to use Resend, which has a free tier and a very small API. And since we are using TypeScript and Node, the code is going to be as short as it gets.

The How

Here's the first (and most honest) version of our code:

// src/welcome.ts
import { Resend } from 'resend'

const resend = new Resend(process.env.RESEND_API_KEY)

export async function sendWelcomeEmail(to: string) {
  await resend.emails.send({
    from: 'onboarding@resend.dev',
    to,
    subject: 'Welcome!',
    text: 'Thanks for signing up 🤝',
  })
}

And our main:

// src/main.ts
import { sendWelcomeEmail } from './welcome.js'

await sendWelcomeEmail('chris@example.com')
console.log('Sent!')

Run it with a valid RESEND_API_KEY and the email shows up in our inbox a second later.

Ship it! 🚀

Now, let's say you keep working on the app. You run main.ts 20 more times while testing the sign up flow.

What happens?

Every run sends a real email.
Your coworkers get spammed when they test with their own address.
Resend's free tier starts counting those emails.
And if someone forgets to set RESEND_API_KEY... boom, the app crashes.

Not great, huh? 😅

What we really want is: send real emails only in production. Everywhere else, just let me see the email without it going anywhere.

Turns out there's a tool made exactly for that: Mailpit. It's a fake SMTP server with a little web UI where you can read every email your app "sent". We can run it with Docker in one line:

# docker-compose.yml
services:
  mailpit:
    image: axllent/mailpit
    ports:
      - '1025:1025' # SMTP (your app talks to this one)
      - '8025:8025' # Web UI (you look at this one)

Run docker compose up -d and open http://localhost:8025. Empty inbox, for now.

Since Mailpit speaks SMTP, we can talk to it with Nodemailer. Let's add that to our function:

// src/welcome.ts
import { Resend } from 'resend'
import nodemailer from 'nodemailer'

const resend = new Resend(process.env.RESEND_API_KEY)
const smtp = nodemailer.createTransport({ host: 'localhost', port: 1025 })

export async function sendWelcomeEmail(to: string) {
  const message = {
    from: 'onboarding@resend.dev',
    to,
    subject: 'Welcome!',
    text: 'Thanks for signing up 🤝',
  }

  if (process.env.NODE_ENV === 'production') {
    await resend.emails.send(message)
  } else {
    await smtp.sendMail(message)
  }
}

Run main.ts again (without NODE_ENV), refresh Mailpit and... there it is!

Problem solved! 🎉

Now, be honest with me. Did something feel a little bit off while reading that code?

Let me help you out:

sendWelcomeEmail() is supposed to be about welcoming people. But now it also knows about Resend, Nodemailer, SMTP ports and NODE_ENV.
The next function (sendPasswordResetEmail()) will need the exact same if/else. And the next one. And the next one.
Want to try a third provider some day? Have fun finding every if in the project.
And the Resend client gets created at import time even when we will never use it. That's where the "forgot the API key" crash comes from.

This, right here, is what tightly coupled code looks like. Our welcome email is glued to two vendors and one environment variable. You cannot touch one without touching the others.

Let's fix it.

Step 1: describe what we need, not who does it

What does our app actually need? To send an email. That's it. It doesn't care who delivers it.

So let's write that down as an interface:

// src/mail/mailer.ts
export interface Email {
  to: string
  subject: string
  text: string
}

export interface Mailer {
  send(email: Email): Promise<void>
}

Notice there's no from here. The provider knows what address it is allowed to send from, our app doesn't need to.

Step 2: one class per provider

Now we give each vendor its own little box. Each class is the only file in the whole project that knows that vendor exists:

// src/mail/resend-mailer.ts
import { Resend } from 'resend'
import type { Email, Mailer } from './mailer.js'

export class ResendMailer implements Mailer {
  private readonly client: Resend

  constructor(apiKey: string) {
    this.client = new Resend(apiKey)
  }

  async send(email: Email) {
    const { error } = await this.client.emails.send({
      from: 'onboarding@resend.dev',
      ...email,
    })
    if (error) throw new Error(error.message)
  }
}

// src/mail/mailpit-mailer.ts
import nodemailer, { type Transporter } from 'nodemailer'
import type { Email, Mailer } from './mailer.js'

export class MailpitMailer implements Mailer {
  private readonly transport: Transporter

  constructor(host = 'localhost', port = 1025) {
    this.transport = nodemailer.createTransport({ host, port })
  }

  async send(email: Email) {
    await this.transport.sendMail({ from: 'dev@localhost', ...email })
  }
}

(Yes, this is TypeScript. If your thing is Kotlin, C#, Go or whatever else, the same idea maps over almost one to one. Pinky promise.)

Step 3: the welcome email goes back to being boring

// src/welcome.ts
import type { Mailer } from './mail/mailer.js'

export async function sendWelcomeEmail(mailer: Mailer, to: string) {
  await mailer.send({
    to,
    subject: 'Welcome!',
    text: 'Thanks for signing up 🤝',
  })
}

Look at the imports. No Resend. No Nodemailer. No process.env. Just the shape of a thing that can send emails.

Step 4: decide once, at the front door

There's exactly one place in the app that knows which environment we are in, and that's where the app starts:

// src/main.ts
import { ResendMailer } from './mail/resend-mailer.js'
import { MailpitMailer } from './mail/mailpit-mailer.js'
import { sendWelcomeEmail } from './welcome.js'

const isProduction = process.env.NODE_ENV === 'production'

const mailer = isProduction
  ? new ResendMailer(process.env.RESEND_API_KEY!)
  : new MailpitMailer()

await sendWelcomeEmail(mailer, 'chris@example.com')
console.log('Sent!')

Now let's try it both ways.

Locally:

npx tsx src/main.ts

Refresh http://localhost:8025 and the email is right there. No API key, no internet, no spam.

And "in production":

NODE_ENV=production RESEND_API_KEY=re_123... npx tsx src/main.ts

Check your real inbox. Same code, same sendWelcomeEmail(), different delivery guy.

Quick note on the test account: Resend's free tier lets you send from onboarding@resend.dev only to the email you signed up with. So use that one as your to while testing and you will get the email without having to verify a domain.

The Why

So, what did we actually win here? Let's count:

sendWelcomeEmail() has one reason to change: the content of the welcome email. Not the vendor, not the environment.
The NODE_ENV check exists in exactly one line of the whole project. Add 10 more kinds of emails and that line doesn't move.
Want to try a third provider (SES, Postmark, you name it)? Write one new class, change one line in main.ts. Nothing else even knows it happened.
The Resend SDK is only imported by ResendMailer. If you never create one, you never touch it. The "forgot the API key" crash is gone for free.
And testing becomes stupidly easy: pass a Mailer that just pushes emails into an array and assert on it. No mocking libraries, no network.

That's what people mean when they say loosely coupled. Our welcome email and Resend used to be glued together. Now they are just two things that happen to agree on a tiny contract called Mailer.

The welcome email doesn't know Resend exists. Resend doesn't know the welcome email exists. And main.ts is the only one who introduces them to each other.

I know it looks like extra ceremony for a two-line email. The day you have to swap a vendor on a Friday afternoon and only one file changes, you will remember this post.

The Goodbye

And that's a wrap. If you've read How I finally understood what Encapsulation is, you might notice this is the same trick at a bigger scale: push the messy details behind a small, dull contract and let everything else lean on the dull thing. Dull is good. Dull doesn't wake you up at 3 AM.

Go send some fake emails. Happy coding 🤝

Introducing Bencho: an open-sourced self-hosted peformance testing bechmark app

Christian Vasquez — Sat, 17 Oct 2026 02:09:03 +0000

While creating an app for my wife and landing a new job, both projects I'll be working on are in high need of performance testing to make sure we are "production ready" in a way. So, I decided to make a full stack web app that uses K6 under the hood to handle all the complexity for me and provide metrics that only I can see running it locally in a Docker container. But, if you wish, you could self-host it on a VPS just as easily with something like Coolify, for example.

As of right now, you can do simple GET /endpoint tests or simulate more complicated user flows with step by step series with randomized delays between each step.

If you are interested, take a look at https://github.com/chrisvasqm/bencho

Introducing Bencho A self hosted web app for performance testing benchmarks to make K6 more user-friendly. With a single docker compose command you can start testing your systems within seconds. https://github.com/chrisvasqm/bencho

Christian Vasquez — Sat, 17 Oct 2026 02:00:14 +0000

GitHub - chrisvasqm/bencho: A user-friendly self-hosted performance benchmark app. · GitHub

A user-friendly self-hosted performance benchmark app. - chrisvasqm/bencho

github.com

How did you end up in this career?

Christian Vasquez — Sun, 31 Mar 2024 04:34:49 +0000

The rise of great job opportunities have lead to software being made by people with a wide range of skills and different backgrounds.

So, I would love to read your story of how you ended up in this career?

How do you get back into studying?

Christian Vasquez — Fri, 29 Jul 2022 14:11:00 +0000

Doing Page Object Model the Right Way - Part 2

Christian Vasquez — Tue, 22 Mar 2022 00:00:01 +0000

For this video, I've decided to take some time to refactor some parts of the code and improve it a tiny bit before we head over to Part 3.

Now, based on previous feedback from Part 1, I decided to keep this (and the future parts) short and sweet being 10 minutes or so.

I hope you enjoy it and I'll see you in the next one!

DEV Community: Christian Vasquez

How I finally understood the Dependency Inversion Principle

The Intro

The What

The How

Step 1: the high-level module describes what it needs

Step 2: the details plug in

Step 3: main.ts becomes the only place that knows everything

Step 4: the test that used to be impossible

The Why

The Goodbye

How I finally understood the Interface Segregation Principle

The Intro

The What

The How

Step 1: split the menu by capability

Step 2: devices pick what they can honestly do

Step 3: routines ask for the capability they use

Step 4: the smart lock test

The Why

The Goodbye

How I finally understood the Liskov Substitution Principle

The Intro

The What

The How

Step 1: stop lying in the type

Step 2: each method tells the truth

Step 3: ask for exactly what you need

The Why

The Goodbye

How I finally understood the Open/Closed Principle

The Intro

The What

The How

Step 1: describe what a rule looks like

Step 2: one small class per rule

Step 3: the calculator stops caring about rules

Step 4: assemble at the front door

Step 5: the Black Friday test

The Why

The Goodbye

How I finally understood what idempotency is

The Intro

The What

The How

Step 1: look before you charge

Step 2: the sneaky gap

Step 3: idempotency keys (the grown-up version)

Step 4: wait, we trust the client to pick the key?

The Why

The Goodbye

How I finally understood the Single Responsibility Principle

The Intro

The What

The How

Step 1: name the jobs

Step 2: keep the data dumb

Step 3: one class to draw it

Step 4: one class to store it

Step 5: wire it up

The Why

The Goodbye

How I finally undestood what loosely coupled modules are

The Intro

The What

The How

Step 1: describe what we need, not who does it

Step 2: one class per provider

Step 3: the welcome email goes back to being boring

Step 4: decide once, at the front door

The Why

The Goodbye

Introducing Bencho: an open-sourced self-hosted peformance testing bechmark app

Introducing Bencho A self hosted web app for performance testing benchmarks to make K6 more user-friendly. With a single docker compose command you can start testing your systems within seconds. https://github.com/chrisvasqm/bencho

GitHub - chrisvasqm/bencho: A user-friendly self-hosted performance benchmark app. · GitHub

How did you end up in this career?

How do you get back into studying?

Doing Page Object Model the Right Way - Part 2

Step 3: `main.ts` becomes the only place that knows everything