DEV Community: Daniel Madrid

Wolfy v0.1.1: A TypeScript Wrapper for the Wolfram Alpha API

Daniel Madrid — Fri, 19 Dec 2025 15:13:03 +0000

Working with the Wolfram Alpha API in JavaScript or TypeScript often means dealing with low-level HTTP requests and response parsing. Wolfy is a lightweight, open-source TypeScript wrapper for the Wolfram Alpha API that simplifies this process while staying minimal and fully typed.

With the release of Wolfy v0.1.1, the library now offers a more polished developer experience across Node.js, Deno, Bun, browsers, and edge runtimes. This project is non-commercial and community-driven, created to make Wolfram Alpha queries easier to use in modern JavaScript applications.

Disclaimer: I am not affiliated with Wolfram Alpha.
Wolfy is an independent, open-source wrapper and does not generate revenue.

Why Wolfy?

The Wolfram Alpha API provides powerful computational knowledge, but using it directly can be verbose when all you need is a quick result. Wolfy aims to solve that by providing:

A simple and predictable API.
Strong TypeScript typings.
Cross-runtime compatibility.
A thin abstraction with no hidden behavior.

Wolfy is distributed via jsr, making it easy to use in modern environments: @danimydev/wolfy

Right now, the library provides callers to Simple, Short Answers and Spoken Results APIs.

// index.ts

import Wolfy from "wolfy";

const result = await Wolfy.shortAnswers({
  appId: "YOUR_WOLFRAM_APP_ID",
  input: "integrate x^2",
});

console.log(result); // x^3/3

const spoken = await Wolfy.spokenResult({
  appId: "YOUR_WOLFRAM_APP_ID",
  input: "What is the speed of light?",
});

console.log(spoken) // c;

What’s New in v0.1.1?

Version 0.1.1 focuses on stability and polish:

Improved typings and API consistency
Small refinements based on early usage
General cleanup and maintenance

Who Should Use This?

Wolfy is useful if you’re:

Building TypeScript or JavaScript apps that need computational answers
Prototyping math, science, or data-driven features
Looking for a minimal Wolfram Alpha client without extra abstractions

Wolfy is intentionally small and focused, and that’s by design. If you’re looking for a simple, typed way to work with the Wolfram Alpha API in TypeScript, this project might be useful to you. Feedback and contributions are always welcome.

Rate limiters with node:http and redis

Daniel Madrid — Wed, 17 Dec 2025 23:24:22 +0000

When you’re running a plain node:http server, adding rate limiting often feels heavier than it needs to be. Most solutions assume Express-style middleware or an API gateway sitting in front of your app.

This approach keeps things closer to the metal, no framework assumptions, no magic lifecycle hooks—just functions that decide whether a request is allowed to continue.

Design goals

Framework-agnostic: works directly with http.createServer.
Redis-backed: safe for multiple processes or servers.

The result is something you can read end-to-end without needing to know a specific ecosystem.

The Base Request Handler

Rate limiters follow the same RequestHandler type used elsewhere in the server. A handler inspects the request, possibly writes a response, and either ends the request or lets it continue.

// request-handler.ts

import http from "node:http";

export type RequestHandler<ReturnType = void> = (
  incommingMessage: http.IncomingMessage,
  serverResponse: http.ServerResponse,
) => ReturnType;

Rate limiter strategies

Fixed window counter

The fixed window strategy is straightforward:

Each client gets a Redis key.
Requests increment a counter.
The key expires after windowSize seconds.
Once the limit is reached, requests are rejected until the window resets.

// redis-rate-limiter.ts

import http from "node:http";
import { createClient, createClientPool } from "redis";

import type { RequestHandler } from "./request-handler";

