DEV Community: Stefan Werfling

TypeScript - Drawing your Schemas with VTS Editor

Stefan Werfling — Thu, 04 Jun 2026 20:12:15 +0000

Introduction

In the previous article I described how I split larger TypeScript projects into several sub-projects, with a schemas package at the bottom that contains all shared types and runtime validators based on vts.

That setup works well, but it has one weakness: writing the schemas by hand. A typical vts schema looks like this:

export const UserSchema = Vts.object({
    id:      Vts.string({description: 'User identifier'}),
    status:  Vts.enum(StatusEnum),
    profile: ProfileSchema,
}, {
    description: 'User entity schema',
    objectSchema: {
        ignoreAdditionalItems: true
    }
});

export type User = ExtractSchemaResultType<typeof UserSchema>;

That is a lot of boilerplate for what is essentially "User has an id, a status and a profile". When you have fifty of those, scattered across folders, with extends and cross-file references, it stops being fun. So I built a small tool that takes care of the boilerplate - VTS Editor.

What is VTS Editor?

VTS Editor is a browser-based visual editor for vts schemas. You draw your types on a canvas, wire them up, and the editor generates the .ts files for the schemas package described in the previous article. It ships as a small CLI (npx vtseditor) that runs inside your own project, reads and writes a single schema.json, and regenerates the TypeScript on every save.

There is no build step, no separate UI server to host, no database. Everything lives in your repository: the schema.json is the source of truth, the generated .ts files are derived artifacts, and both can be committed to git.

The left pane is the file tree (folders and files just like in your editor), the centre is the canvas where each box is a schema or an enum, and the lines between boxes are field references. Resize, drag, rearrange - the layout is persisted with the schema.

Getting Started

