DEV Community: Malloc72P

Frontend Monorepo Architecture: A Practical Guide with pnpm Workspaces and Turborepo

Malloc72P — Wed, 15 Apr 2026 01:22:26 +0000

Note: This post is a translated version of an article originally published on my personal blog. You can read the original Korean post here.

What is a Monorepo?

A monorepo is an approach where multiple projects are managed within a single repository. This helps maintain code consistency, improves reusability, and simplifies dependency management.

Characteristics of a Monorepo

Consistent codebase: Since all projects live in the same repository, you can enforce consistent code style and conventions across all of them.
Code reusability: Common modules and libraries can be easily shared and reused.
Dependency management: Dependencies between projects are much easier to manage.
Unified build and deployment: You can build and deploy the entire project at once, making operations more efficient.

What if You Don't Use a Monorepo?

The approach where each repository contains exactly one project is called a polyrepo. For simple projects, polyrepo can actually be easier to manage — but as projects grow and become more complex, several pain points emerge:

Code duplication: Common modules tend to get duplicated across multiple repositories.
Dependency conflicts: Different repositories may use different versions of the same library, leading to conflicts.
Inconsistency: Code style and conventions can differ from repo to repo.
Complex builds and deployments: Each repository must be built and deployed individually, making management complicated.

Code duplication can be addressed by publishing shared modules to npm or GitHub Packages, but that introduces additional overhead for versioning and release management.

Also, the larger a polyrepo project grows, the harder it becomes to migrate to a monorepo later. Personally, I prefer adopting a monorepo from the start.

Setting Up a Monorepo with pnpm Workspaces

A monorepo can be set up using the workspace feature provided by package managers like npm, yarn, or pnpm. Package managers help treat each project as an independent package and make it easy to link them together.

What is a Workspace?

A workspace allows you to manage multiple packages — each with their own package.json — within a single repository. This makes it straightforward to connect packages inside a monorepo.

Configuring pnpm Workspaces

Let me walk through setting up a monorepo from scratch using pnpm.

First, create a pnpm-workspace.yaml file to define which packages are part of the workspace:

packages:
  - 'apps/*'
  - 'packages/*'

The packages field specifies path patterns for packages included in the workspace.
It's common to create apps and packages directories:
- apps/ — contains applications that will actually be deployed.
- packages/ — contains shared modules and libraries used across multiple apps.
You're not required to use exactly apps and packages — feel free to structure it however makes sense for your project.

Linking Packages: Step 1 — Configure the Package

Packages within a workspace can depend on each other. For example, let's say apps/blog depends on packages/ui.

First, configure packages/ui/package.json:

// packages/ui/package.json
{
  "name": "@repo/ui",        // Package name
  "private": true,           // Important! Prevents accidental publishing to npm
  "version": "0.0.0",
  "type": "module",
  "main": "./src/entry.ts",  // Entry point
  "types": "./src/entry.ts"  // Type definition file
  // ...
}

The name field sets the package name — it must be unique within the workspace. Adding a scope like @repo makes it clear that this package belongs to the monorepo.
Setting private: true prevents the package from being accidentally published to npm.

Important: You need to explicitly expose the files that other packages will consume.

Configure this just like any npm package — usually via main, types, or exports fields. One interesting detail in this example: we're exposing .ts source files directly. This means the consuming app handles TypeScript compilation rather than the package itself, so there's no need to build each package separately — quite convenient.

If the consuming app can't compile TypeScript from node_modules, you can configure the package to expose compiled .js files instead.

Linking Packages: Step 2 — Add the Dependency

Now let's add @repo/ui as a dependency in apps/blog. Add it to dependencies or devDependencies, then run pnpm install:

// apps/blog/package.json
{
  "name": "blog",
  "version": "1.0.0",
  // ...
  "dependencies": {
    // Use workspace:* to reference local workspace packages
    "@repo/ui": "workspace:*"
  }
}

Key	Description
`@repo/ui`	Name of the monorepo package to add as a dependency
`workspace:*`	Tells the package manager to resolve this from the local workspace

Without workspace:*, the package manager would attempt to find @repo/ui on the npm registry rather than locally.

How the Package Manager Links Packages

