DEV Community: JS

Turning Your Database Into an MCP Server With Auth

JS — Tue, 10 Jun 2025 05:39:37 +0000

MCP is trending in AI, But…

MCP(Model Context Protocol) is undoubtedly one of the most exciting trends in AI now. Not only is everyone talking about it, but everyone is also rushing to develop their version to secure a seat at the table of the AI era. Don't feel so? Guess how many MCP servers are listed in MCP Server Directory ?

The number is 4,684 now, and remember, MCP is just a six-month-old baby. However, have you noticed the one and only filter on the left:

Guess how many remain after applying this filter? Only 59—approximately 1% of the total. For those unfamiliar with this filter, I'll provide a brief explanation that you can skip if you already understand it.

MCP was initially conceived primarily as a protocol for local execution, where AI models could interact with local tools and data sources running on the same machine, like the example MCP FileSystem and Fetch listed in the official doc. It means you must install and run the MCP server on your local machine, regardless of whether the underlying transport is stdio or HTTP SSE. This design choice made sense in the early days, as it simplified security concerns and reduced latency. The protocol's simplicity made it perfect for developers to experiment with AI tool integration on their personal machines. However, as MCP gained traction and the AI ecosystem evolved, the need for secure remote execution became increasingly apparent:

// Detect dark theme var iframe = document.getElementById('tweet-1907218594624372868-613'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1907218594624372868&theme=dark" }
With a remote MCP server, organizations expose their data and services to AI models over the internet, so the most important thing is Auth (authentication and authorization). Initially, this was addressed by asking users to generate an API key within the product and then configure it in the MCP settings. Here is an example from the Neon MCP server:

{
  "mcpServers": {
    "neon": {
      "command": "npx",
      "args": [
        "-y",
        "@neondatabase/mcp-server-neon",
        "start",
        "<YOUR_NEON_API_KEY>"
      ]
    }
  }
}

Developers are all familiar with this process. But as more and more SaaS products are providing the MCP server due to fear of death(search ‘SaaS is dead’ if you don't get it 😁), that's definitely not a good user experience for the non-developers. Moreover, users need to manually update the NPM package from time to time to stay current.

Kent raises the same concern in his tweet:

All the examples I see so far have the user generate a token and then put that token in the MCP configuration. Is that the best we have right now? I was hoping to find an example of an MCP client that supported an OAuth flow with a hosted MCP server.

The Advent of Authorization for MCP

The MCP is young but is growing very fast. The OAuth support was introduced in March 2025, around the time he was 3 months old. Here are the Authorization flow steps in the official specification:

The specification comes with SDK support for both client and server, enabling more MCP servers to adopt and leverage it. Even some existing servers that rely on API keys are beginning to embrace the new modern solution. For example, the Neon MCP server mentioned above adds support for it, too.

{
  "mcpServers": {
    "Neon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.neon.tech/sse"]
    }
  }
}

💡 The mcp-remote is for clients that don’t support OAuth. It's unnecessary for clients like Cursor that have supported it.

After adding the above MCP configuration, the MCP client will automatically open the browser to go through the standard OAuth process without needing the API key anymore:

With this modern MCP server, you can stop worrying about the PM or CEO showing up at your desk asking for help connecting to the MCP server of some SaaS product your company uses. Trust me, it happens. 😂

MCP Is a Good Enhancement for SaaS

With the seamless experience of OAuth support, many companies are eager to provide an MCP server to enhance their existing product or service, especially within the SaaS landscape. Balancing flexibility and simplicity is always a core challenge for SaaS - too many buttons overwhelm users, too few constrain power users. For instance, I always love the clean and efficient UX/UI design of Trello:

However, it pricks me every time for certain routine jobs.

How many cards were done last week?
Who has the most incomplete cards?
Which list has the most incomplete cards?

Trello doesn’t provide a direct way to show the answer; you have to do the math manually. This is where the MCP-LLM duo could provide a great solution to let user use natural language to get their job done. I think that’s the actual point that Microsoft CEO Satya Nadella was trying to convey in his presumed “SaaS is dead” interview.

Two Approaches to Building an MCP Server

1. Relying on the Existing API

This seems like the obvious choice. However, since those APIs were most likely designed a long time before the LLM was born, they might not be suitable for the LLM to consume. One thing is that the semantics of the parameters and return data might not be self-explanatory enough for the LLM to understand; The other thing is that the API might not be flexible enough to provide the functionality to support what the user wants to achieve.

2. Start from Scratch

For those considering this approach, the biggest concern is probably time. Don’t worry, we never really build from scratch, do we? The MCP is evolving fast, and so is the whole ecosystem. Let me show you the modern stack that could dramatically reduce the code you need to write to speed it up.

MCP TypeScript SDK

It fully implements the MCP specification, including Authorization. It provides a strong abstraction, freeing you from wrestling with low-level protocol implementation so you can focus on the business logic.

ZenStack

ZenStack is a schema-first TypeScript toolkit on top of Prisma ORM. The core part is a ZModel DSL that unifies data modeling and access control. Here is an example of what a simple blog post looks like:

model User {
  id            Int                 @id @default(autoincrement())
  email         String              @unique
  name          String?
  password      String              @password @omit
  posts         Post[]

  @@allow('read', true)
}

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  content   String?
  published Boolean  @default(false)
  viewCount Int      @default(0)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?     @default(auth().id)

  @@allow('all', auth() == author)
  // logged-in users can view published posts
  @@allow('read', auth() != null && published)
}

Based on the ZModel schema, ZenStack automatically creates well-structured, type-safe, and authorized CRUD APIs for your database. MCP's core value lies in its tools, which fundamentally consist of schema definitions and executable operations—specifically, the CRUD operations on your database for most SaaS applications. ZenStack can generate both directly from its schema, which can be safely called by LLM thanks to the access control policy. Thus, your primary task is to define the schema, and ZenStack manages everything else.

Building an MCP Server from Scratch

So let me walk you through the process of turning your database into an MCP server with OAuth-based authentication and authorization from scratch. I will use the blog post mentioned above as a sample; you can adapt it for your app, and all you need to do is change the ZModel schema accordingly.

You can find the completed project below:

https://github.com/jiashengguo/zenstack-mcp-auth

Initialize the Project

Use the below script to initialize a project with Prisma and Express:

npx try-prisma@latest -t orm/express -n blog-app-mcp

Install the MCP SDK, bcrypt(used to hash password):

npm install @modelcontextprotocol/sdk, bcrypt, @types/bcrypt

Initialize ZenStack:

npx zenstack@latest init

Auth

To support the OAuth, the server needs to store the following information:

OAuth Client
Authorization Code
Access Token
Refresh Token

So let’s add them in the ZModel schema file so that we can use the generated type-safe API to operate on them:

model OAuthClient {
  id                       Int      @id @default(autoincrement())
  client_id                String   @unique
  client_secret            String?
  ...
}

model AuthorizationCode {
  id            Int      @id @default(autoincrement())
  code          String   @unique
  ...
}

model AccessToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

model RefreshToken {
  id        Int      @id @default(autoincrement())
  token     String   @unique
  ...
}

According to the MCP specification, here are the three endpoints that the server must implement:

Endpoint	Url	Usage
Authorization	/authorize	Used for authorization requests
Token	/token	Used for token exchange & refresh
Registration	/register	Used for dynamic client registration

MCP SDK provides a utility function, mcpAuthRouter, to install these standard authorization server endpoints. What we need to do is implement an OAuthServerProvider to pass it to the mcpAuthRouter.

Let’s create an AuthMiddleware class to handle all the Auth logic, and a PasswordAuthProvider implementing the OAuthServerProvider to do the actual logic.

export class AuthMiddleware {
   private authProvider: PasswordAuthProvider;
   private authRouter: express.Router = express.Router();
   ...
    private setupRouter() {
        // Add OAuth router using the mcpAuthRouter function
        this.authRouter.use(
            '/',
            mcpAuthRouter({
                provider: this.authProvider,
                issuerUrl: new URL(config.baseUrl),
                baseUrl: new URL(config.baseUrl),
                scopesSupported: ['read', 'write'],
            })
        );
        ...
    }
}

PasswordAuthProvider

Here are the three functions that will actually be called, corresponding to the three necessary endpoints mentioned above:

export interface OAuthServerProvider {
    // /register
    get clientsStore(): OAuthRegisteredClientsStore;

    // /authorize
    authorize(client: OAuthClientInformationFull, params: AuthorizationParams, res: Response): Promise<void>; 

    // /token
    exchangeAuthorizationCode(client: OAuthClientInformationFull, authorizationCode: string, codeVerifier?: string, redirectUri?: string): Promise<OAuthTokens>;
}

The clientStore deals with register and read through registerClient and getClient functions, it simply writes and reads the OAuthClient model from the database.

The actual authorization flow begins with authorize. Its job is to redirect to the actual authorization server with all the necessary parameters. Since in our case, the authorization server is itself, let’s redirect to the/auth/login path:

      const loginUrl = new URL('/auth/login', config.baseUrl);
      ...
      res.redirect(loginUrl.toString());

Therefore, we need to create a login.html to serve it. It’s a typical login form like below:

After clicking Login, it combines all the URL parameters passed from the authorization flow along with the email and passwords to post to the server endpoint /auth/login.

The server endpoint /auth/login would eventually call into the function handlelogin of PasswordAuthProvider. It verifies the user identity. If it is correct, then create an auth code, return to the client, and store it in an AuthorizationCode instance in the database

  // Generate authorization code
  const authCode = crypto.randomBytes(32).toString('hex');

  // Store authorization code in database
  await this.prisma.authorizationCode.create({
      data: {
          code: authCode,
          clientId,
          userId: user.id,
          codeChallenge,
          redirectUri,
          expiresAt: new Date(Date.now() + 600000), // 10 minutes
          scopes,
      },
  });

After getting the auth code returned from the server, login.html will redirect to the MCP client with the auth code. Finally, the MCP client will use the auth code to call the /token endpoint to exchange for the access token, which will call into the exchangeAuthorizationCode function.

In exchangeAuthorizationCode, the server will first verify that the auth code it just granted is valid, and the client’s identification, such as PKCE. If everything is correct, it will generate both access token and refresh token, store them in the database, and return to the MCP client.

// Store tokens in database
await this.prisma.accessToken.create({
    data: {
        token: accessToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt,
    },
});

await this.prisma.refreshToken.create({
    data: {
        token: refreshToken,
        clientId: client.client_id,
        userId: authData.userId,
        scopes: authData.scopes as any,
        expiresAt: new Date(Date.now() + 86400 * 30 * 1000), // 30 days
    },
});

// Clean up authorization code
await this.prisma.authorizationCode.delete({
    where: { code: authorizationCode },
});

return {
    access_token: accessToken,
    token_type: 'Bearer',
    expires_in: expiresIn,
    refresh_token: refreshToken,
    scope: (authData.scopes as string[]).join(' '),
};

Stateful Multi-connections Streamable HTTP Server

After the MCP client gets the access token, each time it communicates with the server through the main endpoint, it will put the access token in the Authorization header. The server should use it to verify the client and get the client’s identity. Let’s choose the conventional /mcp endpoint as the main endpoint and getFlexibleAuthMiddleware to do so.

The first request sent by the MCP client to the server is an initialize request. The server should respond with server information and a generated session ID, which the client would always include to maintain the session. As a production-ready MCP server, it definitely should support multiple simultaneous connections. Therefore, we use a map to store each client by its session ID.

const transports: { [sessionId: string]: StreamableHTTPServerTransport } = {};

To manage the session for each user, we will create a dedicated MCPServer for it. Since it’s per user per MCP server, we could store the userId in it, which will be used for Authorization when executing tools.

if (sessionId && transports[sessionId]) {
    transport = transports[sessionId];
  } 
else if (!sessionId && isInitializeRequest(req.body)) {
    // Handle new MCP connection initialization
    transport = new StreamableHTTPServerTransport({
        sessionIdGenerator: () => crypto.randomUUID(),
        onsessioninitialized: (sessionId: string) => {
            console.log(`New MCP session initialized: ${sessionId}, User ID: ${userId}`);
            transports[sessionId] = transport!;
        },
    });

    const mcpServer = createMCPServer(userId);
    await mcpServer.connect(transport);
    console.log(`MCP server connected for User ID: ${userId}`);
    // Handle connection close
    transport.onclose = () => {
        if (transport?.sessionId) {
            console.log(`MCP session closed: ${transport.sessionId}`);
            delete transports[transport.sessionId];
        }
    };
}
else {
  // invalid request
  ...
}
// Handle the request
await transport.handleRequest(req, res, req.body);

Tool

We will fully rely on the ZenStack to do the job. Remember the two parts of the Tool: schema and execution.

Schema

ZenStack has a native Zod plugin to generate the Zod schema for its CRUD API. We can enable it by adding the one below to the schema.zmodel :

