Forem: Jackson Kasi

Part 6: The Smart Client SDK (State Synchronization & Fetch Adapters)

Jackson Kasi — Fri, 03 Apr 2026 22:59:24 +0000

Part 6: The Smart Client SDK (State Synchronization & Fetch Adapters)

Welcome back. If you’ve been following the TableCraft series, you know we aren’t here to play around with fragile abstractions or “magic” boilerplates that lock you into a single vendor. We are building robust, enterprise-grade B2B systems.

Today, we look at the Smart Client SDK.

The "Creator-to-Creator" Reality

Let’s be brutally honest for a moment. Most modern frontend boilerplates give you an illusion of speed. They hand you a chaotic global state and 50 scattered fetch() calls hidden inside useEffects or server actions that blur the lines of responsibility.

When your app is a weekend project, that’s fine. When you’re shipping for enterprise clients, that architecture rots faster than you can patch it. You don’t need more magic; you need discipline.

The Librarian / Menu Storytelling Pattern

Think of your client architecture not as a giant bucket of data, but as a Librarian holding a Menu.

The Menu (Fetch Adapters)

The frontend component is the reader. It doesn't go wandering into the stacks (the API/database) looking for data. It reads from a strict, typed Menu.

We build a single isolated adapter layer.

// The Menu
export const TableCraftSDK = {
  tenant: {
    get: (id: string) => librarianFetch(`/api/tenant/${id}`),
    sync: (payload: TenantPayload) => librarianFetch(`/api/tenant`, { method: 'POST', body: payload })
  }
};

By forcing every request through the Librarian (librarianFetch), you gain a single, impenetrable choke point. This is where you handle auth token injection, 401 retries, and global error catching. No more silent failures in random components.

The Librarian (State Synchronization)

When the Menu order is placed, the Librarian handles the synchronization.

Instead of optimistic UI updates that lie to the user when a database transaction inevitably fails, the Librarian maintains a clean local cache (a ledger). It only updates the view when the backend confirms the truth.

class LibrarianStore {
  private ledger = new Map<string, any>();

  // Sync the truth, not the assumption.
  public commit(key: string, data: any) {
    this.ledger.set(key, data);
    this.notifySubscribers(key);
  }
}

Why We Build This Way

This architecture isn't about saving keystrokes. It's about building a moat. When you completely decouple your state synchronization and fetch logic from your React/Vite components, you own your application. If you ever need to rip out the backend or change the frontend framework, the Librarian and the Menu remain intact.

That is how you survive enterprise security reviews and scale without tearing your hair out.

Stay tuned for the next part of the TableCraft series. Keep shipping clean architecture.

How I Reverse-Engineered Cursor IDE to Run on GitHub Copilot (A Proxy Architecture Deep Dive)

Jackson Kasi — Fri, 03 Apr 2026 17:52:21 +0000

I love Cursor IDE. It is arguably the most advanced AI code editor on the market today.

But I hate closed ecosystems. And I absolutely refuse to pay for two AI subscriptions when one should do the job.

I already have a GitHub Copilot license. I wanted Cursor’s UI (the Composer, the terminal execution, the MCP tools) to be powered by the Copilot backend I already pay for.

But Cursor is a walled garden. If you try to use their "Agent" features with your own API keys, it actively blocks you. It hardcodes its internal router to force models like claude-3.5-sonnet through their proprietary billing backend.

So, I decided to build a local Man-in-the-Middle (MITM) proxy. I wanted to trick the smartest IDE in the world into thinking it was talking to its own servers, while secretly tunneling everything to GitHub.

Here is the deep technical breakdown of how I reverse-engineered the handshake, bypassed the router, and mutated the Abstract Syntax Trees (AST) in real-time to make it happen.

🏗️ The Architecture of a Heist

To pull this off, I needed two local services running in tandem:

Port 4141 (The Auth Layer): An open-source connector that handles the OAuth handshake with GitHub and exposes an OpenAI-compatible endpoint.
Port 4142 (The Intelligence Proxy): A Bun-powered proxy router that intercepts Cursor's outbound HTTP traffic, manipulates the payloads, and forwards them to Port 4141.

The flow looks like this:
Cursor UI ➡️ Proxy Router (4142) ➡️ Copilot Bridge (4141) ➡️ GitHub Servers

Building a proxy is easy. Bypassing Cursor's internal logic was the hard part. Here are the two massive roadblocks I had to solve.

🕳️ Hack 1: Bypassing the Router (The `cus-` Loophole)

Cursor is smart. If you go into Settings and define a custom model called claude-3.5-sonnet pointing to localhost:4142, Cursor ignores your URL. It sees the word "claude", assumes it belongs to them, and routes the network request to api2.cursor.sh.

You cannot overwrite their internal routing table.

The Solution: I needed a loophole. Cursor only hijacks known model names. If it doesn't recognize the model, it gracefully falls back to your custom API endpoint.

So, I prepended a custom tag: cus-.

In Cursor, I configured the model as cus-claude-3.5-sonnet. Cursor looks at this, says "I have no idea what this is, must be a local LLM," and allows the payload to escape the IDE and hit my proxy on localhost:4142.

Inside my Bun proxy, I intercept the request body and silently strip the prefix before forwarding it to GitHub:

// proxy-router.ts
let json = await req.json();
const PREFIX = "cus-";

// The Heist: Strip the prefix so Copilot gets the real model name
if (json.model && json.model.startsWith(PREFIX)) {
  const targetModel = json.model.slice(PREFIX.length);
  console.log(`🔄 Rewriting model: ${json.model} -> ${targetModel}`);
  json.model = targetModel; 
}

Handshake bypassed. ✅

🧬 Hack 2: The AST Schema Mutation (The Final Boss)

Routing the request was only 10% of the battle. Getting the Agent to actually write code was a nightmare.

When you use Cursor's Composer or Agent features, the IDE sends massive arrays of Tool Calling instructions (File Editors, Linter commands, Terminal executors).

Because Cursor partners heavily with Anthropic, their frontend is hardcoded to send Anthropic-flavored tool schemas (using the input_schema key).

But GitHub Copilot's API expects strict OpenAI-flavored function calls (using the parameters key wrapped inside a function object).

If you just forward Cursor's request to Copilot, Copilot’s backend immediately throws a 400 Bad Request: Invalid Schema.

Worse, Cursor injects illegal JSON schema properties deep inside the tool definitions—things like additionalProperties: false, title, and $schema. Copilot’s strict parser rejects all of these.

The Solution: Real-Time AST Cleansing

I couldn't just use JSON.stringify.replace(). The payload is too complex.

I had to write a recursive AST cleaner inside the proxy. This function intercepts the HTTP stream in milliseconds, walks the entire JSON tree, and mutates it on the fly:

// --- HELPER: Recursively clean illegal properties from the AST ---
const cleanSchema = (schema: any) => {
    if (!schema || typeof schema !== 'object') return schema;

    // Copilot's OpenAI parser hates these. Nuke them.
    if (schema.additionalProperties !== undefined) delete schema.additionalProperties;
    if (schema.$schema !== undefined) delete schema.$schema;
    if (schema.title !== undefined) delete schema.title;

    // Recurse into nested object properties
    if (schema.properties) {
        for (const key in schema.properties) {
            cleanSchema(schema.properties[key]);
        }
    }
    // Recurse into arrays
    if (schema.items) cleanSchema(schema.items);

    return schema;
};

Once we have a weapon to clean the AST, we intercept Cursor's tools array, dynamically translate the Anthropic shapes into strict OpenAI formats, and run the cleaner over every single tool:

// --- TRANSFORM TOOLS (Anthropic -> OpenAI) ---
if (json.tools && Array.isArray(json.tools)) {
    json.tools = json.tools.map((tool: any) => {
        // Cursor uses input_schema. OpenAI wants parameters.
        let parameters = tool.input_schema || tool.parameters || {};

        // Mutate the AST to remove illegal tokens
        parameters = cleanSchema(parameters);

        // Reconstruct the tool in strict OpenAI format
        return {
            type: "function",
            function: {
                name: tool.name,
                description: tool.desc || tool.description,
                parameters: parameters
            }
        };
    });
}

🤯 The Result: Absolute Freedom

When I spun up the proxy and asked Cursor's Agent to build a React component... it worked.

Cursor’s frontend thinks it’s talking to its proprietary Anthropic backend.
GitHub Copilot thinks it’s serving a standard VS Code extension via OpenAI spec.
I sit in the middle, seamlessly translating their protocols in real-time.

Suddenly, Cursor's "Agent Mode", Terminal Execution, and MCP Tools started working perfectly... powered entirely by my existing Copilot license. Zero duplicate subscriptions. Total freedom.

I open-sourced the entire proxy router so you can run it yourself.

👉 Study the Source Code on GitHub (jacksonkasi1/copilot-for-cursor)

📚 Deeper Exploration

If you are fascinated by this kind of reverse engineering and API mutation, here are the foundational concepts you should explore next:

Man-in-the-Middle (MITM) Proxies: To figure out what Cursor was sending in the first place, I had to intercept the traffic. Tools like mitmproxy or Burp Suite are essential for inspecting encrypted HTTPS traffic and dealing with SSL Certificate Pinning. Read more on reverse engineering private APIs with MITM proxies.
LLM Tool Calling Schemas: The AI industry is heavily fragmented. Understanding the exact schema differences between Anthropic's Tool Use (input_schema) and OpenAI's Function Calling (parameters) is critical if you want to build cross-platform AI tools.
AST (Abstract Syntax Tree) Traversal: The recursive cleanSchema function is a basic form of AST traversal. If you want to write compilers, linters, or advanced proxies, mastering Depth-First Search (DFS) on JSON trees is a mandatory skill.

Have you ever had to build a Man-in-the-Middle proxy to bypass a vendor lock-in? Let's talk about reverse-engineering in the comments.

Stop Writing Frontend Types: Building a Backend-Driven Metadata Protocol

Jackson Kasi — Fri, 03 Apr 2026 17:22:37 +0000

(This is Part 5 of my series on building scalable infrastructure. Catch up on Part 1: Bridging Drizzle & TanStack, Part 2: The Engine-Adapter Pattern, Part 3: Dynamic Query Compilers, and Part 4: Cross-Relational Search).

📖 The Chef, The Waiter, and The Menu

Imagine running a restaurant. The Chef (your Backend) invents a brand new dish.

If your restaurant operates like most tech stacks, the Chef just throws the food out the window. The Waiter (your Frontend) has to catch the food, inspect it, guess what the ingredients are, and write down a manual description for the customer. If the Chef changes the recipe tomorrow, the Waiter serves the wrong description and the customer gets angry.

The Smart Way: The Chef prints a Menu (Metadata). When the dish changes, the Menu changes automatically. The Waiter just reads the Menu.

🛑 The Problem: The Type-Sync Hell

If you are a full-stack developer, you know the pain of adding a single column to a database table.

You add status to your Postgres database.
You update your Drizzle ORM schema.
You update your Zod validation schema.
You update your backend API response type.
You switch to the frontend repository.
You update the TypeScript interface for the API fetcher.
You update the TanStack Table columns definition array so the table actually renders the new column.

You are acting as a human translator between your backend and your frontend. This is exactly how engineering teams slow down and bugs slip into production.

When I built TableCraft, I wanted to eliminate steps 3 through 7 entirely.

If I define a table on the backend, the frontend should just know how to render it. I needed a Backend-Driven Metadata Protocol.

Here is how you build a system where your frontend automatically writes its own code based on your backend database.

🧠 The Core Concept: Schema Reflection

In traditional REST APIs, the server only returns data.
In a Metadata Protocol, the server returns data AND the shape of the data.

When we define a table in TableCraft, we pass it the Drizzle schema object. Drizzle objects contain hidden metadata about the SQL types (e.g., is this a varchar, a boolean, or a timestamp?).

We can extract this metadata and serve it via a dedicated /meta endpoint.

1. The Metadata Builder

Instead of just parsing queries, our engine needs to inspect the database schema and build a JSON representation of what is allowed.

import { getTableColumns } from "drizzle-orm";

export function buildTableMetadata(tableDefinition: any) {
  const columns = getTableColumns(tableDefinition.schema);
  const metadata = {
    columns: {},
    searchableFields: tableDefinition.allowedSearchFields,
    sortableFields: tableDefinition.allowedSortFields,
  };

  for (const [key, col] of Object.entries(columns)) {
    // If we hid the column (like 'password'), skip it!
    if (tableDefinition.hiddenColumns.includes(key)) continue;

    metadata.columns[key] = {
      type: col.dataType, // 'string', 'number', 'boolean'
      nullable: col.notNull === false,
      primaryKey: col.primary,
    };
  }

  return metadata;
}

Now, every TableCraft endpoint automatically exposes a GET /api/engine/users/meta route. It returns a pure JSON schema of what the frontend is allowed to do.

🏗️ The Codegen CLI: Writing Code with Code

Serving JSON is great, but we want strict TypeScript types on our frontend. We don't want to parse JSON at runtime; we want intellisense in VS Code.

To solve this, we build a Codegen CLI.

The CLI fetches the /meta endpoint from your local development server, reads the JSON, and writes a .ts file directly into your frontend codebase.

// packages/codegen/src/generator.ts
import fs from "fs";

export async function generateFrontendTypes(apiUrl: string, outputDir: string) {
  // 1. Fetch the metadata from the backend
  const response = await fetch(`${apiUrl}/meta`);
  const meta = await response.json();

  // 2. Start generating the TypeScript string
  let tsCode = `// ⚠️ AUTO-GENERATED BY TABLECRAFT. DO NOT EDIT.\n\n`;

  tsCode += `export interface UsersRow {\n`;

  for (const [colName, colMeta] of Object.entries(meta.columns)) {
    const tsType = mapSqlTypeToTypeScript(colMeta.type);
    const optionalMarker = colMeta.nullable ? "?" : "";

    tsCode += `  ${colName}${optionalMarker}: ${tsType};\n`;
  }

  tsCode += `}\n`;

  // 3. Write it to the React frontend directory!
  fs.writeFileSync(`${outputDir}/tablecraft-types.ts`, tsCode);
}

Now, instead of manually typing interface User { ... }, the developer just runs bun run tablecraft generate.

The backend dictates the types. The frontend obeys.

🚀 Zero-Config UI (The Holy Grail)

Because the frontend now has access to this metadata, the React client doesn't need you to manually define TanStack Table columns.

The @tablecraft/table React package reads the generated metadata and constructs the UI dynamically:

import { DataTable, createTableCraftAdapter } from "@tablecraft/table";

// The adapter reads the generated metadata internally!
const adapter = createTableCraftAdapter({
  baseUrl: "/api/engine",
  table: "users",
});

// You do not pass columns. You do not pass types. 
// It renders the table, the filter dropdowns, and the search box automatically.
export function UsersPage() {
  return <DataTable adapter={adapter} />;
}