export function fixedWindowCounter(
  client: ReturnType<typeof createClient> | ReturnType<typeof createClientPool>,
  config: {
    limit: number;
    windowSize: number;
    baseKey: string;
    getClientIdFromIncommingRequest: (
      incommingMessage: http.IncomingMessage,
    ) => string;
  },
): RequestHandler<Promise<void>> {
  return async (incommingMessage, serverResponse) => {
    const key = `${config.baseKey}:${config.getClientIdFromIncommingRequest(
      incommingMessage,
    )}`;

    const currentValue = parseInt((await client.get(key)) ?? "");
    const count = Number.isNaN(currentValue) ? 0 : currentValue;

    if (count >= config.limit) {
      const ttl = await client.ttl(key);
      const retryDate =
        ttl > 0
          ? new Date(Date.now() + ttl * 1000).toUTCString()
          : new Date(Date.now() + config.windowSize * 1000).toUTCString();

      serverResponse.statusCode = 429;
      serverResponse.setHeader("Retry-After", retryDate);
      serverResponse.setHeader("Content-Type", "text/plain");
      serverResponse.end("Too Many Requests");
      return;
    }

    const transaction = client.multi();
    transaction.incr(key);
    transaction.expire(key, config.windowSize, "NX");
    await transaction.exec();
  };
}

When this works well

Low to moderate traffic.
Simple abuse prevention.
Internal or trusted clients.

Known limitations

Traffic can spike at window boundaries.
Enforcement is coarse-grained.

If those are acceptable, fixed windows are hard to beat for simplicity.

Sliding window counter

Sliding windows trade simplicity for smoother enforcement. Instead of one counter, requests are grouped into smaller time buckets.

Each request:

Increments a sub-window counter.
Checks the sum of all sub-windows in the main window.
Expires buckets automatically over time.

// redis-rate-limiter.ts

import http from "node:http";
import { createClient, createClientPool } from "redis";

import * as Utils from "../utils";
import type { RequestHandler } from "./request-handler";

export function slidingWindowCounter(
  client: ReturnType<typeof createClient> | ReturnType<typeof createClientPool>,
  config: {
    limit: number;
    windowSize: number;
    subWindowSize: number;
    baseKey: string;
    getClientIdFromIncommingRequest: (
      incommingMessage: http.IncomingMessage,
    ) => string;
  },
): RequestHandler<Promise<void>> {
  return async (incommingMessage, serverResponse) => {
    const key = `${config.baseKey}:${config.getClientIdFromIncommingRequest(
      incommingMessage,
    )}`;

    const values = Object.values(await client.hGetAll(key))
      .map(parseInt)
      .map((v) => (Number.isNaN(v) ? 0 : v));

    const total = Utils.getNumberArraySum(values);

    if (total >= config.limit) {
      const retryDate = new Date(
        Date.now() + config.subWindowSize * 1000,
      ).toUTCString();

      serverResponse.statusCode = 429;
      serverResponse.setHeader("Retry-After", retryDate);
      serverResponse.setHeader("Content-Type", "text/plain");
      serverResponse.end("Too Many Requests");
      return;
    }

    const currentSubWindow =
      Math.floor(Date.now() / (config.subWindowSize * 1000)) *
      (config.subWindowSize * 1000);

    const transaction = client.multi();
    transaction.hIncrBy(key, currentSubWindow.toString(), 1);
    transaction.hExpire(
      key,
      currentSubWindow.toString(),
      config.windowSize,
      "NX",
    );

    await transaction.exec();
  };
}

Trade-offs

Pros

Smoother request distribution.
No hard reset boundaries.

Cons

More Redis operations.
Slightly more complexity.
Still intentionally practical, not theoretical.

Using a rate limiter in a server

Here’s a minimal example wiring a rate limiter into a Node HTTP server.

// server.ts

import http from "node:http";
import { createClient } from "redis";

import { fixedWindowCounter } from "./rate-limiters";

const redis = createClient();
await redis.connect();

const rateLimiter = fixedWindowCounter(redis, {
  limit: 100,
  windowSize: 60,
  baseKey: "rate-limit",
  getClientIdFromIncommingRequest: (req) =>
    req.socket.remoteAddress ?? "unknown",
});

const server = http.createServer();

server.on("request", async (req, res) => {
  await rateLimiter(req, res);

  if (res.writableEnded) {
    return;
  }

  res.statusCode = 200;
  res.end("OK");
});

server.listen(3000);

If the limiter decides the request shouldn’t proceed, it ends the response and nothing else runs.

Closing thoughts

This setup isn’t meant to replace dedicated gateways or edge rate limiting. It’s a pragmatic/educative solution.