plugin zod {
    provider = '@core/zod'
}

Then, after running zenstack generate, it generates the Zod schema for all the operations it supports for every model in @zenstackhq/runtime/zod/input. For example, this is the one for Post :

import { z } from 'zod';
import type { Prisma } from '.zenstack/models';
declare type PostInputSchemaType = {
    findUnique: z.ZodType<Prisma.PostFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.PostFindFirstArgs>;
    findMany: z.ZodType<Prisma.PostFindManyArgs>;
    create: z.ZodType<Prisma.PostCreateArgs>;
    createMany: z.ZodType<Prisma.PostCreateManyArgs>;
    delete: z.ZodType<Prisma.PostDeleteArgs>;
    deleteMany: z.ZodType<Prisma.PostDeleteManyArgs>;
    update: z.ZodType<Prisma.PostUpdateArgs>;
    updateMany: z.ZodType<Prisma.PostUpdateManyArgs>;
    upsert: z.ZodType<Prisma.PostUpsertArgs>;
    aggregate: z.ZodType<Prisma.PostAggregateArgs>;
    groupBy: z.ZodType<Prisma.PostGroupByArgs>;
    count: z.ZodType<Prisma.PostCountArgs>;
};

So each operation for each model will become a Tool of our MCP server.

Execution

The execution of each function is very straightforward; just dynamically invoke the function with the argument generated by the LLM. Therefore, the whole Tool creating logic is simply one lambda expression in less than 30 lines of code:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import crudInputSchema from '@zenstackhq/runtime/zod/input';
...
export function createMCPServer(userId: number) {
    const server = new McpServer(
        ...
    )
    Object.entries(crudInputSchema)
        .filter(([name]) => modelNames.includes(getModelName(name)))
        .forEach(([name, functions]) => {
            const modelName = getModelName(name);

            Object.entries(functions as Record<string, any>)
                .filter(([functionName]) => functionNames.includes(functionName))
                .forEach(([functionName, schema]) => {
                    const toolName = `${modelName}_${functionName}`;
                    server.tool(
                        toolName,
                        `Prisma client API '${functionName}' function input argument for model '${modelName}'. ${currentUserPrompt}`,
                        {
                            args: schema,
                        },
                        async ({ args }) => {
                            console.log(`Calling tool: ${toolName} with args:`, JSON.stringify(args, null, 2));
                            const prisma = getPrisma(userId);
                            const data = await (prisma as any)[modelName]<a href="args">functionName</a>;
                            console.log(`Tool ${toolName} returned:`, JSON.stringify(data, null, 2));
                            return {
                                content: [{ type: 'text', text: JSON.stringify(data, null, 2) }],
                            };
                        }
                    );
                });
        });

    return server;
}

One thing that needs to be mentioned is that the Prisma client that is used to call that operation is the ZenStack-enhanced one that contains the current user identity, which is the userId stored in the MCPServer during initialization. This will completely eliminate unauthorized data access, no matter what parameters LLM generates for the function, even if hallucination happens:

import { enhance } from '@zenstackhq/runtime';
// Gets a Prisma client bound to the current user identity
export function getPrisma(userId: number | null) {
    const user = userId ? { id: userId } : undefined;
    return enhance(prisma, { user });
}

There is another benefit that since these Tools are actually the standard Prisma Client API, it works well for the LLM:

First, its declarative and well-structured nature makes it easy to understand and reason about, allowing LLMs to generate accurate and predictable queries with minimal ambiguity
Second, the API's flexibility allows one single call to access multiple models (database tables), enabling LLMs to efficiently navigate complex data relationships and perform sophisticated queries across different entities without requiring separate API calls or complex orchestration logic.
Third, Prisma has been widely adopted for years, providing a rich ecosystem of documentation, examples, and community usage that LLMs can learn from, greatly increasing the chance of generating correct and context-aware code.

Test

The sample project includes seed data for you to play around with. Simply run the below command to make it ready:

npx prisma db push
npx prisma db seed

It creates three users with posts. The passwords for all users are password123.

Enjoy playing it with whatever MCP client of your choice:

I’m really eager to hear about the results you achieved with your application! If you’re looking for any tips on writing the ZModel schema, please feel free to reach out to me or hop onto our Discord. I’m always willing to help!

How to Build AI Agents to Enhance SaaS With Minimal Code and Effort

JS — Tue, 20 May 2025 05:59:45 +0000

Is SaaS Really Dead?

Several months ago, the internet was abuzz with the Microsoft CEO Satya Nadella saying, “SaaS is dead.”

The conversation started with a question from Bill Gurley about whether Satya was worried that newer startups are building applications with an AI-first approach, which could obfuscate traditional infrastructure like Excel or CRM. Here is Satya’s response:

I think the notion that business applications exist, that's probably where they'll all collapse, right in the agent era, because if you think about it, right, they are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents, and these agents are going to be multi-repo CRUD

Some people might assume he suggested that AI agents could or would replace SaaS. However, if you watch the entire podcast, you'll understand that he's actually discussing how AI agents will transform SaaS rather than replace it:

How? Let me share an example from my experience. At my previous company, we used Trello for project management. I was impressed by its clean and efficient UX design.

However, one drawback that consistently bothered me was the lack of flexibility in performing queries. For instance:

How many cards were done last week?
Who has the most incomplete cards?
Which list has the most incomplete cards?

Trello doesn't provide a direct way to show the answer; you'll need to do the math manually. I understand that offering such flexibility from a UI design perspective is challenging, yet each encounter often brings a sigh of frustration. 😮‍💨

Balancing flexibility and simplicity is a core challenge for SaaS. This is where an AI agent can play a role. The most straightforward solution is to introduce a chatbot that can easily provide answers to all the questions mentioned, without altering any existing features.

Challenge of Building an AI Chatbot

We are all aware of the hallucinations that AI causes. But there is another level of hallucination:

AI makes many things seem easily accomplished on the surface, but you will see the challenge under the iceberg when it comes to production.

My previous company tried to integrate a chat agent into their SaaS product, and was struggling with those challenges:

LLM Failed to Generate the Correct API Call

The initial plan was to have the LLM generate an API call directly based on user input. However, probably because the existing API is not well designed, LLM often struggles to interpret and generate the correct parameters. Sometimes, it even calls the wrong API.
The Complexity of Transforming the LLM Result

Since the initial plan fails, they ask LLM to create the intermediate structured query object, then use code to convert this object into an actual database query. The good thing is that it is the code that makes the final call; the bad thing is that the code can become highly complex as it needs to account for all possible cases the LLM might produce.

One critical issue that needs to be addressed is Authorization. You have to scrutinize and ensure the generated query doesn’t break the authorization rule of the current system, which can sometimes be quite complex. Any oversight could lead to significant security breaches, potentially disastrous for a B2B SaaS.

The fundamental issue seems to be that the current infrastructure is not friendly enough for AI agents, as Bill questioned Satya. So, what type of infrastructure would be suitable for AI?

Schema-First Fit AI-First

Among all the discussions regarding Satya’s statement:

They are essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents.

Many people focus solely on the business logic that will be handled by the agent, often neglecting the essential prerequisite: the CRUD database. In other words, AI must accurately and precisely translate the business logic to the CRUD operation to ensure success. This is where the challenges arise, as illustrated in the previous example. It seems there is a missing layer that focuses on 'what' rather than 'how' to make AI better work: a schema. AI excels at declarative schemas over imperative code. Therefore, if we could make the CRUD database a well-designed schema for AI to manipulate, that could provide a robust foundation for the mission to be done.

The ZenStack schema-first toolkit is well-suited for the task. The core part is a DSL that unifies data modeling and access control, two essential parts of CRUD databases. Here is an example of what a simple blog post looks like:

enum Role {
    USER
    ADMIN
}

model Post {
    id        String  @id @default(cuid())
    title     String
    published Boolean @default(false)
    author    User    @relation(fields: [authorId], references: [id])
    authorId  String  @default(auth().id)

    @@allow('all', auth() == author)
    @@allow('read', auth() != null && published )
    @@allow('read', auth().role == 'ADMIN')
}

model User {
    id       String  @id @default(cuid())
    email    String? @unique
    password String  @password @omit
    role     Role    @default(USER)
    posts    Post[]

    @@allow('create,read', true)
    @@allow('update,delete', auth() == this)
}

Based on the schema, ZenStack automatically generates well-structured, type-safe, and authorized CRUD APIs to the database. Not only can AI understand and manipulate it better with less chance of hallucination, but also developers will be able to build the AI agent on top of it easily.

I know talk is cheap, so let me show you the code!

Building an AI Chatbot from Scratch

Let’s build an AI chatbot for a Todo app to address the pain points of Trello earlier. To keep this concise, I'll focus on the key steps. You can find the link to the completed project on GitHub at the end of the post. Here is the final outcome:

Here is the tech stack we are using:

Next.js - React framework
ZenStack - Full-stack toolkit with access control
NextAuth - Authentication for Next.js
AI SDK - AI integration for chat features

1. Creating the project

Create a Next.js project with create-t3-app with Prisma, NextAuth, and TailwindCSS:

npx create-t3-app@latest --prisma --nextAuth --tailwind --appRouter --CI todo-ai

2. Initialize the project for ZenStack

Run the zenstack CLI to prepare your project for using ZenStack.

npx zenstack@latest init

Replace the schema.zmodel with the below content:

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "sqlite"
    url      = env("DATABASE_URL")
}

plugin zod {
    provider = '@core/zod'
}

/*
 * Model for a Todo list
 */
model List {
    id        String   @id @default(uuid())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    owner     User     @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId   String   @default(auth().id)
    title     String   @length(1, 100)
    private   Boolean  @default(false)
    todos     Todo[]
    // can be read by owner or space members (only if not private) 
    @@allow('read', !private)

    // owner can do anything
    @@allow('all', owner == auth())
}

/*
 * Model for a single Todo
 */
model Todo {
    id          String    @id @default(uuid())
    createdAt   DateTime  @default(now())
    updatedAt   DateTime  @updatedAt
    owner       User      @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId     String    @default(auth().id)
    list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
    listId      String
    title       String    @length(1, 100)
    completedAt DateTime?

    // full access if the parent list is readable
    @@allow('all', check(list, 'read'))
}

model User {
    id       String  @id @default(cuid())
    name     String?
    email    String? @unique
    password String  @password @omit
    todo     Todo[]
    list     List[]

    // everyone can signup, and user profile is also publicly readable
    @@allow('create,read', true)
    // only the user can update or delete their own profile
    @@allow('update,delete', auth() == this)
}

This represents a multi-user Todo app. Todo list can be private or public; list owners have full control over their list. If a user can see the list, they can manipulate all the todos under that list.

3. Implement Signup/Signin

The tasks here are configuring NextAuth to use credential-based auth and creating the signup/signin form. Check out the code for details.

4. Implement the chatbot logic with Vercel AI SDK and ZenStack

We will primarily utilize the AI SDK to develop the chatbot. It not only standardizes integration across various LLM providers but also offers a range of hooks for creating chat and generative user interfaces. With that, building a chatbot with real-time message streaming requires just a few lines of code. Here is the official doc.

Simply put, it provides a userChat hook for the client and a corresponding server endpoint in src/app/chat/route.ts. I will skip the UI part and focus on implementing the endpoint, which is essentially the complete functionality of this bot.

Every AI agent typically consists of two components: Tools and Prompts. As previously discussed, Tools in this context refer to the CRUD APIs of the database. So let’s see how it is getting implemented.

The AI SDK allows Zod Schema to be used to define the parameters of the Tool. So, have you noticed a Zod plugin defined in the schema.zmodel ?

plugin zod {
    provider = '@core/zod'
}

This is a ZenStack native plugin that generates Zod schemas for models and input arguments of Prisma CRUD operations. For instance, it will generate the CRUD schema for every model as below:

declare type TodoInputSchemaType = {
    findUnique: z.ZodType<Prisma.TodoFindUniqueArgs>;
    findFirst: z.ZodType<Prisma.TodoFindFirstArgs>;
    findMany: z.ZodType<Prisma.TodoFindManyArgs>;
    create: z.ZodType<Prisma.TodoCreateArgs>;
    createMany: z.ZodType<Prisma.TodoCreateManyArgs>;
    delete: z.ZodType<Prisma.TodoDeleteArgs>;
    deleteMany: z.ZodType<Prisma.TodoDeleteManyArgs>;
    update: z.ZodType<Prisma.TodoUpdateArgs>;
    updateMany: z.ZodType<Prisma.TodoUpdateManyArgs>;
    upsert: z.ZodType<Prisma.TodoUpsertArgs>;
    aggregate: z.ZodType<Prisma.TodoAggregateArgs>;
    groupBy: z.ZodType<Prisma.TodoGroupByArgs>;
    count: z.ZodType<Prisma.TodoCountArgs>;
};

