Itay Wolfish

No backend, but a real database

Sat, 04 Jul 2026 00:00:00 GMT

I built Scrolls Buddy, a planning tool for a MapleStory private-server community. The audience is about twenty people a day. That number is the whole story of the architecture, because it made one decision for me before I wrote any code: there would be no backend.

Not "a small backend." None. No server to secure, no database to operate, no bill that grows with traffic. The interesting engineering was refusing to give up any real capability to honour that — because "no backend" usually means "no persistence, no analytics, no data," and I wanted all three.

Here is how each one survived the constraint.

Persistence: SQLite in the browser

The app has session history, saved item configurations, and scrolling outcomes I want to query — "show me this session's profit," "what did I roll last time." That is relational data, and localStorage is a bad place to keep it the moment you want to ask it a question: it is a string key-value store, and you end up hand-rolling a query engine over JSON blobs.

So the app runs SQLite compiled to WebAssembly, persisted into the browser through IndexedDB. Real SQL, real tables, real queries — the database just happens to live in the tab instead of on a host. The data never leaves the device, which means there is nothing to breach, nothing to migrate, and nothing to back up. For a single-user tool, the user's own browser is a perfectly good place for their data to live.

External data: pulled, not hosted

Item names, icons, and base stats are not mine to own — they are game data with canonical public sources. Instead of scraping and hosting them, the app fetches from public game-data APIs on demand and lets Cloudflare's edge cache the responses. No asset pipeline, no scraper to babysit, no copy of someone else's data drifting out of date. The client stays thin over sources that are already authoritative.

Analytics: first-party, still serverless

The one thing people assume forces a backend is knowing whether anyone uses your thing. It does not. The app sends product events to PostHog — but through a first-party /ingest path on its own domain rather than straight to PostHog's servers. That rewrite keeps the telemetry first-party and lets it survive ad blockers, while the actual event storage is PostHog's problem, not mine. I run no analytics infrastructure and still get a real funnel: it is how I know the tool holds ~20 daily actives and which features earn their place.

What runs it

A static React/Vite bundle on Cloudflare Pages, deployed on push, on a subdomain of a domain I already manage. SQLite-WASM for the data layer, PostHog for the feed, public APIs for game data. It is a PWA, so once the data is cached it works offline — which follows naturally from the logic and storage already being local.

Total cost to keep running: zero. Total servers to operate: zero.

The point

The reflex, when you want persistence and analytics, is to reach for a backend. Most of the time you are reaching for it out of habit. Between WebAssembly builds of real databases, edge caching in front of public data, and analytics vendors that only need a beacon, a surprising amount of "backend" is just a client-side concern wearing a server costume.

Scoping the tool to twenty people is what made this possible — and, honestly, what made it finished. The serverless architecture was not a clever trick bolted on afterward; it was the direct consequence of building the right size of thing for the actual need. The full write-up, including the MapleRoyals scrolling problem it solves, is on the project page.

Author once, run in every agent: how we share AI skills at Echo

Sat, 04 Jul 2026 00:00:00 GMT

At Echo we lean on AI coding agents hard, and we do not standardize on one. I use Claude Code, someone else lives in Cursor, another engineer runs Codex. That is deliberate — the same "engineers as product owners" instinct that shapes how we build also means people pick the tool that fits their head.

The problem is that a coding skill — how we run the tests, what the PR-review checklist is, which boring-stack conventions we hold to — is the same regardless of which agent you opened. But the moment you write it down, every harness wants it in its own format. Claude Code wants SKILL.md files under .claude/skills/. Cursor wants .mdc rules with its own frontmatter. Codex reads one aggregated AGENTS.md with a size budget. Write the convention three times, and within a week the three copies have drifted and nobody trusts any of them.

I built adeptability to kill that drift. This is how it works and how we actually use it.

The idea: skill as source, harness as build target

adept treats one canonical skill as the source of truth and every harness's format as a build target — the same relationship your source code has to compiled artifacts.

You author once: a SKILL.md with YAML frontmatter and a markdown body, plus optional scripts/ and references/ sidecars. Then:

adept sync     # render the canonical skill into every enabled harness
adept status   # init state, libraries, harnesses, and drift at a glance