Install it as a dev dependency in the project where you want the schemas to live (in the previous article's setup, that would be inside schemas/):

npm install --save-dev vtseditor

Then drop a vtseditor.json next to your package.json:

{
  "projects": [
    {
      "schemaPath": "./schemas/schema.json",
      "destinationPath": "./schemas/src",
      "destinationClear": false,
      "autoGenerate": false,
      "code": {
        "schemaPrefix": "Schema",
        "createTypes": true,
        "createIndex": true,
        "codeComment": true,
        "codeIndent": "    "
      },
      "scripts": {
        "before_generate": [],
        "after_generate": [
          { "path": "./schemas", "script": "npm run compile" }
        ]
      }
    }
  ],
  "server":  { "port": 5173 },
  "browser": { "open": true }
}

The two important fields are:

schemaPath - where the editor stores its source-of-truth JSON file.
destinationPath - where the generated .ts files end up. In the monorepo setup, this is schemas/src - exactly the folder that tsc compiles into schemas/dist.

The after_generate hook then runs npm run compile inside the schemas package, so by the time the editor finishes saving, the backend and frontend already see the updated .d.ts.

Launch it with:

npx vtseditor

A browser tab opens at http://localhost:5173 and you are ready to draw.

Drawing a Schema

Click Add Schema, give it a name (User), and a new box appears on the canvas. Click any field row to open the field editor:

Each schema has:

a name (this becomes the exported UserSchema / User pair),
an optional extend target (translates to Vts.object({...}).extend(OtherSchema) in the output),
an ignoreAdditionalItems flag for the objectSchema options,
and an optional description, which ends up in the second argument of Vts.object(...) and is later visible in API docs or error messages.

Fields are added inline. Each field has a name, a type, and modifiers like optional, array, unknown values. The type picker autocompletes against everything that currently exists in the project - primitive types, your own schemas, your enums, and even extern types from node_modules:

That autocomplete is more than a convenience - it is what keeps the canvas consistent. As soon as you rename User to Customer, every field that references it updates automatically, and the next save regenerates all dependent .ts files.

Linking Schemas Across Files

A real project has dozens of schemas in different folders. VTS Editor lets you point at any schema from any file - the editor handles the cross-file import for you when it generates the output:

In this screenshot, the orange box at the top is a link table - a visual reference to a schema that lives in a different file. The line connecting it to the schema below it represents an extend. When the file is generated, the editor inserts:

import {ContactCorporateSchema} from '../Contact/ContactCorporate.js';

export const ContactCorporateContactSchema = Vts.object({
    // ...
}).extend(ContactCorporateSchema);

…without you having to remember the relative path. This alone has saved me hours over the last few months. Multi-file schemas in a hand-written schemas package are where I usually start making mistakes; with the editor, the imports are simply not my problem any more.

The AI Assistant

If you would rather describe the schema in words than draw it, every project has a small AI assistant baked in. Click Create Schema with AI, type a sentence, and a draft appears that you can refine before adding it to the canvas:

The screenshot above shows the assistant turning "Create a drink with percent" into an AlcoholicDrink schema with name, alcoholPercentage, volume and description. You can keep chatting ("add an ingredients array", "make description optional") and only press Generate once you are happy.

Five providers are supported out of the box: Anthropic, OpenAI, Gemini, LocalAI, and a Claude Code wrapper that uses the claude CLI you already have installed. Configure them in vtseditor.json - see doc/ConfigAI.md for the details.

To keep the conversation cheap on long sessions, past assistant turns are re-encoded in TOON (Token-Oriented Object Notation) before being replayed - that shaves roughly 25–30% off the replay cost compared to JSON.

Generated Output

Pressing the save button writes schema.json and runs the generator. For the User schema from earlier, the output ends up looking like this:

// auto-generated imports
import {ExtractSchemaResultType, Vts} from 'vts';
import {ProfileSchema} from './relative/path.js';
import {ExternalSchema} from 'external-package';

// enums ------------------------------------------------
export enum StatusEnum {
    'active' = 'active',
    'inactive' = 'inactive',
}

// schema + options ------------------------------------
export const UserSchema = Vts.object({
    id:      Vts.string({description: 'User identifier'}),
    status:  Vts.enum(StatusEnum),
    profile: ProfileSchema,
}, {
    description: 'User entity schema',
    objectSchema: {
        ignoreAdditionalItems: true
    }
});

// matching TS type ------------------------------------
export type User = ExtractSchemaResultType<typeof UserSchema>;

That is exactly the kind of file the previous article's schemas package wants. Drop it into schemas/src/User/User.ts, re-export it from schemas/src/index.ts, and the backend and frontend pick it up via import { User } from 'myproject_schemas'.

For boundary checks the pattern stays the standard vts one:

const errors: SchemaErrors = [];

if (!UserSchema.validate(payload, errors)) {
    throw new ValidationError(errors);
}

// payload is now typed as User

Integrating with the Monorepo

Hooking the editor into the monorepo from the previous article is a five-line job. Inside schemas/package.json:

{
  "scripts": {
    "compile": "tsc --project tsconfig.json",
    "editor":  "vtseditor"
  },
  "devDependencies": {
    "vtseditor": "^1.2.0"
  }
}

Now npm run editor --workspace=schemas opens the canvas, and the after_generate hook in vtseditor.json re-runs npm run compile after every save. The backend and frontend never even notice that anything special is happening - they just see new .d.ts files in schemas/dist.

Two more things worth knowing:

Extern schemas. Any package that ships its own vtseditor.json and references a schema file via the vtseditor key in its package.json shows up as a read-only project in the tree. You can reference its types from your own schemas, but you cannot edit them. Perfect for shared component libraries.
Per-schema history. Since version 1.2.0, every save also captures a snapshot of the changed schemas and enums inside the chunk files. The editor's context menu has a View history entry that shows the diff and a one-click restore. Configurable via editor.historySize (default 20).

Conclusion

The setup from the previous article gives you the structure of a monorepo with a shared schemas package. VTS Editor fills that package without forcing you to hand-write a single Vts.object(...). The schema.json becomes your source of truth, the generated .ts files are derived artifacts, and the whole thing fits inside the existing npm run compile pipeline.

If you want to try it out, the project is on GitHub: stefanwerfling/vtseditor - issues and PRs welcome.

The next article in this series will look at the MCP server built into the editor - how to let an AI agent like Claude or Cursor read and mutate the same schema.json over HTTP, in lockstep with an open browser tab.

Happy drawing.

Typescript - several sub-projects + schemas (VTS)

Stefan Werfling — Mon, 01 Jun 2026 23:54:36 +0000

TypeScript - Several Sub-projects

Introduction

Everyone has probably reached a point where a project is so large that it needs to be broken down into parts. In this article I want to show how I structure larger TypeScript projects as a monorepo with several sub-projects that share the same data types and validation logic.

The basic idea is simple: extract everything that is used in more than one place into its own package. The remaining parts of the application then depend on this shared package. With TypeScript's project references and npm workspaces, this can be done without a heavy build tool - plain tsc is enough.

Project Architecture

The structure I keep coming back to looks like this:

myproject/
├── package.json          # root: defines workspaces + dev-deps
├── tsconfig.json         # optional: root references
├── schemas/              # shared types, enums, validators
├── core/                 # plugin system, shared runtime code
├── backend/              # server-side application
└── frontend/             # client-side application (browser)

schemas - pure types, enums, interfaces and (in my case) vts validators. No runtime logic, no I/O.
core - plugin contracts and runtime helpers that both backend and frontend might need.
backend - the Node.js server. Depends on schemas and core.
frontend - the browser application. Depends on schemas (and optionally core).

All sub-projects share the same data shapes via schemas, which means a single change to a DTO is picked up by every consumer the next time they are compiled.

Main Project Setup

I start with an empty directory and create the root package.json:

cd myproject
nano package.json

Root package.json:

{
  "name": "myproject",
  "version": "1.0.0",
  "description": "MyProject is ...",
  "scripts": {
    "compile": "cd ./schemas/ && npm run compile && cd ../core/ && npm run compile && cd ../backend/ && npm run compile"
  },
  "keywords": [],
  "author": "Stefan Werfling",
  "license": "MIT",
  "workspaces": [
    "schemas",
    "core",
    "backend",
    "frontend"
  ],
  "devDependencies": {
    "@stylistic/eslint-plugin-ts": "^3.0.0",
    "@types/node": "^22.15.18",
    "@typescript-eslint/eslint-plugin": "^8.21.0",
    "@typescript-eslint/parser": "^8.21.0",
    "eslint": "^9.19.0",
    "eslint-plugin-import": "^2.31.0",
    "eslint-plugin-prefer-arrow": "^1.2.3",
    "npm-check-updates": "^18.0.1",
    "typescript": "^5.7.3"
  }
}

A few notes on this file:

The workspaces array tells npm to treat the four sub-folders as linked packages. After a single npm install in the root, every sub-project can import from every other sub-project as if it were published to a registry.
The order in which the npm packages are installed is also very important, and we must compile everything in this order: schemas → core → backend (the frontend has its own build pipeline, see below).
The devDependencies are hoisted, so the same TypeScript / ESLint versions are used everywhere - no risk of "works on my machine".

Now run:

npm install

This creates the root node_modules/ with symlinks for myproject_schemas, myproject_core, etc. once those packages exist.

Schemas Sub-project

The schemas package is the foundation. It contains only types, enums, interfaces and validators - no business logic, no I/O. Anything that is needed by more than one sub-project lives here.

Directory structure:

mkdir schemas
cd schemas
mkdir src
mkdir dist

schemas/package.json:

{
  "author": "Stefan Werfling",
  "dependencies": {
    "vts": "git+https://github.com/OpenSourcePKG/vts.git"
  },
  "devDependencies": {
    "@stylistic/eslint-plugin-ts": "^3.0.0",
    "@types/node": "^22.15.18",
    "@typescript-eslint/eslint-plugin": "^8.21.0",
    "@typescript-eslint/parser": "^8.21.0",
    "eslint": "^9.19.0",
    "eslint-plugin-import": "^2.31.0",
    "eslint-plugin-prefer-arrow": "^1.2.3",
    "typescript": "^5.7.3"
  },
  "keywords": [],
  "main": "dist/index.js",
  "name": "myproject_schemas",
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "npm-check-updates": "npm-check-updates"
  },
  "type": "module",
  "types": "dist/index.d.ts",
  "version": "1.0.0",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "require": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  }
}