Therefore, all we need to do is convert each CRUD operation to an AI SDK tool. Let’s create a createToolsFromZodSchema function iterates all the models:

import prismaInputSchema from "@zenstackhq/runtime/zod/input";
import { type Tool, tool, zodSchema } from "ai";

async function createToolsFromZodSchema(prisma: PrismaClient) {
  const tools: Record<string, Tool> = {};
  const functionNames = ["findMany", "createMany", "deleteMany", "updateMany"];
  for (const [inputTypeName, functions] of Object.entries(prismaInputSchema)) {
    // remove the postfix InputSchema from the model name
    const modelName = inputTypeName.replace("InputSchema", "");
    for (const [functionName, functionSchema] of Object.entries(
      functions,
    ).filter((x) => functionNames.includes(x[0]))) {
      const functionParameterType = zodSchema(
        functionSchema as z.ZodObject<z.ZodRawShape>,
        {
          useReferences: true,
        },
      );
      tools[`${modelName}_${functionName}`] = tool({
        description: `Prisma client API '${functionName}' function input argument for model '${modelName}'`,
        parameters: functionParameterType,
        execute: async (input: unknown) => {
          console.log(
            `Executing ${modelName}.${functionName} with input:`,
            JSON.stringify(input),
          );
          // eslint-disable-next-line
          return (prisma as any)[modelName][functionName](input);
        },
      });
    }
  }

To minimize the tool count and alleviate the AI's workload, we offer only four fundamental operations: "findMany," "createMany," "deleteMany," and "updateMany.”

The execute function inside is quite simple, just invoke the corresponding prisma client API function using the passed in PrismaClient object. Here comes the most crucial part, which is also the most exciting part of ZenStack:

The PriamClient object should be the enhanced Prisma client that contains the current user identity instead of the regular Prisma client:

  const authObj = await auth();
  const enhancedPrisma = enhance(db, { user: authObj?.user });
  const tools = await createToolsFromZodSchema(enhancedPrisma);

The greatest advantage is that no matter what parameters AI generates for a function, you never have to worry about unauthorized access. This is because the access policy defined in the schema will always be injected under the hood before reaching the database.

The system prompt is straightforward and general. You can review the code and tailor it to suit your specific requirements:

  const systemPrompt = `...`;

  const result = streamText({
    model: openai("gpt-4.1"),
    system: systemPrompt,
    messages: messages,
    maxSteps: 3,
    tools: tools,
  });

Thanks to the AI SDK and ZenStack, the entire server implementation of this chatbot was completed in less than 100 lines of code! Even more impressive, this implementation is completely app-agnostic. In other words, regardless of your app (zmodel), it works seamlessly.

So if you're a ZenStack user, you now know the best practice for implementing an AI Chatbot. 😉

Try It for Your Own Application

Here is the final project that you can run directly:

https://github.com/jiashengguo/zenstack-ai-chatbot
You can easily test this AI chat agent for your own application — all you need to do is customize schema.zmodel to fit your application.

I would love to hear your feedback on it!

Code as Doc: Automate by Vercel AI SDK and ZenStack for Free

JS — Mon, 23 Dec 2024 06:04:53 +0000

Few developers like writing document

If you have ever worked as a developer in a large company, you know that coding is just one small part of the daily responsibilities. One of Google's full-stack software engineers, Ray Farias, once estimated that developers write about 100-150 lines of code per day at Google. While this estimate may vary across different teams, the order of magnitude matches my observations as a developer at Microsoft.

So where does the time go? A significant portion goes to activities like meetings, code reviews, planning sessions, and documentation tasks. Among all these tasks, documentation is my least favorite—and I suspect many other teammates feel the same way.

The main reason is that we didn't see much value in it. We were required to write design documents at the start of each sprint before coding, and after reviewing them with each other, most would remain unchanged forever. I can't count how many times I found something strange in a document only to have its author tell me it was outdated. 😂 Why don't we update the docs? Because our boss considers it less important than fixing bugs or adding new features.

Documentation should serve as a high-level abstraction of code to aid understanding. When documentation falls out of sync with the code, it loses its purpose. However, keeping doc synchronized with code requires effort—something few people actually enjoy.

Uncle Bob(Robert C. Martin) has a famous quote about clean code:

Good code serves as its own comments

I think it would be great if this principle could be extended to documentation as well:

Good code is its own best documentation

Generate document using AI

There is a simple rule for the current trend in AI adoption: if humans don't enjoy doing something, let AI handle it. Documentation seems to fit perfectly into this category, especially as more and more code has already been generated by AI nowadays.

The timing couldn't be better, as GitHub has just announced that Copilot features are free. You could simply try to let it generate the documentation for your project for free. However, the result might not be as good as you expected. Is it because your prompt isn't good enough? Maybe, but there's a more essential reason behind this:

LLMs don't handle imperative code as well as they handle declarative text.

Imperative code often involves complex control flow, state management, and intricate dependencies. This procedural nature requires a deeper understanding of the intent behind the code, which can be difficult for LLMs to infer accurately. Moreover, the larger the code volume, the more likely the result will be inaccurate and less informative.

What's the first thing you want to see in a web application's documentation? Most likely, it's the data models that serve as the foundation of the entire application. Can data models be defined declaratively? Absolutely! Prisma ORM has already done a great job by allowing developers to define their application models in an intuitive data modeling language.

The ZenStack toolkit, built on top of Prisma, enhances the schema with additional capabilities. By defining access policies and validation rules directly within the data model, it becomes the single source of truth for the backend of your application.

When I say "single source of truth," it contains not only all the information for the backend—it actually is your entire backend. ZenStack automatically generates APIs and corresponding frontend hooks for you. With access policies defined, these can be safely called directly from the frontend without needing to enable row-level security (RLS) in the database layer. Or, in another way, you’ll hardly need to write any code for your backend.

Here is an extremely simplified example of a blog post app:

datasource db {
    provider = 'postgresql'
    url = env('DATABASE_URL')
}

generator js {
    provider = 'prisma-client-js'
}

plugin hooks {
    provider = '@zenstackhq/tanstack-query'
    output = 'lib/hooks'
    target = 'react'
}

enum Role {
    USER
    ADMIN
}

model Post {
    id        String  @id @default(cuid())
    title     String
    published Boolean @default(false)
    author    User    @relation(fields: [authorId], references: [id])
    authorId  String  @default(auth().id)

    @@allow('all', auth() == author)
    @@allow('read', auth() != null && published )
    @@allow('read', auth().role == 'ADMIN')
}

model User {
    id       String  @id @default(cuid())
    name     String?
    email    String? @unique
    password String  @password @omit
    role     Role    @default(USER)
    posts    Post[]

    @@allow('create,read', true)
    @@allow('update,delete', auth() == this)
}

We can easily create a tool that generates documentation from this schema using AI. You don't have to manually write and maintain docs anymore—simply integrate the generation process into the CI/CD pipeline, and there's no out-of-sync problem anymore. Here's an example of documentation generated from the schema:

I will walk you through the steps of how to create this tool.

ZenStack plugin system

Like many wonderful tools in the web development world, ZenStack adopts a plugin-based architecture. At the core of the system is the ZModel schema, around which features are implemented as plugins. Let's create a plugin to generate a markdown for a ZModel so it can be easily adopted by others.

For brevity, we'll focus on core parts. See the ZenStack documentation for complete plugin development details.

A plugin is simply a Node.js module that has the two parts:

A named export name that specifies the name of the plugin used for logging and error reporting.
A default function export containing the plugin logic.

Here's what it looks like:

import type { PluginOptions } from '@zenstackhq/sdk';
import type { DMMF } from '@zenstackhq/sdk/prisma';
import type { Model } from '@zenstackhq/sdk/ast';

export const name = 'ZenStack MarkDown';

export default async function run(model: Model, options: PluginOptions, dmmf: DMMF.Document) {
    ...
}

model is the ZModel AST. It is the result object model of parsing and linking the ZModel schema, which is a tree structure containing all the information in the schema.

We can use ZModelCodeGenerator provided by ZenStack sdk to get the ZModel content from the AST.

import { ZModelCodeGenerator } from '@zenstackhq/sdk';
const zModelGenerator = new ZModelCodeGenerator();
const zmodel = zModelGenerator.generate(model);

Now that we have the ingredients let's have AI do the cooking.

Use Vercel AI SDK to generate document

Initially, I planned to use OpenAI to do the job. But soon, I realized this would exclude developers who don't have access to paid OpenAI services. Thanks to Elon Musk, you can get free API keys from Grok (https://x.ai/).

However, I had to write separate code for each model provider. This is where the Vercel AI SDK shines. It provides a standardized interface for interacting with various LLM providers, allowing us to write code that works with multiple AI models. Whether you're using OpenAI, Anthropic's Claude, or other providers, the implementation remains consistent.

It provides a unified LanguageModel type, allowing you to specify any LLM model you wish to use. Simply check the environment to determine which model is available.

    let model: LanguageModel;

    if (process.env.OPENAI_API_KEY) {
        model = openai('gpt-4-turbo');
    } else if (process.env.XAI_API_KEY) {
        model = xai('grok-beta');
    }
    ...

The rest of the implementation uses the same unified API, regardless of which provider you choose.

Here is the prompt we use to let AI generate the content of the doc:

  const prompt = `
    You are the expert of ZenStack open-source toolkit. 
    You will generate a technical design document from a provided ZModel schema file that help developer understand the structure and behavior of the application. 
    The document should include the following sections:
    1. Overview 
        a. A short paragraph for the high-level description of this app
        b. Functionality
    2. an array of model. Each model has below two information:
        a. model name
        b. array of access policies explained by plain text
    here is the ZModel schema file:
    \`\`\`zmodel
    ${zmodel}
    \`\`\`
    `;

Generating structured data

When dealing with APIs, we prefer to use JSON data instead of plain text. Although many LLMs are capable of generating JSON, each has its own approach. For example, OpenAI provides a JSON mode, while Claude requires JSON formatting to be specified in the prompt. The good news is that Vercel SDK also unifies this ability across model providers using Zod schema.

For the prompt above, here is the corresponding response data structure we expect to receive.

    const schema = z.object({
        overview: z.object({
            description: z.string(),
            functionality: z.string(),
        }),
        models: z.array(
            z.object({
                name: z.string(),
                access_control_policies: z.array(z.string()),
            })
        ),
    });

Then call the generateObject API to let AI do his job:

const { object } = await generateObject({
        model
        schema
        prompt
    });

Here is the returned type that allows you to work within a type-safe manner:

const object: {
    overview: {
        description: string;
        functionality: string;
    };
    models: {
        name: string;
        access_control_policies: string[];
    }[];
}

Generate Mermaid ERD diagram

Let's also generate the ERD diagram for each model. This part is quite straightforward and easy to implement, so I think writing code is more reliable and efficient here. Of course, you could still employ AI as a copilot here. 😄

export default class MermaidGenerator {
    generate(dataModel: DataModel) {
        const fields = dataModel.fields
            .filter((x) => !isRelationshipField(x))
            .map((x) => {
                return [
                    x.type.type || x.type.reference?.ref?.name,
                    x.name,
                    isIdField(x) ? 'PK' : isForeignKeyField(x) ? 'FK' : '',
                    x.type.optional ? '"?"' : '',
                ].join(' ');
            })
            .map((x) => `  ${x}`)
            .join('\n');

        const relations = dataModel.fields
            .filter((x) => isRelationshipField(x))
            .map((x) => {
                // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
                const oppositeModel = x.type.reference!.ref as DataModel;

                const oppositeField = oppositeModel.fields.find(
                    (x) => x.type.reference?.ref == dataModel
                ) as DataModelField;

                const currentType = x.type;
                const oppositeType = oppositeField.type;

                let relation = '';

                if (currentType.array && oppositeType.array) {
                    //many to many
                    relation = '}o--o{';
                } else if (currentType.array && !oppositeType.array) {
                    //one to many
                    relation = '||--o{';
                } else if (!currentType.array && oppositeType.array) {
                    //many to one
                    relation = '}o--||';
                } else {
                    //one to one
                    relation = currentType.optional ? '||--o|' : '|o--||';
                }

                return [`"${dataModel.name}"`, relation, `"${oppositeField.$container.name}": ${x.name}`].join(' ');
            })
            .join('\n');

        return ['```

mermaid', 'erDiagram', {% raw %}`"${dataModel.name}" {\n${fields}\n}`{% endraw %}, relations, '

```'].join('\n');
    }
}

Stitch everything up

Finally, we'll combine all the generated components together to get our final doc:

 const modelChapter = dataModels
        .map((x) => {
            return [
                `### ${x.name}`,
                mermaidGenerator.generate(x),
                object.models
                    .find((model) => model.name === x.name)
                    ?.access_control_policies.map((x) => `- ${x}`)
                    .join('\n'),
            ].join('\n');
        })
        .join('\n');

 const content = [
        `# Technical Design Document`,
        '> Generated by [`ZenStack-markdown`](https://github.com/jiashengguo/zenstack-markdown)',
        `${object.overview.description}`,
        `## Functionality`,
        `${object.overview.functionality}`,
        '## Models:',
        dataModels.map((x) => `- [${x.name}](#${x.name})`).join('\n'),
        modelChapter,
    ].join('\n\n');

Off the shelf

Of course, you don't have to implement this yourself. It's already published as an NPM package for you to install:

npm i -D zenstack-markdown

Add the plugin to your ZModel schema file

plugin zenstackmd {
    provider = 'zenstack-markdown'
}

Just don’t forget to put whatever AI API keys are available for you in your .env. Otherwise, you might get some surprising results. 😉

OPENAI_API_KEY=xxxx
XAI_API_KEY=xxxxx
ANTHROPIC_API_KEY=xxxx

Supabase RLS Alternative

JS — Sun, 01 Dec 2024 05:19:25 +0000

Supabase RLS Alternative

JS for ZenStack ・ Jul 24

#webdev #database #opensource #supabase

Supabase RLS Alternative

JS — Wed, 24 Jul 2024 08:45:12 +0000

A Short History of BaaS

In the early days of web and mobile app development, building a backend from scratch was laborious and error-prone. Developers had to manage servers, databases, and infrastructure and ensure scalability while writing the core business logic of their applications. Then came Backend-as-a-Service (BaaS), promising to liberate developers from this burden.

Firebase: The Pioneer

Firebase was one of the first BaaS platforms to gain widespread adoption. It was acquired by Google, and at Google I/O in 2016, it announced an expansion of its services to become a unified BaaS platform for mobile developers. Firebase quickly became popular among developers for its ease of use and integration with Google's ecosystem.

However, as projects grew in complexity, so did concerns about vendor lock-in and data control. Its rigid data models and scalability issues led developers to seek more flexible and robust alternatives.

Supabase: The Open-Source Contender

In response to these limitations, Supabase was founded in 2020, positioning itself as the “open-source Firebase alternative.” Built on top of PostgreSQL, it offered a more flexible and powerful database solution while remaining open-source. Unsurprisingly, it soon became the new spokesperson for BaaS.

ACL(Access Control Layer) is the Core

While BaaS promises a simple abstraction of connecting the frontend to the database, it actually rejects another old-school promise:

You never expose the database directly to the frontend

The hero behind it is the ACL, or more specifically, authorization. It is the gatekeeper that stands between your database and potentially malicious actors. It ensures that users can only read or write data they are authorized to access.

Firebase: Security Rules

Firebase introduces a simple DSL to enforce access control.

service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;
      allow write: if request.auth != null && request.auth.uid == resource.data.authorId;
    }
  }
}