adept sync writes .claude/skills/run-tests/SKILL.md, .cursor/rules/run-tests.mdc, the right block in Codex's AGENTS.md, and so on — each in that harness's native format, with the frontmatter translation, activation rules, and size budgets handled per harness. Subagents work the same way: one canonical agent definition renders into .claude/agents/, Cursor's agents, Codex's, and the rest.

Edits happen inside harnesses, so sync goes both ways

The naive version of this tool is one-directional and breaks the first time someone tweaks a rule inside Cursor. adept handles it: a content-hash state machine classifies every rendered file as synced, ahead, behind, or diverged. Edit a skill inside a harness and adept sync-from pulls that edit back into the canonical source, then adept sync republishes it everywhere. There is no lockfile — drift is computed from hashes at read time, so there is no second artifact to keep honest.

How we share at Echo

Two layers, because we have two kinds of skills.

Org-wide conventions live in a versioned library. The stuff every repo should know — our code-as-liability conventions, the boring-stack choices, a shared PR-reviewer subagent that reviews to our standard — lives in a library with a remote and a ref. A project commits only the reference, not the content; adept materializes the skills into a per-machine store on demand. A teammate clones a repo, runs adept, and gets the same skills and the same reviewer agent rendered into whichever harness they use. Bump the library ref and everyone moves together.

Project-specific skills are committed in the repo. How this service runs its tests, builds, and deploys is not org-wide knowledge — it belongs to the repo. Those canonical skills sit in the project, and adept sync renders them locally. Clone, sync, and your agent already knows how to run the test suite and ship the thing, no matter which agent it is.

The payoff is concrete: a convention is written once and true everywhere. When we change how we review PRs, I edit one skill and bump the library — I am not chasing the same change through three formats and hoping the Cursor copy and the Codex copy agree.

Scheduled work, too

Some of what we want agents to do is not interactive. adept loop add composes a discovery skill, an evaluator agent, and a cron skeleton in one shot — a scheduled loop that goes looking for something and acts on it. It is the same author-once model applied to automation instead of an interactive session.

Why I think this is the right shape

Echo's whole engineering bet is that code is a liability and the solution is the asset. Skills are the same. The convention — the judgment about how we work — is the asset worth keeping. Which harness's file format it happens to be trapped in is pure liability, and duplicating it across three of them is liability times three. adept makes the skill the durable thing and the harness format disposable, which is exactly the right way round.

adeptability is a single static Go binary, installable via Homebrew, go install, Nix, or a curl script. The project page has the design decisions, the repo has the code, and the docs cover every command and a harness-by-harness breakdown of exactly what gets emitted where.

Typescript Unions and Discriminating Unions

Tue, 08 Dec 2020 00:00:00 GMT

I really really like typescript .... really.

A subject I would like to write about today is Union types. And how to discriminate Unions with literal type, it's a technique I use a lot in my work when working on possible states of the application (Backend/Frontend).

So what is Union?

As the set theory claims Union is the combination of sets.

Our set is typescript definitions !!!

Take user loading state as example:

interface UserLoadFailed{
    statusCode: number
    message: string
}
interface UserLoading{
   isLoading: boolean
   statusCode: number
}
interface UserLoaded{
   data: User
   statusCode: number
}

So when declaring a function to get the current user state:

function getUserState(): UserLoadFailed | UserLoading | User;

const user = getUserState();

console.log(user.statusCode) // is ok because in all of our "sets" / types we have common field named statusCode

console.log(user.data)
/* we will get an error as we are referencing
the Union but `data` exists only in one "set"/Type in the union,
the only fields we can reach are the ones that intersecting (shared across all union types)*/

Discriminating with literal typed field for the problem 💪

Changing our interfaces a bit and creating a Union Type

interface UserLoadFailed {
    status: "Failed";
    statusCode: number;
    message: string;
}

interface UserLoading {
   status: "Loading";
   isLoading: boolean;
}

interface UserLoaded {
    status: "Loaded";
    data: User;
}

type UserStateUnion = UserLoadFailed | UserLoading | UserLoaded;

function getUserState(): UserStateUnion;

const user = getUserState()