If you add an is_active boolean column to your Postgres database, you just restart your server. The metadata updates, the codegen CLI pulls the new types, and your React table instantly displays an is_active column with a True/False filter toggle.

Zero manual frontend work.

🛑 The Shift to Backend-Driven UI

If you are a creator building full-stack tools, you need to think about Reflection.

Your backend is the source of truth. Stop making your users manually duplicate that truth on the frontend. Expose the metadata, build a codegen tool, and let the machines write the boilerplate.

If you want to see exactly how the Codegen CLI generates TanStack Table definitions and Zod schemas on the fly, dig into the open-source codebase here:

👉 Study the Metadata Codegen Protocol in TableCraft (GitHub) (jacksonkasi1/TableCraft)

🔄 What's Next in the Series?

We now have a dynamic backend compiler and an auto-generated frontend. But how do they talk to each other safely?

When a user clicks "Sort by Date", how does the React state seamlessly convert into the ?sort=-date URL parameter without creating messy useEffect loops in your components?

In Part 6, we will dive into The Smart Client SDK—how to build framework-agnostic fetch adapters that handle state synchronization, debouncing, and secure input serialization.

Hit the Follow button so you don't miss it.

Question for the full-stack devs: Are you currently using a Codegen tool (like GraphQL Codegen, tRPC, or OpenAPI), or are you still hand-typing your frontend interfaces? Let's discuss in the comments.

Building a Cross-Relational Search Engine in Drizzle ORM (No Hardcoded WHERE Clauses)

Jackson Kasi — Fri, 03 Apr 2026 17:16:28 +0000

(This is Part 4 of my series on building scalable infrastructure. If you missed them, check out Part 1: Bridging Drizzle & TanStack, Part 2: The Engine-Adapter Pattern, and Part 3: The Dynamic Query Compiler).

📖 The Librarian, The Boxes, and The Database

Imagine you walk into a massive library. You ask the librarian: "Can you give me a list of authors who have written a book with the word 'Magic' in the title?"

Approach A (The Bad Way):
The librarian walks into the back room, finds every single author who wrote a book with 'Magic', packs up every single book that author has ever written, and drops 50 heavy boxes on your desk. You now have to manually dig through the boxes, throwing away duplicates, just to write down the author's name.

Approach B (The Smart Way):
The librarian walks into the aisle, glances at the shelves, sees at least one 'Magic' book for an author, writes the author's name on a clean sheet of paper, and hands you a single piece of paper.

🛑 The Problem: We Are Dropping Boxes on Desks

If you have ever built an admin dashboard, you know the nightmare of the "Global Search Box".

The PM asks for a single input field that searches a user's name, their email, and the titles of their posts.

If you are writing raw Drizzle ORM or SQL, your query usually mutates into a terrifying monster of LEFT JOINs and OR clauses:

// ❌ The "Approach A" Nightmare (Dropping Boxes)
const query = "magic";
db.select().from(users)
  .leftJoin(posts, eq(users.id, posts.userId))
  .where(
    or(
      ilike(users.name, `%${query}%`),
      ilike(posts.title, `%${query}%`)
    )
  )

This code is fundamentally broken.
The LEFT JOIN is "Approach A". It duplicates the user row for every single post they have written. If a user has 1,000 posts, your database sends 1,000 identical user records over the network. You then have to write complex GROUP BY logic in your code just to get a clean list of users.

When I built the engine for TableCraft, I needed to solve this permanently. I needed Approach B. I needed a Cross-Relational Search Engine that generates dynamic SQL vectors using EXISTS instead of LEFT JOIN.

Here is the exact architectural pattern to build it.

🧠 The Core Concept: The SQL Vector Array

Instead of writing a massive where(or(...)) block, we treat conditions as Vectors (an array of SQL AST nodes).

We dynamically build this array based on a configuration object, and then use the spread operator to evaluate it.

In TableCraft, the developer defines the search boundaries at the schema level:

// Define exactly what the global search box is allowed to hit
const usersTable = defineTable(schema.users)
  .search(
    "name", 
    "email", 
    "posts.title" // Nested relation!
  );

When a request comes in (?search=magic), the engine needs to compile "posts.title" into a valid SQL subquery.

🏗️ Algorithm: The Cross-Relational Subquery Builder