So how does pnpm actually connect workspace packages? In the JavaScript ecosystem, installed modules are stored in node_modules, and bundlers resolve imports from there.

Let's see how @repo/ui shows up in apps/blog/node_modules:

You'll find @repo/ui in apps/blog/node_modules, but with a ↳ icon next to it — indicating it's a symbolic link, not a physical copy of the files.

This brings two key benefits:

Disk space savings: The package is linked rather than copied.
Real-time change propagation: Any changes to the package source are immediately reflected without rebuilding.

Using the Package

Now you can import from @repo/ui in apps/blog:

import './style.css';
import { setupCounter } from '@repo/ui';

setupCounter(document.querySelector<HTMLButtonElement>('#counter'));

What you can import is determined by the main, types, and exports fields in packages/ui/package.json. If an import fails, check these two things:

The package is listed in dependencies or devDependencies and pnpm install has been run.
The file you're trying to import is actually exposed in the package's package.json.

The full example is available in the pnpm monorepo example repo.

Turborepo

Turborepo is a monorepo management tool built by Vercel (the team behind Next.js), and it's become one of the most popular tools in this space.

Here's an important detail: Turborepo builds on top of your package manager's workspace feature. So the pnpm workspace setup above stays essentially the same. So why use Turborepo?

Benefits of Turborepo

Benefit	Description
High-performance build system	Uses change-based caching to only rebuild what changed, dramatically speeding up builds.
Caching & parallel execution	Caches build artifacts and runs tasks in parallel to minimize build time.
Unified workflow	Integrates tasks like testing, linting, and deployment into a consistent pipeline.

Think of Turborepo as filling in the gaps that pnpm workspaces leave behind.

Adding Turborepo to Your Monorepo

Starting from the pnpm workspace project, add turbo as a dev dependency at the workspace root:

# --workspace-root installs at the monorepo root level
pnpm add turbo --save-dev --workspace-root

Defining a Build Pipeline with turbo.json

Create a turbo.json file to configure the build pipeline — this defines and orchestrates tasks like builds, tests, and lints:

{
  "$schema": "https://turborepo.dev/schema.json",
  "tasks": {
    "build": {
      // This task depends on the build tasks of upstream packages
      "dependsOn": ["^build"],
      // Input files — if these change, the cache is invalidated
      "inputs": [],
      // Cache these build outputs
      "outputs": ["dist/**", ".next/**", "!.next/cache/**"]
    },
    "lint": {},
    "test": {}
  }
}

Key	Description
`$schema`	Schema for the turbo config file
`tasks`	Defines tasks runnable via the `turbo` CLI
`dependsOn`	Declares task dependencies
`inputs`	Controls cache invalidation
`outputs`	Specifies build artifacts to cache

With "dependsOn": ["^build"], the build task for any package will first run the build tasks of its dependencies. In our project, since apps/blog depends on packages/ui, running build for apps/blog will automatically trigger packages/ui's build first.

Turborepo manages build ordering based on your dependency graph automatically — no manual orchestration needed.

Running Turbo Commands

Run the build pipeline from the project root:

pnpm turbo run build

Turbo will execute each package's build task in the correct order according to the configured pipeline.

If that's too verbose, add a shorthand script to your root package.json:

// package.json
{
  "scripts": {
    "build": "turbo run build"
  }
}

Now you can simply run:

pnpm run build

The full Turborepo example is available in the Turborepo example repo.

Wrapping Up

We've covered the concept of monorepos and how to set one up using pnpm workspaces and Turborepo. As a project scales, a monorepo really shows its value — boosting consistency and operational efficiency across your codebase. I'd encourage you to consider the monorepo approach for your next frontend project.

👉 Read the full post on my blog

How JavaScript Really Executes Code: Execution Context and Scope Chain Explained

Malloc72P — Fri, 10 Apr 2026 00:15:25 +0000

Note: This post is a translated version of an article originally published on my personal blog. You can read the original Korean post here.

Heads up: This post is written based on the ES5 specification. In ES6+, some details changed — such as where ThisBinding lives, and the distinct roles of VariableEnvironment vs LexicalEnvironment. I'll cover the ES6 version in a follow-up post.

Why Should You Care About Execution Context?

