DEV Community: Devlin Duldulao

DaloyJS Is the Latest Modern Enterprise TypeScript Framework, and It Has Your Back on Security

Devlin Duldulao — Sat, 30 May 2026 13:06:10 +0000

DaloyJS Is the Latest Modern Enterprise TypeScript Framework, and It Has Your Back on Security

I want to tell you something that took me years to learn, so you can learn it on a Tuesday afternoon instead of during a production incident: most developers who build REST APIs do not actually know all the security protections their API needs. I did not know them when I started. I learned them slowly, usually right after something broke.

I am a Filipino fullstack developer, about ten years in, now based in Norway. I built DaloyJS (@daloyjs/core) partly so that newer developers do not have to learn security the painful way I did. This post is a gentle walk through the problem and how DaloyJS helps. No gatekeeping, I promise.

First, what even is a "security protection"?

When your API is on the internet, anyone can send it anything. Most people are nice. Some are not, and a few are running automated tools that poke at every API they can find. So your server needs some basic defenses. Here are a few, in plain words:

Body-size limit: stop someone from sending a giant 2GB request that fills up your server's memory and crashes it.
Timeouts: if a request takes forever, give up on it so it does not clog everything.
Prototype-pollution protection: block a sneaky trick where a special key in the JSON (__proto__) can mess with your whole app.
Header safety: reject weird characters in headers so attackers cannot inject their own.
Path-traversal protection: stop a path like ../../etc/passwd from reading files it should not.
Hiding error details in production: do not show strangers your stack traces and internal info.
Rate limiting: stop one person from hammering your API thousands of times a second.
Secure headers and CORS: tell browsers how to safely talk to your API.

You do not need to memorize all of these today. The point I want you to take away is simpler: this list exists, it is longer than most people think, and nobody hands it to you when you write your first endpoint.

Why this is a trap, especially with AI tools

Here is the part that matters most for you right now, because you are probably using AI tools like GitHub Copilot or ChatGPT to help you build. That is great. I use them too. But you need to know how they behave around security.

When you ask an AI "make me an endpoint that saves a JSON body to the database," it does exactly that. It does not add a body-size limit. It does not add a timeout. It does not add rate limiting. It does not protect against prototype pollution. The AI is not being lazy or sneaky. It is doing exactly what you asked, and most of the example code it learned from did not have those protections either.

It gets trickier. Sometimes a security check makes a test fail, and the AI's "fix" is to just remove the check so the test passes. Now your code looks like it works, and the thing that was protecting you is gone.

And here is the real trap, the one I want you to remember: you cannot ask the AI to add protections from a list you do not have. The AI will happily add any security feature you name. But it will not suggest the ones you do not know about. You do not know what you do not know, so you never ask, so it never gets built. Telling the AI to "make it secure" does not work either, because that is too vague to mean anything.

So the trick is not "prompt better." The trick is to start with tools that already have the protections built in, so you do not have to know the whole list to be safe.

A popular framework that does not do this for you

Let me show you what I mean using a famous framework called FastAPI. I genuinely love FastAPI. It is a Python framework, and its best idea (write your route once and get nice API docs for free) is exactly the idea DaloyJS brings to TypeScript. So this is not me dunking on it.

But if you open up FastAPI's code and look in its security folder, you find tools with names like HTTPBearer, OAuth2PasswordBearer, and APIKeyHeader. Sounds very secure, right? Here is what those actually do: they grab a login token out of a request and they add a note about it to your API docs. That is helpful, but notice what it is not. It is not a body-size limit. It is not prototype-pollution protection. It is not rate limiting or secure headers or hiding errors in production.

So even a framework with a folder literally called "security" leaves most of the real protection list up to you. And FastAPI is not unusual here. Express, one of the most popular Node frameworks, ships with almost none of these protections built in. The normal expectation across most frameworks is: "here is a fast way to build routes, the security part is your job." For someone just starting out, that job is basically invisible.

How DaloyJS is different

DaloyJS has one stubborn rule: bad defaults are bugs. That means the protection list above is mostly already turned on for you, and the rest is a single line each. The project even has a rule that you are not allowed to delete a security check just to make a test pass.

Here is what writing a route looks like:

import { z } from "zod";
import { App, NotFoundError, requestId, secureHeaders, rateLimit } from "@daloyjs/core";