schemas/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/schemas.tsbuildinfo",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "removeComments": true,
    "sourceMap": true,
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ]
}

The two important flags here are:

"composite": true - marks the package as a referenceable TypeScript project. Other packages can now list it under references in their own tsconfig.json and benefit from incremental builds.
"declaration": true - emits the .d.ts files that the consumers will pick up via the types field of package.json.

A common pitfall: import paths

If outDir, main, types and exports are not aligned, IDEs (especially WebStorm/IntelliJ) generate the wrong import path on auto-complete. You will see this:

import {BehaviouralStatesResponse} from 'myproject_schemas/dist/index.js';

…where you actually want this:

import {BehaviouralStatesResponse} from 'myproject_schemas';

The fix is to make sure all four locations point at the same file:

field in `package.json`	value
`main`	`dist/index.js`
`types`	`dist/index.d.ts`
`exports["."].import`	`./dist/index.js`
`exports["."].types`	`./dist/index.d.ts`

…and that outDir in tsconfig.json is dist. Once those four match, auto-import resolves to the bare package name.

`schemas/src/index.ts`

Everything you want to share is re-exported from a single barrel file:

export * from './Behavioural/BehaviouralStatesResponse.js';
export * from './User/User.js';
export * from './User/UserRole.js';
// ...

Note the .js extension on the import path even though the source file is .ts - this is required by "module": "NodeNext" and saves you a lot of headache later when the package is consumed from an ESM context.