If you've been writing JavaScript for a while, you've probably run into these puzzling moments:

The same this keyword points to completely different objects depending on the situation
A variable you never declared somehow doesn't throw an error
You can freely access a variable that's defined outside your current scope

Sure, you can get by without knowing why these things happen. But eventually you hit a wall:

Your code "just works" but you can't explain why
You can't control what this points to
Variables get shared in unintended ways, spawning bugs everywhere

Understanding execution context is the key to breaking through that wall.

What Is an Execution Context?

An execution context is an object that holds all the environmental information needed to execute a piece of code.

JavaScript might look like it runs line by line, but under the hood, the engine first collects and prepares environmental information before executing anything. That prepared environment is the execution context.

When an execution context is activated, it gathers three pieces of information:

VariableEnvironment (VE) — a snapshot of the initial environment
LexicalEnvironment (LE) — the live environment that reflects changes during execution
ThisBinding — what this refers to in the current context

When Are Execution Contexts Created?

Execution contexts are created at two points:

When JavaScript first runs → the Global Execution Context is created
When a function is called → a Function Execution Context is created

The global execution context is born when the script starts and lives until the script ends.
A function execution context is created fresh every time a function is called, and it's discarded once the function finishes.

The Call Stack and Execution Contexts

Execution contexts are managed through the Call Stack.

function second() {
  console.log('second');
}

function first() {
  second();
}

first();

Here's how this plays out step by step:

The global execution context is pushed onto the call stack
first() is called → its execution context is pushed on top
second() is called → its execution context is pushed on top
second finishes → its context is popped off
first finishes → its context is popped off
The global context is removed when the script ends

The context at the top of the stack is the one currently running. When a new function is called, the current context pauses and the new one takes over.

VariableEnvironment vs. LexicalEnvironment

Both environments start out identical when an execution context is created. Over time, they diverge:

LexicalEnvironment — updated in real time as code executes
VariableEnvironment — frozen at the state it was in when the context was first created

LexicalEnvironment

The LexicalEnvironment has two components.

environmentRecord

This is where identifier information for the current execution context is stored — parameter names, function declarations, and variable names all live here.

Before executing any code, the JavaScript engine scans through the scope and builds up this environmentRecord. It collects all the variable names ahead of time.

This is what we call hoisting.

For a deeper look at hoisting, check out my hoisting post.

The global execution context works slightly differently: its environmentRecord is the global object (window in browsers, global in Node.js). This is exactly why variables declared with var at the top level are accessible via window.yourVariable.

outerEnvironmentReference

This is a reference to the LexicalEnvironment of the scope in which the current function was declared.

The word "declared" is key here. It doesn't matter where the function is called — only where it was written. This is what makes JavaScript lexically scoped, and it's also the core principle behind closures.

Thanks to outerEnvironmentReference, when the engine needs to look up a variable, it can start in the current scope and walk outward.

The Scope Chain

How Variables Are Looked Up

When the JavaScript engine needs to resolve a variable, it searches in this order:

Look in the current context's environmentRecord
If not found, follow outerEnvironmentReference to the outer scope
Repeat this process all the way up to the global scope
If still not found → ReferenceError

This chain of scopes — where the engine climbs outward looking for a declaration — is called the scope chain.

Scope Chain in Action

var a = 'global';

function outer() {
  var a = 'outer';

  function inner() {
    // No `a` in inner's scope
    // → follows outerEnvironmentReference to outer's scope
    console.log('inner >>> ', a);
  }

  console.log('outer >>> ', a);
  inner();
}

outer();
console.log('global >>> ', a);

outer >>>  outer
inner >>>  outer
global >>>  global

Even though inner never declares a, it finds outer's a through the scope chain.

Notice the last line: global >>> global. The var a = 'outer' inside outer is a completely separate variable from the global a. outer declared its own a in its own scope, so the global a stays untouched.

Scope Is One-Way: Inside-Out Only

An important property of the scope chain is that it's unidirectional — inner scopes can see outer scopes, but not the other way around.

function outer() {
  var outerVar = 'outer';
}

console.log(outerVar); // ReferenceError: outerVar is not defined

Trying to access outerVar from outside the function throws an error because the global scope has no visibility into outer's internals.