Everything happens in plain Node, Redis does the counting, and the behavior is easy to reason about by just reading the code.
If that’s the kind of setup you prefer, this approach fits nicely without dragging in a framework.

Authentication with node:http and better-auth

Daniel Madrid — Sun, 14 Dec 2025 20:04:29 +0000

Sometimes I just want a Node.js server that works without pulling in Express or any other heavy frameworks. This is a simple pattern I’ve been using for handling authentication with node:http and a library called better-auth. I’m writing this down for future me, so I don’t have to remember all the small details. Hope this helps you or at least shows you something new.

Why this approach?

No frameworks: I don’t want to add Express/Koa just for a few endpoints.
Minimal dependencies: better-auth handles the auth logic; everything else stays standard Node.
Control: I can see exactly what’s happening in the request/response pipeline.

The Base Request Handler

This is a representation of a http.Server on request handler that receives an incommingMessage and serverResponse in order to return a generic type <T> or void by default.

// request-handler.ts

import http from "node:http";

export type RequestHandler<ReturnType = void> = (
  incommingMessage: http.IncomingMessage,
  serverResponse: http.ServerResponse,
) => ReturnType;

The Handler

The core of this setup is a small handler function that wraps your auth handler. It converts the raw request, runs the auth, sets headers, and streams the body if present.

// utils.ts

import http from "node:http";

export function incommingMessageToRequest(
  incommingMessage: http.IncomingMessage,
  baseUrl: URL,
): Request {
  const method = incommingMessage.method || "GET";

  const url = new URL(incommingMessage.url || "/", baseUrl);

  const headers = new Headers();
  for (const [key, value] of Object.entries(incommingMessage.headers)) {
    if (Array.isArray(value)) {
      value.forEach((v) => headers.append(key, v));
    } else if (value !== undefined) {
      headers.set(key, value);
    }
  }

  const body =
    method === "GET" || method === "HEAD" ? undefined : incommingMessage;

  return new Request(url.toString(), {
    method,
    headers,
    body,
    duplex: body ? "half" : undefined,
  });
}

// better-auth-handler.ts

import stream from "node:stream";
import streamPromises from "node:stream/promises";

import type { Auth, BetterAuthOptions } from "better-auth";

import type { RequestHandler } from "./request-handler";

import * as Utils from "./utils";

export type Config = {
  baseUrl: URL;
};

export default function betterAuth(
  auth: Auth<BetterAuthOptions>,
  config: Config,
): RequestHandler<Promise<void>> {
  return async (incommingMessage, serverResponse) => {
    const response = await auth.handler(
      Utils.incommingMessageToRequest(incommingMessage, config.baseUrl),
    );

    serverResponse.statusCode = response.status;
    serverResponse.statusMessage = response.statusText;

    response.headers.forEach((value, key) => {
      if (key.toLowerCase() === "transfer-encoding") return;
      serverResponse.setHeader(key, value);
    });

    if (!response.body) {
      serverResponse.end();
      return;
    }

    await streamPromises.pipeline(
      stream.Readable.fromWeb(response.body),
      serverResponse,
    );
  };
}

Hooking it up to a server

Here’s how I use it in a plain Node HTTP server:

// index.ts

import http from "node:http";

import BetterAuthHandler from "./better-auth-handler";

import { auth } from "./auth";

async function main() {
  const httpServer = http.createServer();

  const betterAuthHandler = BetterAuthHandler(auth, {
    baseUrl: new URL(process.env.BETTER_AUTH_URL),
  });

  httpServer.on("request", async (incommingMessage, serverResponse) => {
    await betterAuthHandler(incommingMessage, serverResponse);

    if (serverResponse.writableEnded) {
      return;
    }

    serverResponse.statusCode = 404;
    serverResponse.end("Not Found");
    return;
  });

  httpServer.listen(env.PORT, () => {
    console.log(`http server listening on port ${env.PORT}`);
  });
}

main();

That’s it. Nothing fancy, just a small, predictable setup that does what it needs to do.

If you’re reading this in the future: this worked, it stayed out of the way, and it didn’t require a framework.

Hopefully it’s useful to you too if you’re aiming for the same kind of minimal, boring-in-a-good-way Node server.