Core Sub-project

The core package sits between schemas and the application sub-projects. I use it for things that are not pure data but are still shared - plugin contracts, base classes, small utilities, error types, logging.

core/package.json:

{
  "name": "myproject_core",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/index.js",
      "require": "./dist/index.js",
      "types": "./dist/index.d.ts"
    }
  },
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "npm-check-updates": "npm-check-updates"
  },
  "dependencies": {
    "myproject_schemas": "*"
  },
  "devDependencies": {
    "typescript": "^5.7.3"
  }
}

The "myproject_schemas": "*" dependency works because of npm workspaces: npm symlinks the local schemas/ into core/node_modules/myproject_schemas. No publishing, no npm link, no rebuild gymnastics.

core/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/core.tsbuildinfo",
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" }
  ]
}

The references block is what makes this a true project-reference build. Running tsc -b in the root walks the dependency graph and only rebuilds what actually changed.

A typical core file then looks like:

import {User, UserRole} from 'myproject_schemas';

export interface UserService {
    findById(id: string): Promise<User | null>;
    hasRole(user: User, role: UserRole): boolean;
}

The type comes from schemas, the interface stays in core.

Backend Sub-project

The backend is a plain Node.js application. The interesting part is that it can consume both schemas and core as if they were normal packages.

backend/package.json:

{
  "name": "myproject_backend",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "main": "dist/index.js",
  "scripts": {
    "build": "npm run compile",
    "compile": "tsc --project tsconfig.json",
    "start": "node dist/index.js",
    "npm-check-updates": "npm-check-updates"
  },
  "dependencies": {
    "myproject_schemas": "*",
    "myproject_core": "*",
    "express": "^4.21.0"
  },
  "devDependencies": {
    "@types/express": "^4.17.21",
    "typescript": "^5.7.3"
  }
}

backend/tsconfig.json:

{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "tsBuildInfoFile": "./../.cache/backend.tsbuildinfo",
    "module": "NodeNext",
    "outDir": "dist",
    "rootDir": "src",
    "strict": true,
    "target": "ES2022"
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" },
    { "path": "../core" }
  ]
}

And a route that uses the shared types:

import express from 'express';
import {BehaviouralStatesResponse} from 'myproject_schemas';

const app = express();

app.get('/api/behavioural/states', (_req, res) => {
    const response: BehaviouralStatesResponse = {
        states: [],
        statusCode: 200
    };

    res.json(response);
});

app.listen(3000);

Because the response type is defined once in schemas, the frontend can import the exact same shape and you get end-to-end type safety without a code-generation step.

Frontend Sub-project

The frontend is where the setup deviates a little, because the browser does not understand NodeNext modules and you usually want a bundler in front of it. I use Vite here, but the same approach works with webpack or esbuild.

frontend/package.json:

{
  "name": "myproject_frontend",
  "version": "1.0.0",
  "author": "Stefan Werfling",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "myproject_schemas": "*"
  },
  "devDependencies": {
    "typescript": "^5.7.3",
    "vite": "^5.4.0"
  }
}