And now you are union type-safe 😇

If you want to discover more about Unions go ahead and open the handbook typescript handbook

Dockerizing NestJS application and Debugging

Tue, 24 Nov 2020 00:00:00 GMT

A Long journey involved with Dockerizing a NestJS app and debug efficiently.

This will be a "step-by-step" and a little explaining so you don't just copy-paste 😃.

Installation 🔨

NestJS - a NodeJS framework for server API mainly aims to be developed with TypeScript (but there's also a JS version).

Installing NestJS convenience Command Line Interface to bootstrap the project.
```
npm install -g @nestjs/cli
// OR
yarn global add @nestjs/cli
```
Docker and Docker-Compose - Dockerizing/Packaging into a standardized unit for development, like Virtual Machines but much lighter and efficient, you can read more.

Docker is really awesome, I raise the entire deployment of multi micro-services architecture in a couple of seconds using docker-compose a wrapper CLI around docker-engine.
IDE - I will be using Visual Studio Code

I will be using Visual Studio Code reference mostly in the Debugging part.

Project set up ⚒

Now with all of these awesome tools in our hands let's set up everything 💪!

Starting with NestJS -
```
nest --help
```
Pretty self-explanatory and just to get familiar with the tools this CLI grants us.
So we can create a new app -
```
nest new <the name of your app>
```
Nest will bootstrap the project you will be prompted to select your favorite package management CLI.

Your project folder will contain the following files/folders
Let's move to Dockerfile and .dockerignore files -
```
touch Dockerfile .dockerignore
```
Dockerfile - we describe a set of instructions that eventually will build our Docker Image.

.dockerignore - we describe a set of file/folder paths to be ignored and wouldn't copy into the build context of the Dockerfile.
Writing our Dockerfile and .dockerignore -
```
# Dockerfile
FROM node:lts

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

CMD ["npm","run","start"]
```
Breaking things up -

FROM node:lts - FROM tells our build context which image are we basing/extending on in our build context, node:lts i choose an official image of NodeJS so basically it is IMAGE:TAG where TAG stands for version typically aligned with SemVer (Semantic Versioning).

So node:lts is NodeJS precompiled Docker image with Npm & Yarn CLI installed (You can view their Dockerfile here).

IF I was to create a Java project I would have probably use an OpenJDK image to compile my Java project.

WORKDIR - short term for the working directory, we define in which directory are we going to work on INSIDE THE BUILD CONTEXT AND THE FUTURE CREATED IMAGE.

Browsing the Internet you will see diverse answers around where the WORKDIR should be, eventually, it is your preference!

I use /app most of the time.

NOTE - it is best practice to not move through directories outside of the WORKDIR in the further instructions given to the Dockerfile (build context...)

COPY package*.json ./ - COPY would copy files from side to side, the left side is the host computer (where you ran docker build if haven't run it from a different folder using the -f flag), so I tell the build context COPY my package.json and package-lock.json to ./ so if you are a bit familiar with "FileSystems" . stands for the current directory and I add the / just to be sure that I copy multiple files into the current folder.

RUN npm install - RUN executes the command as you do in your Console (be aware we are always in the WORKDIR we specified).

So I just ran npm install to install all dependencies/devDependencies inside the build context.

COPY . . - after installed everything successfully (hopefully) we copy the entire project directory into our working directory.

I usually copy just the package*.json and install before copying everything so if something fails with npm install it will break the build before I try to copy everything else.

CMD ["npm","run","start"] - the command that will be triggered when we raise the image to a running container.

So I will be using a script as specified in the package.json.

Note for docker images of CLI you better use ENTRYPOINT you can read more here.

That's it for now with the Dockerfile.

# .dockerignore
dist
node_modules
*.log

I Specify which file/folders I wouldn't like to be copied into my image.

node_modules - I would like the node_modules to be installed from the image as all of the modules which require binaries of Linux like (gcc) will be compiled using the binaries that are pre-compiled into the node:lts image.

dist - Later when we modify the Dockerfile for build/production purposes I wouldn't like that in any case my host dist folder will be copied and affect my build output.

*.log - I just don't like log files :).

Building the image and running it 🐳

Build -
```
docker build -t <your image name>:1.0.0 .
```
We initiate a docker command to build an image with a specified tag (-t) at the . current directory (where our project is and the docker files).

This can take a couple of seconds/minutes depending on your project dependencies and Ethernet speed.
Running the ready image -
```
docker run <you image name>:1.0.0
```
Your Console STDIN will be directed into the newly created container of the image you built.

You can CTRL+C to get out but it will shut your container down.

To keep the container running you can run it detached using the -d flag when using the docker run.

If running in detached you can initiate commands on the running container using the docker exec command.

If running in detached in order to stop the container you can use docker container stop < name of the *container* >/< hash of the *container* >

Docker-Compose orchestrate Docker infrastructure 🐳

A bit of overkill for a single service but for 2 and above this is just fantastic.

touch docker-compose.yml

We create a docker-compose.yml file (default file name by the CLI of docker-compose)

⚠ docker-compose.yml is a bit long to explain so i documented on the code itself and you can read more here

version: "3.8" # Specify the version of docker-compose we will use

services: # Specify our services
  backend: # define our first service
    build: # define the build context
      dockerfile: ./Dockerfile # the docker file to use by default it looks for Dockerfile in the context dir so we can omit this key :)
      context: . # where is the build context folder
    image: custom_image_name:1.0.0 # in case we are building the built image name will be from the image entry
    environment:
      NODE_ENV: development
      PORT: 3000
    ports:
      - 3000:3000 # <host port> : <container port>
      - 9229:9229 # 9229 is the default node debug port
    volumes:
        - "/app/node_modules" # save the compiled node_modules to anonymous volume so make sure we don't attach the volume to our host node_modules
        - "./:/app" # link our project directory to the docker  directory so any change will get updated in the running container and also we will benefit from sourcemaps for debugging

So now when we have in our hands the docker-compose file ready just:

docker-compose up -d

# '-d' - for detached

The Docker-compose on the first time will build the image and raise it entirely as specified in the docker-compose.yml

Why compose? for our first service without using docker-compose inorder to raise it as specified we had to build it and then run it as so: docker run -d -p '3000:3000' -p '9229:9229' -e 'NODE_ENV=development' -e 'PORT=3000' -v '${PWD}:/app' -v '/app/node_modules' and thats for one service imagine your self raising microservice architecture of 8+ services.... INSANITY 😵.

Debugging 🐛

package.json

// change start:debug script
"start:debug": "nest start --debug 0.0.0.0:9229 --watch",

By using 0.0.0.0 address inside the docker we allow access from the external network (our host) into the debugger in the container.

Docker-compose.yml we must override the default command in order to start with the debug command:

version: "3.8"

services:
  backend:
    build:
      dockerfile: ./Dockerfile
      context: .
    image: custom_image_name:1.0.0
    environment:
      NODE_ENV: development
      PORT: 3000
    ports:
      - 3000:3000
      - 9229:9229
    volumes:
        - "/app/node_modules"
        - "./:/app"
    command: npm run start:debug # override entry command

VSCode:

It will create a launch.json file where you specify the debug configurations.

And adjust it as so:

Breaking things up:

type - the type of debugger in our case is node debugger.

request - we use attach to attach into running debug instance, launch is to raise a debug instance and attach to it.

name - a name given to the debug configuration.

protocol - the NodeJS debugger protocol to use (you can read more here).

address - the remote address to look out for the debugging instance by default when we raise with docker-compose it uses a network driver that uses the host namespace ( you can read more about host network driver here )

port - the debugging port to attach to (we use the NodeJS default port 9229)

sourceMaps - our project is bootstrapped with NestJs by default it ships with typescript so when typescript compiles it by default ships with source maps so when we place breakpoints in our typescript it translates the breakpoint location to the compiled version (JavaScript).

restart - we set true so the debugger will try to reattach upon disconnection

localRoot - where are the local files in the host machine.

remoteRoot - where are the files in the remote (the running container).

Most of the disconnections are caused by Hot Reloading the code due to code change.

If you bootstrap a project of your own(and not from NestJS) make sure source maps is enabled in tsconfig.json in order to enable debugging.

And you are welcome

Link to the final project