Supabase: RLS(Row Level Security)

Since Supabase is built upon Postgres, it could leverage PostgreSQL's robust RLS to handle access control.

-- owner has full access to her own posts
CREATE POLICY post_owner_policy ON post
    USING (owner = current_user);

Since RLS is written in SQL, it allows more fine-grained access control. Developers can define policies that determine which rows of data a user can access based on their role or other attributes. Theoretically, it could express any authorization pattern you use, like RBAC, ABAC, PBAC, etc.

Multi-Tenancy SaaS Example

Multi-tenancy is the classical pattern used in SaaS applications. An application can host many organizations, and users can join organizations and access resources based on their permissions. Let’s use a ToDo app to illustrate.

Database Model

The User and Space are many-to-many relations through the relation table SpaceUser.
A Todo belongs to a User, and a List
A List belongs to the User, and a Space

RLS rules for List

Let’s go through the access control requirements for List model and the corresponding RLS rules.

Create

owner must be set to the current user.
user must be in the space.

create policy "list_create"
on "public"."List"
to public
with check (
  ((auth.uid() = ("ownerId")::uuid) AND (EXISTS ( SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid())))))
);

Read

can be read by the owner.
can be read by space members if not private.

create policy "list_read"
on "public"."List"
to authenticated
using (
   ((auth.uid() = ("ownerId")::uuid) OR ((NOT private) AND (EXISTS (SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid()))))))
);

Update

only the owner is allowed to update
owner must be in the space of the current list
it doesn’t allow to change owner

