DEV Community: Chukwuemeka Igbokwe

Chuks v0.2.0-rc.1 Is Out, We Need You to Try to Break It

Chukwuemeka Igbokwe — Sat, 19 Sep 2026 07:06:49 +0000

Chuks v0.2.0-rc.1 is live, and unlike our last few release posts, this one isn't "here's what shipped." It's an ask.

What we need

Chuks compiles two ways: a bytecode VM you develop against, and a native binary you ship. Every release lives or dies on those two modes computing the same thing. We have a serious internal gate for that, golden tests on both backends, a differential fuzzer, 24 differential suites, cross-compilation to five targets. What that gate can't do is run a program it's never seen.

So here's the ask: build something with rc.1, or point an existing program at it, and run it both ways.

chuks run main.chuks    # the bytecode VM
chuks build main.chuks  # the native binary

If they don't agree, byte for byte, on everything the program prints, that's a bug we want. File it here with chuks --version and the smallest file that shows it.

# already have Chuks
chuks upgrade --prerelease

# first install
curl -fsSL https://chuks.org/install.sh | bash && chuks upgrade --prerelease

A plain chuks upgrade stays on v0.1.2 until v0.2.0 actually ships, this is opt-in.

Why this matters more than usual this time

Most of what's fixed in rc.1 wasn't found by a test. It was found by building real programs. Two examples, because they show why "someone else's program" is the thing our gate structurally can't replace.

A precedence bug that produced two different wrong answers. await and spawn used to bind to the wrong side of an expression:

"[" + await f() + "]"

This used to parse as await (f() + "]") awaiting the string concatenation instead of the call. The VM printed "Task(pending)". The native binary printed "0". Same source, two backends, two different wrong answers, because the bug was in the grammar itself, not in either backend's implementation of a correctly-parsed program. Our differential fuzzer generates programs; it doesn't yet think like someone writing an async pipeline by hand, which is exactly how this surfaced.

A closure bug that both backends agreed on, and were both wrong about. This is the more interesting failure mode:

var fns = []
for (var i = 0; i < 3; i++) {
    fns.push(function(): int { return i })
}
// every fn used to return 3, on BOTH the VM and the native binary

Every closure made in a loop was reading one shared binding instead of its own per-iteration value, on both backends, identically. Our differential testing checks that the VM and native binary agree. It does not check that what they agree on is correct. They agreed here, and they were both wrong, in exactly the way var in a pre-let JavaScript loop was wrong. Fixed now: each pass gets its own binding.

That second one is why we're asking for outside testing specifically. Agreement between two backends is necessary but not sufficient, it can't catch a bug baked into both from the start. Only someone hitting the actual behavior, expecting something else, catches that.

Also in this RC

String indexing now counts bytes consistently on both backends, with accessors like at/slice snapping to whole Unicode characters, this used to differ between the VM (characters) and native (bytes) for some methods.
A dropped spawn'd task's failure used to disappear silently. It's reported now, at exit for a CLI program, immediately for an embedding host.
Reserved words are usable as field/key names now (dataType Rec { from: string, class: string }), a payload's fields aren't the language's to rename.
Generic base classes now work correctly across module boundaries, with this reflection (json.stringify(this)) seeing the whole object, subclass fields included, identically on both backends.

Full changelog, including all the breaking changes and exact migration notes: chuks.org/blog/chuks-v020-rc1-the-release-candidate

If you try it and it breaks, that's the best possible outcome for this post. File it.

Chuks v0.1.1, The Correctness Release

Chukwuemeka Igbokwe — Sat, 05 Sep 2026 04:52:16 +0000

Chuks has two execution modes: a bytecode VM you develop against, and a native binary you ship. v0.1.1 is about making them agree everywhere, down to the last digit of an IEEE-754 float.

Chuks runs your code two ways.

A bytecode VM you develop against, it starts instantly, so the edit-run loop feels like a scripting language. And a native binary you ship, the compiler lowers your program to native code ahead of time, so production is fast. Code like a script, ship like a binary.

That design only earns its keep if both modes compute the same thing. If a program behaves one way while you develop and another way once you ship, the two-mode model is a liability, not a feature. v0.1.1 is the release that makes them agree, everywhere they are asked to, down to the last digit.

Where v0.1.0 was about speed, this one is about correctness. The headline numbers: 220 commits since v0.1.0, 446 files changed (+33,070 / -2,098), all 407 golden tests green on both the VM and as a native binary, 1,404 differential cells across 17 suites, and a ten-stage release preflight clean.

Here is what that meant in practice.

Agreement to the last ULP

The most instructive fix in this release is a floating-point one, because it shows exactly the standard Chuks holds itself to.

The n-body benchmark computed two different results depending on how it was run. As a native binary it printed 0.013051029850722899; on the VM it printed 0.009171719055316834. We checked against three other IEEE-754 runtimes, all three agreed with the VM, to the last digit. The native binary was the outlier.

The cause was a fused multiply-add. The native backend was contracting a * b + c into a single instruction, which keeps the intermediate product at full internal precision through the addition and rounds once instead of twice. That sounds more accurate, and in isolation it is, but IEEE-754 prescribes a specific sequence with a specific rounding at each step, and every conforming runtime follows it. A fused multiply-add lands one unit in the last place, one ULP from the value the standard specifies.

One ULP is the last digit of a sixteen-digit number. Invisible in a short program. But the first divergence appeared in exactly the shape a compiler wants to fuse:

dx * dx + dy * dy + dz * dz

Run 500,000 times, each result feeding the next, that one-ULP gap compounded into a difference you could read off the screen.

Every float multiply is now rounded explicitly before anything can fuse it. Chuks and every other IEEE-754 runtime now print the same number.

The fix costs about 11% on the most multiply-heavy loop in the benchmark set; roughly half of that came back from computing a repeated array-element read once instead of six times. The rest is gone, and we kept the fix anyway. The lost speed was the speed of a wrong answer, and there is no version of this that keeps both.