To avoid the LEFT JOIN duplication problem, we do not join the tables at the root level. Instead, we use SQL EXISTS subqueries (The Librarian's "glance at the shelf" approach).

If the search target is posts.title, the compiler generates this SQL under the hood:
EXISTS (SELECT 1 FROM posts WHERE posts.user_id = users.id AND posts.title ILIKE '%magic%')

Here is the simplified algorithm to compile this dynamically in Drizzle:

1. The Search Dispatcher

We iterate over the allowed search fields. If it's a local column (name), we build a simple ilike. If it has a dot (posts.title), we hand it off to the Subquery Compiler.

import { ilike, or, SQL } from "drizzle-orm";

function buildGlobalSearch(
  table: AnyPgTable, 
  searchFields: string[], 
  query: string
): SQL | undefined {
  const conditions: SQL[] = [];
  const searchTerm = `%${query}%`;

  for (const field of searchFields) {
    if (field.includes(".")) {
      // It's a relational search! Hand off to the compiler.
      conditions.push(buildExistsSubquery(table, field, searchTerm));
    } else {
      // It's a local search.
      const dbColumn = getColumnMap(table).get(field);
      if (dbColumn) conditions.push(ilike(dbColumn, searchTerm));
    }
  }

  return conditions.length > 0 ? or(...conditions) : undefined;
}

2. The Exists Subquery Compiler

This is the magic. We use the Drizzle getTableRelations introspection to find the foreign keys, then we generate the EXISTS clause dynamically.

import { sql } from "drizzle-orm";

function buildExistsSubquery(
  rootTable: AnyPgTable, 
  relationPath: string, 
  searchTerm: string
): SQL {
  const [relationName, columnName] = relationPath.split(".");

  // Introspect schema metadata
  const relations = getTableRelations(rootTable);
  const relationDef = relations[relationName];

  // Get the target table (e.g., 'posts')
  const targetTable = schema[relationDef.referencedTableName];
  const targetColumn = getColumnMap(targetTable).get(columnName);

  // Get the foreign key columns mapping
  const sourceFk = rootTable[relationDef.fields[0]];
  const targetFk = targetTable[relationDef.references[0]];

  // Compile the SQL EXISTS AST dynamically!
  return sql`EXISTS (
    SELECT 1 FROM ${targetTable} 
    WHERE ${targetFk} = ${sourceFk} 
    AND ${targetColumn} ILIKE ${searchTerm}
  )`;
}

🚀 The Power of the Dynamic Engine

Because we abstracted the search logic into a compiler, look at what happens to our API endpoint:

// 1. Parse the URL
const searchQuery = req.query.search; // "magic"

// 2. Compile the Dynamic SQL Vectors
const searchAST = buildGlobalSearch(schema.users, ["name", "email", "posts.title"], searchQuery);

// 3. Execute
const results = await db.select().from(schema.users).where(searchAST);

Zero hardcoded joins. Zero duplicated rows.

If the product manager says, "Hey, can we also search by the user's company name?", you don't touch the backend API. You don't write another LEFT JOIN. You just update the definition array:

.search("name", "email", "posts.title", "company.name")

The engine resolves the relation, builds the subquery, and executes perfectly.

🛑 Stop Hardcoding Your Backends

If you are building SaaS platforms, internal tools, or SDKs, this is the architecture you need to adopt.

Writing one-off SQL queries for every dashboard table is a massive waste of human capital. Build the engine once, and let it compile your logic for you.

If you want to see how this EXISTS subquery algorithm is recursively implemented for infinitely deep relations (e.g., posts.comments.author.name), I open-sourced the entire engine core:

👉 Study the Search Compiler Architecture in TableCraft (GitHub) (jacksonkasi1/TableCraft)

🔄 What's Next in the Series?

We have successfully built the backend engine: It parses URLs, compiles dynamic relational filters, handles cursor pagination, and executes cross-relational global searches.

But a backend API is useless without a frontend.

How do you make the React frontend (TanStack Table) automatically know what columns exist, what filters are allowed, and how to render the UI without writing duplicate TypeScript interfaces?

In Part 5, we will dive into The Metadata Builder Protocol—how to generate a semantic JSON schema from the Drizzle backend so your frontend builds itself.

Hit the Follow button to catch the next masterclass.

Question for the builders: Do you prefer EXISTS subqueries or LEFT JOIN + GROUP BY when handling 1-to-many searches? Let's argue about query planners in the comments.

The Algorithm That Killed 10,000 Lines of API Boilerplate (Building a Dynamic Query Compiler)

Jackson Kasi — Fri, 03 Apr 2026 17:14:39 +0000

(This is Part 3 of my series on building scalable infrastructure. If you missed them, check out Part 1: Bridging Drizzle & TanStack and Part 2: The Engine-Adapter Pattern).

Most backend engineers spend their entire careers writing "Switchboard APIs". You know the type: an endpoint that receives ?include=posts, checks an if statement, and manually adds a SQL JOIN.

It is tedious, it is brittle, and frankly, it is boring.

If you are a tool creator, you shouldn't be writing switchboards. You should be writing compilers.

When I built the engine for TableCraft, I didn't want to write endpoints. I wanted to build an HTTP-to-SQL compiler that could dynamically resolve infinitely nested database relations and construct complex B-Tree optimized cursor paginations on the fly.

Here are the exact algorithms and architectural patterns I used to do it. If you build infrastructure, SDKs, or internal developer platforms, read this carefully.

🧠 Algorithm 1: Recursive Relation Graph Traversal (The AST Compiler)

The hardest problem in dynamic APIs is nested relational filtering.

Imagine a URL query like this:
?filter[posts.author.company.name][eq]=Acme

To execute this safely in Drizzle ORM, you have to traverse from the Users table, to Posts, to Authors, to Companies.

You cannot hardcode this. You need a Depth-First Search (DFS) algorithm that walks the ORM's relational graph.

Here is the architectural pattern to solve this:

1. The Tokenizer

First, we tokenize the string path posts.author.company.name into an array: ["posts", "author", "company", "name"].

2. The Recursive Resolver

Next, we write a recursive compiler. It takes the token array and checks the Drizzle Schema metadata at every node to ensure the path actually exists.

import { getTableRelations } from "drizzle-orm";

function resolveRelationPath(
  currentTable: AnyPgTable, 
  pathTokens: string[], 
  schema: Record<string, any>
): { targetTable: AnyPgTable, columnName: string } {

  // Base Case: We reached the final token (the column name)
  if (pathTokens.length === 1) {
    return { targetTable: currentTable, columnName: pathTokens[0] };
  }

  // Recursive Step: Extract the next relation
  const [relationName, ...remainingTokens] = pathTokens;

  // Introspect Drizzle's hidden relation metadata
  const tableRelations = getTableRelations(currentTable);
  const relationDef = tableRelations?.[relationName];

  if (!relationDef) {
    throw new Error(`Security Exception: Invalid relation path '${relationName}'`);
  }

  // Find the next table in the schema dictionary
  const nextTable = schema[relationDef.referencedTableName];

  // Recurse deeper into the graph
  return resolveRelationPath(nextTable, remainingTokens, schema);
}

The "Wow" Factor: This algorithm makes your API infinitely scalable. Whether the user joins 1 table or 10 tables, the compiler resolves the abstract syntax tree safely. If a hacker tries ?filter[posts.passwords.hash], the graph traversal halts because the relation definition isn't exposed in the safe schema.

🔥 Algorithm 2: Dynamic Keyset Pagination (The Math)

Offset pagination (OFFSET 10000 LIMIT 50) is a database killer. It requires Postgres to scan and discard 10,000 rows.

The enterprise solution is Keyset Pagination (Cursor Pagination). But generating dynamic keyset SQL for multi-column sorting is a mathematical nightmare.

If a user sorts by [-createdAt, id], the SQL requires tuple comparison:
WHERE (created_at, id) < ('2023-10-01', 504)

How do you generate this dynamically from a URL string?

The Vector Comparison Algorithm

In TableCraft, the engine parses the sort array and the cursor object, then builds a vector array for Drizzle.

import { sql } from "drizzle-orm";

function buildDynamicCursor(
  sortFields: { column: AnyColumn, direction: 'asc' | 'desc' }[],
  cursorData: Record<string, any>
) {
  // 1. Extract the column objects and cursor values
  const columns = sortFields.map(f => f.column);
  const values = sortFields.map(f => cursorData[f.column.name]);

  // 2. Generate the Tuple SQL dynamically
  // If direction is 'desc', we use '<', if 'asc', we use '>'
  const operator = sortFields[0].direction === 'desc' ? '<' : '>';

  // 3. Inject raw SQL into the Drizzle AST
  return sql`(
    ${sql.join(columns, sql`, `)}
  ) ${sql.raw(operator)} (
    ${sql.join(values.map(v => sql`${v}`), sql`, `)}
  )`;
}

By abstracting this into the engine, the frontend engineer just passes a base64 encoded cursor string. The backend parses it, feeds it to the Vector Comparison Algorithm, and generates a perfectly optimized B-Tree index scan.

Zero sequential scans. Zero manual SQL.

🛑 The Paradigm Shift for Creators

If you are building an open-source tool, you have to stop thinking about endpoints and start thinking about state machines and compilers.

When you build a recursive AST compiler like the one inside TableCraft, you aren't just writing a library. You are giving developers a primitive engine they can wrap in any framework they want (Hono, Express, Next.js).

This is what separates basic wrappers from god-tier infrastructure.

I open-sourced the entire engine. If you want to see how the recursive relation builder and dynamic pagination vector math is actually wired up to the Drizzle ORM core, dig into the repository:

👉 Deep Dive the Compiler Architecture in TableCraft (GitHub) (jacksonkasi1/TableCraft)

🔄 What's Next in the Series?

We’ve covered the Engine-Adapter pattern and the Compiler Algorithms. But what happens when the user types a global search query and expects instant results across 5 deeply nested, joined tables?

In the next article, I’m going to break down The Cross-Relational Search Engine—how to dynamically build generic full-text search SQL vectors without hardcoding a single WHERE clause.

If you are serious about backend architecture, hit the Follow button so you don't miss it.

To the other infrastructure creators out there: What is the most complex algorithmic challenge you've had to solve in your core engine? Drop it in the comments below, and let's debate the best approaches.

How to Build Framework-Agnostic Open Source Tools (The Engine-Adapter Pattern)

Jackson Kasi — Fri, 03 Apr 2026 17:13:55 +0000

Look at your codebase right now.

If you are building an open-source library, an SDK, or a generic backend tool, and you are importing express, next/server, or hono directly into your core business logic... you are building a trap.

I know, because I fell into it. When you tie your logic to a specific HTTP framework, you alienate 80% of the developer ecosystem. A Next.js dev can't use your Express tool. A Hono dev can't use your Fastify plugin.

If you want to build tools that other developers actually adopt, you have to think like an architect, not just a coder.

You need to master The Engine-Adapter Pattern.

This is exactly how I built TableCraft to seamlessly support Hono, Express, Next.js, and Elysia from a single codebase. Let's break down how you can build this pattern for your next open-source project.

🛑 The Anti-Pattern: Framework Coupling

Most developers start building an API library like this:

// ❌ BAD: Tightly coupled to Express
import { Request, Response } from 'express';

export function myAwesomeLibrary(req: Request, res: Response) {
  const query = req.query.search;
  // ... core logic ...
  return res.json({ success: true, data });
}

The moment you do this, your library is dead to anyone not using Express.

🏗️ The Solution: The Engine-Adapter Architecture

To fix this, you must aggressively separate your Core Engine from the HTTP Layer.

Your architecture should look like this:

The Engine: Pure TypeScript. Zero dependencies on any HTTP framework. It takes standard inputs (strings, objects) and returns standard outputs.
The Adapters: Tiny, 20-line wrappers that translate a specific framework's request into the standard input your Engine expects.

Let's look at how to actually code this.

Step 1: Build the Framework-Agnostic Engine

Your engine should only care about raw data. It doesn't know what a "Request" or "Response" is.

// packages/engine/src/index.ts
// ✅ GOOD: Pure TypeScript. No HTTP context.

export interface EngineContext {
  url: string;
  method: string;
  body?: any;
}

export class CoreEngine {
  async handleRequest(ctx: EngineContext) {
    // 1. Parse the raw URL
    const url = new URL(ctx.url, 'http://localhost');
    const searchParams = url.searchParams;

    // 2. Execute pure business logic
    const result = await myComplexLogic(searchParams);

    // 3. Return a standard response object
    return {
      status: 200,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(result)
    };
  }
}

Step 2: Build the Adapters

Now, we create isolated packages for each framework. These are the "Adapters". Their only job is translation.

The Hono Adapter:

// packages/adapter-hono/src/index.ts
import { Context } from 'hono';
import { CoreEngine } from '@my-org/engine';

export function createHonoAdapter(engine: CoreEngine) {
  return async (c: Context) => {
    // Translate Hono Request -> Engine Context
    const response = await engine.handleRequest({
      url: c.req.url,
      method: c.req.method,
    });

    // Translate Engine Response -> Hono Response
    return c.json(JSON.parse(response.body), response.status);
  };
}

The Express Adapter:

// packages/adapter-express/src/index.ts
import { Request, Response } from 'express';
import { CoreEngine } from '@my-org/engine';

export function createExpressAdapter(engine: CoreEngine) {
  return async (req: Request, res: Response) => {
    // Translate Express Request -> Engine Context
    const response = await engine.handleRequest({
      url: req.originalUrl,
      method: req.method,
    });

    // Translate Engine Response -> Express Response
    res.status(response.status).json(JSON.parse(response.body));
  };
}

🧠 Why This Changes Everything

When you build like this, magic happens:

Infinite Reach: Adding support for a new framework (like SvelteKit or Nuxt) takes 10 minutes. You just write a new 20-line adapter.
God-Tier Testing: You can unit test your CoreEngine perfectly without ever spinning up a mock HTTP server. You just pass it JSON objects.
Monorepo Ready: You can use Turborepo or npm workspaces to publish @my-org/engine, @my-org/adapter-hono, and @my-org/adapter-next as separate packages. Users only install what they need.

🚀 See It In The Wild

This isn't theory. This is exactly the architecture I used to build TableCraft — a headless data table engine for Drizzle ORM.

I wanted TableCraft to work for everyone. So I built @tablecraft/engine as a pure logic core, and exposed it via @tablecraft/adapter-hono, @tablecraft/adapter-express, etc.

If you are a creator, a library author, or just someone who wants to understand how scalable open-source repositories are structured, I highly recommend studying this pattern in a real codebase.

👉 Study the Monorepo Architecture in TableCraft on GitHub (jacksonkasi1/TableCraft)

If you are building an open-source tool right now, what is the hardest architectural decision you are currently facing? Let's talk in the comments.

How to Dynamically Map URL Queries to Type-Safe SQL (Drizzle ORM Architecture)

Jackson Kasi — Fri, 03 Apr 2026 17:13:13 +0000

(This is part of my series on building scalable infrastructure. If you missed it, check out Part 1: Bridging Drizzle & TanStack).

If you use an ORM like Drizzle or Prisma, you eventually run into a wall: How do you safely convert dynamic URL query strings into type-safe SQL queries?

Imagine a user hits this endpoint from a data table on your frontend:

GET /api/users?filter[name][ilike]=%jack%&filter[age][gte]=18&sort=-createdAt

You need to convert that string into this Drizzle ORM execution:

db.select()
  .from(users)
  .where(
    and(
      ilike(users.name, "%jack%"), 
      gte(users.age, 18)
    )
  )
  .orderBy(desc(users.createdAt));

Most developers write a giant, brittle switch statement for every single API endpoint. It's unscalable, error-prone, and a massive security risk if not sanitized properly.

In this post, we are going to look at the Dynamic Query Builder Architecture. This is the exact pattern I used to build the engine behind TableCraft, and you can use it to build your own generic API endpoints.

🧠 The Core Problem: String to AST

You cannot just pass user input into database functions. You need an intermediate layer. The architecture looks like this:

URL Query -> Parser -> Abstract Syntax Tree (AST) -> ORM Builder -> SQL

Let's break down how to actually build this in TypeScript with Drizzle.

Step 1: The Operator Dictionary

The first step is mapping string-based operators from the URL (e.g., ilike, gte, eq) to actual Drizzle functions safely.

Instead of if/else hell, we use an Operator Dictionary.

import { eq, ne, gt, gte, lt, lte, like, ilike, inArray } from "drizzle-orm";

// A secure map of allowed operations
export const operatorMap = {
  eq: (col, val) => eq(col, val),
  ne: (col, val) => ne(col, val),
  gt: (col, val) => gt(col, val),
  gte: (col, val) => gte(col, val),
  lt: (col, val) => lt(col, val),
  lte: (col, val) => lte(col, val),
  like: (col, val) => like(col, val),
  ilike: (col, val) => ilike(col, val),
  in: (col, val) => inArray(col, Array.isArray(val) ? val : [val]),
} as const;

export type AllowedOperator = keyof typeof operatorMap;

If a user passes ?filter[name][DROP TABLE]=..., the engine immediately rejects it because DROP TABLE is not a valid key in operatorMap.

Step 2: Drizzle Schema Introspection

How do we know if users.age is actually a column in the database? We have to extract the metadata from the Drizzle table object dynamically.

Drizzle tables hold their column definitions internally. We can build a utility to extract them:

import { getTableColumns } from "drizzle-orm";
import type { AnyPgTable } from "drizzle-orm/pg-core";

export function getColumnMap(table: AnyPgTable) {
  const columns = getTableColumns(table);
  const map = new Map<string, any>();

  for (const [key, col] of Object.entries(columns)) {
    // We map the string name to the actual Drizzle column object
    map.set(key, col); 
  }

  return map;
}

Now, when the URL asks to filter by age, we check getColumnMap(users).has("age"). If it doesn't exist, we throw a 400 Bad Request. Zero SQL injection risk.

Step 3: The Filter Builder (The Magic)

Now we write the parser. It takes the raw JSON/Query object, validates it against the schema, and builds the Drizzle where array.

import { and, SQL } from "drizzle-orm";

function buildFilters(rawFilters: Record<string, any>, table: AnyPgTable): SQL | undefined {
  const columnMap = getColumnMap(table);
  const conditions: SQL[] = [];

  for (const [columnName, operations] of Object.entries(rawFilters)) {
    const dbColumn = columnMap.get(columnName);

    // Security check: Does the column exist?
    if (!dbColumn) continue; 

    for (const [op, value] of Object.entries(operations)) {
      const dbOp = operatorMap[op as AllowedOperator];

      // Security check: Is the operator allowed?
      if (!dbOp) continue;

      // Construct the Drizzle AST
      conditions.push(dbOp(dbColumn, value));
    }
  }

  return conditions.length > 0 ? and(...conditions) : undefined;
}

Step 4: Connecting it to the ORM

With our buildFilters function, our API endpoint becomes incredibly clean. It doesn't matter if there is 1 filter or 100 filters, the code remains the same.

// Example inside an Express or Hono handler
const filters = parseUrlToFilters(req.url); // Extracts { name: { ilike: '%jack%' } }

const conditions = buildFilters(filters, schema.users);

const results = await db.select()
  .from(schema.users)
  .where(conditions) // Safely inject the dynamic AST
  .limit(50);

🚀 Why This Matters

When you understand this pattern, you stop writing repetitive backend code. You stop writing custom endpoints for every table.

Instead, you write the Engine once, and it automatically handles filtering, sorting, and pagination for every table in your database.

This exact architecture is how I built TableCraft. It abstracts this entire engine so you can generate these dynamic, secure endpoints in one line of code:

const usersTable = defineTable(schema.users).search("email").sort("-createdAt");

If you want to see how deep this rabbit hole goes (handling relational joins recursively, cursor pagination, and input validation), dive into the open-source source code here:

👉 Explore the Architecture in TableCraft on GitHub (jacksonkasi1/TableCraft)

🔄 What's Next in the Series?

Now you know how to map URL queries to safe SQL ASTs. But what if you want to expose this logic across multiple frameworks like Express, Hono, and Next.js without rewriting the core engine?

In the next article, How to Build Framework-Agnostic Open Source Tools, I break down the Engine-Adapter pattern that makes TableCraft universally compatible.

Hit the Follow button so you don't miss the rest of the masterclass.

Stop Hand-Wiring React Tables: How I Bridged Drizzle ORM and TanStack in 5 Minutes

Jackson Kasi — Fri, 03 Apr 2026 17:08:54 +0000

Most startups don't die because of a bad idea. They die because of bad engineering velocity.

If your engineering team is spending days wiring up basic data tables, pagination, and sorting for your internal dashboards, you are bleeding money.

I know, because I audited my own workflow. Every time a PM asked for a new view in our B2B SaaS, it meant:

Setting up a new TanStack Table instance.
Wiring up frontend state for pageIndex, sortBy, and filters.
Writing a backend endpoint to parse ?sort=-createdAt&status=active.
Writing the Drizzle ORM logic to map those URL strings to actual SQL queries.

It was a brittle, soul-crushing translation layer. And it had to be rewritten for every single table.

I decided to kill the translation layer entirely. I built TableCraft.

Here is the deep dive into the architecture, how it handles complex edge cases, and why building "systems" beats building "components."

🛑 The Problem: The Translation Layer Hell

TanStack Table is the gold standard for headless UI. Drizzle ORM is the gold standard for type-safe SQL.

But they don't speak the same language.

When a user filters a column on the client, TanStack spits out an array of filter objects. You have to send that to your backend, validate it, and write a manual Drizzle where: and(eq(...), like(...)) clause.

If you change a column name in your database, your frontend table breaks. If you add a new relation, you have to rewrite the API.

"We were spending an hour wiring up a single table. That is unacceptable for a team trying to find Product-Market Fit."

🏗️ The Architecture: How TableCraft Works

I structured TableCraft as a Turborepo monorepo to separate the core engine from the framework-specific adapters.

The goal was simple: Define the rules on the backend, and let the frontend automatically inherit them.

1. The Engine (`@tablecraft/engine`)

Instead of writing manual API routes, you define the table behavior at the schema level.

import { defineTable } from "@tablecraft/engine";
import * as schema from "./db/schema";

// We define exactly what is allowed. Zero boilerplate.
export const usersConfig = defineTable(schema.users)
  .hide("password") // Never leaks to the client
  .search("email", "name")
  .sort("-createdAt");

2. The Framework Adapters

I built adapters for the most aggressive modern backend frameworks: Hono, Elysia, Express, and Next.js.

The adapter takes your defineTable configs and dynamically generates the REST endpoints. It handles input validation, parses the URL query params, and safely executes the Drizzle query.

import { createHonoApp } from "@tablecraft/adapter-hono";

// This single line generates all the filtering, sorting, and pagination APIs.
const app = createHonoApp({ db, schema, configs: { users: usersConfig } });

3. The React Client (`@tablecraft/table`)

On the frontend, you don't write useReactTable from scratch anymore. The client SDK reads the metadata from the auto-generated API and constructs the table dynamically.

import { DataTable, createTableCraftAdapter } from "@tablecraft/table";

const adapter = createTableCraftAdapter({
  baseUrl: "/api/engine",
  table: "users",
});

// Drop this in. You're done.
export function UsersPage() {
  return <DataTable adapter={adapter} />;
}

🧠 Handling the Complex Stuff

Building a basic table generator is easy. Building one that survives an enterprise production environment is hard. Here is how TableCraft handles the complexity:

Cursor Pagination: Offset pagination gets exponentially slower on large datasets. The engine includes an internal core/cursorPagination builder that automatically switches to cursor-based queries for massive tables.
Deep Relational Filtering: Users don't just filter flat tables. They want to filter Orders by the User.email. The core/relationBuilder recursively maps nested Drizzle relations so the frontend can query across joins effortlessly.
Soft Deletes & Aggregations: Need to hide soft-deleted rows or show SUM/AVG rows at the bottom? Handled out of the box via core/softDelete and core/aggregationBuilder.

🏁 How It Ended: 1 Hour ➡️ 5 Minutes

By bridging the gap between Drizzle and TanStack natively, the time to deploy a fully functional, highly complex data table went from ~1 hour of manual wiring to exactly 5 minutes.

The frontend engineers no longer bother the backend engineers for new filter parameters. It is all inherited automatically.

🔮 What's Next?

The engine currently supports Hono, Next.js, and Express. The next phase is expanding the ecosystem:

SvelteKit & Vue Adapters: Because React shouldn't have all the fun.
AI Schema Optimization: Integrating an agentic layer that reads the slow queries hitting the TableCraft engine and automatically suggests PostgreSQL indexes.

If you are tired of writing the same pagination logic every week, stop building components. Start building systems.

👉 Fork TableCraft on GitHub (jacksonkasi1/TableCraft)

Let me know in the comments how your team currently handles the Drizzle-to-Frontend translation layer!

How ORM Migrations Are Hiding Missing Indexes (And How to Actually See Your Database)

Jackson Kasi — Fri, 03 Apr 2026 17:03:04 +0000

I spent 4 hours last week debugging a slow API endpoint.

The culprit? A missing index on a foreign key that my ORM "helpfully" abstracted away during a schema migration.

When you use modern tools like Prisma or Drizzle, it’s incredibly easy to forget what your database actually looks like. The visual connection between tables is lost in hundreds of lines of TypeScript.

🛑 The Hidden Danger of ORMs

Let's look at a standard relational setup: you have Users and Orders. In your ORM, you define a relation. The ORM generates a migration adding a user_id column to Orders with a foreign key constraint.

What it doesn't always do automatically is add a B-Tree index to user_id.

-- What the ORM generated
ALTER TABLE "orders" ADD CONSTRAINT "fk_user" FOREIGN KEY ("user_id") REFERENCES "users"("id");

-- What you actually needed for performance
CREATE INDEX "idx_orders_user_id" ON "orders"("user_id");

Without that index, every time you query a user's orders, Postgres has to perform a sequential scan on the Orders table. At 1,000 rows, it's fine. At 10,000,000 rows, your API grinds to a halt.

Because developers only look at their schema.ts file, they never visually spot the missing index.

👁️ Stop Guessing. Look at your Database.

I wanted a tool that let me see my PostgreSQL schema and design it visually, without losing the power of raw SQL. When I couldn't find a good one that wasn't locked behind a massive enterprise paywall, I built one.

Meet Tiger SQL 🐯

It’s a lightweight, open-source Postgres visualizer with built-in AI assistance.

✅ Visual ERDs: You paste your schema (or connect your DB), and it maps the relationships instantly.
✅ AI-Assisted Optimization: It analyzes your tables and actively warns you about missing indexes or poorly optimized queries before they hit production.
✅ Zero Bloat: It runs entirely in your browser/local environment.

🚀 Take Control of Your SQL

Don't let your ORM build a black box. You need to understand the underlying relational structure of your application.

Tiger SQL is completely free and open-source. Fork it, run it, and find the missing indexes in your own projects:

👉 Fork Tiger SQL on GitHub (jacksonkasi1)

How do you currently visualize and audit your Postgres schemas in your team? Let me know below.

Why Your React Data Tables Are a Bloated Mess (And How to Automate Them)

Jackson Kasi — Thu, 02 Apr 2026 18:25:58 +0000

🛑 Building data tables in B2B SaaS is the most tedious, soul-crushing task in full-stack engineering.

Every time you need a new dashboard view, your engineers do the exact same dance:

👎 1. Write 200 lines of TanStack Table frontend boilerplate.
👎 2. Manage useQuery state for pagination, sorting, and complex filtering.
👎 3. Write a backend API to parse ?column=price&sort=desc&page=2 into something the DB understands.
👎 4. Write Drizzle ORM queries to manually map those query params to SQL conditions.

If your team is doing this manually for every single table in your enterprise app, you are burning money and engineering hours on solved problems.

🔌 The Disconnect Between Client and Server

TanStack Table is a masterpiece. Drizzle ORM is a masterpiece.
But out of the box, they don't communicate.

When a user clicks "Sort by Date" on the frontend, you have to manually map that string to an orderBy: desc(invoices.date) on the backend. Multiply this by 50 tables, 10 columns each, and varying filter types (contains, equals, greater than).

💥 The Result: You end up with a massive, brittle translation layer that breaks every time a schema changes.

🛠️ The Engineering Solution: TableCraft

I got tired of watching teams waste entire sprints building standard CRUD tables. So I built an engine to eliminate the translation layer.

Meet TableCraft.

TableCraft acts as the missing bridge between Drizzle ORM and TanStack Table. Instead of writing the frontend state and the backend query logic separately, TableCraft auto-generates the APIs directly from your Drizzle schema:

✅ Filtering
✅ Sorting
✅ Pagination
✅ End-to-end type safety

You define the schema once. The engine automatically handles the REST API generation (via Hono) and the frontend table rendering (via React).

📈 Why This Matters for Scale

When you are moving fast to find Product-Market Fit (PMF), you cannot afford to spend 5 hours building a user directory table. You need to drop the schema, render the table, and move back to writing core business logic.

Stop building pagination and sorting from scratch. It is junior-level busywork.

🚀 Try it yourself

I open-sourced the engine. If you want to stop wasting your engineering team's time and enforce strict, type-safe table generation, check it out below:

👉 Fork TableCraft on GitHub (jacksonkasi1)

Build systems, not components.

How to Build True Multi-Tenant Database Isolation (Stop using if-statements)

Jackson Kasi — Thu, 02 Apr 2026 18:22:40 +0000

🚨 If you are building a B2B SaaS, your biggest nightmare isn't downtime—it's a cross-tenant data leak.

Most tutorials teach you to handle multi-tenancy like this:

// ❌ The Junior Developer Approach
const data = await db.query.invoices.findMany({
  where: eq(invoices.orgId, req.body.orgId)
});

💥 This is a ticking time bomb.

It relies on the developer remembering to append the orgId check on every single database query. If a developer forgets it on one endpoint, Tenant A just saw Tenant B's invoices.

Here is how you build true multi-tenant isolation that senior engineers actually trust.

🛡️ 1. The Principle of Zero Trust in the Application Layer

Your application logic should not be responsible for tenant isolation. The isolation must happen at the middleware or database level.

When a request comes in, the context of who is asking and which organization they belong to must be established before the route handler is even executed.

⚙️ 2. The Implementation: Hono + Drizzle + Better Auth

In modern architectures, we can leverage middleware to inject the tenant context into the request lifecycle. Here is how we handle it in our stack.

Step 1: Validate and Extract the Tenant
Every request passes through an authentication middleware. If the token is valid, we extract the activeOrganizationId.

// ✅ The Architect Approach (Hono Middleware)
import { createMiddleware } from 'hono/factory';

export const tenantAuthMiddleware = createMiddleware(async (c, next) => {
  // Extract session securely from cookies/headers
  const session = await betterAuth.getSession(c.req);

  if (!session || !session.activeOrganizationId) {
    // Failure Handling: Explicitly reject missing tenant contexts
    return c.json({ error: "Unauthorized: Missing organization context." }, 401);
  }

  // Inject the trusted org ID into the request context
  c.set("orgId", session.activeOrganizationId);
  await next();
});

Step 2: Enforced Database Context
Now, inside your route, you don't rely on the client payload. You rely on the strictly validated context.

app.get("/api/protected/invoices", tenantAuthMiddleware, async (c) => {
  const orgId = c.get("orgId"); // Guaranteed to be valid and authorized

  // The DB query relies on the trusted middleware context, not req.body
  const tenantInvoices = await db
    .select()
    .from(invoices)
    .where(eq(invoices.orgId, orgId));

  return c.json(tenantInvoices);
});

🚦 3. Handling Failure States

What happens if the service-to-service call fails, or the JWT expires mid-flight?

🔴 Token Expired: The middleware catches the expired session and returns a 401 Unauthorized before hitting the database. The frontend is forced to refresh the session.
🔴 Tenant Mismatch: If a user tries to access a resource belonging to Org B but their token resolves to Org A, the middleware throws a 403 Forbidden. The database is never touched.

🐘 4. Going Further: Row-Level Security (RLS)

For absolute paranoia, you push this logic down into PostgreSQL itself using Row-Level Security (RLS).

You set the Postgres session variable app.current_tenant to the orgId upon connection, and Postgres physically blocks any query trying to read rows outside that ID, even if the application developer blindly writes select * from invoices.

🎯 The Takeaway

Stop building SaaS templates that rely on application-level if statements for security.

I got tired of auditing codebases with these vulnerabilities, so I built an open-source monorepo that enforces these boundaries by default. It separates the Vite frontend from the Hono API, uses Drizzle ORM, and strictly isolates tenant data at the middleware level using Better Auth.

👉 If you want to see the full production implementation of this architecture, check out the organization-v2 branch of FlowStack on my GitHub.

Don't let framework magic make you lazy about security boundaries.

I’m sick of $200 SaaS boilerplates that leak tenant data. Here is how to build real isolation.

Jackson Kasi — Thu, 02 Apr 2026 16:57:49 +0000

🤢 I’m sick of "SaaS boilerplates" that charge you $200 just to wrap a framework and leave you to figure out multi-tenant database isolation yourself when your first enterprise customer signs up.

Most templates start clean, but turn into this within a month.

Your if (user.orgId === req.body.orgId) checks are going to leak data eventually. It's just a matter of time. You don't need "magic" hidden in node_modules. You need an explicit, boring, production-grade foundation.

I got tired of rebuilding the same complex isolation architecture, so I built FlowStack.

Today, I’m open-sourcing the organization-v2 branch. No paywalls. No games.

🏗️ Why "Boring" Architecture Wins

When you are building a B2B SaaS, your architecture needs to respect strict boundaries. FlowStack is built as a Turborepo monorepo to enforce this separation physically, not just logically.

📦 apps/server (The API)
🖥️ apps/web (The Client)
🔐 packages/auth (Identity & Isolation)
🗄️ packages/db (Type-safe Postgres Schemas)

If a package doesn't need to know about the database, it doesn't get access to it. Zero Leakage.

⚡ The Engine: Hono + Bun

Cold starts are the enemy of good UX. By running the API on Hono and Bun, the server responds in milliseconds.

Speed isn't a feature; it's a foundation.

🔐 True Multi-Org Isolation (Powered by Better Auth)

Most developers spend weeks building invitation flows, password resets, and role-based access controls (RBAC).

FlowStack integrates Better Auth with custom plugins to handle this natively. Let's look at how we automatically resolve active organizations on login without exposing it to the client:

// Inside packages/auth/src/auth.ts
databaseHooks: {
  session: {
    create: {
      before: async (session) => {
        try {
          // Auto-assign the user's first organization
          const userMemberships = await db
            .select()
            .from(memberTable)
            .where(eq(memberTable.userId, session.userId))
            .limit(1);

          if (userMemberships.length > 0) {
            return {
              data: {
                ...session,
                activeOrganizationId: userMemberships[0].organizationId,
              },
            };
          }
          return { data: session };
        } catch (error) {
          logger.error(`Failed to set active organization: ${error.message}`);
          return { data: session };
        }
      },
    },
  },
}

This ensures the session always knows its boundaries before the first request is even processed.

🎨 The Frontend: React 19 + Vite 7

We didn't compromise on Developer Experience (DX).

✅ React 19 & Vite 7 for immediate HMR.
✅ TanStack Start for flawless routing.
✅ Tailwind CSS v4 for the styling engine.

🚀 Try It Yourself

If you want magic "one-click" illusions that break in production, go buy a template.

If you want a production-ready monorepo that won't make you rewrite your entire auth logic in 6 months, fork FlowStack.

git clone -b organization-v2 https://github.com/jacksonkasi1/FlowStack.git
bun install
bun dev

⭐ Star the repo if this saves you 100+ hours of architectural headaches!
👉 GitHub: FlowStack/organization-v2

Let me know in the comments how you handle tenant isolation in your current stack!

Forem: Jackson Kasi

Part 6: The Smart Client SDK (State Synchronization & Fetch Adapters)

Part 6: The Smart Client SDK (State Synchronization & Fetch Adapters)

The "Creator-to-Creator" Reality

The Librarian / Menu Storytelling Pattern

The Menu (Fetch Adapters)

The Librarian (State Synchronization)

Why We Build This Way

How I Reverse-Engineered Cursor IDE to Run on GitHub Copilot (A Proxy Architecture Deep Dive)

🏗️ The Architecture of a Heist

🕳️ Hack 1: Bypassing the Router (The cus- Loophole)

🧬 Hack 2: The AST Schema Mutation (The Final Boss)

The Solution: Real-Time AST Cleansing

🤯 The Result: Absolute Freedom

📚 Deeper Exploration

Stop Writing Frontend Types: Building a Backend-Driven Metadata Protocol

📖 The Chef, The Waiter, and The Menu

🛑 The Problem: The Type-Sync Hell

🧠 The Core Concept: Schema Reflection

1. The Metadata Builder

🏗️ The Codegen CLI: Writing Code with Code

🚀 Zero-Config UI (The Holy Grail)

🛑 The Shift to Backend-Driven UI

🔄 What's Next in the Series?

Building a Cross-Relational Search Engine in Drizzle ORM (No Hardcoded WHERE Clauses)

📖 The Librarian, The Boxes, and The Database

🛑 The Problem: We Are Dropping Boxes on Desks

🧠 The Core Concept: The SQL Vector Array

🏗️ Algorithm: The Cross-Relational Subquery Builder

1. The Search Dispatcher

2. The Exists Subquery Compiler

🚀 The Power of the Dynamic Engine

🛑 Stop Hardcoding Your Backends

🔄 What's Next in the Series?

The Algorithm That Killed 10,000 Lines of API Boilerplate (Building a Dynamic Query Compiler)

🧠 Algorithm 1: Recursive Relation Graph Traversal (The AST Compiler)

1. The Tokenizer

2. The Recursive Resolver

🔥 Algorithm 2: Dynamic Keyset Pagination (The Math)

The Vector Comparison Algorithm

🛑 The Paradigm Shift for Creators

🔄 What's Next in the Series?

How to Build Framework-Agnostic Open Source Tools (The Engine-Adapter Pattern)

🛑 The Anti-Pattern: Framework Coupling

🏗️ The Solution: The Engine-Adapter Architecture

Step 1: Build the Framework-Agnostic Engine

Step 2: Build the Adapters

🧠 Why This Changes Everything

🚀 See It In The Wild

How to Dynamically Map URL Queries to Type-Safe SQL (Drizzle ORM Architecture)

🧠 The Core Problem: String to AST

Step 1: The Operator Dictionary

Step 2: Drizzle Schema Introspection

Step 3: The Filter Builder (The Magic)

Step 4: Connecting it to the ORM

🚀 Why This Matters

🔄 What's Next in the Series?

Stop Hand-Wiring React Tables: How I Bridged Drizzle ORM and TanStack in 5 Minutes

🛑 The Problem: The Translation Layer Hell

🏗️ The Architecture: How TableCraft Works

1. The Engine (@tablecraft/engine)

2. The Framework Adapters

3. The React Client (@tablecraft/table)

🧠 Handling the Complex Stuff

🏁 How It Ended: 1 Hour ➡️ 5 Minutes

🔮 What's Next?

How ORM Migrations Are Hiding Missing Indexes (And How to Actually See Your Database)

🛑 The Hidden Danger of ORMs

👁️ Stop Guessing. Look at your Database.

🚀 Take Control of Your SQL

Why Your React Data Tables Are a Bloated Mess (And How to Automate Them)

🔌 The Disconnect Between Client and Server

🛠️ The Engineering Solution: TableCraft

📈 Why This Matters for Scale

🚀 Try it yourself

How to Build True Multi-Tenant Database Isolation (Stop using if-statements)

🛡️ 1. The Principle of Zero Trust in the Application Layer

⚙️ 2. The Implementation: Hono + Drizzle + Better Auth

🚦 3. Handling Failure States

🐘 4. Going Further: Row-Level Security (RLS)

🕳️ Hack 1: Bypassing the Router (The `cus-` Loophole)

1. The Engine (`@tablecraft/engine`)

3. The React Client (`@tablecraft/table`)