Summary

An execution context is an object holding the environmental info (VE, LE, ThisBinding) needed to run code.
A new execution context is created every time a function is called; it gets pushed onto the call stack and popped off when done.
The environmentRecord in LexicalEnvironment stores identifier info for the current scope.
The outerEnvironmentReference points to the outer environment where the function was declared, not where it was called.
Variable lookup starts in the current scope and walks outward through outerEnvironmentReference — this is the scope chain.

Closing Thoughts

Execution context is the foundation that ties together some of JavaScript's most important behaviors: hoisting, scope, and this binding all connect back to it.

In particular, the scope chain formed through outerEnvironmentReference is also the core mechanism behind closures — which I'll explore in a future post.

Thanks for reading!

👉 Read the full post on my blog

How Can We Stream AI Chat Messages Like ChatGPT?

Malloc72P — Fri, 03 Apr 2026 02:19:13 +0000

Note: This post is a translated version of an article originally published on my personal blog. You can read the original Korean post here.

How Can We Stream AI Chat Messages Like ChatGPT?

Can We Do It With Traditional HTTP?

When using services like ChatGPT, Claude, or Gemini, you'll notice that the AI's response is printed out on the screen bit by bit. How exactly is this implemented?

Fundamentally, web services operate on the HTTP protocol. This protocol works as unidirectional communication: the client sends a request to the server, and the server sends back a single response.

However, what we want is for the server to send AI message tokens down to the client as soon as they are ready. The traditional request-response pair we are familiar with isn't quite cut out for this.

Can We Use WebSockets?

As an alternative, we could use WebSockets, but this isn't a great approach either. Here's why:

Streaming messages doesn't actually require a bidirectional channel. We only need the server to be able to respond in multiple chunks after the client makes a single request.
Since it's not HTTP, we can't leverage existing HTTP features out of the box, such as authentication (cookies, tokens), CORS, caching, and logging.
It makes scaling difficult.

Load balancer configuration is the biggest headache. In a typical web service, a load balancer distributes traffic across multiple servers. But if you use WebSockets, a specific server must maintain a persistent connection with the client. Therefore, you have to keep the connection alive using Sticky Sessions, which makes horizontal scaling difficult because traffic won't be distributed evenly.

The Answer is Server-Sent Events (SSE)

Actually, this problem can be solved with the HTTP protocol. A typical HTTP response sends the entire payload at once, like this:

HTTP/1.1 200 OK
Content-Length: 42
...

Because there is a Content-Length, the browser closes the connection once it receives that amount of data.

On the other hand, an SSE response looks like this:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/event-stream

data: chunk 1

data: chunk 2

...

data: chunk N

Notice that there is no Content-Length, and Transfer-Encoding is set to chunked. In this case, the browser assumes the response is not yet finished, keeps the connection open, and processes the data whenever it arrives.

Just by doing this, we can maintain the standard HTTP protocol while allowing the server to send a response in multiple chunks for a single request. This is how we can stream AI messages.

Simpler than you thought, right?

Well, seeing is believing, so let's implement it ourselves.

Implementing Message Streaming with SSE

In this tutorial, we will create a Next.js app and implement a Route Handler that responds with messages using SSE. First, let's setup the Next.js app.

Next.js App Setup

# Create a next app using boilerplate
pnpm create next-app@16.2.1 sse-exam --yes

# Navigate to the generated project
cd sse-exam

# Run the dev server
pnpm dev

We're all set. Now let's create the Route Handler.

Creating the Route Handler 1: Preparation

Create the app/api/route.ts file and paste the following code:

// Dummy tokens for testing
const tokens = [
  'Never gonna give you up ',
  'Never gonna let you down ',
  'Never gonna run around and desert you ',
  'Never gonna make you cry ',
  'Never gonna say goodbye ',
  'Never gonna tell a lie and hurt you ',
];

/**
 * A function to simulate an external API call by delaying execution.
 * @param ms Delay time in milliseconds
 */
async function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve();
    }, ms);
  });
}

tokens is a list of dummy tokens we'll use for testing. We need some data for the server to respond with!
sleep is used to simulate the latency of calling an external API. In reality, calling the GPT or Anthropic API introduces latency, so we use this to mimic that behavior.