The lasting part is the guard. We added a differential suite of 17 shapes covering every adjacency of a multiply to an addition, crossed with every path an operand takes to reach it. The inputs are adversarial, a case only counts if fusing genuinely changes the answer, and each carries the exact value computed in rational arithmetic, not just the VM's output. That last detail is what makes it airtight: if both backends were wrong the same way, comparing them to each other would prove nothing. Checking against a hand-computed exact value means two backends that agree with each other but not with IEEE-754 still fail. All 17 shapes fail without the fix.

How these bugs surface

Chuks has been carrying real software for several releases, a package registry and its frontend, HTTP services, a growing package ecosystem, an editor backend. Those programs turned up most of what v0.0.7 through v0.1.0 fixed, and they keep doing that job.

What this cycle added was a different kind of pressure. A mobile framework is a large program whose generics cross package boundaries constantly: a class in one package specialized on a type from another, a specialization that has to be emitted somewhere neither package owns, closures capturing module state, the same private name declared in three files. And it runs on two targets that must agree, which turns any disagreement into a visible bug rather than a latent one. That combination is what shook these fixes loose, not because earlier releases were only tested, but because this workload leans hardest on the seam this release is about.

One example, because it is representative. A generic function's specialization carries a map of type arguments, and by that stage the map holds compiled types, not Chuks ones. Naming the specialized class converted them back to Chuks names first, and that inverse only handled primitives. A class argument fell through to the opaque case, so the compiler emitted a reference to a Cell_ptr_any that nothing ever generated. The program ran perfectly on the VM and failed to build as a binary.

The fix removed the round trip. The lasting part, again, is the guard: a class type argument axis was added to the generics differentials, because only a class argument makes a type-map value a pointer. That axis immediately found two more bugs, one of them a cross-package import cycle.

The rule that came out of it:

A real consumer build is the compiler's best fuzzer, and every bug it finds is converted into a generated test axis rather than a single regression case.

That is why the battery grew by three axes this cycle instead of by forty-eight one-off tests. An axis is a permanent net; a regression test is a single caught fish.

Live imports

The one behavioral change worth reading carefully. Previously the VM copied an imported module-level variable at import time, while the native compiler read the exporter's current value, so the same program could print different numbers in development and in a release build.

In Chuks, an import is a live binding: a window onto the exporting module, not a snapshot of it. The VM is what changed to match.

// counter.chuks
export var total: int = 0
export function add(n: int): void { total = total + n }

// main.chuks
import { total, add } from "./counter.chuks";
println(string(total))   // 0
add(5)
println(string(total))   // 5, in both execution modes

Three consequences:

A binding is live. Reading an imported name always sees the exporting module's current value.
Assigning to an imported name is a compile error. It is a read-only view, export a setter instead. Aliasing doesn't create a writable copy: import { f as g } gives you g, not f.
A module is one instance per run. It used to be re-initialized for every importer, so its side effects ran once per importer and any accumulated state was discarded.

If you were relying on the old copy behavior, the compiler tells you at the assignment.

Reading a map yields an optional

The other breaking change, and worth reading. A key that is not present has no value, so reading a typed map gives you an optional:

var stock: map[string]int = {"apples": 3, "pears": 0}

stock["kiwis"] == null      // true
stock["pears"] == null      // false - a stored zero is a value, not an absence
stock["kiwis"] ?? 0         // 0

Previously this was null on the VM and the zero value in a native build, and the difference was not cosmetic: m[k] + 5 printed a number as a binary and aborted the VM with a type mismatch. The same source working when shipped and dying in development is the worst shape a bug can take.

The migration is ?? default, and it is free, that form compiles to a single lookup that never builds an optional, measured at the same speed as the old unchecked index over two million reads. A null check narrows the type, so if (m[k] != null) { total = total + m[k] } works too. .get(k), .getOr(k, d), and .has(k) are unchanged.

Generics across packages

Generics that stay inside one module were already solid. This release fixes what happens when a specialization has to be placed somewhere. The specialization of a generic from package A on a type from package B is emitted in B, next to the type, because A cannot import its own consumer. Nested arguments pin to the innermost class, so Box<Box<Node>> lands where Node lives rather than where Box does. A function specialization emitted into a foreign package qualifies its reads and its writes of the defining module's variables, and declared types of module-level variables are now published across packages so a reader no longer treats a typed value as opaque.

Mobile: a real development loop

The mobile toolchain gained a proper edit-reload loop. chuks pack collects an app and its dependencies into a single source bundle, chuks serve serves it with hot reload, and the Chuks Mobile Runtime (CMR) is an on-device VM that runs it. The device needs no compiler toolchain and no framework source, and a save reaches the running app as a delta. chuks pack type-checks and fails closed, a bundle that doesn't compile is never served, and when something fails at runtime the host shows a red error card with the file and line, built from a structured payload with clean paths, a code frame, and a filtered stack.

Underneath it, --c-archive lets the AOT compiler emit a C-ABI bridge, which is what allows a native host a UIKit or Android app, to embed a compiled Chuks program in the first place.

Streaming HTTP, both ways

Server-Sent Events on the server:

res.sse()
res.push("tick", "1")
res.end()

and a pull-based streaming client, so a response is consumed as it arrives rather than buffered whole:

const stream = http.open("GET", url, null)