frontend/tsconfig.json:

{
  "compilerOptions": {
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "target": "ES2022",
    "lib": ["ES2022", "DOM"],
    "strict": true,
    "jsx": "preserve",
    "isolatedModules": true,
    "noEmit": true
  },
  "include": [
    "src/**/*"
  ],
  "references": [
    { "path": "../schemas" }
  ]
}

Two things differ from the Node sub-projects:

"moduleResolution": "Bundler" - tells TypeScript that some external tool (Vite) will resolve the imports.
"noEmit": true - the bundler emits the final JavaScript, tsc is only used for type-checking.

A component then consumes the shared schema exactly like the backend does:

import {BehaviouralStatesResponse} from 'myproject_schemas';

async function loadStates(): Promise<BehaviouralStatesResponse> {
    const res = await fetch('/api/behavioural/states');
    return res.json();
}

If you change a field in schemas/src/Behavioural/BehaviouralStatesResponse.ts, both the Express handler and the fetch call above turn red in the IDE on the next save. That single feedback loop is, for me, the main reason for going through the monorepo setup in the first place.

Build Order and Project References

There are two ways to build everything:

Sequential - the simple compile script in the root package.json. It just cds into each folder and runs tsc. Works for small projects.
Project references - run tsc -b (build mode) in the root, with a root tsconfig.json that references the sub-projects:

   {
     "files": [],
     "references": [
       { "path": "./schemas" },
       { "path": "./core" },
       { "path": "./backend" }
     ]
   }

tsc -b then figures out the topological order itself and only rebuilds what changed. The .tsbuildinfo files cached under .cache/ make subsequent builds nearly instant.

For CI I keep both: npm run compile for "build everything from scratch", tsc -b for the watch / incremental case during development.

Tips & Pitfalls

A short list of things that bit me along the way:

Always use the .js extension in TypeScript imports when module is set to NodeNext. The source is .ts, the import says .js. This is correct, even though it looks wrong.
Hoist devDependencies to the root package.json. If every sub-project pins its own TypeScript version, tsc -b will complain about "duplicate identifier" errors when the versions diverge.
Add dist/ to .gitignore in every sub-project, but commit the tsconfig.json and package.json. The output is regeneratable, the build config is not.
Keep a single .cache/ folder at the root for all .tsbuildinfo files (as in the examples above). That way you can rm -rf .cache to force a clean rebuild without touching dist/.
Don't put runtime code into schemas. The moment you do, the frontend bundle starts pulling in Node-only modules, and you spend an afternoon debugging Vite errors. Keep it types-only.
Pin the workspace dependency to * or workspace:*, never to a concrete version. With npm workspaces, "myproject_schemas": "*" reliably resolves to the local symlink.

Conclusion

This setup gives you a clear separation between data definitions, shared runtime code and the actual applications, without forcing you to publish anything to a registry or run a heavy build tool. The schemas package is the contract that keeps backend and frontend in sync, and TypeScript's project references make sure that contract is enforced on every save.

If you want to see this approach in action on a real project, have a look at vtseditor - a browser-based visual editor for exactly the kind of schemas package described in this article. It lets you draw your schemas, exports them as vts-based TypeScript files, and is published as an npm CLI (npx vtseditor) so you can drop it into any monorepo without changing your existing build setup.

Happy splitting.

Redirect HTTP to HTTPS on the same port

Stefan Werfling — Mon, 05 Aug 2024 14:43:24 +0000

Intro

I've found that I can document things very well and yet others get it wrong.

The best example is

after installation, open the interface at https://localhost:3000

Watch here "https". People then wrote to me saying that the access wasn't working. During my research I discovered that the person was trying to access it via "http".

The URL also had a copy action, you just had to copy the line.

Alright, let's tackle the problem!

I then sat down and poked around in the depths of the express classes.

Code

import https from 'https';
import express from 'express';

const exp = express();

// todo somthing with express
// ...

const httpsServer = https.createServer({
   key: ck.key,
   cert: ck.crt,
}, exp);

At the beginning we create a server with https, pass the key and the crt.