Creating the Route Handler 2: GET Request Handler

Now let's implement the handler for the GET request. Add the following function to the app/api/route.ts file:

export async function GET() {
  // Create a ReadableStream for SSE
  const stream = new ReadableStream({
    async start(controller) {
      const encoder = new TextEncoder();

      // Encode tokens and enqueue them into the controller
      for (const token of tokens) {
        // Format the data according to the SSE standard
        const encodedToken = encoder.encode(`data: ${JSON.stringify({ text: token })}\n\n`);

        await sleep(100);
        controller.enqueue(encodedToken);
      }

      controller.enqueue(encoder.encode('data: [DONE]\n\n'));
      controller.close();
    },
  });

  // Create and return a Response object containing the Stream
  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
    },
  });
}

It might look complicated, but it's actually quite simple. You just create a ReadableStream object, put it inside a Response object, and return it.

Let's dig a little deeper.

Deep Dive into ReadableStream

ReadableStream is an object that reads and transmits data in chunks, rather than sending the entire payload at once.
You can provide an asynchronous start function as an argument to the constructor, where you can write the logic for reading and sending data in chunks.
To read and send a chunk, simply call enqueue on the controller parameter of the start callback.
Once all transmissions are complete, you can call close to end the stream.
A simplified version looks like this:

const stream = new ReadableStream({
  start(controller) {
    // Called once when the stream is created
    controller.enqueue('first chunk'); // Push data
    controller.enqueue('second chunk');
    controller.close(); // Close stream
  },
});

Deep Dive into Response

// Create and return a Response object containing the Stream
return new Response(stream, {
  headers: {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
  },
});

When creating the response object, we define a few attributes in the headers.
As mentioned earlier, we set Content-Type to text/event-stream.
Also, since we passed a ReadableStream as the body of the Response, the transfer-encoding is automatically set to chunked.
The client calling this API will read these attributes from the HTTP response headers and realize, "Ah, the server is sending the message in chunks. I should treat the result as a ReadableStream and read it accordingly."
Cache-Control isn't strictly required, but it's added defensively to prevent unexpected caching in production environments.

Midpoint Summary

That was a long explanation, so let's summarize before moving on.

First, the advantages and characteristics of SSE:

To stream fragmented AI messages down to the client, you should use the SSE approach.
Because SSE operates over the standard HTTP protocol, you can use existing authentication methods (cookies, tokens) as is.
Unlike WebSockets, it remains unidirectional, making horizontal scaling much easier.

How to implement SSE on the server:

Create a ReadableStream object and place it in the body of a Response object to send it back.
Set the Content-Type header to text/event-stream. By placing a stream object in the body, the transfer-encoding automatically becomes chunked.

Client-Side Implementation

Now let's see how the client calls the API that sends messages via SSE.

First, open app/page.tsx and modify it as follows:

'use client';

import { useState } from 'react';

export default function Home() {
  const [message, setMessage] = useState<string>('');

  const onClick = async () => {
    // Write the API call logic here!
  };

  return (
    <div className="w-160 h-175 bg-gray-50 border border-gray-300 shadow-md rounded-md mx-auto mt-10 overflow-hidden">
      <div className="flex justify-between items-center bg-gray-100 p-5 border-b border-b-gray-300">
        <h1 className="font-bold text-xl">SSE Exam</h1>
        <button
          className="px-4 py-2 bg-blue-700 rounded-md text-white font-bold hover:brightness-105 cursor-pointer"
          onClick={onClick}
        >
          Request AI
        </button>
      </div>

      <div className="p-5 overflow-auto">
        {message.length === 0 && <p className="text-gray-500 text-2xl">no data!</p>}
        {message.length > 0 && message}
      </div>
    </div>
  );
}

This is a simple UI that displays the message sent from the server via SSE when the Request AI button is clicked.
Now let's implement onClick. Write it like this:

const onClick = async () => {
  const response = await fetch('/api', { method: 'GET' });
  const reader = response.body?.getReader();

  if (!reader) {
    throw new Error('Invalid response. Failed to get reader.');
  }

  const decoder = new TextDecoder();

  while (true) {
    const { done, value } = await reader.read();

    if (done) break;

    const lines = decoder.decode(value).split('\n\n');

    for (const line of lines) {
      if (!line.startsWith('data: ') || line === 'data: [DONE]') continue;

      const { text } = JSON.parse(line.slice(6));
      setMessage((prev) => prev + text);
    }
  }
};

Since the server sent a ReadableStream in the body, the client must also read it as a ReadableStream.

You can easily extract the stream reader object by calling response.body.getReader().

We run a loop reading messages until there's no more data left (done).
At this point, you might worry that entering a while(true) loop will block the UI thread, but it's perfectly fine.
If you look closely, there is an await on reader.read(). Because this method is asynchronous, the event loop will process other tasks until the server sends a chunk.
Therefore, this code will not block the UI.

Checking Network Requests in DevTools

Now, when you press the Request AI button, you'll see the message being printed out piece by piece on the screen.
To see how the transmission actually happens, let's open the Network tab in DevTools.

First, here are the response message headers:

Header	Value
cache-control	no-cache
content-type	text/event-stream
transfer-encoding	chunked

As configured earlier, you can see that the content type and transfer encoding are set correctly.

Next, here is the list of messages actually received in the EventStream tab:

Type	Data	Time
message	`{"text":"Never gonna give you up "}`	11:04:21.967
message	`{"text":"Never gonna let you down "}`	11:04:22.179
message	`{"text":"Never gonna run around and desert you "}`	11:04:22.280
message	`{"text":"Never gonna make you cry "}`	11:04:22.380
message	`{"text":"Never gonna say goodbye "}`	11:04:22.482
message	`{"text":"Never gonna tell a lie and hurt you "}`	11:04:22.583

The EventStream tab is specific to SSE transmissions, showing exactly which messages were sent in chronological order.
It's truly fascinating that you can respond in chunks as soon as the data is ready using simple HTTP configurations and ReadableStream, without any complex WebSocket setup.

Honestly, before researching how this feature was implemented, I naturally assumed it used WebSockets. Finding out that it can be done over HTTP was a pleasant surprise.
Even outside of AI chatbots, HTTP chunked transfer—which underpins SSE—can be used when transmitting large files bit by bit. I read that combining this with the MediaSource API allows browsers to receive and play video or audio chunks seamlessly.

Conclusion

In this post, we explored how to leverage HTTP specifications to stream AI messages to the client, much like ChatGPT or Claude.
Before looking into it, I thought it would be difficult, assuming WebSockets were mandatory. However, I was surprised by how easy and intuitive it turned out to be.
I definitely want to use this approach when building my next AI-powered project.

Check out the complete source code for this tutorial in the sse-exam repository.

Thanks for reading this post!

Building a Full-Stack Data Grid App with Next.js, Prisma, and AG Grid

Malloc72P — Thu, 26 Mar 2026 06:56:18 +0000

TL;DR

Build a complete CRUD data grid app using Next.js (Server Components + Server Actions), Prisma ORM (type-safe DB access), and AG Grid (inline editing, sorting, virtual scroll).
Server Components fetch data on the server; Server Actions let clients call server-side functions like regular async functions — no REST API needed.
Prisma provides auto-generated TypeScript types from your schema, making DB queries fully type-safe.
AG Grid's applyTransaction API enables optimistic updates — the UI updates instantly, and rolls back on failure.

Key Concepts

Next.js: Server Components & Server Actions

Server Components run on the server and can call business logic directly:

// app/page.tsx — Server Component
export default async function Home() {
  const orders = await getOrders(); // Direct DB call
  return <OrderGrid orders={orders} />;
}

Server Actions let client components call server functions with a simple 'use server' directive:

'use server';

export async function createOrderAction(input: CreateOrderInput) {
  return createOrder(input);
}

The client calls it like a normal function — Next.js handles the HTTP layer internally.

Prisma ORM: Type-Safe Database Access

Define your schema in Prisma's DSL, then generate a fully typed client:

model Order {
  id    Int @id @default(autoincrement())
  price Int
  qty   Int
}

CRUD operations are concise and type-safe:

// Create
await prisma.order.create({ data: { price, qty } });