const app = new App({ bodyLimitBytes: 1024 * 1024, requestTimeoutMs: 5_000 });

// Security middleware. One line each, that is it.
app.use(requestId());
app.use(secureHeaders());
app.use(rateLimit({ windowMs: 60_000, max: 120 }));

app.route({
  method: "GET",
  path: "/books/:id",
  request: { params: z.object({ id: z.string() }) },
  responses: {
    200: { description: "Found", body: z.object({ id: z.string(), title: z.string() }) },
    404: { description: "Not found" },
  },
  handler: async ({ params }) => {
    const book = await findBook(params.id);
    if (!book) throw new NotFoundError(`No book with id ${params.id}`);
    return { status: 200, body: book };
  },
});

What you cannot see in that code is everything the framework is already doing quietly: the body-size limit, the timeout, the prototype-pollution-safe JSON parsing, the header safety, the path-traversal rejection, and hiding error details in production. You did not write any of that, and you cannot forget it, because it is just on.

It even watches your install step

One more thing, because it is sneaky. The packages you install can be dangerous too. There is an attack called "slopsquatting" where an AI suggests a package name that does not exist, an attacker has already registered that exact name with malware, and your install runs it.

DaloyJS helps here as well. Its core has zero outside dependencies, and the projects it creates for you are set up to block sketchy install scripts and to refuse installing brand-new packages published in the last 24 hours (the window where bad packages usually get caught). You do not need to understand all of that yet. Just know somebody already thought about it so you do not get burned while you are still learning.

The nice part: you still get all the good stuff

DaloyJS is not security-only and boring. You still get the things that make building fun:

Write a route once and get automatic API docs at /docs.
Validation and TypeScript types from that same single definition.
A typed client SDK your frontend can use, generated for you.
The ability to run the same app on Node, Bun, Deno, Cloudflare Workers, and Vercel Edge.

It is genuinely beginner-friendly, and it is also the kind of thing a serious team runs in production. You do not have to choose between "easy to learn" and "safe to ship."

Try it

pnpm create daloy@latest my-api

That gives you a working project with the docs and the safe defaults already set up. Build an endpoint, open http://localhost:3000/docs, and look around. The protections you did not even know to ask for are already there, doing their job.

When I was starting out, I learned the security checklist one mistake at a time. You get to skip most of that. Take the shortcut. You earned it just by reading this far.

Docs and source: daloyjs.dev and github.com/daloyjs/daloy.

What Is DaloyJS? A Beginner-Friendly Tour of a Contract-First TypeScript Framework

Devlin Duldulao — Sat, 30 May 2026 12:15:24 +0000

When I started building APIs, I spent way too much of my life keeping three things in sync: the actual route code, the validation, and the docs. You change one field, you forget the other two, and a week later someone on the frontend team pings you asking why the docs say title but the API returns name. Been there. Shipped that bug. Apologized in standup.

DaloyJS is the framework I wish I had back then. Let me walk you through what it is, in plain language, without assuming you have ten years of backend scars.

The one-sentence version

DaloyJS is a TypeScript web framework where you define a route once, and from that single definition you get validation, types, OpenAPI docs, and a typed client SDK. No copy-pasting. No drifting docs.

If you have heard of FastAPI in the Python world, that "write it once, get docs for free" feeling is exactly what DaloyJS brings to TypeScript.

Why should a junior developer care?

Here is the thing nobody tells you early on: most of the pain in backend work is not writing the logic. It is keeping everything that describes your logic honest. The docs, the input validation, the response shapes, the client code. They all want to lie to you the moment you stop watching them.

DaloyJS makes one definition the single source of truth. You write a route, and that route is the contract. That is what "contract-first" means. The framework reads your contract and generates the boring stuff for you.

What a route looks like

Here is a real example. Do not worry about understanding every line yet, just look at the shape of it.

import { App, NotFoundError } from "@daloyjs/core";
import { z } from "zod";

const BookSchema = z.object({ id: z.string(), title: z.string() });

const app = new App({
  openapi: { info: { title: "Bookstore API", version: "1.0.0" } },
  docs: true,
});

app.route({
  method: "GET",
  path: "/books/:id",
  operationId: "getBookById",
  request: { params: z.object({ id: z.string() }) },
  responses: {
    200: { description: "Book found", body: BookSchema },
    404: { description: "Book not found" },
  },
  handler: async ({ params }) => {
    const book = await findBook(params.id);
    if (!book) throw new NotFoundError(`No book with id ${params.id}`);
    return { status: 200, body: book };
  },
});