create policy "list_update"
on "public"."List"
to authenticated
using (
  ((auth.uid() = ("ownerId")::uuid) AND (EXISTS ( SELECT 1
   FROM "SpaceUser"
  WHERE (("SpaceUser"."spaceId" = "List"."spaceId") AND (("SpaceUser"."userId")::uuid = auth.uid())))))
with check (
  (auth.uid() = ("ownerId")::uuid)
);

Delete

can be deleted by owner

create policy "list.delete"
on "public"."List"
to authenticated
using (
  (auth.uid() = ("ownerId")::uuid)
);

Supabase provides a RESTful API using PostgREST. However, without RLS, you will expose your database to the frontend. With the RLS policies created above, it’s safe to expose the API to the public because each user can only access the data allowed by the policy. For example, if you try to get all the List items using the API below, you will only receive the ones you are allowed to read by the read policy:

curl '{SUPABASE_PROJECT_URL}/rest/v1/List?select=*' \
-H "apikey: SUPABASE_ANON_KEY" \
-H "Authorization: Bearer USER_JWT_TOKEN"

Everything looks perfect, especially if you are familiar with SQL. So why do I need alternatives?

The Problems of Supabase RLS

1.Separation from Application Logic

As a modern developer, you know the sense of control when you can launch with a one-click. The prerequisite is to keep everything within the codebase. It's not just about convenience; it's about maintaining a single source of truth, ensuring consistency, and streamlining your workflow.

However, for RLS, you have to define authorization directly in the database, not in your source code. Of course, you could store it as an SQL file in your codebase, but you need to rely on SQL migration to ensure consistency. I think it’s the same reason why you seldom see people using stored procedures of databases nowadays despite all the benefits they offer.

What makes the consistency even worse is that you have to duplicate the policy filters in the application code. For example, if you are using the Supabase JS SDK, you have to use the two queries below to get the result:

// First, get the user's spaceIds
const { data: userSpaces } = await supabase.from('SpaceUser').select('spaceId').eq('userId', userId);

// Extract spaceIds from the result
const userSpaceIds = userSpaces.map((space) => space.spaceId);

// Now, query the List table
const { data, error } = await supabase
    .from('List')
    .select('*')
    .or(`ownerId.eq.${userId},and(private.eq.false,spaceId.in.(${userSpaceIds.join(',')}))`);

Why? Because otherwise, you might experience 20x slower query performance, according to the official benchmark of Supabase. 😲

Add filters to every query | Supabase Docs

2. Poor DX

If you are an SQL expert, you can ignore this one.

Writing SQL itself is not considered a good developer experience (DX) for many developers, with the majority adopting ORM. Moreover, you have to write it in a UI box without the help of Intellisense and often get an obscure error after clicking the save button:

The more challenging part is testing and debugging. Honestly, I have no idea about the best practice for it; if you have any tips, please share them in the comments.

3. Scalability

You might feel the aforementioned RLS for List is clear and straightforward, but that’s only for one table. If the access control policy for Todo is the same as List, which is a very common case, what policy do you need to create for Todo? The answer is that you have to duplicate all the policies of the list for Todo. That’s definitely not DRY(Don’t repeat yourself).

If you don't think it's a big deal, imagine you're lucky enough to grow your Todo SaaS into a team collaboration platform that manages various entities like dashboards, tasks, bugs, projects, etc.

4. Maintainability

Let’s say we get a feature request that if a team member can see a Todo list, he will have full access to all the Todos under it, even the ones not owned by him.

Do you know what change you need to make? You need to delete all the policies copied from the List mentioned above and then create a new policy below:

create policy "Todo"
on "public"."Todo"
to authenticated
using (
  ((EXISTS ( SELECT 1
   FROM "List"
  WHERE (("List".id = "Todo"."listId") AND (("List"."ownerId")::uuid = auth.uid())))) OR (EXISTS ( SELECT 1
   FROM (("List"
     JOIN "Space" ON (("List"."spaceId" = "Space".id)))
     JOIN "SpaceUser" ON (("SpaceUser"."spaceId" = "Space".id)))
  WHERE (("List".id = "Todo"."listId") AND (("SpaceUser"."userId")::uuid = auth.uid()) AND (NOT "List".private)))))
)

Do you think you can write this kind of policy all by yourselves? I actually asked ChatGPT to write it myself. Even if it's not a problem for you, think about how another team member might feel when he sees it for the first time.

And don't forget to duplicate this change in your application code for performance's sake. 😂

Alternative Solution

Remember in 2016 when Google I/O Firebase announced its expansion to BaaS? In the same year, another product with an interesting name joined this journey: Graphcool.

Maybe you haven't heard about it because it was sunsetted in 2020, the same year Supabase came out (what a coincidence!). Why was it sunsetted? See the detailed explanation on its home page:

https://www.graph.cool/

TLDR: The team felt that BaaS was too limited for developers to build the next generation of web applications, so they pivoted it to the Prisma ORM.

It simplifies database interactions by providing a type-safe query builder, seamless migrations, and an intuitive data modeling language. While Prisma ORM does provide more flexibility compared to BaaS, it intentionally misses the access control layer as an ORM. Consequently, you have to switch back to implementing Authorization logic at the application level.

Is it possible to bring back the convenience of not writing code for the Authorization like BaaS while maintaining the flexibility of a custom backend?

That's why we built ZenStack on top of Prisma ORM, adding the missing authorization layer and auto-generating type-safe APIs/hooks. It gives you the same convenience as using BaaS while maintaining flexibility with everything in your codebase.

Let’s cut the crap and see the code directly. Below are the equivalent ZenStack schema definitions of List and Todo you need to write for the ToDo apps.

abstract model BaseEntity {
    id        String   @id @default(uuid())
    space     Space    @relation(fields: [spaceId], references: [id], onDelete: Cascade)
    spaceId   String
    owner     User     @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId   String   @default(auth().id)

    // can be read by owner or space members 
    @@allow('read', owner == auth() || (space.members?[user == auth()]))

    // when create, owner must be set to current user, and user must be in the space
    @@allow('create', owner == auth() && space.members?[user == auth()])

    // when create, owner must be set to current user, and user must be in the space
    // update is not allowed to change owner
    @@allow('update', owner == auth() && space.members?[user == auth()] && future().owner == owner)

    // can be deleted by owner
    @@allow('delete', owner == auth())
}

/**
 * Model for a Todo list
 */
model List extends BaseEntity {
    title   String  @length(1, 100)
    private Boolean @default(false)
    todos   Todo[]

    // can't be read by others if it's private
    @@deny('read', private == true && owner != auth())
}

/**
 * Model for a single Todo
 */
model Todo {
    id          String    @id @default(uuid())
    owner       User      @relation(fields: [ownerId], references: [id], onDelete: Cascade)
    ownerId     String    @default(auth().id)
    list        List      @relation(fields: [listId], references: [id], onDelete: Cascade)
    listId      String
    title       String    @length(1, 100)
    completedAt DateTime?

    // same as its parent list
    @@allow('all', check(list))
}

Keep in mind that with this schema done, although you still need a server to deploy, you hardly need to write any backend code. ZenStack introspects the schema and installs CRUD APIs to the framework of your choice. Thanks to the access policy defined in the model, the APIs are fully secure and can be directly exposed to the public. You can also generate the OpenAPI(swagger) specification.

In fact, you don’t even need to be aware of the API, as ZenStack generates fully typed client hooks that call into the generated APIs. You can directly use those hooks with intrinsic automatic invalidation and optimistic update support.

What about the problems of RLS? Let’s go through them one by one.

1. Single Source of Truth

The access policies are now defined alongside the database models. The schema becomes the single source of truth of your backend, enabling an easier understanding of the system as a whole.

Moreover, whether calling from the frontend or backend, you don’t need to use any filter regarding the authorization rules, which will be injected into queries automatically by the ZenStack runtime. The application code you need to write is clean and clear:

   // frontend query：hook is auto generated by ZenStack
   const { data: lists } = useFindManyList();    
   ...

   // server props  
   export const getServerSideProps: GetServerSideProps<Props> = async ({ req, res, params }) => {
    const db = await getEnhancedPrisma({ req, res });

    const lists = await db.list.findMany();
    return {
        props: { lists },
    };
};

Remember the complex query you need to write for the RLS case mentioned above?

2. Good DX

ZenStack comes with a VSCode extension. All the basic features of IntelliSense, like autocomplete, Inline error reporting, Go-to definition, finding the reference, and auto-format,

work as usual.

If you have GitHub Copilot, there is a big chance that you don’t have to write the policy yourself:

For testing and debugging, you can enable ZenStack's debug logging by setting a simple flag. Then, you can see all the Prisma queries ZenStack actually calls to the database from the console log:

prisma:info [policy] `findMany` list:
{
  where: {
    AND: [
      { NOT: { OR: [] } },
      {
        OR: [
          { owner: { is: { id: 1 } } },
          {
            AND: [
              {
                space: {
                  members: {
                    some: { user: { is: { id: 1 } } }
                  }
                }
              },
              { NOT: { private: true } }
            ]
          }
        ]
      }
    ]
  }
}

Since all the code is actually running on your server, you can set breakpoints in the generated code to debug it step by step.

ZenStack also provides a REPL CLI for interactive query execution. You can quickly switch between different user contexts and see how the access policies affect the result.

3. Scalability

Have you noticed that for Todo there is only one line of the policy rule?

    // same as its parent list
    @@allow('all', check(list))

There is no need to duplicate the policies of List as needed for RLS.

Furthermore, if you need to add a new top-level entity like Bug, all you need is to add the below model in the schema:

model Bug extends BaseEntity {
    title    String @length(1, 100)
    priority Int
}

What about the policy rules for it? Thanks to model inheritance, it could inherit all the policies from the abstract base model BaseEntity.

As you can see, ZenStack has provided several features to keep schemas DRY and achieve better scalability.

4. Maintainability

Implementing the requirement change request mentioned above is just adding one parameter

// full access if the parent list is readable
// @@allow('all', check(list))
   @@allow('all', check(list, 'read'))

Nothing explains better than code here.

Here is the complete runnable project for this SaaS ToDo app:

https://github.com/zenstackhq/sample-todo-nextjs

The Art of Trade-off

As developers, we know better than others that every sword has two blades. For all the problems I mentioned with RLS above, the opposite side also shows its advantage. For example:

Although the policy is separate from the application, you don’t have to redeploy the application to let the new policy take effect.
While RLS's SQL policy may seem less intuitive than ZenStack’s, it is more flexible and has a better ecosystem.

Software engineering is an art of trade-offs. It involves balancing time and space, stability and flexibility, performance and code complexity, and more. What ZenStack provides is just another alternative; it's up to you to balance these trade-offs and make it an art.

Someone has completed the artwork in production 😉

We've launched MermaidChart's team feature using ZenStack. Much cleaner and easier to maintain than writing RLS policies or application level checks that will surely leak after some time.

— Sidharth MermaidChart

PHP: Laravel, Ruby: Rails, JavaScript:?

JS — Tue, 28 May 2024 10:23:41 +0000

Recently, there has been a heated discussion on Twitter between JS developers and Laravel and Rails developers. It started with a lengthy tweet from Taylor Otwell, author of Laravel:

// Detect dark theme var iframe = document.getElementById('tweet-1791468060903096422-861'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1791468060903096422&theme=dark" }
In short, he suggested that the whole JavaScript ecosystem lacks a real "full stack" framework like Laravel or Rails, which could allow a single developer to build the next GitHub, Airbnb, or Shopify.

I deeply empathize with this, as I share the same goal when building ZenStack, the TypeScript toolkit on top of Prisma ORM. In fact, I have often heard that kind of word from our community:

No one can deny the popularity and fast-paced growth of the JS ecosystem, even among non-members. So why is it?

The Historical Reason

Men make their own history, but they do not make it as they please; they do not make it under self-selected circumstances, but under circumstances existing already, given and transmitted from the past -- Karl Marx

Both PHP and Ruby were designed as server-side languages from the start. PHP was created in 1994 to build dynamic web pages, while Ruby, which appeared in the mid-1990s, was designed for general-purpose programming.

Given their server-side origins, PHP and Ruby were naturally suited for comprehensive frameworks that could handle all aspects of web development, from routing and controllers to database interactions and templating engines. This led to the creation of frameworks like Laravel and Rails to offer a complete, opinionated way to build web apps.

Contrastingly, JavaScript was born as a client-side scripting language for web browsers. It had nothing to do with the backend until 2009, when Node.js was introduced. If you've heard of the "Browser Wars" between Netscape Navigator and Internet Explorer, you're likely aware of the ongoing chaos in the frontend, which continues to drive front-end developers crazy today in the name of browser compatibility. As a result, the early web was about piecing together disparate technologies. Therefore, JavaScript developers became accustomed to modularity, allowing flexibility to mix and match libraries and tools for survival. That's why NPM, which emerged alongside Node.js, has grown astonishingly, quickly becoming the largest software registry in the world.

These different circumstances led to the different developer cultures:

PHP/Ruby devs: "Give me a framework that just works. I want conventions, stability, and a clear path to shipping."
JS devs: "Don't box me in! I want flexibility, the latest tools, and the freedom to build my way, even if it means more work upfront."

As a result, even after expanding to the backend world, a monolithic, "one-size-fits-all" approach could hardly fly in the JavaScript ecosystem.

Contemporary Endeavor

On one hand, this culture leads to constant evolution, keeping the entire ecosystem exciting and innovative. However, it also results in more decision fatigue and a steeper learning curve for newcomers.

"Where there's muck, there's brass." Some individuals embarked on an adventurous journey to build a Rails-like, battery-included framework to challenge the status quo. Here are some popular examples:

RedwoodJS

Full-stack JavaScript framework that integrates React, GraphQL, and Prisma. It simplifies development with a unified setup and automatic code generation, perfect for scalable applications.
Biltz.js

Blitz.js extends Next.js into a full-stack framework featuring a zero-API data layer and Prisma for database access. It aims to simplify development by allowing direct server-side code calls from the frontend.
AdonisJS

AdonisJS is a TypeScript-first web framework for building web apps and API servers. It offers a rich set of features out of the box, including an ORM, authentication, and a powerful CLI, making it ideal for developers seeking a comprehensive and structured development environment.

Will they become the Laravel or Rails of the JS world? It's probably too early to say, but at least RedwoodJS shows great momentum:

Another bunch of guys are trying to solve this problem by providing “start kits” with opinionated battery-included toolkits. Among these, the most popular one is Create-T3-App, which combines Next.js, tRPC, Tailwind CSS, and other powerful tools to give you a solid foundation for building typesafe web applications.

Interestingly, Theo, the creator of T3, seems to be pessimistic about this whole endeavor in the JavaScript world:

// Detect dark theme var iframe = document.getElementById('tweet-1792136001345003748-539'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1792136001345003748&theme=dark" }

Optimistic Future

Any application that can be written in JavaScript will eventually be written in JavaScript. — Jeff Atwood

While I'm not entirely convinced by Atwood's law, I do envision a promising future for JavaScript in the field of web development. The reason is simple:

It’s the first time in history that the whole web app could be developed with one programming language.

This is a significant benefit, particularly for novice developers. Thanks to TypeScript's excellent type inference system, we are not only capable of doing it but also willing to do so.

A common critique from Laravel or Rails users is that these frameworks lack a conventional method for modeling the relationship between different entities in your system, like the following:

// Detect dark theme var iframe = document.getElementById('tweet-1791531154212033004-712'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1791531154212033004&theme=dark" }

While it may not have reached the level of Laravel or Rails, the current efforts in the JS world have recognized this issue. If you look at the toolkit of the solution mentioned above, you'll find a common name: Prisma

If you haven’t heard about Prisma, it is a modern TypeScript-first ORM that allows you to manage database schemas easily, make queries and mutations with great flexibility, and ensure excellent type safety. This empowers JavaScript developers with a level of data handling sophistication and ease of relationship modeling traditionally found in Laravel and Rails, much like Laravel’s Eloquent ORM.

The ZenStack toolkit I’m building on top of Prisma aims to narrow down the gap further. It adds an Authorization layer on top of the schema and then automatically generates both APIs and frontend hooks for you. So, put simply, once you're done with your schema, you're almost done with your backend. You can then choose whatever frontend framework, like React, Vue, or Svelte, to get your UI done.

Begin With the End in Mind

Will JavaScript ever have its Laravel/Rails moment? Personally, I believe, or at least hope, that having standardized conventions leads to global optimization for the entire ecosystem. However, given the history and culture of JavaScript, achieving this may take a significant amount of time. It's unclear whether AI will accelerate this process or completely overturn it.

So, it seems we have to wait and see. However, let's not get lost in this debate and forget our original intention, as Lee Robinson says:

// Detect dark theme var iframe = document.getElementById('tweet-1792215708715122752-685'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1792215708715122752&theme=dark" }

So, I will quote a statement from the W3C Web Platform Design Principles at the end:

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

Stories Behind ZenStack V2!

JS — Mon, 29 Apr 2024 08:00:00 +0000

After polishing ZenStack V2 in the future branch for more than two months, we are happy to make it official now. I would like to take this opportunity to briefly show you the main features of V2 and the stories behind it.

Polymorphic Relations

This feature is the reason we created V2. It's one of the most desired features of Prisma, which you can see from the reactions to the two related GitHub issues:

Some folks even think that an ORM is incomplete without polymorphism support.

As the believer and enhancer of Prisma, one of our strategies is to pick up where Prisma has left. So, it did come to our radar at the early stage:

Support for Polymorphic Associations #430

It quickly became one of the most desired features of ZenStack too. Not only for the reactions themselves but also because more issues actually depend on it:

However, we know it’s a non-trivial task. Therefore, instead of rushing into the implementation, we wrote a blog post first to explain our approach and send it to the communities of both Prisma and ZenStack to get their feedback:

Tackling Polymorphism in Prisma

The feedback has exceeded our expectations. One guy even refers to it as Christmas magic:

Comment for #1644

leonard-henriquez commented on Dec 22, 2023

@jiashengguo is this what we call the christmas magic? 😍

View on GitHub

Gaining enough confidence, we began working on the implementation. Our confidence was further boosted when Prisma mentioned it as a third-party solution in its official blog, even though the feature was still in the alpha stage:

Now, you can fully enjoy it with the latest version of ZenStack:

Polymorphic Relations

Why should you use it? Check out the below post to illustrate the benefit with a real example:

End-To-End Polymorphism: From Database to UI, Achieving SOLID Design

Edge Support

This is a surprising gift we received from Prisma. Previously, when a user asked if ZenStack could run on Edge, we would direct them to the Prisma Accelerate proxy, as it was the only way to do it. However, not all users are willing to use another service. This situation is frustrating for us because, unlike resolving polymorphism, we can't fully address it from ZenStack unless reimplementing the entire Prisma engine.

Fortunately, Prisma sent us a fantastic gift at the start of 2024. Without hesitation, we began tweaking ZenStack to ensure its compatibility with the edge runtime. Even though the workload is minimal compared to polymorphism, we gained substantial knowledge throughout the process. If you're also planning to adapt to the Edge runtime, we hope our experience can save you some time:

Adapting ZenStack to the Edge: Our Struggles and Learnings

By the way, Edge support is in preview for both Prisma and ZenStack, so if you run into any issues, feel free to contact us via Twitter, Discord, or GitHub.

`Auth()` in `Default()`

This is a very special feature. The brilliant idea came from one of our users at a very early time:

Support for auth() in @default annotation #310

The best part is that right before we started to consider whether to implement it in V2, another user sent out a PR for it:

Support for auth() in @default attribute #958

This is the first feature of ZenStack that is fully implemented by the community. We would like to express our gratitude by sharing the author’s GitHub profile link here.

It once again shows the benefit of using declarative schema to reduce the duplication of imperative code:

before

//schema.zmodel
model Post {
  ...
  owner User @relation(fields: [ownerId], references: [id])
  ownerId Int
}

//xxx.ts
const db = enhance(prisma, { user });
await db.post.create({
  data: {
   owner: { connect: { id: user.id } },
   title: 'Post1'
  }
})

after

//schema.zmodel
model Post {
  ...
  owner User @relation(fields: [ownerId], references: [id])
  ownerId Int @default(auth().id) // <- assign ownerId automatically
}

//xxx.ts
const db = enhance(prisma, { user });
await db.post.create({ data: { title: 'Post1' } });

VSCode Auto-Formatting

This is the feature I regret the most. In fact, I would call it a fix instead of a feature because I did implement it in V1:

// Detect dark theme var iframe = document.getElementById('tweet-1720036341642154260-732'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1720036341642154260&theme=dark" }
I mentioned "minimize disruptions for prisma users", but you know what? It was actually a lie. Although I tried to make ZModel look as same as Prisma, it used a different indentation style:

Which one do you think looks better? 😉 I convinced myself that the left one was better due to its consistency with TS style. Why need consistency with TS? Because it includes the access policy code.

It turns out that all of that was just an excuse to avoid making changes. Even when I realized it soon, I found another excuse that the change would disturb existing users. You can see how skilled our mind is at finding excuses to avoid work. However, it struggles to estimate the actual workload accurately because it attempts to avoid it.

The total time I spent to implement it is just a couple of hours which even includes flags both in VSCode extension and CLI to give the user the option to preserve the old style if he likes:

Usage: zenstack format [options]

Format a ZenStack schema file.

Options:
  --no-prisma-style  do not use prisma style

Don't let inertia obscure the truth; use your heart to find the right path and pursue it.

Final Words

You can find the complete change detail in the below post:

Upgrading to V2

In the Game of Thrones series finale, Tyrion Lannister said the following words:

What unites people? Armies? Gold? Flags? Stories. There's nothing in the world more powerful than a good story.

These features will probably be forgotten as time passes or even not used at all by most people. But I hope the stories behind them could still have some meaning for you.

End-To-End Polymorphism: From Database to UI, Achieving SOLID Design

JS — Thu, 28 Mar 2024 10:22:55 +0000

Polymorphism Is the Key To Open-Closed Principle

The three fundamental pillars of Object-Oriented Programming(OOP) are Encapsulation, Inheritance, and Polymorphism. Polymorphism is likely the least-mentioned concept, possibly because this term is not frequently used in daily life. However, it is the most important one because it is the key to achieving compliance with the Open-Closed Principle (OCP) in OOP.

The Open-Closed Principle is one of the five SOLID principles of object-oriented design. It states that software entities should be open for extension but closed for modification. This means that you should be able to extend the behavior of a system without modifying existing code. I always treat this as one of the ultimate goals in software design as it fosters flexibility, extensibility, and maintainability for the system.

I have no doubt that you have already benefited from it in your backend or frontend code. But have you considered database modeling? What’s the benefit you could get from it? Let me illustrate it with a real example, from the database to the UI.

A Classical Feed System

Let's use a typical news feed system as an example, which you can think of as a simplified version of Twitter.

You can create or delete a post.
You can publish or unpublish a post. When published, other logged-in users can view it.
You can like or unlike a post. Each post displays its total like count and its author.

You know what, there's already one there 😉

https://github.com/zenstackhq/docs-tutorial-nextjs

It is built using Next.js and ZenStack.

If you haven’t heard about ZenStack, it supercharges Prisma ORM with a fine-grained Authorization layer, auto-generated type-safe APIs/hooks to unlock its full potential for full-stack development.

The content now only supports posts with text. Here comes the polymorphic part, let’s try to add support for image and video. Regardless of the programming language you're using, you could definitely model it in your code like this:

However, it might not be that straightforward at the database layer.

Database Modeling

Thanks to Prisma, the entity used to model the database appears similar to the Type or Class used in the code. Here is the definition for the existing Post :

model Post {
  id String @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title String
  published Boolean @default(false)
  author User @relation(fields: [authorId], references: [id])
  authorId String

  // author has full access
  @@allow('all', auth() == author)

  // logged-in users can view published posts
  @@allow('read', auth() != null && published)
}

The bottom part is the access control policy, with which it could directly generate the secured type-safe front-end hooks.

Unfortunately Prisma hasn’t supported polymorphism yet. As such, you can't use inheritance to model the entity in the same way as in your programming language, as depicted in the above class diagram. The good news is that we could imitate it using table inheritance.

Table Inheritance

Without inheritance, what else can we rely on to establish relationships between different models? Of course, it is the foreign key, the reason we refer to it as a relational database. So let’s refactor our existing Post model as below:

model Content {
  id String @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  published Boolean @default(false)
  author User @relation(fields: [authorId], references: [id])
  authorId String
  contentType String // discriminator indicates the specific type 
  likes Like[] // like is added here for all kinds of content
  post Post?  // 1-1 relation with Post
  // author has full access
  @@allow('all', auth() == author)

  // logged-in users can view published posts
  @@allow('read', auth() != null && published)
}

model Post {
  id String @id @default(cuid())
  title String
  content Content @relation(fields: [id], references: [id], onDelete: Cascade, onUpdate: Cascade)

  // author has full access
  @@allow('create,delete', auth() == content.author)
  // logged-in users can view 
  @@allow('read', auth() != null)
}

Content would be the base model with the common data and access policy for all the different kinds of feed type.
contentType is added to indicate the concrete type that this content record represents. The value should be the model name of the concrete type, such as Post.
Each concrete feed type model like Post has a one-to-one relation with Content. It has its own specific data like title for a post feed.
In concrete type, the access policy needs to reference the Content model to check the author because it has been moved there.
The new One-to-Many relation with Like model is added to the Content model.

So let’s try to add a new Image feed type, here is what we need to change:

model Image {
  id String @id @default(cuid())
  url String
  content Content @relation(fields: [id], references: [id], onDelete: Cascade, onUpdate: Cascade)

  // if 
  @@allow('create,delete', auth() == content.author)
  // logged-in users can view 
  @@allow('read', auth() != null)
}

model Content {
   ...
   image Image?  // add 1-1 relation with image 
   ...
}

Thanks to the table inheritance, we don’t have to duplicate all the common fields that have been moved into the Content model. Having said that, you can still see some repetitive things that need to be done for every new concrete type:

Need to add the content relation field for each new type.
Need to add the reversed relation field in Content model.
Has to define the same access policy rule for each concrete type.

💡 pain-point 1: I will show you how to address them later. 😉

Backend

Nothing needs to be done here. Seriously, it's not a joke. ZenStack directly generates API and frontend hooks according to the schema. So let’s jump to the frontend.

Frontend

Use `Content` to handle all the common behavior

Read all the content
```
  // list all contents that're visible to the current user
  const { data: contents } = useFindManyContent(
    {
      include: {
        author: true,
        post: true,   
        image: true,
        ... /// list all the concrete content type here**
      },
      orderBy: { createdAt: "desc" },
    },
    // fetch only when user's logged in
    { disabled: !session?.user }
  );
```
The useFindManyContent is auto-generated by ZenStack, and it inherits the best type-safety DX Prisma client API provided. For example, you can use include to get the concrete content type data in a single query. And the best part is that the return type will match exactly according to your query:

The benefit is that if you try to access the field from a concrete type without include it in this query, you will see the error instantly:

On the other hand, when adding a new concrete type, you always need to modify this query to include the new type
💡 pain-point 2: I will show you how to address them later. 😉

Update content

  async function onTogglePublished(content: Content) {
    await updateContent({
      where: { id: content.id },
      data: { published: !content.published },
    });
  }

  async function onToggleLike(content: Content, isLiked: boolean) {
    if (isLiked) {
      await deleteLike({
        where: {
          authorId: user.id,
        },
      });
    } else {
      await createLike({
        data: {
          contentId: content.id,
          authorId: user.id,
        },
      });
    }
  }

Delete content
```
  async function onDelete(content: Content) {
    await deleteContent({ where: { id: content.id } });
  }
```
Thanks to the Cascade relation, we can simply delete the content, and database will take care of deleting the concrete type.

Handle Concrete Type

Create

  async function onCreatePost() {
    const title = prompt("Enter post title");
    if (title) {
      await createPost({
        data: {
          title,
          content: {
            create: {
              contentType: "Post",
              authorId: user?.id,
            },
          },
        },
      });
    }
  }

When creating concrete content, you first need to create the Content type to maintain the foreign relation. Thankfully, due to the fine-grained API, you don't have to do this separately.

Have you noticed that you need to hard-coded the correct contentType here?

💡 pain-point 3: I will show you how to address them later. 😉

Render the concrete content

        {contents?.map((content) => {
          let concreteContent = <></>;
          if (content.contentType == "Post") {
            concreteContent = <span>{content.post?.title}</span>;
          } else if (content.contentType == "Image") {
            concreteContent = (
              <Image src= {content.image?.url || ""} alt={content.id} />
            );
          }
          ...
         }

Since we have retrieved all the content data above, we can use contentType discriminator to decide how to render it.

Despite its simplicity, the if-else branch logic in the code is very error-prone. You have to ensure that the data accessed, such as content.post?.title, matches the literal string "Post" specified in the if condition. TypeScript has no knowledge of this, which is why the nullable operator is necessary whenever accessing the concrete type field.

💡 pain-point 4: I will show you how to address them later. 😉

Polymorphism at Database

By utilizing table inheritance, we managed to avoid repetition to some extent. However, do you still remember the issues we encountered? Would they have been resolved if polymorphism were available at the database level?

Action speaks louder than words, let's do it! Although Prisma has not yet supported polymorphism, ZenStack, as a believer in Prisma, has taken the initiative to add it in the V2 beta version through a unique approach. You can find all the details in the document below:

Polymorphic Relations | ZenStack

Real Inheritance Between Models

With the extend keyword introduced by ZenStack, now in schema, you can use real inheritance between the models:

model Content {
  id String @id @default(cuid())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  published Boolean @default(false)
  author User @relation(fields: [authorId], references: [id])
  authorId String
  contentType String
  likes Like[]
  @@delegate(contentType)

  // author has full access
  @@allow('all', auth() == author)

  // logged-in users can view published posts
  @@allow('read', auth() != null && published)
}

model Post extends Content {
  title String
}

model Image extends Content {
  url String
}

Let's review the pain-point 1 we had using the new approach.

~~Need to add the content relation field for each new type.~~
~~Need to add the reversed relation field in Content model.~~
~~Has to define the same access policy rule for each concrete type.~~

✅ pain-point 1 is resolved.

The practical benefit it brings is that when you need to add a new Type, such as Video, here is all you need to change:

model Video extends Content {
  url String
  duration Int
}

The Open-Closed Principle is perfectly achieved here.

Union Type

Let's return to the place where we retrieve all the contents:

  // list all contents that're visible to the current user
  const { data: contents } = useFindManyContent(
    {
      include: {
        author: true,
        likes: true,
      },
      orderBy: { createdAt: "desc" },
    },
    // fetch only when user's logged in
    { disabled: !session?.user }
  );

Have you noticed the difference? We no longer need to specify all the concrete types in the include properties. We have once again adhered to the Open-Closed Principle. ✌️

✅ pain-point 2 is resolved

How this is achieved? if you look at the return type of useFindManyContent you will know why:

In generated types/functions, Content is actually a union type of all the delegated concrete types:

Type Content = ({ contentType: 'Post' } & Post) 
  | ({ contentType: 'Image' } & Image) 
  | ...;

This is another missing feature of Prisma: https://github.com/prisma/prisma/issues/2505

So that TypeScript's type narrowing can work its magic for the following code:

      if (content.contentType == "Post") {
        concreteContent = <span>{content.title}</span>;
      } else if (content.contentType == "Image") {
        concreteContent = (
          <Image src= {content.url || ""} alt={content.id} />
        );
      } 
      ...

Right, this is the rendering logic we see above. All the field access here is completely typesafe now.

✅ pain-point 4 is resolved.

There's one pain-point remaining when creating content. Let's examine what it looks like now:

  async function onCreatePost() {
    const title = prompt("Enter post title");
    if (title) {
      await createPost({ data: { title, authorId: user.id } });
    }
  }

Now you can totally forget about the existence of Content at all, just create a Post as it is.

✅ pain-point 3 is resolved.

How is this achieved? Besides the extend keyword, a new attribute @@delegate(contentType) has been added to mark the base model. It delegates field access to concrete models as needed. For example, when trying to create a Post instance, it knows it has to first create an associated Content and set the contentType to Post.

Polymorphic UI Components

All the pain-points have been resolved, what else is left? Let’s take a look at the render part:

      if (content.contentType == "Post") {
        concreteContent = <span>{content.title}</span>;
      } else if (content.contentType == "Image") {
        concreteContent = (
          <Image src= {content.url || ""} alt={content.id} />
        );
      } 
      ...

Although it's now type-safe, this typical if-else branch definitely violates the Open-Closed Principle. Whenever you add a new type, you must add a new else-if statement here. Let’s see how we can use polymorphism to address it.

Firstly, let’s create a UI component for each concrete type.

export const Post = ({ content }: { content: Content }) => {
  const post = content as Post;
  return <span>{post.title}</span>;
};

export const Image = ({ content }: { content: Content }) => {
  const image = content as Image;
  return (<Image src= {image.url || ""} alt={image.id} />);
};

The content prop contains all the information for this specific type instance, which can be used for rendering.

Consider how you typically eliminate large if-else statements in coding. A straightforward approach is to use a dictionary instead:

const componentLookup: {
  [key: string]: (content: { content: Content }) => JSX.Element;
} = {
  Post
  Image
  // Add other components here...
};

const PolymorphicContent = ({
  componentName,
  content,
}: {
  componentName: string;
  content: Content;
}) => {
  const Component = componentLookup[componentName];
  return Component ? <Component content={content} /> : null;
};

For the rendering part, we can allow PolymorphicContent to decide which component to render based on the contentType.

   <div>
      <PolymorphicContent
        componentName={content.contentType}
        content={content}
      ></PolymorphicContent>
      <p className="text-lg"> by {content.author.email}</p>
    </div>

Now, whenever you add a new concrete type, all you need to do, besides creating a new component, is to add the component to the componentLookup. Isn’t it good enough?

No, it still violates the Open-Closed Principle as you must modify the existing code, and ensure the Component has the same name as your concrete type. Let’s see how we can resolve it.

Ultimate Polymorphism

To avoid manually defining the componentLookup dictionary, we can utilize the import mechanism of TypeScript to do that for us.

Let's create new content-components.tsx file and transfer the Post and Image UI components into it. After doing so, you can use the import * to get that dictionary.

import * as ContentComponents from "./content-components";

Awesome! Let’s make a final tweak to get to the Eden：

const PolymorphicContent = ({
  content,
}: {
  content: Content;
}) => {
  const Component = ContentComponents[content.contentType];
  return Component ? <Component content={content} /> : null;
};

We can directly use content.contentType to get the appropriate UI component. It is a union type of all the specific type names:

type contentType = 'Post' | 'Video' | ...

Now, you don't need to worry about mismatches between the UI component name and the concrete type name defined in the schema. For instance, if you add a new Video type to the schema, but you haven't added a UI component with the same name in content-components.tsx, TypeScript is smart enough to let you know it:

Property 'Video' does not exist on type 'typeof import("/content-components")'.

Conclusion

I must say thank you for walking this long road with me to reach here. However, I believe this is not even worth mentioning compared to the lifelong path of pursuing excellence in software design as a good software engineer.

So, here's the final complete project for you, hope it can be some help for you:

GitHub - zenstackhq/docs-tutorial-nextjs at polymorphic

What Are the Chances of You Creating a Programming Language

JS — Wed, 07 Feb 2024 08:58:46 +0000

If I asked what’s your favorite words of Steve Jobs, I believe most people would say:

Stay Hungry. Stay Foolish

It’s coming from the 3rd story of the speech he gave at Stanford. But my favorite one is coming from the first story:

Connecting the Dots

Would You Ever Create a New Language?

Does the below content look familiar to you?

If you have studied computer science before, it should be. This is the content from the classic Dragon Book:

Even if your school adopted a different textbook for the Compiler Principles course, the concept of DFA is a cornerstone that you can't forget. Or does it? 😄

If this course were not compulsory for our major, I doubt how many students would choose to take it. Not only is it challenging to learn, but also from a pragmatic perspective:

What are the chances of us creating a new programming language in the workplace?

Therefore, the motivation for many students is just to pass the exam and to get the credit. Some of them ended up getting a good score on the final exam due to the excessive practice of manual deduction of the regular expression, NFA, DFA, BNF, etc. However, few of them are actually interested in how a programming language is constructed from the ground up.

I also had that doubt. But for me, it was the first time I ever felt the science part of my major. Honestly, I never expected to have the opportunity to create a language either. However, somehow it did attract me to learn it rather than pass it. Perhaps it's because I feel relieved to understand the principles behind the tools I'll likely use throughout my career.

With hindsight, now I would say:

You Never Know What Would Happen

During my last year of graduate school, I was lucky to get an internship at Microsoft. The even more lucky part is that the team I joined was building a new DSL(Domain Specific Language) for protocol.

Initially, I worked on an output adapter that generates documents from the parsed Abstract Syntax Tree (AST). After a while, my leader assigned me a new task to investigate the possibility of rewriting the current LR parser with a new Recursive-Descent parser. I guess that due to my previous devotion to Compiler Principles, it didn't take as much time as they had expected for me to obtain the result.

I still remember the day when the architect of my team reviewed my prototype with me one-on-one. In general, he affirmed my approach and provided some guidance and suggestions. Although it's just him and me because all the other team members are going off-site, that was the best moment in my internship.

I thought the job was done for me, the next step would be assigning a full-time employee to write the production code. To my surprise, I’m the one who put it into production. I assume that’s the main reason why I finally got the offer to join Microsoft.

I Would Never Write Front-End Code

As a backend developer with over 10 years of experience, I never imagined that I would write any front-end code. This is not only because front-end and back-end development require different skill sets, but also because I believe that having a good sense of visual aesthetics is a crucial quality for front-end developers, which I lack. However, there is a significant shortage of developer resources for the new SaaS product we were building in my previous company. As a result, I had to write front-end code.

Although the view still stands that I would never be a good front-end developer, it is that experience that opened the door to full-stack development for me. I could see the knowledge gap between front-end and back-end developers, which makes it inefficient to deliver features end-to-end for complex web apps.

The Dots Are Connected

If you investigate some successful software, you will notice that many of them are created due to the pain point of the creators themselves. The underlying logic is easy to understand:

You need to be the customer of your own product to make it right.

The reason why we created ZenStack is the same as the experience above. We have felt many pain points that significantly slowed down product delivery from end-to-end during that time. Therefore, it gave us a strong motivation to explore the tooling & infrastructure space and find ways to improve efficiency.

The DSL experience comes naturally to us as we have witnessed how well-designed language can greatly simplify programming tasks. We know it is challenging, but not as difficult as many may feel. Therefore, we chose the schema-first design to create ZenStack toolkit on top of Prisma ORM that leverages code generation to significantly reduce the code developers need to write and make them move a lot faster.

Check out the details of how we built it:

How Much Work Does It Take to Build a Programming Language?

Allow It and Make the Magic Happen

Despite ZenStack being relatively young, it has already integrated with various types of stacks:

Sometimes we were questioned if we were a little unfocused. The short answer to that is that we haven’t figured it out clearly, so we have to give it a try.

Here, I would like to use Steve Jobs’s words to answer it:

Again, you can’t connect the dots looking forward; you can only connect them looking backward. So you have to trust that the dots will somehow connect in your future. You have to trust in something — your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.

What Will Happen to the Full-Stack Framework in the Future?

JS — Thu, 21 Dec 2023 12:18:43 +0000

Don't Reinvent the Wheel

As software developers, we are all familiar with the phrase "Don't reinvent the wheel". However, I have heard many complaints that the Javascript world seems to do the exact opposite. 😂

From the positive side of the coin, there are always abundant choices at almost every level from the bottom up:

Runtime: Node.js, Deno, Bun
Package Manager: Npm, Pnpm, Yarn
Bundler: Webpack, Rollup, Parcel, Vite, Turbopack
UI Framework: React, Vue, Svelte, Angular
FullStack framework: Next.js, Remix, Nuxt, Sveltekit

The negative side is that developers, especially those with less experience, may feel overwhelmed and caught in the crossfire of choices. The recent debate between Remix and Next.js camps could well illustrate that:

Why I Won't Use Next.js

Why I'm Using Next.js

Although there are quite a few opinionated battery-included frameworks that have picked up everything for you like RedwoodJS, Blitz, and Create-T3-App, you still need to choose between them and hope that they will remain mainstream and well-maintained in the future. So how should we choose?

In the book The 7 Habits of Highly Effective People, the habit that resonates most with me is the second one:

Begin With the End in Mind

When we find ourselves lacking a clear vision in the present, one effective strategy is to envision what the framework could potentially evolve into in the future.

Features of the Future Framework

Abstraction of the Data Layer

Bezos has a famous quote about the success of Amazon:

So people today want fast shipping. And they’re going to want faster and faster shipping in 10 years… so that’s going to matter today and tomorrow.

It means focusing on things that don’t change. While technologies and methodologies continuously shift and evolve, the fundamental need to store, manage, and retrieve data consistently persists. So you still need to have at least a database to achieve so.

Even now, fewer full-stack developers are willing to directly talk with databases through the complexities of SQL queries and database schema management, let alone the ones that come from the front-end world. Therefore ORM has already been the standard kit for the existing framework. For instance, all three frameworks mentioned above have adopted Prisma ORM.

Furthermore, when it comes to scaling an application, it's common to think about the complexity of the code. However, in reality, the underlying data layer is often the root cause of scaling issues. If the data layer is tightly coupled with the application code, and as the application grows, the relationships between data entities become increasingly complex and difficult to manage. This challenge is even more pronounced in a full-stack environment where the frontend and backend are tightly coupled. Therefore, the abstraction layer that ORM provides ensures consistency across different layers of the application and facilitates efficient communication between the frontend and backend.

Write Less Code and Utilize Code Generation

Writing less code not only saves time and energy from developers but also makes the application better to scale and maintain:

a hundred lines of code is easier to scale than a thousand lines of code

That’s exactly the job of the framework to handle more things that used to be implemented by ourselves like Routing, Data Fetching, Rendering Error Handling, etc.

“Writing less boilerplate code” has become the slogan for almost every framework. They usually provide the scaffold CLI to generate all kinds of stuff for you, including those that were previously considered essential like API.

Since the ORM has defined the data models, which include the data types, relationships, and constraints, it could automatically generate meaningful APIs from it. It allows developers to gain more bandwidth to concentrate on the business logic instead of dedicating manual API implementation.

For example, RedwoodJS generates the GraphQL API using the types generated from Prisma. If you are using ZenStack, which is built on top of Prisma, it can generate both RESTful-style and RPC-style APIs with Swagger documentation or tRPC routers.

More Declarative for AI

Austrian economist Joseph Schumpeter is most known for coining the phrase "creative destruction" which describes the process that sees new innovations replacing existing ones that are rendered obsolete over time. The analogy could be:

no matter how much improvement is made to a wagon, it can never become a car.

Since we are discussing the next generation of the framework, we would like to see some innovations that can significantly improve productivity, similar to the leap from a wagon to a car.

What is the strong force that could make this happen? Take a look at the list of the new YC batch W24, and you will find out 😄

The YC Startup Directory | Y Combinator

Yes, definitly AI. I think the more declarative the framework could be, the better AI could understand the application and help to manipulate it as much as possible. The reason is that the declarative approach is a paradigm where you write code by describing WHAT you want to do rather than HOW. That’s exactly what we are talking to ChatGPT every day.

You can find a POC from the declarative framework Wasp:

MAGE GPT Web App Generator ✨ MageGPT

Of course, these are just some aspects I think are important. I would love to hear your thoughts or any opposing viewpoints. Please feel free to leave comments or reach out to me on Twitter!

Contributing To Open Source Projects Might Be Easier Than You Think

JS — Tue, 05 Dec 2023 13:52:17 +0000

As a software developer, you may not have directly participated in any open-source project, but you have likely benefited from the open-source world unless you don't use Git, GitHub, or Linux. 😄 In return, many of us would like to contribute and be a part of this new wave of collaborative and transparent development.

However, many people have not taken their first step because the process of contributing can be intimidating.

How to find a suitable issue to contribute?
How to confirm with the maintainer that this is actually what they want?
How to make sure my solution is the right way to go?
Do I need to add some test cases or documentation?
What if something goes wrong?

First of all, due to the nature of human beings, we tend to exaggerate difficulties before attempting a new task. Even leave it alone, here lies a common misconception about contributing to open-source projects:

You need to contribute code

While code contributions are undoubtedly valuable, they represent just one facet of the broader landscape of open-source collaboration. There are other ways you might make an even greater contribution than code.

What It Means To Contribute

I wrote a post about implementing a high-concurrency ticket booking system leveraging on Optimistic Concurrency Control (OCC):

How To Build a High-Concurrency Ticket Booking System With Prisma

JS for ZenStack ・ Sep 18 '23

#webdev #database #performance #typescript

Many people are impressed by the concise code by Prisma or ZenStack to achieve that:

    await client.seat.update({
        data: {
            userId: userId,
            version: {
                increment: 1,
            },
        },
        where: {
            id: availableSeat.id,
        },
    });

What they might not know is that it’s not possible before Prisma 4.5.0 because of the below issue:

Be able to update or retrieve a single record including non-unique fields in the "where" conditions. #7290

ksmithut posted on May 26, 2021

Problem

I am unable to utilize non-unique fields in single update queries. To be clear, I want to still use the unique fields, I just want to filter it down even more.

Alternatives

One alternative is to do a .findUnique({ where: { id: input.clientId } }) and then check if the personId of the client is the same as the one passed in. This however creates two database calls where only one is needed.

Another alternative is to do a .updateMany({ where: { id: input.clientId, personId: input.personId } }) but I don't get any of the clients back. If I got the clients back in the query and if there was a limit I could pass in to limit it to one, I would feel better about this so it wouldn't have to do any unneeded scans of the rows, but it still feels less idiomatic than updating the .update() command to allow for non-unique fields.

View on GitHub

Before that you have to use updateMany followed by the count check as below:

const seats = await client.seat.updateMany({
  data: {
    claimedBy: userEmail,
    version: {
      increment: 1,
    },
  },
  where: {
    id: availableSeat.id,
    version: availableSeat.version, 
})

if (seats.count === 0) {
  throw new Error(`That seat is already booked! Please try again.`)
}

Although a little verbose, it works. However, before Prisma 4.4.0, it was unable to function due to the issue described below:

`updateMany()` causes lost-updates #8612

boiledfroginthewell posted on Aug 06, 2021

Bug description

updateMany() returns incorrect updated counts when multiple processes or asynchronous functions run simultaneously.

The SQL log of updateMany() shows it emits SELECT and then UPDATE. Since prisma uses the default isolation level of DBMS, those queries are NON-REPEATEBLE READ in many DBMS and can cause lost-updates. I believe SELECT ... FOR UPDATE or single query UPDATE .... WHERE ... is required.

How to reproduce

bookSeat.js

const {PrismaClient} = require('@prisma/client')

const client = new PrismaClient({
  // log: ["query"]
})


async function bookSeat(userId) {
  const movieName = 'Hidden Figures'

  // Find the first available seat
  // availableSeat.version might be 0
  const availableSeat = await client.seat.findFirst({
    where: {
      // Movie: {
      //  name: movieName,
      // },
      claimedBy: null,
    },
    orderBy: [{id: "asc"}]
  })

  if (!availableSeat) {
    throw new Error(`Oh no! ${movieName} is all booked.`)
  }

  // Only mark the seat as claimed if the availableSeat.version
  // matches the version we're updating. Additionally, increment the
  // version when we perform this update so all other clients trying
  // to book this same seat will have an outdated version.
  const seats = await client.seat.updateMany({
    data: {
      claimedBy: userId,
      version: {
        increment: 1,
      },
    },
    where: {
      id: availableSeat.id,
      version: availableSeat.version, // This version field is the key; only claim seat if in-memory version matches database version, indicating that the field has not been updated
    },
  })

  if (seats.count === 0) {
    throw new Error(`That seat is already booked! Please try again.`)
  }

  return seats.count
}


async function demonstrateLostUpdate() {
  if (process.argv[2] === "createData") {
    await client.seat.deleteMany()
    for (let i = 0; i < 1000; i++) {
      await client.seat.create({
        data: {
          id: i,
          version: 0,
          movieId: 1,
          claimedBy: null,
        }
      })
    }
    process.exit()
  }


  const userId = process.argv[2]

  let updatedCount = 0
  for (let i = 0; i < 1000; i++) {
    try {
      updatedCount += await bookSeat(userId)
    } catch {
      // ignore lock failure
    }
  }


  // Detect lost-updates
  const actualCount = await client.seat.count({
    where: {
      claimedBy: userId
    },
  })
  console.log({
    userId,
    updatedCountByUpdateMany: updatedCount,
    actualUpdatedCount: actualCount
  })
  process.exit()
}

demonstrateLostUpdate()

With the above script, run

$ node bookSeat.js createData
$ node bookSeat.js Sorcha & node bookSeat.js Ellen

The schema and logic in the script are taken from the optimistic concurrency control example in the doc: https://www.prisma.io/docs/guides/performance-and-optimization/prisma-client-transactions-guide#optimistic-concurrency-control

Outputs:

{
  userId: 'Sorcha',
  updatedCountByUpdateMany: 968,
  actualUpdatedCount: 461
}
{
  userId: 'Ellen',
  updatedCountByUpdateMany: 974,
  actualUpdatedCount: 539
}

Expected behavior

updatedCountByUpdateMany should be equal to actualUpdatedCount in the outputs.

Prisma information

schema.prisma:

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model Seat {
  id        Int   @id @default(autoincrement())
  userId    Int?
  // claimedBy User? @relation(fields: [userId], references: [id])
  claimedBy String?
  movieId   Int
  // movie     Movie @relation(fields: [movieId], references: [id])
  version   Int
}

SQL query Logs of repro:

prisma:query SELECT "public"."Seat"."id", "public"."Seat"."userId", "public"."Seat"."claimedBy", "public"."Seat"."movieId", "public"."Seat"."version" FROM "public"."Seat" WHERE "public"."Seat"."claimedBy" IS NULL ORDER BY "public"."Seat"."id" ASC LIMIT $1 OFFSET $2 prisma:query BEGIN prisma:query SELECT "public"."Seat"."id" FROM "public"."Seat" WHERE ("public"."Seat"."id" = $1 AND "public"."Seat"."version" = $2) prisma:query UPDATE "public"."Seat" SET "claimedBy" = $1, "version" = ("version" + $2) WHERE "public"."Seat"."id" IN ($3) prisma:query COMMIT

Environment & setup

OS: Mac OS
Database: PostgreSQL
Node.js version: v14.17.0

Prisma Version

Environment variables loaded from .env
prisma               : 2.28.0
@prisma/client       : 2.28.0
Current platform     : darwin
Query Engine         : query-engine 89facabd0366f63911d089156a7a70125bfbcd27 (at node_modules/prisma/node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli 89facabd0366f63911d089156a7a70125bfbcd27 (at node_modules/prisma/node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core 89facabd0366f63911d089156a7a70125bfbcd27 (at node_modules/prisma/node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt 89facabd0366f63911d089156a7a70125bfbcd27 (at node_modules/prisma/node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : 89facabd0366f63911d089156a7a70125bfbcd27
Studio               : 0.417.0

View on GitHub

The issue was filed when it was already listed as an example of Optimistic Concurrency Control (OCC) in the official documentation of Prisma (which is still present today). Therefore, before it was fixed, the Prisma team had to temporarily add a warning to the documentation at that time.

After closely examining the threads of the two mentioned issues, I believe you would agree that Prisma team implemented the fix as a result of conversations and discussions among actively involved community members. If you are the maintainer of Prisma, would you consider these people as contributors? Regardless of your opinion, GitHub will do:

Issues, pull requests and discussions
Issues, pull requests, and discussions will appear on your contribution graph if they were opened in a standalone repository, not a fork.

Feedback Might Be More Valuable Than PR

I recently listened to a talk by Tanner Linsley, the creator of TanStack (React Query), about his personal experience in the open-source community. I highly recommend listening to it:

Open Source Hour with Tanner Linsley

During the interview, the hoster asked him a question:

What types of contributions do you find most valuable for your projects

Here is the simplified version of his answer:

The most valuable contributions are at kind of the leaf node level. It’s the gentle feedback of

I tried following the documentation or I tired doing this and it didn’t work

I got confused or I’m stuck It may not be feedback that makes it all the way out of the library.

And once in a while, you will get people who go above and beyond and propose something, either a documentation change itself or maybe an API change. I feel like it's an exponential falloff. There are so many people who are willing to offer their two cents on, it didn't work. Most people beyond that aren't going to help you out; they are just going to kind of dine and dash.

Only one percent of those people are going to open a PR. Those are great, but usually, they require guidance from the core maintainers to say: "We would love to do that, but we can't do it that way because of XYZ." And I feel like less than 10 percent of those people will stick to the PR. Those are the people you need to nurture and pay attention to.

contributions come in many forms.

Open Source Contributions Go Beyond Code

Open source projects are more than just code. They provide a collaborative space where people can report problems, ask questions, and suggest fixes or improvements, among other things. So, if you notice anything wrong or feel that something could be better or different in the project you already use or want to use, don't hesitate to let the community hear your voice.

ZenStack is an open-source toolkit that we are developing on top of Prisma ORM. It provides an innovative schema-first approach for building web applications. If you feel that it could be helpful for you, simply trying it out and letting us know your thoughts would be a great contribution to us!

How To Get Type-Safe Frontend Queries Like GraphQL Without GraphQL Using TypeScript

JS — Tue, 24 Oct 2023 09:58:16 +0000

Fading of API

I previously wrote a post about the history of APIs:

A Brief History of API: RPC, REST, GraphQL, tRPC

JS for ZenStack ・ Jan 11 '23

#discuss #ai #blockchain

I still believe that GraphQL is the most efficient solution for a big project with separate or multiple front-end and back-end teams. However, after my partner and I left our last company, it was mainly just the two of us working on the full-stack project. Therefore, we prefer to leverage the "integrated" APIs of full-stack frameworks like getServerSideProps, loader, and load functions (I bet at least you know one of them 😄). When necessary, we will use tRPC as a complementary. The overall experience is quite neat as you almost forget about API design and implementation.

Miss the Benefit of GraphQL

However, there is one feature listed on the front page of GraphQL's official website that I miss very much:

Ask for what you need, get exactly that

The even better thing is that by adopting tools like GraphQL Code Generator, you can obtain the exact type you request without executing the code, thanks to the powerful type inference of TypeScript. This can be highly beneficial in real coding scenarios.

If you have ever worked with a REST API, you may have encountered a runtime error where a field is missing from the response, similar to the case of the director field mentioned above. With TypeScript, you can now receive an immediate compiler error instead, which fulfills the type-checking ability of TypeScript:

Fail fast, Fail often

Can I Implement It Myself Using tRPC?

Unfortunately, no. While you can make it work locally, the dynamicity of the return type is lost when exposed to tRPC due to its implementation details. If you are interested in more technical details about this, you can check out the post below:

Limitation of TRPC's Type Inference and How We Improved It

ymc9 for ZenStack ・ Jul 11 '23

#webdev #javascript #typescript #trpc

Enlightened by Prisma

After using TypeORM for many years, I switched to Prisma because of the excellent developer experience (DX) it provides, especially in terms of type safety. I'm thrilled to see that this capability has been incorporated into the Prisma client API.

Actually, you won’t be surprised if you know the original name of Prisma, Graphcool.

If you haven't read the post about tRPC limitations, you might be wondering why both GraphQL and Prisma are able to do something that tRPC cannot. The answer is simple: they both utilize code generation to overcome the limitations of type inference.

If Prisma could achieve that in the backend, it should technically be able to do the same thing in the frontend as well.

Here Comes ZenStack

ZenStack supercharges Prisma schema with an access control and validation policy. This additional layer enables the auto-generation of secure frontend query hooks. We should not miss the opportunity to bring the best part to the frontend. The generated hooks are mirrors of the Prisma client. Here is the same Todo query that you use in the frontend:

Not only can you obtain type-safe frontend queries like GraphQL, but you also get the same coding experience in both the frontend and backend. This aligns with the trend of blurring boundaries between them in modern full-stack development frameworks.

ZenStack generates queries that target either SWR or TanStack, making it compatible with a wide range of full-stack frameworks such as Next.js, Remix, SvelteKit, Nuxt, and more.

Easter Egg

ZenStack can also generate a tRPC router from the schema. During this process, we make a small tweak to overcome the limitations of tRPC. As a result, you can enjoy the same DX as Prisma client for our generated tRPC routers:

Trying to bring the best full-stack DX to the developer is one of the reasons we are building ZenStack. So if you have any suggestions or unfulfilled requirements, please feel free to discuss them with us:

ZenStack - Simplified Full-Stack Development with Prisma ORM | ZenStack

A TypeScript toolkit that enhances Prisma ORM with flexible Authorization and auto-generated, type-safe APIs/hooks, simplifying full-stack development.

zenstack.dev

DEV Community: JS

Turning Your Database Into an MCP Server With Auth

MCP is trending in AI, But…

The Advent of Authorization for MCP

MCP Is a Good Enhancement for SaaS

Two Approaches to Building an MCP Server

1. Relying on the Existing API

2. Start from Scratch

Building an MCP Server from Scratch

Initialize the Project

Auth

PasswordAuthProvider

Stateful Multi-connections Streamable HTTP Server

Tool

Schema

Execution

Test

How to Build AI Agents to Enhance SaaS With Minimal Code and Effort

Is SaaS Really Dead?

Challenge of Building an AI Chatbot

Schema-First Fit AI-First

Building an AI Chatbot from Scratch

1. Creating the project

2. Initialize the project for ZenStack

3. Implement Signup/Signin

4. Implement the chatbot logic with Vercel AI SDK and ZenStack

Try It for Your Own Application

Code as Doc: Automate by Vercel AI SDK and ZenStack for Free

Few developers like writing document

Generate document using AI

ZenStack plugin system

Use Vercel AI SDK to generate document

Generating structured data

Generate Mermaid ERD diagram

Stitch everything up

Off the shelf

Supabase RLS Alternative

Supabase RLS Alternative

JS for ZenStack ・ Jul 24

Supabase RLS Alternative

A Short History of BaaS

Firebase: The Pioneer

Supabase: The Open-Source Contender

ACL(Access Control Layer) is the Core

Firebase: Security Rules

Supabase: RLS(Row Level Security)

Multi-Tenancy SaaS Example

Database Model

RLS rules for List

The Problems of Supabase RLS

1.Separation from Application Logic

2. Poor DX

3. Scalability

4. Maintainability

Alternative Solution

1. Single Source of Truth

2. Good DX

3. Scalability

4. Maintainability

The Art of Trade-off

PHP: Laravel, Ruby: Rails, JavaScript:?

The Historical Reason

Contemporary Endeavor

Optimistic Future

Begin With the End in Mind

Stories Behind ZenStack V2!

Polymorphic Relations

Comment for #1644

Edge Support

Auth() in Default()

VSCode Auto-Formatting

Final Words

End-To-End Polymorphism: From Database to UI, Achieving SOLID Design

Polymorphism Is the Key To Open-Closed Principle

A Classical Feed System

Database Modeling

Table Inheritance

Backend

Frontend

Use Content to handle all the common behavior

`Auth()` in `Default()`

Use `Content` to handle all the common behavior