Also in this cycle: generic type inference (a generic call's type arguments are inferred from its arguments into the result type, so useState("") is a Cell<string> with no annotation), and as now accepts an interface, a generic instantiation, and a union, previously only a bare class name or a primitive.

Where Chuks stands

Nine benchmarks, five languages, best of seven runs on an M4 Max. Outputs are compared before any timing is reported, a benchmark where two languages compute different things is not a benchmark, and two of these were doing exactly that until this release.

Milliseconds, lower is better.

Read honestly: startup floors the small numbers. Chuks starts in 2.3ms, Bun 5.1ms, Python 12.2ms, Java 20.8ms, so the whole Java column below about 25ms is JVM startup rather than work.

Chuks takes seven of nine against Bun and eight of nine against Java, and leads Python by between four and two-hundred-and-fifty times. The two it loses are allocation-heavy and hash-heavy, and one has a known cause: values() and keys() sort their keys for a deterministic order, which is 14.75ms of a 17.6ms call on a map of 100,000 entries. That is the next piece of performance work, not a mystery.

The n-body row carries the footnote from earlier. The correctness fix cost 0.9ms there. Every runtime in that table computes 0.009171719055316834, and so does Chuks. Buying that 0.9ms back would mean printing a different number than everybody else.

Upgrading

chuks upgrade

Two changes can break existing code, and both report themselves at the line responsible:

Assignment to an imported binding is a compile error. Export a setter instead.
Reading a typed map yields V?. Add ?? default where a value is required, also the fastest form, or bind it and check for null where absence means something.

Everything else in this release makes programs that already worked on the VM behave the same way as a native binary.

That is what the Correctness Release is: not a headline feature, but a promise that the thing you develop against and the thing you ship compute the same answer, verified across 1,404 differential cells, and held even when the correct answer is the slower one.

Try Chuks at chuks.org

Chuks v0.1.0: unboxing the hot path (and a 58x speedup hiding in `any`)

Chukwuemeka Igbokwe — Mon, 29 Jun 2026 13:44:15 +0000

A loop counter should not allocate memory. An accumulator that only ever holds an int should not be boxed, unboxed, and re-boxed on every iteration. Obvious, and yet for nine releases that is exactly what our runtime was doing.

Chuks spent its whole 0.0.x line on correctness and feature breadth. v0.1.0, landing July 2026, is about speed. Both execution backends, the bytecode VM and the ahead-of-time (AOT) native compiler, got a deep performance pass, and the numbers moved a lot. Here is the interesting part of how.

The boxing tax

In a dynamically-shaped runtime, every value on the stack is usually a boxed object: a pointer to a heap cell that carries its type. That is fine for genuinely dynamic data. It is a disaster in a tight numeric loop, where a single i + 1 becomes unbox, add, re-box, allocate. Multiply by a few hundred million iterations and you are not measuring arithmetic, you are measuring the garbage collector.

The fix is to prove the type statically and keep the value unboxed. We did that on both backends.

The VM: typed slots

The bytecode VM now keeps parallel unboxed stacks and local-variable arrays for int, float, and bool, alongside the existing boxed object stack. When the compiler can statically prove a value's type, it emits typed load/store and typed arithmetic opcodes (OP_ILOAD, OP_FSTORE, the typed arithmetic family) that operate directly on those stacks. It only crosses into the boxed world when it has to, through explicit OP_BOX / OP_UNBOX bridge ops, and a typed peephole pass then cancels redundant box/unbox pairs and fuses common sequences into super-instructions.

The result: the arithmetic-heavy paths the VM cares about most now run without touching the heap. You write the same code. The compiler picks the typed path.

The AOT compiler: inlining array reads

The native compiler had a subtler problem. It splits its output into a main package and a crt runtime package, and typed-slice reads were going through a generic __idx_slice[T]() helper. Generic functions cannot inline across a package boundary, so every arr[i] in a hot loop became a real cross-package CALL.

v0.1.0 emits non-generic, per-type read helpers instead (__idx_slice_i64, __idx_slice_f64, __idx_slice_str, __idx_slice_bool). Those are monomorphic, so they inline across the boundary. The out-of-range slow path is routed through a package-level function variable to keep it out of the fast helper, and the friendly catchable error is preserved:

index 10 out of range [0:3]

You still write arr[i]. The compiler takes the fast path whenever the array holds a primitive.

Warm benchmarks (min ms, arm64, lower is better)

Workload	v0.0.9 AOT	v0.1.0 AOT
nbody	110	15
matrix	20	6
sort	10	6

nbody got about 7x faster and now runs at native speed. The residual on matrix and sort is bounds-checked native writes, which is the irreducible cost of safe array access.

The 58x hiding in `any`

Here is my favorite one, because it is a trap every developer falls into.

any exists for genuinely dynamic data: a request body, a parsed JSON value, a heterogeneous list. But it is easy to reach for when the value is really just one type:

var sum: any = 0
for (var i = 0; i < 300_000_000; i = i + 1) {
    sum = sum + i
}

That used to cost you everything. Each sum + i boxed the value and dispatched through a dynamic-type helper at runtime. The compiler now proves when an any local only ever holds a single concrete type and stores it unboxed as that type, so the operations run directly: no boxing, no dispatch.

That 300M-iteration loop dropped from 3.5s to 0.07s. About 58x faster, with no code change.

The honest framing matters: genuinely-dynamic any still boxes, because it must, the type is unknown until runtime. So this is pure upside. The "accidental any" tax is gone, and any still means exactly what it should. It is the native counterpart of the VM's typed slots, and the same idea shows up again in control flow (typed compares now feed unboxed branches with no boolean allocated per iteration) and in linked structures (a nullable class type lowers to a direct, unboxed pointer link).

Speed was not the only headline

A performance release is a good excuse to ship the things that needed the performance work to be safe. A few that I think matter most:

A data race that is now a compile error. The most common concurrency bug for people arriving from Node, Python, Java, or C# is a stateful object (a query builder, a service) shared across requests and mutated inside an async handler. It passes every test, works in dev, then corrupts data under load. Chuks now catches it statically: if a class whose methods mutate this is shared and a mutator is called without a lock, the program does not compile. The error names the three fixes (make it task-local, move its state into the task context, or wrap it in lock(...)). Read-only sharing stays legal, single-threaded code is untouched, and a self-synchronizing class can opt out with @threadSafe.

Real infrastructure, written in the language. A complete gRPC stack (HTTP/2 framing and HPACK, Protocol Buffers, all four RPC kinds, metadata, deadlines, TLS/mTLS, reflection) was built entirely in Chuks this cycle. So were two production data clients: @chuks/mongo (a hand-rolled BSON codec, the OP_MSG wire protocol, and SCRAM-SHA-256 auth, with typed Model<T> over a dataType, 62/62 against MongoDB 7.0) and @chuks/kafka (the Kafka binary protocol end to end, 65/65). Building on real wire protocols is the best stress test there is: @chuks/mongo alone surfaced and fixed eight latent compiler defects.

A full debugger. A complete debug adapter: conditional, function, and exception breakpoints, hit counts, logpoints, real-name variables, and a Watch console that evaluates real Chuks expressions against the paused frame (including function and method calls, on a separate evaluator so inspecting state never disturbs it), plus setVariable.

Unicode-correct strings. for ... of now walks code points, not bytes, so multi-byte characters and emoji come through whole, with a new runeCount() and locale-aware case conversion.

A browser playground. The VM now compiles to WebAssembly, so you can run Chuks in the browser with no install.

The throughline: one language, two backends, kept honest

Every feature above behaves identically on the VM and as a native binary. That is not a hope, it is a test: a differential fuzzer generates programs in four shapes (single-file, multi-module, deep-recursion, and large-data), runs each through both backends, and diffs the output. A separate coverage-guided typechecker fuzzer hammers the shared frontend. The golden suite now runs 339 tests green on both backends, with the fuzzer reporting 100% agreement across hundreds of generated programs. Several of the speedups in this post exist because a fuzzer found the divergence first.

Try it

v0.1.0 is in preview now, with the stable release landing in July.

# First-time install
curl -fsSL https://chuks.org/install.sh | CHUKS_PRERELEASE=1 bash

# Already have Chuks
chuks upgrade --prerelease

Then re-run your benchmarks. The VM no longer boxes the hot path, and native array reads finally inline cleanly.

Docs and the full changelog are at chuks.org. If you build something with it, I would love to see it.

Chuks Language Data Types

Chukwuemeka Igbokwe — Fri, 01 May 2026 18:08:20 +0000

Stop fighting your data. Let dataType win.

Most languages make you choose between the safety of structs and the convenience of maps. Chuks gives you both, with built-in validation, generics, embedding, and nullable safety baked right into the type system.

chuks dataType is a lightweight, fields-only container. No constructor boilerplate. No class overhead. Initialize with a map literal and the compiler checks every field.

@validate: one annotation, full validation.

Attach validation rules directly to fields. Call validate(x) and get back every error. No third-party library. No schema duplication. It lives with your data.

Custom validators: your rules, first class

Need a strongPassword rule? Write a function, annotate it with @validator, and use it in any dataType across your whole codebase, including imported modules.

Nullable types + type narrowing
Append ? to any type and it can hold null. Chuks does control-flow analysis, after a null guard, the compiler narrows the type automatically. No casts. No optional chaining syntax. The compiler just knows.

Embedding: compose shapes, not hierarchies

Embed one dataType inside another, and its fields are promoted directly. The Go embedding model without the Go verbosity. Perfect for Auditable, Identifiable, and any shared schema pattern.

@json — rename fields for the wire

Your internal field names stay clean. Your API contract stays happy. One annotation handles both serialization and parsing, no mapping layer needed.

Chuks, A New Programming Language That Outperforms Go on HTTP Throughput

Chukwuemeka Igbokwe — Wed, 18 Mar 2026 19:50:01 +0000

Hi i've been building a programming language called Chuks, and it just hit v0.0.6. Here's why I think it's worth your attention.

What is Chuks?
Chuks bridges scripting-language simplicity with compiled-language performance. Think TypeScript's developer experience, Go's deployment model, and a runtime that's faster than both.

It ships as a single binary with a VM, AOT compiler, built-in HTTP server, 4 SQL database drivers, structured concurrency, and 30+ standard library modules — all included, no packages required.

import { createServer, Request, Response } from "std/http"

var app = createServer()

app.get("/", function(req: Request, res: Response) {
    res.json('{"status": "ok"}')
})

app.listen(3000)

That's a production-grade, multi-threaded HTTP server in 8 lines.

The Numbers

Chuks beats Go on Fibonacci, matches it on N-Body, and is 2–5x faster than Java and Node.js across the board. It's 60–255x faster than Python.

How?
Chuks compiles to Go source via AOT, then to native machine code. The AOT compiler produces devirtualized method dispatch, typed arithmetic, and zero-cost nil checks — code that's nearly identical to hand-written Go.

It handles requests across all CPU cores by default.

What Makes Chuks Different
Dual execution modes. Run with chuks run (VM for rapid development) or build with chuks build (AOT for production). No other language offers both.

True structured concurrency. spawn runs any function in parallel. async/await handles I/O. Parent task cancellation automatically cascades to children — no leaked Promises, no dangling goroutines.

async function handleRequest(req: Request, res: Response):Task<void>{
    var userTask: Task<any> = spawn fetchUser(req.params["id"])
    var ordersTask: Task<any> = spawn fetchOrders(req.params["id"])

    var user: any = await userTask
    var orders: any = await ordersTask

    res.json({ "user": user, "orders": orders })
}

Batteries included. The standard library covers HTTP, JSON, JWT, crypto, validation, rate limiting, UUID, regex, logging, channels, TCP/TLS, file I/O, and 4 built-in SQL drivers (SQLite, PostgreSQL, MySQL, MSSQL).

Growing package ecosystem. Redis, Kafka, RabbitMQ, MongoDB, Elasticsearch, gRPC, NATS, WebSocket, S3, SMTP, GraphQL, OpenAPI, OAuth, OpenTelemetry, cron, CSV, XML, YAML — all available as packages.

Tooling from day one. VS Code extension with syntax highlighting, LSP, and snippets. Built-in debugger (DAP). REPL. Self-updating CLI with chuks upgrade.

Get Started

# Install (macOS/Linux/Windows)
curl -fsSL https://raw.githubusercontent.com/chuks-programming-language/releases/main/install.sh | bash

# Create a project
chuks new my_app
cd my_app
chuks run src/main.chuks

# Build for production
chuks build src/main.chuks
./build/main.chuks.bin

X: @Chukslang
Website: chuks.org
GitHub: github.com/chuks-programming-language

Chuks is still early (v0.0.6), but the foundation is solid — 157 tests passing, cross-platform releases (macOS, Linux, Windows), and real-world projects already running on it.

I'd love feedback. What would you want from a language like this?

ExpressWebJs 4 is now released!

Chukwuemeka Igbokwe — Wed, 21 Sep 2022 17:17:22 +0000

ExpressWebJs version 4 is now released and it includes many new features, including:

Mongoose and ObjectionJs ORM support.
SQL database relationship addons.
Multi-tenancy support for mongo DB.
Route match.
Route redirect.
Improved middleware handler methods.
Improved service registry handlers.
Custom validation rules.
Improved event class generation.
Added Redis to the supported queue connections.
Service communication for distributed services.
Domain-driven design (DDD).
Support for Restana platform service for faster request processing.
New utility features like Optional( ),ObjectMapper( ), FirstCharacterToLowerCase( ), Group( ), ObjectHasProperty( ).
New Collection feature which helps you work on advanced data structures and algorithms.

ExpressWebJs uses a variety of community driven packages for a number of features in the framework.

ExpressWebJs version 4 will receive bug fixes until November 2023 and security fixes until February 2024. Here are some of the features that we’ve covered in detail.

We’ve added some relationship add-ons for the SQL database model.
The relationship mapping method now has a nice way of handling relationships with the new hasMany, belongsTo, hasOne, hasOneThrough, hasManyThrough methods that also accept additional options.

hasManyThrough()

 export class UserModel extends Model {
  static tableName = "users";

  id!: string;
  name!: string;
  email!: string;
  password!: string;

  static relationMappings() {
    return {
      carOwner: this.hasManyThrough("App/Model/Cars_model",
      "App/Model/CarOwners_model", {
        join_final_foreign_key: "user_id",
        join_parent_foreign_key: "car_id",
      }),
    };
  }
}

hasOneThrough()

 export class UserModel extends Model {
  static tableName = "users";

  id!: string;
  name!: string;
  email!: string;
  password!: string;

  static relationMappings() {
    return {
      carOwner: this.hasOneThrough("App/Model/Cars_model", 
        "App/Model/CarOwners_model", {
        join_final_foreign_key: "user_id",
        join_parent_foreign_key: "car_id",
      }),
    };
  }
}

hasOne()

export class UserModel extends Model {
  static tableName = "users";

  id!: string;
  first_name!: string;
  last_name!: string;
  email!: string;
  password!: string;

  static relationMappings() {
    return {
      profile: this.hasOne("App/Model/Profile_model"),
    };
  }
}

hasMany()

export class UserModel extends Model {
  static tableName = "users";

  id!: string;
  first_name!: string;
  last_name!: string;
  email!: string;
  password!: string;

  static relationMappings() {
    return {
      profile: this.hasMany("App/Model/Cars_model"),
    };
  }
}

belongsTo()

export class Posts extends Model {
  static tableName = "posts";

  id!: string;
  name!: string;
  user_id!: string;

  static relationMappings() {
    return {
      users: this.belongsTo("App/Model/Users_model"),
    };
  }
}

Relation filters
You can also add some filters to your relationship mapping:

static relationMappings() {
    return {
      profile: this.hasMany("App/Model/Cars_model",{
        filter: (builder) => {
          builder.where("name", "Mercedes");
        },
      }),
    };
  }

Some route features are also added

Route Match
Sometimes you may need to register a route that responds to multiple HTTP verbs. You may do so using the match method. Or, you may even register a route that responds to all HTTP verbs using the all method:

  Route.match(["get", "post"], "/books", 
        "UserController@process");

Route Redirect
If you are defining a route that redirects to another URI, you may use the Route redirect method. This method provides a convenient shortcut so that you do not have to define a full route or controller for performing this task.

 Route.redirect("source_url", "destination_url");

You can see the complete list of new features and updates on ExpressWebJs website.

Kindly follow ExpressWebJs on twitter.

And don't forget to star on github.

You can also join the discord channel

Dependency Injection in ExpressWebJs V3

Chukwuemeka Igbokwe — Sun, 17 Oct 2021 11:42:51 +0000

In software engineering, dependency injection is a technique in which an object receives other objects that it depends on, called dependencies.

Typically, the receiving object is called a client and the passed-in ('injected') object is called a service.

The code that passes the service to the client is called the injector. Instead of the client specifying which service it will use, the injector tells the client what service to use. The 'injection' refers to the passing of a dependency (a service) into the client that uses it.

We can inject the classes into another class’s constructor and then get the object of that class, and through that object, we can access its methods and properties.

ExpressWebJs Dependency Injection

The Service Container in ExpressWebJs is a Dependency Injection Container and a registry for the application.

ExpressWebJs Container is a powerful tool for managing dependencies and stores objects for various purposes.

First let's create our Service and register it in App/Providers/AppServiceProvider.ts register method:

UserServiceInterface:

interface UserServiceInterface {
  createUser(user: object): Promise<UserObject>;
  findUserById(id: string): Promise<UserObject>;
}
export default UserServiceInterface;

UserService:


import Users from "App/Model/Users_model";
import UserServiceInterface from "./UserServicerInterface";

class UserService implements UserServiceInterface {
  async findUserById(id: string): Promise<object> {
    return await new Promise(async (resolve, reject) => {
      try {
        let user = await Users.query().findById(id);
        resolve(user);
      } catch (error) {
        reject(error);
      }
    });
  }

  async createUser(user: object): Promise<object> {
    return await new Promise(async (resolve, reject) => {
        try {
          let result = await Users.query().insert(user);
          resolve(result);
        } catch (error) {
          reject(error);
        }
      });
  }
}

export default UserService;

Now we register UserService in App/Providers/AppServiceProvider.ts register method:

import ServiceProvider from "Elucidate/Support/ServiceProvider";
import UserService from "App/Service/UserService";

class AppServiceProvicer extends ServiceProvider {
  /**
   * Register any application services.
   * @return void
   */
  public register() {
     this.app.singleton("UserService", UserService, "class");
  }
}

We can now inject our UserService into UserController Constructor:

"use strict";
import UserServiceInterface from "App/Service/UserService/UserServicerInterface";
import { Request, Response, NextFunction } from "Elucidate/HttpContext";
import HttpResponse from "Elucidate/HttpContext/ResponseType";

class UserController {
  protected userService: UserServiceInterface;

  constructor(UserService: UserServiceInterface) {
    this.userService = UserService;
  }

  /**
   * Display the specified resource.
   * @method GET
   * @endpoint api/user/get_user/:id
   * @param Request
   * @return Response
   */
  show = async (req: Request, res: Response, next: NextFunction) => {
    try {
      let user = await this.userService.findUserById(req.params.id);
      return HttpResponse.OK(res, user);
    } catch (error) {
      return next(error);
    }
  };
}

export default UserController;

In this example, the UserController needs to retrieve a user by id from a data source. So, we injected our service (UserService) that is able to retrieve users.

I hope this is helpful.

Kindly visit Expresswebjs Docs for documentation and usage.

Join ExpressWebJs community on Discord

You can follow ExpressWebJs on twitter @expresswebjs

And don't forget to star ExpressWebJs Project on Github
ExpressWebJs Javascript Version

ExpressWebJs Typescript Version

ExpressWebJs 3.2 Released

Chukwuemeka Igbokwe — Sun, 19 Sep 2021 22:57:35 +0000

The ExpressWebJs team have released 3.2 with auto endpoint documentation, and improvement in service injection.

Auto Endpoint Documentation:

Reference documentation for API endpoints consists of five general sections: resource descriptions, endpoints and methods, parameters, sample requests, and sample responses and schemas. All these are auto documented for you while you code, to allow you focus on building your amazing application.

To get started, install ExpressWebJs by running the command below

 npx expresswebcli new MyApplication --ts

and run 'npm install' to install the node packages 📦. Then create few endpoints and visit your base url in a browser followed by /documentationView for HTML view or /documentationJson for JSON.

Example: http://127.0.0.1:5000/documentationView or http://127.0.0.1:5000/documentationJson.

Service Injection

You can now inject services irrespective of the order in the application context.

In our Application Service Provider register method, we've registered some services.


  public register() {
    this.app.singleton("UserService", UserService, "class");
    this.app.singleton("CompanyService", CompanyService, "class");
    this.app.singleton("FolderService", FolderService, "class");
  }

Now we can inject UserService into FolderService like so:


import FolderRepository from "App/Repository/FolderRepository";
import BaseService from "../BaseService";
import IFolderService from "./IFolderService";
import IUserService from "./IUserService";

class FolderService extends BaseService implements
  protected userService:IUserService

  constructor(UserService:IUserService){
    this.userService = UserService
  }

 IFolderService {
  async getSubFolders(user_id: string): Promise<object> {
    return await new Promise(async (resolve, reject) => {
      try {
        let data = await new userService().findById(user_id);
        ...
      } catch (error: any) {
        ...
      }
    });
  }
}

You can join ExpressWebJs community on Discord and don't forget to give us a star on github
ExpressWebJs Javascript and ExpressWebJs Typescript

ExpressWebJs Maintenance Mode

Chukwuemeka Igbokwe — Mon, 16 Aug 2021 03:15:22 +0000

In this tutorial, I will show you how to switch your ExpressWebJs application to maintenance mode, and also how to change the default ExpressWebJs maintenance mode message to your custom message.

More often than not you would need to perform some maintenance for your ExpressWebJs application, luckily ExpressWebJs makes it super easy to put your application in maintenance mode.

You can switch your application to maintenance mode in Config/app.ts file.

 /*
  |-----------------------------------------------------------
  | Application maintenance mode
  |-----------------------------------------------------------
  | Mode ==> Determine if application is in maintenance mode 
  |    or not. Default value is false
  | Message ==> The message to render while in maintenance 
  |    mode.
  | Retry ==> The number of seconds after which the request 
  |    may be retried
  | Endpoints ==> The endPoints that should be reachable while 
  |    maintenance mode is enabled.
  |    endpoints example: ['api/users','api/accounts']
  |
*/
  maintenanceMode: {
    mode: true, //enable and disable maintenance mode
    message: "Application is in maintenance mode.",
    retry: 50,
    endPoints: [],
  },

When your application is in maintenance mode, a default message "Application is in maintenance mode" will be sent as a response to all requests accessing your application. This makes it easy to "disable" your application on downtime.

This downtime could be for a lot of reasons, including but not limited to:

Bugs.
Database error.
Migration to another server.
Server upgrade.
Decoupling to a new architecture.
SSL Error.
Updating Application etc.

A maintenance mode check is included in the default middleware stack for your application. If the application is in maintenance mode, a MaintenanceModeException will be thrown with a status code of 503.

To read more about ExpressWebJs, visit the Documentation site at ExpressWebJs .
You can also join the Discord community

You can follow me on twitter @EmekaIgbokwe
You can follow ExpressWebJs on twitter @expresswebjs
and don't forget to star on github ExpressWebJs

Please, let me know if you have any questions in the comment section. 😊

ExpressWebJs 3 Is Now Released!

Chukwuemeka Igbokwe — Fri, 13 Aug 2021 22:59:03 +0000

ExpressWebJs team is proud to announce the release of ExpressWebJs 3 and it’s now available to everyone. This release marks the start of the ExpressWebJs framework using Typescript.

Also, this release includes improved authentication and authorization responses, job, middleware, route collections, sub-query improvements, among many other improvements.

Here are some of the new features included in ExpressWebJs 3:

Model Types for SQL and NOSQL
Maker Command
Persistent Repository
Multi Tenancy
Social Authentication
Encryption
Hashing
Route Groups and middleware
Request Validation (Inline and external)
Dependency Injection
Service Providers
Events And Listeners
Queues
Task Schedulers
Web Socket

Please visit Expresswebjs Docs for documentation and usage.

Thanks to everyone who have contributed with issue reports and pull requests. Our next set of releases are due March 19, 2022.

How can you help?
If you’re interested in helping out, or if you have general questions, please ask on stackoverflow.com using the ExpressWebJs tag or chat with the community on Discord

JWT authentication in Expresswebjs

Chukwuemeka Igbokwe — Sun, 07 Mar 2021 10:50:46 +0000

With the rising popularity of single page applications, mobile applications, and RESTful API services, the way web developers write back-end code has changed significantly. We now use expresswebjs to build APIs that our front-end applications consume. ExpressWebJs strives to give you the tools you need to implement authentication quickly, securely, and easily. Since ExpressWebJs does not support session state, incoming requests that you wish to authenticate will be authenticated via a stateless mechanism such as API tokens.

In this article, we will look at using JWT to secure our ExpressWebJs APIs.

What is a JSON Web Token?

JSON Web Token (JWT) is an open standard that allows two parties to securely send data and information as JSON objects. This information can be verified and trusted because it is digitally signed.

JWT authentication has aided the wider adoption of stateless API services. It makes it convenient to authorise and verify clients accessing API resources. It is a critical part of the authentication system in javascript powered applications.

Getting Started

The first thing we are going to do is create a new expresswebjs application.To start your new project, you can open your terminal or CLI and type npx expresswebcli new command, followed by your project name. Example:

  npx expresswebcli new jwtApp

Once that is done, cd into your project like so cd jwtApp and run npm install to install your packages.

When that is done, you can now create your .env file:

   cp example.env .env

In our .env we can now configure our database. ExpressWebJs supports SQL and NOSQL database. In this tutorial, we will be using Mysql which is an SQL database.

APP_KEY=base64:Mk9TtGvMu3Kfp9wdahuownbdgsI3VTx2MXTQjN/6CFBadI=
APP_NAME=ExpressWebJs
APP_ENV=local
APP_HOST=127.0.0.1
APP_PORT=5000
APP_TRANSFER_PROTOCOL=http

DB_SHOULD_CONNECT=true
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_USER=
DB_PASSWORD=
DB_DATABASE=network-provider
DB_USENEWURLPARSER=true
DB_USEUNIFIEDTOPOLOGY=true
DB_USECREATEINDEX=true

Note: Don't forget to set your APP_KEY.

run npm run dev to start your app

To generate our authentication files, we will now run auth Maker command to setup our auth routes

  node maker make-auth

Our auth routes will be generated in Routes/authRoute/index.js file.

"use strict";
const Route = require("@routerManager");

/*
|-------------------------------------------------------------
| Authentication Route File   
|-------------------------------------------------------------
|
| This route handles both login and registration.
| 
*/

Route.post("/register", "Auth/RegisterController@register");

Route.post("/login", "Auth/LoginController@login");

module.exports = Route.exec;

Next, uncomment the auth middleware inside the App/Http/kernel.js file routeMiddleware section:

  /*
  |-----------------------------------------------------------
  | Route Middleware
  |-----------------------------------------------------------
  |
  | Route middleware is a key/value object to conditionally 
  | add middleware on
  | specific routes or assigned to group of routes.
  |
  */
  routeMiddleware: {
    auth: "App/Http/Middleware/Auth",
  },

At this point we need to setup and run our migration schema for our user model. Head over to Database/Migrations/20201209124747_user.js file.

/**
 * Migration layout file.
 * Assign your table name to the tableName variable.
 * Remember, it's always in plural
 */
let tableName = "users";
exports.up = function (knex) {
  return knex.schema.createTable(tableName, (table) => {
    table.increments("id");
    table.string("username").notNullable();
    table.string("email").unique().notNullable();
    table.string("password", 255).notNullable();
    table.timestamps(true, true);
  });
};

exports.down = function (knex) {
  return knex.schema.dropTable(tableName);
};

we can now run our migration with the following command:

   node maker run-sql-migration

To view our authentication config, head over to App/Config/auth.js file.

  module.exports = {
  /*
  |-----------------------------------------------------------
  | Authenticator
  |-----------------------------------------------------------
  |
  | ExpressWebJs does not support session state, incoming 
  | requests that 
  | you wish to authenticate must be authenticated via a 
  | stateless mechanism such as API tokens.
  |
  */
  authenticator: "jwt",

  /*
  |-----------------------------------------------------------
  | Jwt
  |-----------------------------------------------------------
  |
  | The jwt authenticator works by passing a jwt token on each 
  | HTTP request
  | via HTTP `Authorization` header.
  |
  */
  jwt: {
    model: "User_model",
    driver: "jwt",
    uid: "email",
    password: "password",
    secret: process.env.APP_KEY,
    options: {
      expiresIn: 86400, //default is 86400 (24 hrs)
    },
  },
};

To read more about authentication config, visit ExpressWebJs Authentication.

Route Authentication

We can now authenticate our routes like so:

  Route.get('/user', 'UserController@index',['auth']);

You can also authenticate your route groups like so:

  Route.group('/user',['auth'],()=>{
    Route.get('/', 'UserController@index');
    Route.get('/:id', 'UserController@show');
    Route.post('/save', 'UserController@save');
    Route.patch('/update', 'UserController@update');
    Route.delete('/delete', 'UserController@destroy');
});

READ developing-rest-apis-with-expresswebjs-v2.

In your PostMan, access the register endpoint using a post method 127.0.0.1:5000/api/register and input your username, email and password.

Conclusion

Well done! You have learned how to secure your API routes with ExpressWebjs. Need to use ExpressWebjs to build your API or micro-service? I'd bet on ExpressWebjs as the tool of choice for speed and ease of use.

I will be discussing on ExpressWebjs Data Validation in my next article.
You can follow me on twitter @EmekaIgbokwe
You can follow ExpressWebJs on twitter @expresswebjs
and don't forget to star on github ExpressWebJs

Please, let me know if you have any questions in the comment section. 😊

Documenting your ExpressWebJs API with Swagger

Chukwuemeka Igbokwe — Fri, 26 Feb 2021 14:23:34 +0000

Almost every application today has to be connected to share data with other applications. The best way to do that is through APIs and ExpressWebjs is the goto framework for building your node apis.

In this tutorial, however, we’re going to explore Swagger usage along with expressWebjs.

What is Swagger?
On the Swagger site we can find definition of Swagger:
Swagger is the world’s largest framework of API developer tools for the OpenAPI Specification(OAS), enabling development across the entire API lifecycle, from design and documentation, to test and deployment.

In our example, we’ll be making use of the two libraries: swagger-ui-express and swagger-jsdoc.

The first is a module that allows you to feed a Swagger UI (auto-generated views based on the swagger-ui project) from a swagger.json file, or from an inline object.

The second is about integrating Swagger using JSDoc comments in Docs directory in ExpressWebjs. This is pretty useful, especially when you have extensive APIs and dozens of models.

Application setup

Install ExpressWebJs

Run the following command in your terminal to create a new project with ExpressWebJs:

   npx expresswebcli new myNewApp

cd into your newly created project.

   cd myNewApp

Visit my article on developing rest apis with expresswebjs or expresswebjs documentation for work through on how to get started with expresswebjs.

Adding swagger

Now that our application is ready,

we can now integrate swagger by creating our swagger.json file in the root directory

{
    "definition": {
      "openapi": "3.0.n",
      "info": {
        "title": "My Website API Documentation",
        "version": "0.1.0",
        "description":
          "My website API docs with ExpressWebJs and documented with Swagger",
        "license": {
          "name": "MIT",
          "url": "https://spdx.org/licenses/MIT.html"
        },
        "contact": {
          "name": ""
        }
      },
      "servers": [
        {
          "url": "http://localhost:5100/api"
        }
      ]
    },
    "apis": ["./Docs/*.js"]
  }

This "apis": ["./Docs/*.js"] section specifies the path where your actual documentations are. In our case, it is in Docs folder in the root directory.

After that we can now create our swagger service in App/Service directory.

In App/Service directory, lets create a Swagger folder with an index.js file. Our path will be App/Service/Swagger/index.js

 //App/Service/Swagger/index.js
const swaggerJsdoc = require("swagger-jsdoc");
const swaggerUi = require("swagger-ui-express");
const options = require("../../../swagger.json");

class Swagger{
  static run(){
    let specs = swaggerJsdoc(options);
    serverApp.use("/api-docs",swaggerUi.serve,swaggerUi.setup(specs,{exporer:true}));
  }
}

module.exports = Swagger;

ExpressWebJs ServiceProvider

Next we will register our swagger service in our application service provider. Navigate to App/Providers/AppServiceProvider.js file and add our swagger service to be executed at boot time

 const swagger = require("../Service/swagger");

 class AppServiceProvider {
  /**
   * Register application services.
   */
  register() {
    return {
      //
    };
  }

  /**
   * Bootstrap any application services.
   *
   * @return void
   */
  boot() {
    swagger.run();
  }
}

module.exports = AppServiceProvider;

Note: you can create your own service provider. Read more about ExpressWebjs ServiceProvider in the Documentation site.

Once all the setup is done, you can now start writing your api documentation in the Docs directory.

To view your swagger docs, run your project using

  npm run dev

and navigate to http://127.0.0.1/api/api-docs in your browser.

Conclusion

Thank you for reading my article
You can follow me on twitter @EmekaIgbokwe
You can follow ExpressWebJs on twitter @expresswebjs
and don't forget to star on github ExpressWebJs

Please, let me know if you have any questions in the comment section. 😊

DEV Community: Chukwuemeka Igbokwe

Chuks v0.2.0-rc.1 Is Out, We Need You to Try to Break It

Also in this RC

Chuks v0.1.1, The Correctness Release

Agreement to the last ULP

How these bugs surface

Live imports

Reading a map yields an optional

Generics across packages

Mobile: a real development loop

Streaming HTTP, both ways

Where Chuks stands

Upgrading

Chuks v0.1.0: unboxing the hot path (and a 58x speedup hiding in `any`)

The boxing tax

The VM: typed slots

The AOT compiler: inlining array reads

Warm benchmarks (min ms, arm64, lower is better)

The 58x hiding in any

Speed was not the only headline

The throughline: one language, two backends, kept honest

Try it

Chuks Language Data Types

Stop fighting your data. Let dataType win.

@validate: one annotation, full validation.

Custom validators: your rules, first class

Embedding: compose shapes, not hierarchies

@json — rename fields for the wire

Chuks, A New Programming Language That Outperforms Go on HTTP Throughput

ExpressWebJs 4 is now released!

Dependency Injection in ExpressWebJs V3

ExpressWebJs Dependency Injection

UserServiceInterface:

UserService:

Now we register UserService in App/Providers/AppServiceProvider.ts register method:

We can now inject our UserService into UserController Constructor:

ExpressWebJs 3.2 Released

Auto Endpoint Documentation:

Service Injection

ExpressWebJs Maintenance Mode

ExpressWebJs 3 Is Now Released!

JWT authentication in Expresswebjs

What is a JSON Web Token?

Getting Started

Note: Don't forget to set your APP_KEY.

Route Authentication

Conclusion

Documenting your ExpressWebJs API with Swagger

Application setup

Install ExpressWebJs

Adding swagger

ExpressWebJs ServiceProvider

Conclusion

The 58x hiding in `any`