Notice what you did here without realizing it:

You said the URL param id is a string, so DaloyJS validates it for you.
You said a 200 response returns a BookSchema, so your editor knows the exact shape of book.
You set docs: true, so the framework mounts a live docs page at /docs automatically.

That last point is my favorite. You did not write a single line of documentation, and you still get a real, clickable API docs page. The first time I saw that, I genuinely felt a little robbed of all the hours I used to spend on Swagger config.

The "free stuff" you get from one route

1. Automatic API docs

Set docs: true and DaloyJS mounts /docs, /openapi.json, and /openapi.yaml. Your docs are generated from the same route you already wrote, so they cannot drift out of sync. When you change the route, the docs change with it. No more "the docs lied to me" tickets.

2. Validation you do not have to wire up

The schemas in request and responses are not decoration. DaloyJS actually validates incoming data against them. Send a request with a missing field, and you get a clean, standardized error response instead of a mysterious crash deep in your handler.

DaloyJS uses something called Standard Schema, which is a fancy way of saying you are not locked into one validation library. The examples use Zod 4 because it is small and modern, but Valibot, ArkType, and TypeBox all work too. Pick the one your team likes.

3. End-to-end types

Because your route knows the shape of its inputs and outputs, your editor knows too. Inside the handler, params.id is typed as a string. The body you return is checked against BookSchema. If you typo a field name, TypeScript yells at you before your code ever runs. This is the kind of safety net that makes refactoring feel less like defusing a bomb.

4. A generated client SDK

Once your API has an OpenAPI spec, you can run one command and get a fully typed fetch client out of it (DaloyJS uses Hey API for this). Your frontend can call your backend with full autocomplete and type checking, and that client regenerates whenever your contract changes. Less guessing, fewer "what does this endpoint return again?" moments.

It runs basically everywhere

A lot of frameworks quietly assume you are on Node and only Node. DaloyJS is built on the web standard Request to Response model, which is a fancy way of saying its core does not care where it runs. The same app works on Node, Bun, Deno, Cloudflare Workers, and Vercel Edge through small adapters.

For a junior dev this matters more than it sounds. It means the thing you learn today does not become useless the moment your company decides to deploy to the edge or experiment with Bun. Your knowledge travels with you.

Security you get without becoming a security expert

This is the part I wish someone had handed me on day one. Security is hard, and it is really easy to ship something insecure without knowing it. DaloyJS takes the position that bad defaults are bugs, so a bunch of protections are just on out of the box:

Request body size limits, so someone cannot send you a 2GB payload to knock your server over.
Request timeouts, so slow requests do not pile up forever.
JSON parsing that is safe against prototype pollution (a sneaky attack class you will eventually read about and be glad you were protected from).
Path-traversal rejection, so people cannot trick your server into reading files it should not.
Standardized, RFC 9457 error responses that redact sensitive details in production.

There is also first-party middleware for the usual suspects: secure HTTP headers, CORS, CSRF, rate limiting, and request ids. You add them with one line each:

app.use(requestId());
app.use(secureHeaders());
app.use(rateLimit({ windowMs: 60_000, max: 120 }));

The framework even hardens the install side of things, with defaults that wait 24 hours before pulling freshly published packages and block sketchy lifecycle scripts. You do not need to understand all of that yet. Just know that someone thought about it so you do not get burned while you are still learning.

So when would you reach for it?

If you are building a REST API in TypeScript and you want:

Docs that stay correct without extra effort,
Validation and types from one definition,
A typed client for your frontend,
Sane security defaults,
The freedom to deploy to Node now and the edge later,

then DaloyJS is worth a try. It is genuinely beginner-friendly because it removes the busywork that usually trips up newer developers, while still being the kind of thing a senior team can run in production.

Try it in two minutes

The fastest way in is the official scaffolder:

pnpm create daloy@latest my-api

That gives you a working project with docs routes, OpenAPI wiring, and production defaults already set up. Open it, poke at the example route, change a field, and watch the docs update. That little feedback loop is, honestly, the whole pitch.

I spent years duct-taping docs, validation, and types together by hand. If you are just starting out, you get to skip that phase entirely. Lucky you.