Next we adapt the event to tlsClientError, here we open it when the browser tries to access an https connection via http. This attempt produces a TLS error.

httpsServer.on('tlsClientError', (err, tlsSocket) => {
//....
});

To help, I created the following classes:

import * as net from 'net';
import * as tls from 'tls';

export class TlsClientError extends Error {

    public library: string = '';

    public reason: string = '';

    public code: string = '';

    public stack: string = '';

}

export class TlsSocket extends tls.TLSSocket {

    public _parent?: net.Socket;

}

We now catch the tls error, check whether it was an http request and if it was, we send a blank header in http 1.1 format with the 'location' to https.

httpsServer.on('tlsClientError', (err, tlsSocket) => {
   const tlsError = err as TlsClientError;

   if (tlsError.reason === 'http request') {
      const tTlsSocket = tlsSocket as TlsSocket;

      if (tTlsSocket._parent) {
         tTlsSocket._parent.write('HTTP/1.1 302 Found\n' +
            `Location: https://localhost:${this._port}`);
      }
   }
});

this._port is in my class and gets the port from the setting. tTlsSocket._parent is the socket stream before the TLS encryption, everything we write on it goes to the browser unencrypted.

As a last step we start the listing:

httpsServer.listen(this._port, () => {
   console.log('Listen start.');
});

Summary

Now express runs with https and if you call the http you are redirected again.

If you know of a better way, let me know, I'm open to ideas! ;)

NodeJS + ROHC

Stefan Werfling — Tue, 30 Jul 2024 14:22:43 +0000

From the idea to implementation

I would like to introduce you to my idea and how it came about giving “ROHC” a binding in NodeJS.

I wanted to implement a VPN that runs over Web-Socket. The advantages would be that the service would be hidden over HTTPS. With HTTP3 this would be even more optimized. So I started playing around with the TunTap2 Module for NodeJS, which I had to patch first.

Always fascinated by wireless technology, at some point I came across “LoRa” and with it a project “IP2Lora”.

Image source

In this project “IP2Lora”, the IP packets were shortened to save 40 bytes, which is very important for the transfer; with a radio band of 434 MHz or 868 MHz, not that much can be transferred.

Image source

In the graphic you can clearly see how the IP packet size decreases.

Unfortunately there was only one lib binding for Python.

So why not write a node lib binding yourself!?

The result can now be seen.
https://www.npmjs.com/package/node-rohc

You can find out more about how ROHC works in the links to the project or simply search for it. I won't explain it here so as not to make the post too long.

Installation Lib

I installed under Linux Debian/Mint. I think this should be similar to other Linux versions.

(By the way, I also had to patch the ROHC-lib to the new kernel.)

sudo apt-get install autotools-dev
sudo apt-get install automake
sudo apt-get install libtool
sudo apt-get install libpcap-dev
sudo apt-get install -y libcmocka-dev

git clone https://github.com/stefanwerfling/rohc.git
cd rohc

./autogen.sh --prefix=/usr

make all
sudo make install

Installation NPM

Now we can go into our project and install the module.

cd yourProject
npm i node-rohc

Now we have to create the NodeJS binding (this has to be compiled for each CPU architecture itself).

cd yourProject/node_modules/node-rohc
npm run build --loglevel verbose

The installation is now complete.

Coding/API usage

Now let's assume we get an IP packet that we want to compress into the following packets to save bytes.

const ipU8Packet = new Uint8Array(ipPacketBufferWithContent);
console.log(ipU8Packet);

Uint8Array(52) [
   69,   0,   0,  52,   0,   0,   0,   0,  64,  6, 249,
  112, 192, 168,   0,   1, 192, 168,   0,   2, 72, 101,
  108, 108, 111,  44,  32, 116, 104, 105, 115, 32, 105,
  115,  32, 116, 104, 101,  32, 100,  97, 116, 97,  32,
  112,  97, 121, 108, 111,  97, 100,  33
]

The module is now imported and the Unit8Array in which the IP packet is given to the Rhoc object for compression.

import {Rohc} from 'node-rohc';