// Read with filters
await prisma.order.findMany({
  where: { price: { gt: 1000 } },
  skip: 20,
  take: 20,
});

// Update
await prisma.order.update({ where: { id }, data: { price, qty } });

// Delete
await prisma.order.delete({ where: { id } });

AG Grid: Optimistic Updates with applyTransaction

The optimistic update pattern — update the UI first, then sync with the server:

async function handleCreate() {
  const tempId = -Date.now();
  const tempRow: Order = { id: tempId, price: 0, qty: 0 };

  // Optimistic: add temp row immediately
  gridRef.current?.api.applyTransaction({ add: [tempRow] });

  try {
    const created = await createOrderAction({ price: 0, qty: 0 });
    // Replace temp row with real data
    gridRef.current?.api.applyTransaction({
      remove: [tempRow],
      add: [created],
    });
  } catch {
    // Rollback on failure
    gridRef.current?.api.applyTransaction({ remove: [tempRow] });
  }
}

The same pattern applies to update (rollback cell value on failure) and delete (re-add the row on failure).

Code Examples

Setting up the AG Grid component with inline editing and a delete button:

const colDefs: ColDef<Order>[] = useMemo(() => [
  { field: 'id', editable: false, sort: 'asc' },
  { field: 'price', editable: true },
  { field: 'qty', editable: true },
  {
    headerName: '',
    width: 100,
    cellRenderer: (p: ICellRendererParams<Order>) => (
      <button onClick={() => handleDelete(p.data!)}>Delete</button>
    ),
  },
], []);

<AgGridReact
  ref={gridRef}
  rowData={orders}
  columnDefs={colDefs}
  getRowId={(p) => String(p.data.id)}
  onCellValueChanged={handleCellValueChanged}
/>

This is a summary of my original 3-part series written in Korean.
For the full articles with step-by-step setup instructions, check out the originals:

👉 Part 1: Next.js Basics
👉 Part 2: Prisma ORM Setup & CRUD
👉 Part 3: AG Grid & Optimistic Updates

AntiGravity: Getting the Most Out of Agentic Coding with Rules, Skills, and Workflows

Malloc72P — Thu, 26 Mar 2026 06:56:08 +0000

TL;DR

AntiGravity is a VS Code fork by Google DeepMind, built for agentic coding with enhanced AI agent features.
The .agent folder lets you define Rules, Skills, and Workflows to give your AI agent project-specific context.
Rules set coding conventions the agent must follow (e.g., architecture, style guides). Use always_on sparingly — prefer model_decision to avoid context overload.
Skills teach the agent how to solve specific problems using specific tools (e.g., using GitHub MCP to fetch commit history).
Workflows automate repetitive command sequences (e.g., install → type-check → build) and can be triggered via slash commands.

Key Concepts

Rules: Coding Standards for Your Agent

Rules live in .agent/rules/ and define principles the agent must follow. Each rule file uses frontmatter to control when it activates:

---
trigger: always_on
---
# Always-on rules (use sparingly)

---
trigger: model_decision
description: Backend rules for Server Actions, Prisma, Auth, etc.
---
# Contextual rules — agent decides when to apply

Keep rules concise. If the agent wouldn't make a mistake without the rule, leave it out — too much context causes hallucinations.

Skills: Teaching Your Agent How to Solve Problems

Skills (.agent/skills/) define what tool to use and how to use it for specific scenarios.

---
name: git-history
description: Uses GitHub MCP to fetch and summarize recent commit history.
---

## When to Use
- "What changed recently?"
- "Summarize recent commits"

## Steps
1. Identify repo owner/name
2. Call `list_commits` via GitHub MCP (perPage: 5-10)
3. Optionally call `get_commit` with `include_diff: true`
4. Summarize changes in categories (features, fixes, refactors)

Workflows: Automating Repetitive Tasks

Workflows (.agent/workflows/) chain commands together:

---
description: Build & type-check workflow
---

1. Install dependencies
// turbo
'pnpm install'

2. Type check
// turbo
'pnpm check-types'

3. Build
// turbo
'pnpm build'

The // turbo comment tells the agent to run the command automatically without user approval.

This is a summary of my original post written in Korean.
For the full article with detailed explanations and more examples, check out the original:

👉 Read the full post on my blog