Posts

When the library is ESM-only and the app is still CommonJS

Sometimes you ship a CommonJS codebase - require(), older bundler defaults, or tooling that never moved to native ESM. Then you need a dependency that is ESM-only (often marked "type": "module" or exports that resolve only to .mjs). Migrating the whole project is the right long-term fix, but deadlines and risk often say no.

This post shows a small pattern: keep the project on CJS, but load one ESM module with a real dynamic import() ...

Create your own Lua engine

Embedding Lua in Node.js lets you run user-defined automation inside your process: fetch data, call an API, send mail, without a second runtime. wasmoon runs Lua 5.4 over WebAssembly. You bind JavaScript functions to Lua globals; scripts call those names like normal functions. Async JS returns Promises; from Lua you use :await() on the handle wasmoon gives you.

A typical pipeline (as in example-script.lua): pull Coinbase product (or candles), jsonStrin...

API Contracts without copy/paste and maintenance hell

In a polyglot microservice stack-Go, Java, Node, and Python talking over Kafka and gRPC-you quickly hit the same problem: who owns the .proto files, the topic lists, and the XML or JSON that multiple services must agree on? Copying files into every repo guarantees drift. Git submodules help a little but still feel heavy for small, frequent contract changes.

In one real engagement the landscape was several dozen microservices spread across mult...

The "one-man army" DevOps repository "pattern"

One way to run production without leaning on a full PaaS or a big cloud control plane is to keep a single Git repository that is only about operations on your own servers: Docker Compose stacks, nginx samples, deployment workflows, and shared scripts. Application repositories stay in charge of lint, test, build, and pushing images (often to a managed registry such as AWS ECR). The operations repo then owns what runs on the machine and how it is rolle...