const r = new Rohc([
  RohcProfiles.ROHC_PROFILE_UNCOMPRESSED,
  RohcProfiles.ROHC_PROFILE_IP,
  RohcProfiles.ROHC_PROFILE_TCP,
  RohcProfiles.ROHC_PROFILE_UDP,
  RohcProfiles.ROHC_PROFILE_ESP,
  RohcProfiles.ROHC_PROFILE_RTP
]);

try {
    const compress = r.compress(ipU8Packet);
    console.log(compress);
} catch (e) {
    console.error(e);
}

Uint8Array(53) [
  253,   4,  69,  64,   6, 192, 168,   0,   1, 192, 168,
    0,   2,   0,  64,   0,   0,  32,   0, 251, 103,  72,
  101, 108, 108, 111,  44,  32, 116, 104, 105, 115,  32,
  105, 115,  32, 116, 104, 101,  32, 100,  97, 116,  97,
   32, 112,  97, 121, 108, 111,  97, 100,  33
]

In the constructor of the Rohc object we specify the profiles that should be used for compression in an array.

Then comes compression. In the output we see the new package. But why isn't it smaller?

The first packet still contains the information about port/IP-Address etc. Only the following packets become significantly smaller.

To convert the Rohc packet back into a normal IP packet we use decompress.

try {
    const decompress = r.decompress(compress);
    console.log(decompress);
} catch (e) {
    console.error(e);
}

Uint8Array(52) [
   69,   0,   0,  52,   0,   0,   0,   0,  64,  6, 249,
  112, 192, 168,   0,   1, 192, 168,   0,   2, 72, 101,
  108, 108, 111,  44,  32, 116, 104, 105, 115, 32, 105,
  115,  32, 116, 104, 101,  32, 100,  97, 116, 97,  32,
  112,  97, 121, 108, 111,  97, 100,  33
]

What is important is the beginning, the first packet is compressed and transmitted to the destination and the destination has decompressed the packet, the instance must be maintained. So that the connection ID remains known. This means that the program has to keep the object instance running. If one of the two pages (source with compression or destination with decompression) is stopped, both pages must be restarted.

Additional function with useful information:

Last compress/decompress status

import {Rohc, RohcStatus} from 'node-rohc';

    if (r.getLastStatus() === RohcStatus.ROHC_OK) {
      console.log('All OK');
    }

During compression or decompression, the status is remembered; this can be queried again immediately afterwards to get more detailed information about what happened.

Last compress/decompress packet info

console.log(r.compressLastPacketInfo());
console.log(r.decompressLastPacketInfo());

{
  version_major: 0,
  version_minor: 0,
  context_id: 0,
  is_context_init: true,
  context_mode: 1,
  context_state: 1,
  context_used: true,
  profile_id: 4,
  packet_type: 0,
  total_last_uncomp_size: 52,
  header_last_uncomp_size: 20,
  total_last_comp_size: 53,
  header_last_comp_size: 21
}
{
  version_major: 0,
  version_minor: 0,
  context_mode: 2,
  context_state: 3,
  profile_id: 4,
  nr_lost_packets: 0,
  nr_misordered_packets: 0,
  is_duplicated: false,
  corrected_crc_failures: 11745388377929038000,
  corrected_sn_wraparounds: 14987979559889062000,
  corrected_wrong_sn_updates: 12105675798372346000,
  packet_type: 449595,
  total_last_comp_size: 18407961667527770000,
  header_last_comp_size: 1940628627783807,
  total_last_uncomp_size: 18407961667125117000,
  header_last_uncomp_size: 217316637802623
}

Information about the last compression or decompression.

General compress/decompress info

console.log(r.compressGeneralInfo());
console.log(r.decompressGeneralInfo());

{
  version_major: 0,
  version_minor: 0,
  contexts_nr: 1,
  packets_nr: 1,
  uncomp_bytes_nr: 52,
  comp_bytes_nr: 53
}
{
  version_major: 0,
  version_minor: 0,
  contexts_nr: 1,
  packets_nr: 1,
  comp_bytes_nr: 53,
  uncomp_bytes_nr: 52,
  corrected_crc_failures: 0,
  corrected_sn_wraparounds: 8518447232180027000,
  corrected_wrong_sn_updates: 4295000063
}

General information about compression and decompression.

Final word

I hope you enjoyed my little post. I am always open to improvements.