AI agents have moved beyond the experimental stage and are now being deployed in real-world applications. Unlike a traditional API endpoint, an agent can reason, make decisions and handle complex tasks on behalf of a user. This shift is exciting, but it raises important concerns about knowing exactly who is calling an agent and what they are allowed to do.

When an agent is built and deployed, it can be directly accessed by anyone. This can result in wrongful consumption of API credits, and it poses a significant risk in use cases where the agent is connected to sensitive tools such as databases, file systems and email systems. This is where authentication and authorization come into play. It is important to implement such security protocols to verify the identity and permissions of an agent’s users.

In this article, we’ll explore how to secure agents built with Mastra, a framework for building agents and other AI-powered applications. We’ll build a demo Next.js application integrated with a simple Mastra agent, then implement authentication and authorization using Firebase.

Prerequisites

To follow along with this article, you should have:

• Node.js v22.13.0 or later installed
• Basic knowledge of React and Next.js
• A Google account to set up Firebase
• An API key from a supported model provider

Why Security Matters for AI Agents

To understand why security matters here, let’s first understand what an AI agent actually is and how it differs from a regular application. A traditional application is fixed in its behavior. When an API endpoint is called, it runs a fixed block of code and returns a predictable response. There is no reasoning, no decision-making or any action other than what was explicitly programmed.

An AI agent is quite different. Instead of following a fixed preset, an agent receives an open-ended instruction and figures out how to fulfill it. It can reason about a problem, decide which tools to use, call those tools, interpret the results and take further action, all in a single interaction.

Now let’s talk about security. When you expose an API endpoint, you know exactly what it can do. On the other hand, when you expose an agent, the surface area is much wider. An agent connected to a database can read and write records. An agent connected to email can send messages on someone’s behalf. An agent connected to a payment system can initiate transactions. If an unauthorized person reaches that agent, they could potentially instruct it to do any of those things.

The more capable an agent is, the more important it is to control who can reach it and what it can be asked to do. Also, note that calls to AI agents mostly come at the expense of API credits, so it is important to regulate usage in order to avoid incurring unnecessary costs.

Authentication and Authorization

These two words are often used interchangeably and misplaced for each other. However, they mean different things and solve different problems.

Authentication answers the question “Who are you?” It verifies the identity of the person making a request. Generally, a user signs in, proves who they are, and receives a token that proves their identity on subsequent requests.

Authorization answers the question “What are you allowed to do?” It verifies that the authenticated user actually has permission to perform the action they’re requesting.

Why Firebase?

There are different ways to implement authentication and authorization on Mastra AI agents. In this article, we are using Firebase for several reasons. First, Firebase is a fully managed service. It abstracts away the complexity of OAuth flows, token signing, token expiration, session management and much more.

Next, with Firebase’s Firestore, we don’t need to set up a separate database just to store and manage user roles. Firestore is a natural place to store user roles because it is already in the Firebase ecosystem. Firestore also has built-in security rules, which means we can control and manage access.

Finally, Mastra has first-class support for Firebase through the @mastra/auth-firebase package. This means that protecting Mastra’s own internal server endpoints is straightforward and requires very little configuration.

Demo Setup

So far, we’ve touched briefly on what AI agents are, the need for security and why we’re using Firebase in this article. We can now start building our demo application to see how authentication and authorization can be implemented on Mastra AI agents using Firebase.

For the demo, we’ll build a simple prompt-and-response application that integrates with a Mastra agent under the hood. We’ll configure security beyond just agent protection. Security here is applied in four different layers.

Layer 1 redirects all unauthenticated users to the login page. At Layer 2, every request to the API route must carry a valid Firebase token. If it doesn’t, the request is rejected with a 401 error before anything else happens. This cannot be bypassed in the browser because it runs entirely on the server.

At Layer 3, once the token is verified and the server knows who the user is, it checks their role in Firestore. If their role does not qualify, the request is rejected with a 403 error. At this point, the agent has not even been triggered.

Layer 4, which is the core of this article, uses the MastraAuthFirebase class to apply the same Firebase token verification to Mastra’s own endpoints. Note that this security configuration can be approached in different ways. The most important thing is to properly define the MastraAuthFirebase class.

To get started, run the command below in your terminal to create a new Next.js application:

npx create-next-app@latest test-nextjs-agent

This creates a project called test-nextjs-agent. Feel free to rename the project, and complete the resulting prompts as shown below:

Run the following commands to navigate into the newly created project and start the development server:

cd test-nextjs-agent
npm run dev

Initialize Mastra

Open a new terminal and run the code below to initialize Mastra:

npx mastra@latest init

This installs the Mastra core dependencies and scaffolds the necessary folders and configurations without generating a new project from scratch.

In the resulting prompt when you run the command above, select a default model provider from the list provided. Here, we’ll use Google, but you can select any other provider of your choice.

There is also a prompt to provide the API key for the selected provider. Since we’re using Google, you can create and retrieve a new API key from Google AI Studio, as shown below:

You can skip this step, but you’ll need to create a .env file and define the API key manually, as shown below:

GOOGLE_GENERATIVE_AI_API_KEY=YOUR-GOOGLE-API-KEY

You should now see a new /mastra folder with some predefined files inside the /src folder. It is important to take note of the following files:

• /mastra/index.ts: This holds a Mastra instance, imported from @mastra/core/mastra.
• /mastra/agents/weather-agent.ts: Holds a test weather agent predefined by the Mastra team. The agent uses the google/gemini-2.5-pro model by default. For testing purposes, you can change that to google/gemini-2.5-flash, which is a less expensive model.
• /mastra/tools/weather-tool.ts: Contains a tool that fetches weather data and integrates with the weather agent.

We can see this agent in action by running this command in the terminal:

npx mastra dev

The command starts a server that exposes Mastra Studio and REST endpoints for your agents, tools and workflows. Open http://localhost:4111/ to access Mastra Studio, which has the test agent ready to be interacted with.

Our focus for this article is on agent authentication and authorization in Mastra using Firebase, so we won’t consider the inner workings of creating agents, tools, workflows and the rest. Instead, we’ll work with this predefined agent. However, you can explore the official documentation to learn more.

Integrating Mastra with Next.js

Since we now have our instance of Mastra up and running, we should be able to call it in our demo Next.js project.

Let’s create a chat API route. Create a src/app/api/chat/route.ts file and add the following to it:

import { mastra } from "@/mastra";
import { NextResponse } from "next/server";

export async function POST(req: Request) {
  const { message } = await req.json();

  if (!message) {
    return NextResponse.json({ error: "Message is required" }, { status: 400 });
  }

  const agent = mastra.getAgent("weatherAgent");
  const result = await agent.generate([{ role: "user", content: message }]);

  return NextResponse.json({ response: result.text });
}

The code above creates an API route that receives a message and has the agent instance generate a response based on the message. We’re intentionally keeping this route simple for demo purposes, with no streaming, memory, thread IDs, etc.

Next, let’s create a simple chat page on the frontend. Replace the contents of your src/app/page.tsx with the following:

"use client";

import { useState } from "react";

export default function Home() {
  const [message, setMessage] = useState("");
  const [response, setResponse] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSubmit = async () => {
    if (!message.trim()) return;
    setLoading(true);
    setResponse("");

    const res = await fetch("/api/chat", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ message }),
    });

    const data = await res.json();
    setResponse(data.response);
    setLoading(false);
  };

  return (
    <main className="flex min-h-screen flex-col items-center justify-center p-8 gap-6">
      <h1 className="text-2xl font-bold">Weather Agent</h1>
      <textarea
        className="w-full max-w-lg border rounded p-3 text-sm"
        rows={3}
        placeholder="Ask about the weather anywhere..."
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      <button
        onClick={handleSubmit}
        disabled={loading}
        className="bg-blue-600 text-white px-6 py-2 rounded disabled:opacity-50"
      >
        {loading ? "Thinking..." : "Send"}
      </button>
      {response && (
        <div className="w-full max-w-lg border rounded p-4 bg-gray-50 text-sm">
          {response}
        </div>
      )}
    </main>
  );
}

Here, we created a simple chat page where we can send a message and have the returned response rendered on the screen. Open http://localhost:3000/ in your browser to see the updated demo project.

Set Up Firebase

With our agent up and running, the next step is securing it. Right now, it is completely open, and when deployed, anyone with the URL can interact with it. To fix this, we’ll introduce Firebase as our authentication and authorization layer so that only verified users can access both the agent and the demo project as a whole.

Let’s start by setting up and configuring a Firebase project. Go to Firebase and create a new Firebase project. You can call it test-nextjs-agent or give it any other name you prefer.

On the left sidebar in the dashboard, go to Security → Authentication and click “Get started.”

Enable the Google sign-in provider, set a public-facing name and support email, and then click “Save.” You can also work with any other provider you prefer. For this demo, we’ll use Google.

Next, in the sidebar, go to Project Settings → General tab. Scroll down to “Your apps” and click the web icon (</>). Register a web app with any nickname.

Firebase will display a firebaseConfig object as shown below. Copy this object and save it, as we’ll be using it later:

const firebaseConfig = {
  apiKey: "...YOUR-API-KEY",
  authDomain: "test-nextjs-agent.firebaseapp.com",
  projectId: "test-nextjs-agent",
  ...
};

Next, go to Project Settings and click on the Service Accounts tab. Then click to generate a new private key. This will download a JSON file that serves as the server’s proof of identity to Firebase.

This service account file is very important. It enables server-side access to Firebase. Do not commit it to your project’s version control. Move the file to the project’s root folder and add it to .gitignore immediately.

Next, run the command below:

npm install firebase firebase-admin @mastra/auth-firebase

This installs the following:

• firebase: The Firebase client-side SDK that runs in the browser. Since we’re using Google sign-in here, it handles the sign-in pop-up and manages the user’s ID token.
• firebase-admin: The server-side SDK that runs in Next.js API routes. It verifies that the ID token the browser sent is real and hasn’t been tampered with.
• @mastra/auth-firebase: Mastra’s built-in auth wrapper for Firebase.

Finally, open the .env file and update the environment variables as shown below:

GOOGLE_GENERATIVE_AI_API_KEY=YOUR-GOOGLE-API-KEY
    
    NEXT_PUBLIC_FIREBASE_API_KEY=YOUR-FIREBASE-API-KEY
    NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=test-nextjs-agent.firebaseapp.com
    NEXT_PUBLIC_FIREBASE_PROJECT_ID=test-nextjs-agent
    
    FIREBASE_SERVICE_ACCOUNT=/absolute/path/to/the/service/account/file.json

Here, we included environment variables required for both the frontend and backend. The firebaseConfig object we copied earlier contains the frontend values, while FIREBASE_SERVICE_ACCOUNT is an absolute path to the service account file we downloaded.

If you’re unsure how to get the absolute path, run the command below in the terminal:

pwd

Copy the returned path, then append the filename and its extension to form the full file path.

Implementing Firebase Agent Authentication

In this section, we’ll see how to implement Firebase authentication across our application, including for our Mastra agent.

Create a src/lib/firebase.ts file and add the following to it to initialize the Firebase client SDK:

import { initializeApp, getApps, getApp } from "firebase/app";
import { getAuth, GoogleAuthProvider } from "firebase/auth";

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
};

const app = getApps().length ? getApp() : initializeApp(firebaseConfig);

export const auth = getAuth(app);
export const googleProvider = new GoogleAuthProvider();

This sets up a Firebase app instance using environment variables, with a guard to prevent duplicate initialization during Next.js hot reloads. It then exports the Firebase Authentication instance and a Google sign-in provider, both ready to be used anywhere in the app.

We also need to initialize the Firebase Admin SDK. Create a src/lib/firebase-admin.ts file and add the following to it:

import admin from "firebase-admin";
import fs from "fs";

if (!admin.apps.length) {
  const serviceAccountPath = process.env.FIREBASE_SERVICE_ACCOUNT as string;

  const serviceAccount = JSON.parse(
    fs.readFileSync(serviceAccountPath, "utf-8"),
  );

  admin.initializeApp({
    credential: admin.credential.cert(serviceAccount),
  });
}

export const adminAuth = admin.auth();

In the code above, we initialized the Firebase Admin SDK, the server-side counterpart to the client-side Firebase setup. It reads the service account JSON file from the path specified in the FIREBASE_SERVICE_ACCOUNT environment variable, uses it to authenticate as a trusted admin and exports adminAuth, which will be used server-side to verify and decode user tokens sent from the client.

Next, create a src/context/AuthContext.tsx file and add the following to it:

"use client";

import {
  createContext,
  useContext,
  useEffect,
  useState,
  ReactNode,
} from "react";
import { onAuthStateChanged, User } from "firebase/auth";
import { auth } from "@/lib/firebase";

interface AuthContextValue {
  user: User | null;
  loading: boolean;
}

const AuthContext = createContext<AuthContextValue>({
  user: null,
  loading: true,
});

export function AuthProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const unsubscribe = onAuthStateChanged(auth, (firebaseUser) => {
      setUser(firebaseUser);
      setLoading(false);
    });
    return () => unsubscribe();
  }, []);

  return (
    <AuthContext.Provider value={{ user, loading }}>
      {children}
    </AuthContext.Provider>
  );
}

export const useAuth = () => useContext(AuthContext);

This file creates a React context that tracks the currently signed-in Firebase user across the app, exposing a user object and a loading state. The useAuth hook is then exported to allow access to the context values from any component.

Open the src/app/layout.tsx file and wrap the application with the context provider, AuthProvider, as shown below:

import type { Metadata } from "next";
import { Geist, Geist_Mono } from "next/font/google";
import "./globals.css";
import { AuthProvider } from "@/context/AuthContext";

//...

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html
      lang="en"
      className={`${geistSans.variable} ${geistMono.variable} h-full antialiased`}
    >
      <body className="min-h-full flex flex-col">
        <AuthProvider>{children}</AuthProvider>
      </body>
    </html>
  );
}

Now, let’s create a simple login page that will be used to test the Firebase authentication in the browser.

Create a src/app/login/page.tsx file and add the following to it:

"use client";

import { useState } from "react";
import { useRouter } from "next/navigation";
import { signInWithPopup } from "firebase/auth";
import { auth, googleProvider } from "@/lib/firebase";

export default function LoginPage() {
  const router = useRouter();
  const [error, setError] = useState<string | null>(null);

  const handleSignIn = async () => {
    try {
      await signInWithPopup(auth, googleProvider);
      router.push("/");
    } catch (err) {
      console.error(err);
      setError("Sign-in failed. Please try again.");
    }
  };

  return (
    <main className="flex min-h-screen flex-col items-center justify-center gap-6 p-8">
      <h1 className="text-2xl font-bold">Weather Agent</h1>
      <p className="text-gray-500">Sign in to continue</p>
      {error && <p className="text-sm text-red-500">{error}</p>}
      <button
        onClick={handleSignIn}
        className="bg-blue-600 text-white px-6 py-2 rounded"
      >
        Sign in with Google
      </button>
    </main>
  );
}

This renders a “Sign in with Google” button that triggers a Firebase Google pop-up sign-in. On success, the user is redirected to the homepage; on failure, an error message is displayed.

Now, let’s protect our chat page and also attach the token. Open the src/app/page.tsx file and update it as shown below:

"use client";

import { useState, useEffect, useRef } from "react";
import { useRouter } from "next/navigation";
import { User } from "firebase/auth";
import { signOut } from "firebase/auth";
import { auth } from "@/lib/firebase";
import { useAuth } from "@/context/AuthContext";

export default function Home() {
  const { user, loading } = useAuth();
  const router = useRouter();
  const userRef = useRef<User | null>(null);

  const [message, setMessage] = useState("");
  const [response, setResponse] = useState("");
  const [fetching, setFetching] = useState(false);

  useEffect(() => {
    userRef.current = user;
  }, [user]);

  useEffect(() => {
    if (!loading && !user) {
      router.push("/login");
    }
  }, [user, loading, router]);

  const handleSubmit = async () => {
    if (!message.trim() || !userRef.current) return;
    setFetching(true);
    setResponse("");
    const token = await userRef.current.getIdToken(true);
    const res = await fetch("/api/chat", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${token}`,
      },
      body: JSON.stringify({ message }),
    });
    const data = await res.json();
    setResponse(data.response ?? data.error);
    setFetching(false);
  };

  const handleSignOut = async () => {
    await signOut(auth);
    router.push("/login");
  };

  if (loading || !user) return null;

  return (
    <main className="flex min-h-screen flex-col items-center justify-center p-8 gap-6">
      <div className="w-full max-w-lg flex justify-between items-center">
        <h1 className="text-2xl font-bold">Weather Agent</h1>
        <div className="flex items-center gap-4">
          <span className="text-sm text-gray-500">{user.email}</span>
          <button
            onClick={handleSignOut}
            className="text-sm text-red-500 hover:underline"
          >
            Sign out
          </button>
        </div>
      </div>
      <textarea
        className="w-full max-w-lg border rounded p-3 text-sm"
        rows={3}
        placeholder="Ask about the weather anywhere..."
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      <button
        onClick={handleSubmit}
        disabled={fetching}
        className="bg-blue-600 text-white px-6 py-2 rounded disabled:opacity-50"
      >
        {fetching ? "Thinking..." : "Send"}
      </button>
      {response && (
        <div className="w-full max-w-lg border rounded p-4 bg-gray-50 text-sm">
          {response}
        </div>
      )}
    </main>
  );
}

The code above redirects a user if not authenticated. On the other hand, if authenticated, it presents the user with a textarea to send messages to the weather agent.

Before each request, it fetches a fresh Firebase ID token and attaches it to the Authorization header when calling the /api/chat endpoint. It also displays the agent’s response and provides a sign-out button.

That’s it for the client side. Now let’s update the API route to verify the token. Open the src/app/api/chat/route.ts file and update the code as shown below:

import { mastra } from "@/mastra";
import { NextResponse } from "next/server";
import { adminAuth } from "@/lib/firebase-admin";

export async function POST(req: Request) {
  const authHeader = req.headers.get("Authorization");

  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const idToken = authHeader.split("Bearer ")[1];

  try {
    await adminAuth.verifyIdToken(idToken);
  } catch {
    return NextResponse.json(
      { error: "Invalid or expired token" },
      { status: 401 },
    );
  }

  const { message } = await req.json();

  if (!message) {
    return NextResponse.json({ error: "Message is required" }, { status: 400 });
  }

  const agent = mastra.getAgent("weatherAgent");
  const result = await agent.generate([{ role: "user", content: message }]);

  return NextResponse.json({ response: result.text });
}

In the code above, instead of just receiving messages from the client side and generating responses based on that, we now include an authentication verification layer.

First, it validates the Authorization header, extracting and verifying the Firebase ID token using the Admin SDK. It rejects any request that is unauthenticated or carries an invalid token. If verification passes, it forwards the user’s message to the Mastra weather agent and returns the agent’s response.

For the final piece, which is adding the authentication guard to our Mastra instance, update the src/mastra/index.ts file as shown below:

import { Mastra } from "@mastra/core/mastra";
import { PinoLogger } from "@mastra/loggers";
import { LibSQLStore } from "@mastra/libsql";
import {
  Observability,
  DefaultExporter,
  CloudExporter,
  SensitiveDataFilter,
} from "@mastra/observability";
import { weatherWorkflow } from "./workflows/weather-workflow";
import { weatherAgent } from "./agents/weather-agent";
import { MastraAuthFirebase } from "@mastra/auth-firebase";

export const mastra = new Mastra({
  workflows: { weatherWorkflow },
  agents: { weatherAgent },
  storage: new LibSQLStore({
    id: "mastra-storage",
    url: "file:./mastra.db",
  }),
  server: {
    auth: new MastraAuthFirebase(),
  },
  logger: new PinoLogger({
    name: "Mastra",
    level: "info",
  }),
  observability: new Observability({
    configs: {
      default: {
        serviceName: "mastra",
        exporters: [
          new DefaultExporter(),
          new CloudExporter(),
        ],
        spanOutputProcessors: [
          new SensitiveDataFilter(),
        ],
      },
    },
  }),
});

For now, pay close attention only to this part:

server: {
    auth: new MastraAuthFirebase(),
},

By passing an instance of the MastraAuthFirebase class to the auth option in the Mastra server config, Mastra will automatically intercept every incoming request to the agent and validate the Firebase ID token, thereby restricting access if no token is provided or if an invalid token is provided.

It is important to note that MastraAuthFirebase will automatically read the FIREBASE_SERVICE_ACCOUNT and FIRESTORE_DATABASE_ID environment variables, so no additional configuration is required other than verifying those values are set in the .env file.

Now you can test the application in your browser to see the authentication in action.

Implementing Authorization

With authentication done, our agent is no longer publicly accessible so only signed-in users can access it. In this section, we’ll add an extra layer of control, which involves checking whether an authenticated user actually has permission to use the agent.

For this, we need somewhere to store user roles. Firestore is the best fit for this, since it is already part of the Firebase ecosystem.

In the sidebar of the Firebase dashboard, go to Databases and Storage → Firestore and click “Create Database.” Next, pick a region and select “Start in test mode.”

After successfully creating it, open the .env file and add the database ID as shown below:

//...previous environment variables

FIRESTORE_DATABASE_ID=(default)

In the snippet above, (default) is the ID Firestore assigns to the first database it creates for a project.

Now, open the src/lib/firebase-admin.ts file to update the Firestore admin to export Firestore:

import admin from "firebase-admin";
import fs from "fs";

if (!admin.apps.length) {
  const serviceAccountPath = process.env.FIREBASE_SERVICE_ACCOUNT as string;
  const serviceAccount = JSON.parse(
    fs.readFileSync(serviceAccountPath, "utf-8"),
  );
  admin.initializeApp({
    credential: admin.credential.cert(serviceAccount),
  });
}

export const adminAuth = admin.auth();
export const adminFirestore = admin.firestore();

Here, admin.firestore() provides a Firestore client that uses the service account credentials. Instead of writing the role-checking logic directly inside the API route, let’s create a separate file for that. Create a src/lib/authorization.ts file and add the following to it:

import { adminFirestore } from "./firebase-admin";

export type UserRole = "admin" | "user" | "blocked";
const ALLOWED_ROLES: UserRole[] = ["admin", "user"];

export async function getUserRole(uid: string): Promise<UserRole | null> {
  const doc = await adminFirestore.collection("users").doc(uid).get();

  if (!doc.exists) return null;

  const data = doc.data() as { role: UserRole };
  return data.role ?? null;
}
export async function isUserAuthorized(uid: string): Promise<boolean> {
  const role = await getUserRole(uid);
  if (!role) return false;
  return ALLOWED_ROLES.includes(role);
}

In the code above, getUserRole takes a Firebase UID, looks up the corresponding document in the users Firestore collection, and returns the role stored in it. If no document exists for that UID, it returns null, meaning that the user has never been granted access.

Also, isUserAuthorized calls getUserRole and checks whether the result is in the ALLOWED_ROLES array. Only “admin” and “user” pass this check. A “blocked” role or a missing document both return false.

Next, let’s add the authorization check to our API route. Open the src/app/api/chat/route.ts file and update the code as shown below:

import { mastra } from "@/mastra";
import { NextResponse } from "next/server";
import { adminAuth } from "@/lib/firebase-admin";
import { isUserAuthorized } from "@/lib/authorization";

export async function POST(req: Request) {
  const authHeader = req.headers.get("Authorization");

  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const idToken = authHeader.split("Bearer ")[1];
  let decodedToken;

  try {
    decodedToken = await adminAuth.verifyIdToken(idToken);
  } catch {
    return NextResponse.json(
      { error: "Invalid or expired token" },
      { status: 401 },
    );
  }

  const authorized = await isUserAuthorized(decodedToken.uid);
  if (!authorized) {
    return NextResponse.json(
      { error: "You do not have access to this agent." },
      { status: 403 },
    );
  }

  const { message } = await req.json();

  if (!message) {
    return NextResponse.json({ error: "Message is required" }, { status: 400 });
  }

  const agent = mastra.getAgent("weatherAgent");
  const result = await agent.generate([{ role: "user", content: message }]);

  return NextResponse.json({ response: result.text });
}

We updated the code to follow a sequential flow. First, we verify the token (authentication), then checking the role (authorization). If either check fails, an error is returned.

Notice how the message is only read after both checks pass. There is no reason to retrieve the message if the user is not authenticated or not authorized.

Now, let’s update our Mastra server instance. We want to inform it about our role system as well, so that even direct calls to Mastra’s server go through the same authorization logic.

Open the src/mastra/index.ts file and update it as shown below:

import { Mastra } from "@mastra/core/mastra";
import { PinoLogger } from "@mastra/loggers";
import { LibSQLStore } from "@mastra/libsql";
import {
  Observability,
  DefaultExporter,
  CloudExporter,
  SensitiveDataFilter,
} from "@mastra/observability";
import { weatherWorkflow } from "./workflows/weather-workflow";
import { weatherAgent } from "./agents/weather-agent";
import { MastraAuthFirebase } from "@mastra/auth-firebase";
import { isUserAuthorized } from "@/lib/authorization";

export const mastra = new Mastra({
  workflows: { weatherWorkflow },
  agents: { weatherAgent },
  storage: new LibSQLStore({
    id: "mastra-storage",
    url: "file:./mastra.db",
  }),
  server: {
    auth: new MastraAuthFirebase({
      authorizeUser: async (user) => {
        return isUserAuthorized(user.id);
      },
    }),
  },
  logger: new PinoLogger({
    name: "Mastra",
    level: "info",
  }),
  observability: new Observability({
    configs: {
      default: {
        serviceName: "mastra",
        exporters: [
          new DefaultExporter(),
          new CloudExporter(),
        ],
        spanOutputProcessors: [
          new SensitiveDataFilter(),
        ],
      },
    },
  }),
});

Let’s pay attention to this block of code:

export const mastra = new Mastra({
  ...
  server: {
    auth: new MastraAuthFirebase({
      authorizeUser: async (user) => {
        return isUserAuthorized(user.uid);
      },
    }),
  },
///
});

The authorizeUser function receives the decoded Firebase token after verification. Then user.uid is passed to the same isUserAuthorized function we used earlier in the API route. This keeps the role logic in one place and enforces it consistently across both entry points.

Let’s update the chat page to acknowledge authorization. Open the src/app/page.tsx file and update the code as shown below:

"use client";
import { useState, useEffect, useRef } from "react";
import { useRouter } from "next/navigation";
import { User } from "firebase/auth";
import { signOut } from "firebase/auth";
import { auth } from "@/lib/firebase";
import { useAuth } from "@/context/AuthContext";

export default function Home() {
  const { user, loading } = useAuth();
  const router = useRouter();
  const userRef = useRef<User | null>(null);

  const [message, setMessage] = useState("");
  const [response, setResponse] = useState("");
  const [fetching, setFetching] = useState(false);
  const [forbidden, setForbidden] = useState(false);

  useEffect(() => {
    userRef.current = user;
  }, [user]);

  useEffect(() => {
    if (!loading && !user) {
      router.push("/login");
    }
  }, [user, loading, router]);

  const handleSubmit = async () => {
    if (!message.trim() || !userRef.current) return;
    setFetching(true);
    setResponse("");

    const token = await userRef.current.getIdToken(true);

    const res = await fetch("/api/chat", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${token}`,
      },
      body: JSON.stringify({ message }),
    });

    if (res.status === 403) {
      setForbidden(true);
      setFetching(false);
      return;
    }

    const data = await res.json();
    setResponse(data.response ?? data.error);
    setFetching(false);
  };

  const handleSignOut = async () => {
    await signOut(auth);
    router.push("/login");
  };

  if (loading || !user) return null;
  return (
    <main className="flex min-h-screen flex-col items-center justify-center p-8 gap-6">
      <div className="w-full max-w-lg flex justify-between items-center">
        <h1 className="text-2xl font-bold">Weather Agent</h1>
        <div className="flex items-center gap-4">
          <span className="text-sm text-gray-500">{user.email}</span>
          <button
            onClick={handleSignOut}
            className="text-sm text-red-500 hover:underline"
          >
            Sign out
          </button>
        </div>
      </div>

      {forbidden && (
        <div className="w-full max-w-lg border border-red-300 rounded p-4 bg-red-50 text-sm text-red-700">
          You do not have access to this agent. Please contact the
          administrator.
        </div>
      )}

      <textarea
        className="w-full max-w-lg border rounded p-3 text-sm"
        rows={3}
        placeholder="Ask about the weather anywhere..."
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      <button
        onClick={handleSubmit}
        disabled={fetching}
        className="bg-blue-600 text-white px-6 py-2 rounded disabled:opacity-50"
      >
        {fetching ? "Thinking..." : "Send"}
      </button>
      {response && (
        <div className="w-full max-w-lg border rounded p-4 bg-gray-50 text-sm">
          {response}
        </div>
      )}
    </main>
  );
}

Here, we added a new forbidden state that is set to true when the user is unauthorized. In that case, a message is rendered on the screen. The user then understands what happened and what to do next (contact whoever manages access).

To test this, in the Firestore database we created earlier, create a collection called users. Follow the steps below for each user you want to grant access:

• Click “Add document.”
• Set the Document ID to the user’s Firebase UID (you’ll have to copy this from Authentication → Users in the Firebase dashboard).
• Add two fields: email and role. Email should be of type string with a value of the email you want to test with. Role should also be of type string, and its value should be either “user” or “admin,” or “blocked” if you want to deny a user access.

For this demo, we are manually adding users to Firestore to keep things simple. In a real application, you would automate this by creating the user’s Firestore document programmatically right after their first sign-in.

Go to the Rules tab in Firestore and update the default rules as shown below:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2026, 4, 23);
    }
    
    match /users/{uid} {
      allow read, write: if false;
    }
  }
}

This prevents any browser code from reading role data directly. The server (Admin SDK) bypasses these rules entirely, so it still works fine.

Now, you can test the application in your browser. The agent now restricts access to users with the “blocked” role.

Change the role to “admin” or “user.”

The user can now get responses to messages sent.

Conclusion

Agent authentication and authorization are key security mechanisms that cannot be overlooked. Authentication confirms who the user accessing an agent is, while authorization determines whether that user should be granted access.

The MastraAuthFirebase class makes the setup straightforward and allows us to add these security layers to our agent’s server easily.

In this article, we built a simple Next.js project that implements authentication and authorization across the frontend, the Next.js API, and the agent’s server. We covered the basics here, but you can explore the official Mastra documentation to build on what we covered.

IT teams often assume that scaling a .NET application means moving it to a larger virtual machine or containerizing the application. While such actions do have their place, performance problems are often tied to infrastructure design rather than the application itself.

This article discusses some of the most common infrastructure-related mistakes that are often made when scaling a .NET application.

1. Adding Instances Without Thinking About Traffic Distribution

Application scaling very often involves adding additional nodes to handle the increased demand. However, it is a mistake to add nodes without considering how requests will reach those nodes. Oftentimes organizations will use round-robin load balancing to evenly distribute inbound requests across the available nodes. However, load balancing can break down when session affinity comes into play.

Session affinity occurs as a result of session data being stored on a specific server. This in turn causes all of a user’s requests to be sent to that same server, because that’s where the user’s session lives. This isn’t necessarily a problem by itself, but session affinity can become problematic under the right conditions, especially when there is a mixture of active and inactive users.

In such situations, a particular instance may become overloaded, even if plenty of capacity exists on other instances, simply because the session is bound to that instance. Additionally, if that instance were to fail, then the users on that instance lose their session.

A better approach is to design services to be stateless and to store session data within shared storage rather than placing it in an instance’s memory. This allows the load balancer to freely distribute requests.

2. Assuming That All Requests Look Alike

Basic load distribution strategies, such as round robin, assume that every instance can deliver the same level of performance and that every request has the same impact. In reality though, these assumptions are naïve.

Some requests, for example, trigger longer running operations, call external services or make more complex database queries. As such, some requests will inevitably be completed more quickly than others. This can result in some nodes being bogged down while others remain nearly idle.

The best way to avoid this type of problem is to avoid blindly distributing traffic across nodes. Instead, consider each node’s health when making routing decisions. As an example, if a node were experiencing excessive latency or had a significant queue depth, then it would be better to route inbound requests to a node that is under less of a load rather than assigning the request to the struggling node just because it is that node’s turn.

3. Not Having a Load-Shedding Strategy

Although it may seem counterintuitive, load shedding can sometimes be the most appropriate course of action. For those who might not be familiar with the term, load shedding refers to the practice of intentionally rejecting certain requests as a way of helping the system to stay healthy.

To use an analogy from everyday life, consider what might happen if a restaurant kept seating additional guests in spite of the kitchen and the waitstaff being completely overwhelmed. In such a situation, everyone would receive poor service. Conversely, if the restaurant were to pause and not seat anyone else until the staff had a chance to catch up, then it would result in a better overall experience for everyone.

Load shedding works similarly. When a system becomes overwhelmed with more requests than the nodes can handle, then the load balancer intentionally fails some requests so that those requests that do make it through can still be serviced normally.

4. Lack of Visibility

This one seems so simple (and it is), yet it is so important. Organizations often make the mistake of just assuming that load balancing is working as intended without doing anything to verify their assumptions. The problem is that if an organization cannot see how requests are being routed, then scaling an application becomes guesswork.

Without proper visibility, you can’t tell whether traffic is being evenly distributed, if there are nodes that are constantly struggling or which instances are handling slow requests. It becomes easy to misdiagnose bottlenecks and blame the application for poor performance when routing is the real problem (or vice versa).

Ideally, an organization should be able to collect per-instance metrics from its nodes including CPU and memory usage and the request count. There should also be a way to trace requests as they flow across services and there should be a way to track load distribution metrics to see how the individual nodes are being leveraged.

5. Treating Load Balancing as an Afterthought

One of the single biggest mistakes that is often made when scaling an application is treating load balancing as an afterthought. Typically, an application is deployed and works fine. Eventually though, demand increases and the application begins to struggle. IT distributes the application across several nodes and places a basic load balancer in front of those nodes. In these types of situations, load balancers often use default settings because, “round robin is good enough for not” or “the cloud provider’s defaults should be fine.”

The end result is that while the application has indeed been scaled, there is a good chance that some of the original problems still exist. The added infrastructure now makes those problems more difficult to diagnose.

True load balancing is not about spreading traffic evenly. It’s about making informed decisions as to where each inbound request should be routed. This informed decision making means using application aware routing to base routing decisions on application behavior, not just routing rules. It also means taking instance health and readiness into account and continually adjusting routing decisions based on latency, errors and available capacity.

How do you go from idea to working software? That’s the challenge we face as software developers.

While AI feels like it’s changed everything, it hasn’t changed that fundamental problem.

It’s not a question of how quickly AI can write code (answer: very quickly), but rather how soon can we find out if our assumptions are correct and if we’re building the right thing to move the needle.

Do we even know what needle we’re trying to move in the first place?

In this short series, we’ll explore how we can use AI to build the right things, to solve the most urgent problems, without shipping substandard code.

• We’ll start with a vague premise and see if AI can help us sharpen our understanding of what we’re building (and why).
• Then we’ll move on to working with AI to carve out the headline feature we want to build first.
• We’ll remove ambiguity (and reach a shared understanding of what we’re building) using prototypes and tracer bullets.
• Then we’ll establish the architecture of what we’re building (including key technology choices), break the work down into smaller steps and build it.

First, we need to get clear about what we’re building.

A Journey of a Thousand Miles Begins with a Single Step

If you’ve been experimenting with AI, you already know the big AI trap. The temptation to just throw a vague prompt its way, cross your fingers and hope it magically builds the perfect web application (while you sleep).

In reality it’s not that simple.

AI will happily run off and build whatever you ask it to, which is problematic if you ask it to build the wrong thing, start with fuzzy requirements or give it too much to do in one step.

So, the first task is the same as it’s always been: get clear about the problem you’re solving.

In this case, I started with a simple problem to solve. I have a goal of writing at least one article a week for my personal blog and also an email to my newsletter audience (based on the same blog post). In reality, that cadence is rarely once a week, and often drifts to once a month or, in the worst case, once “every now and then.”

So starting with that problem, I gave this prompt to GPT 5.5 (via the Codex GUI):

I want to build a new web application using .NET 10 and Blazor. Please grill me on the idea, what it’s for, key technology choices, and help me scope out a reasonable first version so we can get user feedback as soon as possible

This did not go well.

GPT 5.5 responded with a giant wall of text and lots of questions. It started diving into implementation details about Blazor (which render mode to use, etc.) and essentially skipped the part where it finds out what I’m trying to build before focusing on those implementation details.

I started over, and tried different variations of the same prompt.

First I got it to ask me one question at a time, which worked better, but I realized it was still jumping to technical details. I wanted to keep it focused on problems and ideal outcomes, not technical matters or even defining the feature details at this stage.

After a few iterations we arrived at this:

I want to build a new web application using .NET 10 and Blazor.

Please grill me on the idea.

Ask me one question at a time, and include your brief recommendation for each question.

Dig into each answer until that thread is clear, then move on to the next question.

For notable decisions (anything fundamental, or where the reasoning for which can’t be deduced from implementation), capture that decision as an ADR in a decisions folder.

Help me explore the problem space, and the core outcomes we want this application to achieve.

Do not scope features at this point, that will come next.

This worked better.

Over the course of a 45-minute back-and-forth, we fleshed out the problem I was trying to solve, and the rough shape of any potential solution. I won’t include the entire conversation here, but here are some highlights.

It asked:

Where do ideas currently appear first: while at your computer, on your phone, in notes, in code/projects, from conversations, or somewhere else?

The answer I gave included this phrase: “Could be anywhere really.”

GPT 5.5 wasn’t having that.

This one isn’t quite a decision yet, because “could be anywhere” can lead to a lot of product surface.

Follow-up question:

For the first version, is it acceptable if mobile capture is only a lightweight inbox, with real writing/editing still expected to happen at a keyboard?

In my experience, AI shines with this kind of process, digging into answers you give it and getting clear so you can make concrete decisions, not just hand-wavey “ideas.”

Some more questions it posed:

What would make this application feel like a calm writing system rather than another obligation to maintain?

What is the smallest publishing rhythm that would still feel successful: exactly one post/email every week, or a sustainable average with occasional skips and catch-ups?

What would make you stop using this app, even if it technically worked?

Notice how GPT 5.5 stayed on task here, exploring the problem and not getting into feature design, or technical choices.

Eventually we arrived at this summary:

The core shape is now clear: a local-first, single-user Blazor/.NET app that helps you maintain a weekly blog-plus-newsletter rhythm, with the Astro repo as source of truth, a calm Markdown writing experience, lightweight AI assistance, and explicit publishing/Git steps.

The main technical decision made was the one I started with (that we’d be using Blazor to build it) and some high level thoughts around source of truth, and the existing systems (like my blog).

We also ended up with a number of architecture decision records (ADRs) captured in markdown documents. ADRs are typically used to capture technical decisions, but were also useful here for capturing the decisions we arrived at around the problem and solution itself.

Here’s one example:

# ADR 0028: Slug Generation
Status
Accepted

## Context
Blog posts need a final URL slug. The slug should usually be short, readable, and aligned with the article's content or main takeaway.

Manual override is sometimes needed.

## Decision
The application should generate slugs automatically from the article title or main takeaway, while allowing the user to override them.

Slugs should be treated as stable after publication unless deliberately changed.

## Consequences
Slug generation should optimize for short, meaningful URLs rather than blindly mirroring the full title.
The user must retain control over the final slug.
Published slug changes should be treated as deliberate edits, not incidental metadata updates.

Whenever I work through an AI interview like this, I find I emerge with a much clearer picture of what I’m building (and why). The LLM’s questions force me to think and often surface angles I hadn’t previously considered. In some cases I’ve gone on to realize building a feature is actually unnecessary (a change to existing habits or processes would achieve the same result).

In this case, though, we’re on the right track and have a clearly scoped brief for an editor to capture ideas and author content.

Make It Work for You

When you try to use AI to build something like this, you might feel like there should be some simple streamlined process you can work through. A clean process where you feed a feature idea in, AI gives you perfect code out and you ride off into the sunset.

Alas, software design is anything but streamlined, and no AI tool is going to take the chaos of defining and refining an idea and handle it in a nice straight line.

In this case, getting AI to grill you about the idea is one part of the design process, but there are others, which we’ll come to shortly. We started high-level here because this was an embryonic idea and a greenfield application. But if you already had an app and were adding a feature, you might skip this step and jump straight into designing a specific feature/requirement.

Iterate Your Prompts

But what about the prompt itself? Did I happen upon some perfect, fully formed prompt that made AI work perfectly? In short, no!

Prompts rarely arrive fully formed. In this case, I started with a vague prompt, then refined and tested it until I found one that worked better for my needs. This is a key difference I’ve noticed between people who get good results from an LLM and those who feel frustrated.

It’s useful to learn how to write effective prompts, or “meta prompts” (where you get AI to write the prompt for you), and run rapid iterations so you can get something that works for you. Here it took around five minutes to get to a prompt that worked well for this exercise.

You can also turn to examples published online (Matt Pocock’s skills are a clear standout), but it’s useful to learn how to create your own skills/prompts, based on your own unique workflow and preferences.

With that said, we’ve carved out our idea: a simple “surface” for capturing ideas and turning those into articles (with the source of truth being an MDX in an Astro blog).

Now to define the headline features. That’s next, in Part 2.

Angular version 21.0 introduced one of the most exciting and awaited features: Signal Forms. Traditionally, there have been two types of forms:

1. Template Forms
2. Reactive Forms

Angular 21.0 introduced a new form type:

3. Signal Forms

And now, Angular 22 makes Signal Forms stable. Signal Forms are a combination of Signal-based reactivity and forms. In my opinion, Signal Forms are the future of forms and user input in Angular.

This article gives you a basic introduction to Signal Forms and shows you how to work with models, validation and two-way synchronization.

First Signal Form

Signal-based forms use a new form function. It creates a form from a writable signal model, where the model is the source of truth, and any change in the form or the model is automatically reflected in the other.

Let’s start by creating an interface to represent the user:

export interface IUser {
    email: string;
    password: string;
}

Next, we create a model that will be used to create the form, as shown below. As mentioned earlier, the model must be a writable signal.

user : WritableSignal<IUser> = signal({
    email: '',
    password: ''  
  })

We can create a signal-based form using the form() function from the @angular/forms/signals.

loginForm = form(this.user);

That’s it. You have created a signal-based form in Angular.

The form function returns a FieldTree, where each field is represented as a signal. In other words, the form function produces a data structure in which every field is a signal enriched with signal-based properties such as value, dirty, invalid and others.

To better understand this structure, let’s print the following values:

console.log(this.loginForm.email().value());
console.log(this.loginForm().valid());
console.log(this.loginForm.email().invalid());
console.log(this.loginForm.email().dirty());
console.log(this.loginForm.email().touched());
console.log(this.loginForm.email().errors());

As shown in the example above, the email field is a signal, and all of its properties are signals as well. Because both the field and its properties are signals, you can use them directly in the template, as demonstrated below.

<input type="email" [formField]="loginForm.email" />
<input type="password" [formField]="loginForm.password" />

To use formField, import it into the component class, as shown below:

import { form, FormField } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [FormField],
  templateUrl: './login.html',
  styleUrl: './login.css',
})
export class Login {}

As discussed earlier, the form() function creates a form from the given model, where the model is the single source of truth, so changes in the form update the model and changes in the model update the form.

In simple words, the model and the form are connected through two-way data binding. This means that when the model signal changes, the form value updates accordingly, and when the form value changes, the model updates as well.

To demonstrate this, read the model signal value inside an effect, as shown below:

constructor(){
  effect(()=>{
    console.log(this.user())
  })
}

As soon as you start typing in the form, you can read the updated value in the effect. Similarly, when you change the model signal value, the form value is reflected as well.

this.user.set({
  email: 'a@a.com',
  password:'abc'
})
console.log(this.loginForm().value()); // updated value of the form

In summary, in signal-based forms, the model used by the form and the form itself are connected via two-way data binding. Updating one automatically updates the other.

Adding Validations

The form() function in Signal Forms makes it simple to add validators to form fields. You can pass a schema function to the form() function to add validators to the form.

In Signal Forms, validations are defined using a schema function. You pass this schema function as the second parameter to the form() function.

You can add the required validators to the email and password fields as shown below:

loginForm = form(this.userModel,(schema)=>{
  required(schema.email,{message:'email is required'});
  email(schema.email,{message:'email is not valid'});
  required(schema.password,{message:'password is required'});
});

We have added the required and email built-in validators and used the message option to provide custom error messages.

As discussed earlier, in a Signal Form, all properties of a field are signals. This allows you to use them directly. For example, to display validation error messages for the email field, as shown below.

<label>
  Email
  <input type="email" [formField]="loginForm.email" />
</label>
@if (loginForm.email().invalid() && loginForm.email().touched()) {
  <div class="error">
    @for (error of loginForm.email().errors(); track error.kind) {
      <span>{{ error.message }}</span>
    }
  </div>
}

In the same way, error messages for the password field can be displayed as below:

<label>
        Password
        <input type="password" [formField]="loginForm.password" />
    </label>
    @if (loginForm.password().invalid() && loginForm.password().touched()) {
    <div class="error">
        @for (error of loginForm.password().errors(); track error.kind) {
        <span>{{ error.message }}</span>
        }
    </div>
    }

Submitting the Form

To complete the form, you can add submit functionality by importing the submit() function and using that to submit the form.

  onSubmit(event: Event) {
    event.preventDefault();
    submit(this.loginForm, async () => {
      const u = this.userModel();
      console.log('Logging in with:', u);
    });
  }

The submit() function runs the logic only when the form is valid.

In the template, the form submit event can bind to the onSubmit () function using event binding, as shown below. You can also disable the submit button when the form is invalid.

<form (submit)="onSubmit($event)">
    // other code for fields …..
    <button [disabled]="loginForm().invalid()" type="submit">Login</button>
</form>

Complete Signal-based Login Form

Putting everything together, the login form using Signal Forms can be implemented as shown below.

The IUser interface is created as shown below:

export interface IUser {
    email:string; 
    password : string; 
}

The Login component using a Signal Form is created as shown below.

import { Component, signal, WritableSignal } from '@angular/core';
import { IUser } from '../user';
import { email, form, FormField, required, submit } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [FormField],
  templateUrl: './login.html',
  styleUrl: './login.css',
})
export class Login {

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: ''
  });

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
    required(schema.password, { message: 'password is required' });
  });

  onSubmit(event: Event) {
    event.preventDefault();
    submit(this.loginForm, async () => {
      const u = this.userModel();
      console.log('Logging in with:', u);
    });
  }
}

In the template, the form can be created as shown below:

<form (submit)="onSubmit($event)">
    <label>
        Email
        <input type="email" [formField]="loginForm.email" />
    </label>
    @if (loginForm.email().invalid() && loginForm.email().touched()) {
    <div class="error">
        @for (error of loginForm.email().errors(); track error.kind) {
        <span>{{ error.message }}</span>
        }
    </div>
    }

    <label>
        Password
        <input type="password" [formField]="loginForm.password" />
    </label>
    @if (loginForm.password().invalid() && loginForm.password().touched()) {
    <div class="error">
        @for (error of loginForm.password().errors(); track error.kind) {
        <span>{{ error.message }}</span>
        }
    </div>
    }
    <button [disabled]="loginForm().invalid()" type="submit">Login</button>
</form>

Understanding Forms Models

Signal Forms are backed by a model, which is a writable signal. When the model value changes, the form updates automatically. Likewise, when the user interacts with the form, the model is updated. In this way, the model and the form are connected through two-way binding, which means changes in one are reflected in the other.

It is always best practice to use an interface to define the model. For example, if we are creating a form to edit a product, we can define a type for it as shown below.

export interface IProduct{
    id:number;
    name:string;
    price:number;
    description:string;
    category:string; 
}

export interface IProductForm extends Omit<IProduct, 'id' | 'category'> {}

Now to edit the product, fetch it from the API using the resource API as shown below:

    idToFetch = signal(1);

    productsResource = resource({
        params: this.idToFetch,
        loader: async ({ params }) => {
            let id = params;
            const response = await fetch(`http://localhost:3000/product/${id}`);
            if (!response.ok) {
                throw new Error(`HTTP error! status: ${response.status}`);
            }
            return response.json() as Promise<IProductForm>;
        }
    });

We have received the product data to be updated from the API. In the next step, we will create a signal-based form to bind this data and allow the user to update the product.

   productUpdateModel = signal<IProductForm>({
        name: '',
        price: 0,
        description: ''
    });

    productForm = form(this.productUpdateModel);

That’s it. Now, in the template, use the formField directive to display the fetched product data in the form, as shown below.

<form (submit)="onSubmit($event)">
    <label>
        Name
        <input type="text" [formField]="productForm.name" />
    </label>

    <label>
        Price
        <input type="number" [formField]="productForm.price" />
    </label>

    <label>
        Description
        <input type="text" [formField]="productForm.description" />
    </label>

    <button [disabled]="productForm().invalid()" type="submit">Update</button>
</form>

To update the product, let’s add an input field and a button to load the product.

<label>Update Product Id : <input #productIdInput type="number" [value] ='idToFetch()'/></label>
<button (click)="fetchProduct(+productIdInput.value)">Load Product</button>

To fetch the updated product, set the signal accordingly. There are multiple ways to bind the value returned from the API to the productUpdateModel. You can either use productResource.value() directly in the template or assign it as shown below.

   fetchProduct(id: number) {
        this.idToFetch.set(id);
        if (this.productsResource.hasValue()) {
            this.productUpdateModel.set(this.productsResource.value());
        }
    }

As you see from the above example, the form model and form fields are in two-way data-binding synchronisation, and changes flow bidirectionally between them.

The interaction between user input and the model follows these steps:

1. The user enters text or selects a value from the dropdown.
2. The formField directive detects the change.
3. The corresponding FieldState is updated.
4. The model signal is updated accordingly.

This flow is illustrated in the diagram below.

The flow between the model and the user input follows the steps below:

1. Use code to set() or update() signal model
2. Notifies all subscribers
3. Field state updates
4. formField directive updates the input element

This flow is illustrated in the diagram below.

Two-way data synchronization can be better understood by the following simple code example.

count = signal({ v: 0 });
  countInput = form(this.count);

  updateCount() {
    this.count.update(c => ({ v: c.v + 1 }));
  }

And on the template:

<input type="number" [formField]="countInput.v" />
 <button (click)="updateCount()">update count</button>
 <p>Count: {{ count().v }}</p>

When you run the above code, you will see that the input and model value are in sync with each other.

Optional Fields

Always use explicit TypeScript type to define the model. So to create a login form create a type like below.

export interface IUser {
    email:string; 
    password : string; 
    rememeberme?: boolean;
}

You use them to create a signal form as shown below:

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: '',
    rememberMe: null
  });

  loginForm = form(this.userModel);

When you define a form using explicit types as shown above, the resulting field tree is fully type-safe. For example, loginForm.email is inferred as FieldTree<string>, and any attempt to access a property that doesn’t exist will produce a compile-time error. In the code below, TypeScript will infer type of email as string.

email = this.loginForm.email;

And to set the optional field:

• Set the value explicitly to null
• For input fields such <input type=”text” />, set the value to empty string.
• Do not use undefined

Fields explicitly set to undefined are omitted from the field tree. A model defined as { value: undefined } behaves the same as {}. Accessing that field returns undefined instead of a FieldTree instance.

Nested Objects in Model

You can use nested objects to create a form like below:

export interface IProduct {
    id:number;
    name:string;
    price:number;
    description:string;
    category:string;
    vendor : IVendor;
}

export interface IVendor{
    id:number;
    name:string;
    email:string;
    phone:string;   
}

Next, you can create the form using the nested object as shown below:

   productModel = signal<IProduct>({
    id: 0,
    name: '',
    price: 0,
    description: '',
    category: '',  
    vendor: {
      id: 0,
      name: '',
      email: '',
      phone: ''
    } 
   });

   productForm = form(this.productModel);

In the template, you can access nested object properties using dot notation, as shown below.

<form (submit)="onSubmit($event)">
    <label>Name</label>
    <input type="text" [formField]="productForm.name" />
    <label>Vendor Name</label>
    <input type="text" [formField]="productForm.vendor.name" />
    <button type="submit">Submit</button>
</form>

Before moving to the validation section, note that the form model and the domain model are two different concepts and should be treated separately.

Your API response may map directly to the domain model, but you should define a dedicated form model when working with signal-based forms.

We will explore this distinction in more detail in a separate article.

Validations

You pass validation rules to the Signal Forms using a schema. You pass schema as second parameter to the form function.

  userModel: WritableSignal<IUser> = signal({
    email: '',
    password: ''
  });


  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
    required(schema.password, { message: 'password is required' });
  });

As shown above, you provide a schema definition along with validation rules to apply validations to the respective fields of the form.

The schema function gets a SchemaPathTree object that lets us define the validation rules. The schema function runs at the time of initialization, and validation runs automatically whenever field values change.

On the template, you can use the validation as shown below:

<label>
        Email
        <input type="email" [formField]="loginForm.email" />
    </label>
    @if (loginForm.email().invalid() && loginForm.email().touched()) {
    <div class="error">
        @for (error of loginForm.email().errors(); track error.kind) {
        <span>{{ error.message }}</span>
        }
    </div>
    }

Validation works in these steps:

1. Define validation rules in schema
2. Validation rules runs when filed value changes
3. Validation errors are propagated as signals
4. UI automatically updates when validation state changes

There are two types of validations:

1. Synchronous validation – required(), email(), etc.
2. Asynchronous validation – validateHttp()

When a field value changes, Angular runs validation in the sequence:

1. First it runs all synchronous validations.
2. If all synchronous validation pass, then it runs asynchronous validation.
3. After that, it updates the field state signal values such as valid(), invalid(), errors() and pending().

Angular provides these built-in validation rules:

1. required()
2. email()
3. min()
4. max()
5. minLength()
6. maxLength()
7. pattern()

You can apply required() and email() validation on email field as shown below:

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
  });

When you have multiple validation rules applied, each rule runs independently and can cause form to be invalid.

Angular Signal Forms make it straightforward to implement custom validations. For example, if you want to verify that the email belongs to the nomadcoder domain, you can easily add a custom validator as shown below.

  loginForm = form(this.userModel, (schema) => {
    required(schema.email, { message: 'email is required' });
    email(schema.email, { message: 'email is not valid' });
     validate(schema.email, ({ value }) => {
      if (!value().endsWith('@nomadcoder.ai')) {
        return {
          kind: 'emailDomain',
          message: 'Email must end with @nomadcoder.ai'
        }
      }
      return null;
    });
  });

In upcoming articles, we will get into details of custom validation and asynchronous validation.

Form Field and Its Signal Properties

The form function returns a FieldTree that represents all properties of the model. Each property is exposed as a signal, and each property signal includes a set of attributes that are also implemented as signals.

When you access a field from the field tree, as shown below, you can retrieve its associated attributes as illustrated:

The various signal attributes are as below:

1. value()
2. dirty()
3. hidden()
4. errors
5. errorSummary
6. valid
7. invalid
8. pending
9. submitting
10. Etc.

As all these are signals(), they can be directly used on the template. I hope now you understand Angular Signal Forms. In coming articles, we will go deeper into:

1. asynchronous validators
2. custom validators

I hope you find this article useful. Thanks for reading.

While we were at JSNation and React Summit (read about our hackathon there!), we wanted to take advantage of our booth space to do a little user research. We asked folks who stopped by to answer a simple question for us: What still causes the most friction when building modern web applications?

Instead of running a formal survey, we set up a whiteboard, handed folks a sticky note and a sharpie, and invited them to air their grievances. Over the two days of the combined conferences, we collected 120+ responses across two prompts:

• Day 1 (JS Nation): What’s the most annoying frontend task or component to build from scratch?
• Day 2 (React Summit): What does AI still get wrong when building UI in React?

The responses were (at least to me) surprisingly consistent. While frameworks, tooling and AI assistants continue to evolve, many of the age-old pain points haven’t disappeared. Turns out, it sucked to build a date picker 10 years ago and it still sucks today.

Building UI Components Is Still a Challenge

We left the first question open-ended, allowing folks to pick between tasks and components that they found annoying. Personally, I was expecting to see more tasks than components—especially now that we can AI-generate components fairly quickly—but that’s not what happened. In fact, the split between individual components and tasks was a fairly even split.

Date picker components topped the list, with developers calling out everything from timezone handling to accessibility and date ranges. Unsurprisingly, AI is next up—adopting any new technology is going to come with some pain points and process adjustments. Accessibility was in third place with several callouts about struggling with compliance and testing, specifically.

AI Has Become Part of the Workflow—and Part of the Friction

As you can see in the results above, even before we introduced an AI-specific discussion on Day 2 developers were already talking about AI. But when we asked specifically about AI-generated React code, the conversation shifted from whether AI is useful to where it still struggles.

The top complaint was related to React architecture. Developers repeatedly mentioned AI-generated code that:

• Violates the rules of hooks
• Creates unnecessary useState calls
• Places state outside components
• Generates new components instead of reusing existing ones
• Produces code without understanding project requirements
• Includes poor quality CSS

Some Pain Points Refuse to Go Away

Across both days, several themes kept resurfacing. Accessibility appeared on both walls, suggesting that AI hasn’t eliminated many of the challenges developers face when building inclusive interfaces. Developers also repeatedly mentioned:

• Design systems
• Figma-to-code workflows
• Localization
• Testing
• State management
• Performance
• CSS

These aren’t new problems—and many of them have to do with very human aspects of software development such as coordination across teams, inclusivity, creating work for a global audience and user testing.

So? What Does All This Mean

The difficulty now (as it always has been) is in the integration of tools into cohesive systems. The tools have changed, but the challenge has not. Frontend developers today are spending their time wrestling with accessibility, architecture, complex UI components, evolving requirements and figuring out how to integrate AI into real production workflows.

AI is clearly changing how developers build software, but it hasn’t eliminated the need for thoughtful engineering. In many cases, it’s shifted developers’ attention toward reviewing, refining and improving generated code rather than writing every line themselves. Whether that’s an improvement or not is something only time will tell.

The good news is that many of the component-centric frustrations that developers shared at our booth—date pickers, data grids, accessibility, design systems and more—all have something in common: they’re problems with existing solutions.

Modern component libraries exist so developers can focus on building the unique parts of their applications instead of spending weeks recreating foundational UI. Likewise, AI tools are most effective when paired with production-ready building blocks that help developers generate better code, faster.

Investing in the right UI foundation can remove much of the friction developers told us they’re still experiencing today. We may not have the answer to every frontend development struggle, but there are plenty that the Progress Telerik and Kendo UI libraries can help address today.

State management in React can get complicated quickly. Most libraries make you choose between simple and powerful. Simple tools break as your app grows or become difficult to manage. Powerful tools require you to write a lot of setup/config code before anything works. And when you need to handle async operations or derive state from multiple sources, you’re writing custom logic from scratch all over again.

Effector works differently. It is event-driven in the sense that you tell the app what happened (an event), the data updates in the store and the UI updates accordingly. Side effects are handled cleanly, and TypeScript works without extra setup. Instead of dispatching actions and writing reducers, you simply fire events that your stores react to.

Prerequisites

• Understanding of JavaScript/TypeScript
• Basic familiarity with React

Project Setup

We’re going to build a to-do app to see how Effector handles state, async operations and UI updates. The app will let users add, update, delete and load todos from an API. We’ll use Vite to set up a React + TypeScript project.

Open your terminal and run the following command:

npm create vite@latest effector-todo -- --template react-ts 

Once that is done, run the following command to navigate into your project:

cd effector-todo
npm install

Run this command to install Effector dependencies:

npm install effector effector-react

Effector works with any framework, but we need effector-react to connect it to React. The core effector package handles state management, while effector-react provides hooks like useUnit to access state in components.

What Is Effector?

Effector is built around events. All you need to do is describe what happened and the store updates, and the UI will follow. If we compare that to Redux, you need an action, a reducer and a type constant to update a single value in a component.

Zustand made this simpler by letting us call functions directly on the store, which felt like a relief. But async operations are where things get complicated. Suppose we want to save a todo to a database before updating the screen. The fetch call, the loading flag and error handling will all end up in one place, making the function grow messy.

Effector handles async operations differently. We wrap them in an effect, and the loading, success and failure states are all tracked automatically. With this, there is no need for manual flag management.

Then we also have React Context. If you change anything in a provider, your entire component tree re-renders. Effector avoids this by only updating the specific components subscribed to the store that actually changed. TypeScript also works out of the box. If you define types once in the store, they are known everywhere in the codebase.

The powerful thing about Effector is that it isn’t tied to React alone. It gives you the flexibility to work with Vue, Svelte or any other framework.

The 3 Building Blocks

As mentioned earlier, Effector is built around three primitives called units: stores, events and effects. Everything in your app is one of these three things.

• A store holds your data, and it is a reactive container. When it changes, every component subscribed to it updates automatically. More precisely, every part of your UI that depends on it updates automatically. You never have to tell React that something has changed or trigger a re-render. The store handles that.
• Events are signals. They represent things that happen in your app, such as a button being clicked, a form being submitted or a user typing something. An event doesn’t contain logic itself, it just announces what happened and carries the relevant data (the payload). This separation is intentional. Because an event is just a signal, you can wire it to any store or effect without the UI caring. The React button just triggers the event, so it doesn’t need to know what happens next. That’s the store’s job.
• Effects are where async operations live. Anytime your app needs to talk to the outside world (fetch data, write to an API or read from localStorage), that goes in an effect. The reason effects exist as a separate primitive is that async operations have a lifecycle. They start, they either succeed or fail, and the UI needs to reflect each of those states. In most libraries, you manage this yourself with useState hooks and try/catch blocks scattered across your component. Effector handles it automatically. Every effect gives you a loading state, a success state and an error state out of the box. All you need to do is connect them, and you’re done.

Building the Todo Store

Create a src/store.ts file and add the following to it:

import { createStore } from "effector";

type Todo = {
  id: number;
  text: string;
  done: boolean;
};

export const $todos = createStore<Todo[]>([]);

In the code above, we have a Todo type for TypeScript, which is just the shape of one item in our todos array, a single todo. The $ prefix is Effector’s convention for signaling that this is a store, not a regular variable. Because we passed Todo[] as the type, everywhere we use $todos, TypeScript already knows exactly what’s inside it. The code above is our entire data layer for todos.

Creating the Events

A store on its own doesn’t do much. We mentioned earlier that events are one of the three building blocks in Effector, and this is where we create them. Update your src/store.ts file with the following:

import { createStore, createEvent } from "effector";

export const addTodo = createEvent<string>();
export const toggleTodo = createEvent<number>();
export const deleteTodo = createEvent<number>();

Here we have three events that can happen in the app. addTodo carries a string, which is the text of the new todo. toggleTodo and deleteTodo carry a number which is the ID of the todo to act on.

One thing to notice here is that there’s no logic. addTodo doesn’t know how todos are stored or what happens when it fires. It’s just a signal. This is what we described earlier when we said that the button that fires the event doesn’t need to know what happens next.

Connecting Events to the Store

Right now, the store and the events exist independently, nothing connects them. That’s what .on() does. Update your src/store.ts with the following:

$todos
.on(addTodo, (state, text) => [
  ...state,
  { id: Date.now(), text, done: false },
])
.on(toggleTodo, (state, id) =>
  state.map((todo) =>
    todo.id === id? { ...todo, done: !todo.done } : todo
  )
)
.on(deleteTodo, (state, id) =>
  state.filter((todo) => todo.id !== id)
);

Each .on() method takes two parameters: the event to listen for, and a function that describes how the state should change. The function receives the current state and the event payload, then returns a new state. It never mutates the previous state; instead, it always returns a new value.

In the code above, when addTodo fires, we spread the existing todos and add a new one. When toggleTodo fires, we find the todo with that ID and toggle its done value. When deleteTodo fires, we filter that todo out of the array.

That’s the complete data layer for our todo app. There are no classes and no reducers. Just a store, three events and three .on() handlers describing exactly what changes when each event fires.

Connecting to React

Our store exists, the events are wired up, but our UI doesn’t know any of that yet. This is where effector-react comes in. It gives you a single hook, useUnit, that connects your components to your stores.

Reading State with useUnit

import { useUnit } from "effector-react";
import { $todos } from "./store";

function App() {
  const todos = useUnit($todos);
}

useUnit subscribes the component to $todos. When the store changes, the component re-renders with the new value. If nothing changes, it doesn’t re-render.

We don’t have context providers wrapping our app here. Compare this to how you would do the same with Context:

<TodoContext.Provider value={{ todos, setTodos }}>
  <App />
</TodoContext.Provider>
const { todos } = useContext(TodoContext);

Every time setTodos is called, every component inside that provider re-renders. As you can see, Effector gives us a much cleaner approach. With Effector, there’s no provider. All we have to do is just import the store and call useUnit.

Create an App.tsx file in your src directory if you haven’t already, and add the following to it:

import { useState } from "react";
import { useUnit } from "effector-react";
import { $todos, addTodo, toggleTodo, deleteTodo } from "./store";

function App() {
  const todos = useUnit($todos);
  const [input, setInput] = useState("");

  const handleAdd = () => {
    if (input.trim()) {
      addTodo(input);
      setInput("");
    }
  };

  return (
    <div className="min-h-screen bg-gray-50 p-8">
      <div className="max-w-2xl mx-auto">
        <h1 className="text-3xl font-bold text-gray-900 mb-8">
          Effector Todo
        </h1>
        <div className="bg-white rounded-lg shadow p-6 mb-6">
          <div className="flex gap-2">
            <input
              type="text"
              value={input}
              onChange={(e) => setInput(e.target.value)}
              onKeyPress={(e) => e.key === "Enter" && handleAdd()}
              placeholder="Add a new todo..."
              className="flex-1 px-4 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500"
            />
            <button
              onClick={handleAdd}
              className="px-6 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors"
            >
              Add
            </button>
          </div>
        </div>
        <div className="bg-white rounded-lg shadow divide-y">
          {todos.length === 0 ? (
            <div className="p-4 text-gray-500 text-center">
              No todos yet. Add one above!
            </div>
          ) : (
            todos.map((todo) => (
              <div key={todo.id} className="p-4 flex items-center gap-3">
                <input
                  type="checkbox"
                  checked={todo.done}
                  onChange={() => toggleTodo(todo.id)}
                  className="w-5 h-5 text-blue-600 rounded"
                />
                <span className={`flex-1 ${todo.done ? "line-through text-gray-400" : "text-gray-900"}`}>
                  {todo.text}
                </span>
                <button
                  onClick={() => deleteTodo(todo.id)}
                  className="px-3 py-1 text-sm text-red-600 hover:bg-red-50 rounded"
                >
                  Delete
                </button>
              </div>
            ))
          )}
        </div>
      </div>
    </div>
  );
}`

In the code above, you’ll notice we’re not attaching any state logic in our App component, all thanks to Effector. It doesn’t care how todos are stored, added or deleted. All it does is read $todos and trigger events when something happens.

The only place we’re using useState is for the input field, which makes sense since that’s just local UI state which doesn’t need to live in the store.

Derived Store with .map()

Our store works, and the UI is connected, but most apps aren’t as straightforward as our todo app currently is. At some point, you might want to show only completed todos in one place, count remaining tasks somewhere else or filter by priority in another component. You can already see where this is heading.

What comes to mind first is filtering inside each component. That works until you need to change how something works and realize your logic is scattered across the app, where changing one thing breaks another.

Effector handles this with derived states. Instead of rewriting the same logic or recomputing values across components, you derive them once.

Let’s update our store.ts file with these derived stores:

export const $completedTodos = $todos.map((todos) =>
  todos.filter((todo) => todo.done)
);
export const $activeTodos = $todos.map((todos) =>
  todos.filter((todo) => !todo.done)
);
export const $remainingCount = $todos.map(
  (todos) => todos.filter((todo) => !todo.done).length
);

$todos.map() is a method we call on a store. This might look familiar, but it’s not the same as JavaScript’s array.map(). When this one is called on a store, it returns a new store.

In Effector, when you call .map() on a store, it creates a new store that watches the original one. Whenever $todos updates, the derived store runs your transformation function and updates itself. This way, everything stays in sync automatically.

Effector also follows immutability. Nothing gets changed in place. Every time you derive something, you’re creating a new value instead of modifying the existing one, and the transformation function handles that for you.

Let’s see this in action by updating our App.tsx file to look like so:

//App.tsx

import { useState } from "react";
import { useUnit } from "effector-react";
import {
  $activeTodos,
  $completedTodos,
  $remainingCount,
  addTodo,
  toggleTodo,
  deleteTodo,
} from "./store";

export function App() {
  const activeTodos = useUnit($activeTodos);
  const completedTodos = useUnit($completedTodos);
  const remainingCount = useUnit($remainingCount);
  const [input, setInput] = useState("");

  const handleAdd = () => {
    if (input.trim()) {
      addTodo(input);
      setInput("");
    }
  };

  return (
    <div className="min-h-screen bg-gray-50 p-8">
      <div className="max-w-2xl mx-auto">
        <div className="flex items-center justify-between mb-8">
          <h1 className="text-3xl font-bold text-gray-900">Effector Todo</h1>
          <span className="text-gray-500 text-sm">
            {remainingCount} {remainingCount === 1 ? "task" : "tasks"} remaining
          </span>
        </div>

        <div className="bg-white rounded-lg shadow p-6 mb-6">
          <div className="flex gap-2">
            <input
              type="text"
              value={input}
              onChange={(e) => setInput(e.target.value)}
              onKeyPress={(e) => e.key === "Enter" && handleAdd()}
              placeholder="Add a new todo..."
              className="flex-1 px-4 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500"
            />
            <button
              onClick={handleAdd}
              className="px-6 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors"
            >
              Add
            </button>
          </div>
        </div>

        {activeTodos.length > 0 && (
          <div className="bg-white rounded-lg shadow divide-y mb-6">
            {activeTodos.map((todo) => (
              <div key={todo.id} className="p-4 flex items-center gap-3">
                <input
                  type="checkbox"
                  checked={todo.done}
                  onChange={() => toggleTodo(todo.id)}
                  className="w-5 h-5 text-blue-600 rounded"
                />
                <span className="flex-1 text-gray-900">{todo.text}</span>
                <button
                  onClick={() => deleteTodo(todo.id)}
                  className="px-3 py-1 text-sm text-red-600 hover:bg-red-50 rounded"
                >
                  Delete
                </button>
              </div>
            ))}
          </div>
        )}

        {completedTodos.length > 0 && (
          <div>
            <h2 className="text-sm font-medium text-gray-500 mb-2">
              Completed
            </h2>
            <div className="bg-white rounded-lg shadow divide-y opacity-60">
              {completedTodos.map((todo) => (
                <div key={todo.id} className="p-4 flex items-center gap-3">
                  <input
                    type="checkbox"
                    checked={todo.done}
                    onChange={() => toggleTodo(todo.id)}
                    className="w-5 h-5 text-blue-600 rounded"
                  />
                  <span className="flex-1 line-through text-gray-400">
                    {todo.text}
                  </span>
                  <button
                    onClick={() => deleteTodo(todo.id)}
                    className="px-3 py-1 text-sm text-red-600 hover:bg-red-50 rounded"
                  >
                    Delete
                  </button>
                </div>
              ))}
            </div>
          </div>
        )}
      </div>
    </div>
  );
}

As seen above, the app component stays clean and just does what it is supposed to do.

Async Operations with Effects

Every app eventually needs to talk to the outside world, and it may be through fetching data, saving something to a server or reading from storage. This is where most state management solutions make you manually create a loading flag, set it to true before the request, set it back to false when it finishes, handle the error case and clean up if the component unmounts. You end up writing the same boilerplate every time.

The good thing about Effector is that it has a dedicated concept for this called Effects.

Creating an Effect

Let’s update our store.ts file by first adding a new import called createEffect. This handles fetching data and, more generally, any kind of side effect.

We’ll also use a dummy API to fetch some todos and define the type of each todo we expect back.

import { createStore, createEvent, createEffect } from "effector";

type ApiTodo = {
  id: number;
  todo: string;
  completed: boolean;
  userId: number;
};

export const loadTodosFx = createEffect(async () => {
  const response = await fetch("https://dummyjson.com/todos?limit=5");
  const data = await response.json();
  return data.todos.map((todo: ApiTodo) => ({
    id: todo.id,
    text: todo.todo,
    done: todo.completed,
  }));
});

In the code above, createEffect wraps an async function. The Fx suffix is an Effector convention in the sense that just as $ signals a store, Fx signals an effect. Anyone reading the code immediately knows what they’re dealing with.

The function inside is just a regular async function that fetches data, transforms it and returns it.

Effector offers three things out of the box:

• loadTodosFx.pending: A store that is true while the effect is running and false when it finishes
• loadTodosFx.doneData: An event that fires with the return value when the effect succeeds
• loadTodosFx.fail: An event that fires with the error if something goes wrong

We don’t write any of this, and you’ll see it in action when we connect the effects to the store.

Connecting the Effect to the Store

We’ll wire doneData to $todos the same way we wired events with .on().

In your store.ts file, update the $todos connection to include the effect:

$todos
  .on(addTodo, (state, text) => [
    ...state,
    {
      id: Date.now(),
      text,
      done: false,
    },
  ])
  .on(toggleTodo, (state, id) =>
    state.map((todo) =>
      todo.id === id ? { ...todo, done: !todo.done } : todo,
    ),
  )
  .on(deleteTodo, (state, id) => state.filter((todo) => todo.id !== id))
  .on(loadTodosFx.doneData, (_, todos: Todo[]) => todos);

The only new thing in the code above is the last .on() call. Before now, the store was reacting to events we triggered manually. Now it’s also reacting to the result of an async operation.

When loadTodosFx.doneData fires (which happens when the request succeeds), the store replaces the current todos with whatever came back from the API.

Using the Fx in the Component

Now update your App.tsx to import loadTodosFx and read the loading state:

import { useState } from "react";
import { useUnit } from "effector-react";
import {
  $activeTodos,
  $completedTodos,
  $remainingCount,
  addTodo,
  toggleTodo,
  deleteTodo,
  loadTodosFx,
} from "./store";

export function App() {
  const activeTodos = useUnit($activeTodos);
  const completedTodos = useUnit($completedTodos);
  const remainingCount = useUnit($remainingCount);

  const loadTodos = useUnit(loadTodosFx);
  const isLoading = useUnit(loadTodosFx.pending);

  const [input, setInput] = useState("");

  const handleAdd = () => {
    if (input.trim()) {
      addTodo(input);
      setInput("");
    }
  };

  return (
    <div className="min-h-screen bg-gray-50 p-8">
      <div className="max-w-2xl mx-auto">
        <div className="flex items-center justify-between mb-8">
          <h1 className="text-3xl font-bold text-gray-900">Effector Todo</h1>

          <div className="flex items-center gap-4">
            <span className="text-teal-700 text-2xl font-extrabold">
              {remainingCount} {remainingCount === 1 ? "task" : "tasks"}{" "}
              remaining
            </span>

            <button
              onClick={() => loadTodos()}
              disabled={isLoading}
              className="px-4 py-2 bg-green-600 text-white rounded-lg hover:bg-green-700 disabled:opacity-50"
            >
              {isLoading ? "Loading..." : "Fetch Todos"}
            </button>
          </div>
        </div>

        <div className="bg-white rounded-lg shadow p-6 mb-6">
          <div className="flex gap-2">
            <input
              type="text"
              value={input}
              onChange={(e) => setInput(e.target.value)}
              onKeyPress={(e) => e.key === "Enter" && handleAdd()}
              placeholder="Add a new todo..."
              className="flex-1 px-4 py-2 border border-gray-300 rounded-lg focus:outline-none focus:ring-2 focus:ring-blue-500"
            />
            <button
              onClick={handleAdd}
              className="px-6 py-2 bg-blue-600 text-white rounded-lg hover:bg-blue-700 transition-colors"
            >
              Add
            </button>
          </div>
        </div>

        {activeTodos.length > 0 && (
          <div className="bg-white rounded-lg shadow divide-y mb-6">
            {activeTodos.map((todo) => (
              <div key={todo.id} className="p-4 flex items-center gap-3">
                <input
                  type="checkbox"
                  checked={todo.done}
                  onChange={() => toggleTodo(todo.id)}
                  className="w-5 h-5 text-blue-600 rounded"
                />
                <span className="flex-1 text-gray-900">{todo.text}</span>
                <button
                  onClick={() => deleteTodo(todo.id)}
                  className="px-3 py-1 text-sm text-red-600 hover:bg-red-50 rounded"
                >
                  Delete
                </button>
              </div>
            ))}
          </div>
        )}

        {completedTodos.length > 0 && (
          <div>
            <h2 className="text-sm font-medium text-gray-500 mb-2">
              Completed
            </h2>
            <div className="bg-white rounded-lg shadow divide-y opacity-60">
              {completedTodos.map((todo) => (
                <div key={todo.id} className="p-4 flex items-center gap-3">
                  <input
                    type="checkbox"
                    checked={todo.done}
                    onChange={() => toggleTodo(todo.id)}
                    className="w-5 h-5 text-blue-600 rounded"
                  />
                  <span className="flex-1 line-through text-gray-400">
                    {todo.text}
                  </span>
                  <button
                    onClick={() => deleteTodo(todo.id)}
                    className="px-3 py-1 text-sm text-red-600 hover:bg-red-50 rounded"
                  >
                    Delete
                  </button>
                </div>
              ))}
            </div>
          </div>
        )}
      </div>
    </div>
  );
}

Two things changed in this component. First, we imported loadTodosFx, which is now called when the “Load Todos” button is clicked. Second, loadTodosFx.pending is read with useUnit, which automatically gives us the loading state. The button disables itself while loading, the label switches and todos appear when the fetch is complete.

Connecting Units with Sample

We have stores, events and effects, but sometimes you need them to talk to each other. When one thing happens, it triggers something else. That’s what sample is for. The idea here is straightforward: when a clock fires, read from a source, optionally transform the data and send it to a target.

Before we look at the code, let’s break down what each of those terms actually means:

• clock – The trigger. This is what starts everything. It can be an event, an effect or even another store. When it fires, everything else follows.
• source – The data you want to read at that moment. Usually a store.
• fn – An optional function to transform the data before it goes anywhere. If you don’t need to transform anything, you can skip it.
• target – Where the result goes. Can be a store, an event or an effect.

Here is an example:

import { sample } from "effector";

sample({
  clock: someEvent,    // when this fires...
  source: $someStore,  // grab the current value of this store...
  fn: (sourceValue, clockPayload) => ..., // optionally transform...
  target: anotherEvent // and send it here
});

Now, let’s go through a real example from our todo app. Right now, when you add a todo, the list updates locally. But in a real app, you’d want to reload from the server after adding so everything is in sync. Without sample, you’d handle that inside the component by calling addTodo, then manually calling loadTodosFx right after. That works, but now that logic is tied to one specific button in one specific component.

Add this to your store.ts file:

Import {sample} from “effector”; 
sample({
  clock: addTodo,
  target: loadTodosFx,
});

Now, instead of completely replacing the todos when the request finishes, we’ll merge the data from the API with what we already have locally.

In your store.ts file, update the last .on() call to look like this:

.on(loadTodosFx.doneData, (state, apiTodos: Todo[]) => {
    const apiIds = new Set(apiTodos.map((t) => t.id));
    const localTodos = state.filter((t) => !apiIds.has(t.id));
    return [...apiTodos, ...localTodos];
  });

Every time addTodo fires from anywhere in our app, from any component, loadTodosFx runs automatically. The component has no idea this is happening. It just calls addTodo, and Effector handles the rest.

Conclusion

Honestly, Effector isn’t the right tool for every project. If you’re building something small with just a few components and basic state, stick with useState and useContext. Save Effector for when your app genuinely starts getting messy.

It shines in specific scenarios like when you’re dealing with async operations that need proper loading and error handling, when multiple unrelated components need to access the same state, when you’re computing the same derived data all over the place, or when you catch yourself copy-pasting the same async logic everywhere.

We’ve only scratched the surface here. Effector can do much more, but we’ve covered the basics and core concepts, which are the foundation for everything else. If you want to go deeper, check out the Effector documentation.

Nuxt has gone through a few updates since Nuxt 4, and Appwrite has some new ways of handling data with TableDB. Let’s build a TODO app!

⚠️ This app assumes you have basic Nuxt knowledge and can create an Appwrite database.

TL;DR

We are building Nuxt Notes, a basic to-do app using Nuxt 4 and Appwrite. I could not find any good documentation on setting up Appwrite correctly with Nuxt 4, nor on handling the new TablesDB class. This will cover both.

Appwrite

1. Create a new Appwrite project. This project is called notes-app.
2. For this example, we create a new database called notes. Copy the Database ID for later.

3. Since we are not doing anything complex, the table can also be called notes.

4. We need to configure our tables to have a note string column and an author string column.

5. A user should be able to fully CRUD. You can find this in Settings and then Permissions.

Nuxt 4 Setup

Now we need to configure Nuxt 4 before we handle the notes.

1. Create a new Nuxt 4 app.
2. Configure Tailwind.
3. Install Appwrite with npm i appwrite.

ENV

First, update nuxt.config.ts to read from .env file.

import tailwindcss from "@tailwindcss/vite";

export default defineNuxtConfig({
  compatibilityDate: "2025-07-15",
  devtools: { enabled: true },
  css: ['./app/assets/css/main.css'],
  vite: {
    plugins: [
      tailwindcss(),
    ],
  },
  runtimeConfig: {
    public: {
      appwriteEndpoint: '',
      appwriteProjectId: '',
      appwriteDatabaseId: '',
    },
  },
});

• Yes, the variables will be empty strings! They automatically get replaced by the ENV data. We use NUXT_PUBLIC_ as the public prefix to allow it to be available on the client.
• New words will be capitalized in the config file.

We need to copy our environmental variables into .env from our Appwrite application.

NUXT_PUBLIC_APPWRITE_PROJECT_ID=69168c49003b2c79aafe
NUXT_PUBLIC_APPWRITE_DATABASE_ID=69b5c9ff0024d4feae10
NUXT_PUBLIC_APPWRITE_ENDPOINT=https://nyc.cloud.appwrite.io/v1

• Your data will be completely different!

You can find this in project Settings.

App File at app/app.vue

<template>
  <main class="flex items-center flex-col gap-5 p-5">
    <h1 class="text-3xl font-bold text-red-800">Notes App!</h1>
    <Auth />
  </main>
</template>

• We need to display our app, the Auth component will be created in a bit!

Loader at app/components/loading.vue

We can create a simple loading spinner.

<template>
  <div
    class="animate-spin rounded-full h-10 w-10 border-4 border-b-current border-gray-200"
  ></div>
</template>

Configure Appwrite at app/plugins/appwrite.ts

I believe it is bad practice to export data directly and import it in components. Nuxt has plugins for loading data the correct way.

import { ID, TablesDB } from 'appwrite'
import { Client, Account, Permission, Role, Query } from 'appwrite'

export default defineNuxtPlugin(() => {

    const config = useRuntimeConfig()

    const client = new Client()

    const tables = new TablesDB(client)

    client
        .setEndpoint(config.public.appwriteEndpoint)
        .setProject(config.public.appwriteProjectId)

    const account = new Account(client)

    const databaseId = config.public.appwriteDatabaseId

    return {
        provide: {
            ID,
            Permission,
            Role,
            Query,
            client,
            account,
            tables,
            databaseId
        }
    }
})

• Load the config data with useRuntimeConfig()
• Set the client, tables and account classes to be reusable
• Initialize the project with our ENV files with client.setEndpoint().setProject(), and export the databaseId

Authentication Composables

Appwrite does not have an observable like Firebase or Supabase. You must manually grab the user when you need it with account.get().

User Composable at app/composables/use-user.ts

import type { Models } from "appwrite"

type User = Models.User<Models.Preferences>

export const useUser = () => {

    const { $account } = useNuxtApp()

    const user = useState<{
        data: User | null,
        loading: boolean
    }>('user', () => ({
        data: null,
        loading: true
    }))

    const getUser = async () => {
        try {
            user.value.loading = true
            user.value.data = await $account.get()
        } catch (error) {
            user.value.data = null
        } finally {
            user.value.loading = false
        }
        return user
    }

    return {
        user,
        getUser
    }
}

• Create a reusable user variable, and set it to be sharable from many components with useState instead of ref with the current user state.
• We need to show a loading state while loading.
• getUser will have to be called on component mounting.

Auth Composable at app/composable/use-auth.ts

import { AppwriteException } from "appwrite"

export const useAuth = () => {

    const { $account, $ID } = useNuxtApp()

    const { getUser } = useUser()

    const authError = ref<string | null>(null)

    const authForm = ref({
        email: "",
        password: "",
        name: ""
    })

    const login = async () => {
        
        const { email, password } = authForm.value
        
        try {
            await $account.createEmailPasswordSession({
                email,
                password
            })

            await getUser()

        } catch (error) {
            if (error instanceof AppwriteException) {
                authError.value = error.message
            }
            if (error instanceof Error) {
                authError.value = error.message
            }
            throw error
        }
    }

    const register = async () => {

        const { email, password, name } = authForm.value

        try {
            await $account.create({
                userId: $ID.unique(),
                email,
                password,
                name
            })

            await login()

        } catch (error) {
            if (error instanceof AppwriteException) {
                authError.value = error.message
            }
            if (error instanceof Error) {
                authError.value = error.message
            }
            throw error
        }

    }

    const logout = async () => {
        try {
            await $account.deleteSession({
                sessionId: "current"
            })

            await getUser()

        } catch (error) {
            if (error instanceof AppwriteException) {
                authError.value = error.message
            }
            if (error instanceof Error) {
                authError.value = error.message
            }
            throw error
        }
    }

    return {
        register,
        login,
        logout,
        authError,
        authForm
    }
}

• We must handle login, register and logout. We can also create a shared variable for authError and authForm containing the email, password and name data.
• Most examples don’t handle errors. We do here by sending a message to the authError signal.
• We need to check for the correct error types, if there is an error.
• Creating an account does not automatically log in the user.

await $account.create({
    userId: $ID.unique(),
    email,
    password,
    name
})

You must manually call login afterward.

await $account.createEmailPasswordSession({
    email,
    password
})

await getUser()

And we call getUser so that our user state signal gets updated reactively.

Auth Component at app/components/auth.vue

<script setup lang="ts">
const { user, getUser } = useUser()
onMounted(getUser)
</script>

<template>
  <template v-if="user.loading">
    <Loading />
  </template>
  <template v-else-if="user.data">
    <Logout />
    <Notes />
  </template>
  <template v-else>
    <LoginForm />
  </template>
</template>

• We call getUser on mount to load the user state.
• We display loading if necessary.
• We show login form if not logged in; otherwise we show logout with our notes component.

Logout Component at app/components/logout.vue

<script setup lang="ts">
const { logout } = useAuth()
const { user } = useUser()
</script>

<template>
  <h1>Hello {{ user.data?.name }}</h1>
  <button
    type="button"
    @click="logout"
    class="rounded-lg bg-gray-200 px-4 py-2 text-sm font-medium text-gray-900 transition hover:bg-gray-300"
  >
    Logout
  </button>
</template>

• We display the name using useUser, and create a link to logout using useAuth.

Login Form

Let’s handle registering and logging in!

<script setup lang="ts">
const { login, register, authError, authForm } = useAuth()

const isLogin = ref(true)
</script>

<template>
  <div
    class="mx-auto max-w-md rounded-xl border border-gray-200 bg-white p-6 shadow-sm"
  >
    <form class="space-y-3">
      <input
        autocomplete="email"
        type="email"
        placeholder="Email"
        v-model="authForm.email"
        class="w-full rounded-lg border border-gray-300 px-3 py-2 text-sm outline-none transition focus:border-gray-500"
      />

      <input
        autocomplete="current-password"
        type="password"
        placeholder="Password"
        v-model="authForm.password"
        class="w-full rounded-lg border border-gray-300 px-3 py-2 text-sm outline-none transition focus:border-gray-500"
      />

      <template v-if="isLogin">
        <p class="text-sm text-gray-600">
          Don't have an account?
          <button
            type="button"
            @click="isLogin = false"
            class="text-blue-600 hover:underline"
          >
            Register
          </button>
        </p>
      </template>
      <template v-else>
        <input
          autocomplete="name"
          type="text"
          placeholder="Name"
          v-model="authForm.name"
          class="w-full rounded-lg border border-gray-300 px-3 py-2 text-sm outline-none transition focus:border-gray-500"
        />
        <p class="text-sm text-gray-600">
          Already have an account?
          <button
            type="button"
            @click="isLogin = true"
            class="text-blue-600 hover:underline"
          >
            Login
          </button>
        </p>
      </template>

      <template v-if="isLogin">
        <button
          type="button"
          @click="login"
          class="rounded-lg bg-gray-900 px-4 py-2 text-sm font-medium text-white transition hover:bg-gray-800"
        >
          Login
        </button>
      </template>
      <template v-else>
        <button
          type="button"
          @click="register"
          class="rounded-lg bg-gray-200 px-4 py-2 text-sm font-medium text-gray-900 transition hover:bg-gray-300"
        >
          Register
        </button>
      </template>
      <template v-if="authError">
        <p class="mt-2 text-sm text-red-600">{{ authError }}</p>
      </template>
    </form>
  </div>
</template>

• isLogin will toggle login versus registering.
• We don’t need to program any functions in our component, as this is all beautifully handled in our useAuth composable!
• We could have created our reactive data directly in this component, but in this case it is automatically synced with the composable.

Notes

We need to add and remove notes.

Notes Composable at app/composables/use-notes.ts

import { AppwriteException } from "appwrite"

type Note = {
    note: string,
    id: string
}

export const useNotes = () => {

    const notes = useState<{
        data: Note[],
        loading: boolean
    }>('notes', () => ({
        data: [],
        loading: false
    }))

    const newNote = ref('')

    const noteError = ref<string | null>(null)

    const { user } = useUser()

    const {
        $tables,
        $ID,
        $databaseId,
        $Permission,
        $Role,
        $Query
    } = useNuxtApp()

    const getNotes = async () => {

        if (!user.value.data) {
            throw new Error('User not authenticated')
        }

        const userId = user.value.data.$id

        try {
            notes.value.loading = true
            const { rows } = await $tables.listRows({
                databaseId: $databaseId,
                tableId: 'notes',
                queries: [
                    $Query.equal('author', userId)
                ]
            })

            notes.value.data = rows.map(row => ({
                note: row.note,
                id: row.$id
            }))
        } catch (error) {
            if (error instanceof AppwriteException) {
                noteError.value = error.message
            }
            if (error instanceof Error) {
                noteError.value = error.message
            }
            throw error
        } finally {
            notes.value.loading = false
        }
    }

    const addNote = async () => {

        const note = newNote.value.trim()

        const userData = user.value?.data

        if (!userData) {
            throw new Error('User not authenticated')
        }

        const userId = userData.$id

        // optimistically add note

        const rowId = $ID.unique()

        notes.value.data.push({
            note,
            id: rowId
        })

        newNote.value = ''

        try {
            await $tables.createRow({
                databaseId: $databaseId,
                tableId: 'notes',
                rowId,
                data: {
                    note,
                    author: userId
                },
                permissions: [
                    $Permission.read($Role.user(userId)),
                    $Permission.update($Role.user(userId)),
                    $Permission.delete($Role.user(userId))
                ]
            })

        } catch (error) {

            // remove optimistically added note
            notes.value.data = notes.value.data.filter(n => n.note !== note)

            newNote.value = note

            if (error instanceof AppwriteException) {
                noteError.value = error.message
            }
            if (error instanceof Error) {
                noteError.value = error.message
            }
            throw error
        }
    }

    const removeNote = async (id: string) => {

        // optimistically remove note
        const index = notes.value.data.findIndex(n => n.id === id)

        if (index === -1) {
            noteError.value = 'Note not found'
            return
        }

        const note = notes.value.data[index]!

        notes.value.data.splice(index, 1)

        try {
            await $tables.deleteRow({
                databaseId: $databaseId,
                tableId: 'notes',
                rowId: id
            })
        } catch (error: unknown) {
            // re-add optimistically removed note
            notes.value.data.splice(index, 0, note)
            if (error instanceof AppwriteException) {
                noteError.value = error.message
            }
            if (error instanceof Error) {
                noteError.value = error.message
            }
            throw error
        }
    }

    const resetNotes = () => {
        notes.value = {
            data: [],
            loading: false
        }
    }

    return {
        addNote,
        removeNote,
        notes,
        noteError,
        getNotes,
        resetNotes,
        newNote
    }
}

• We getNotes to display them, addNotes from the form, and removeNotes from the button.
• There should be no case where a user can see notes without being logged in, but we handle that anyway.

const getNotes = async () => {

    if (!user.value.data) {
        throw new Error('User not authenticated')
    }
    ...

• We optimistically add notes to our notes signal, and if it fails, we remove them. This is what Firebase does automatically. We also optimistically remove them, and if it fails, add them back. This will create an extremely fast UI!

notes.value.data.push({
    note,
    id: rowId
})

...

// optimistically remove note
const index = notes.value.data.findIndex(n => n.id === id)

if (index === -1) {
    noteError.value = 'Note not found'
    return
}

const note = notes.value.data[index]!

• Appwrite handles permissions on create by the user that created them.

await $tables.createRow({
    databaseId: $databaseId,
    tableId: 'notes',
    rowId,
    data: {
        note,
        author: userId
    },
    permissions: [
        $Permission.read($Role.user(userId)),
        $Permission.update($Role.user(userId)),
        $Permission.delete($Role.user(userId))
    ]
})

• We also need the database id when we add a new note, and we want to match it with the user author it belongs to.
• The Role.user(userId) gets created by the logged in userId.
• Removing is simple:

await $tables.deleteRow({
    databaseId: $databaseId,
    tableId: 'notes',
    rowId: id
})

• Fetching requires a filter of the userId:

const { rows } = await $tables.listRows({
    databaseId: $databaseId,
    tableId: 'notes',
    queries: [
        $Query.equal('author', userId)
    ]
})

• Query.equal covers our author column filter.

Add a Note at app/components/add-note.vue

<script lang="ts" setup>
const { addNote, noteError, newNote } = useNotes()
</script>

<template>
  <form class="mx-auto flex max-w-md gap-2">
    <textarea
      autocomplete="note"
      type="text"
      name="note"
      v-model="newNote"
      placeholder="Enter a note"
      class="flex-1 rounded-md border border-gray-300 px-3 py-2 text-sm outline-none focus:border-gray-500"
    />
    <button
      type="submit"
      @click.prevent="addNote"
      class="rounded-md bg-black px-4 py-2 text-sm font-medium text-white hover:bg-gray-800"
    >
      Add Note
    </button>
  </form>

  <p v-if="noteError" class="mx-auto mt-2 max-w-md text-sm text-red-600">
    {{ noteError }}
  </p>
</template>

• Putting things in our composables makes our templates extremely clean. Again, we handle our errors with noteError.

Notes Component at app/components/notes.vue

And we display our notes to each user.

<script lang="ts" setup>
const { notes, removeNote, resetNotes, getNotes } = useNotes()

onMounted(getNotes)
onUnmounted(resetNotes)
</script>

<template>
  <p class="mb-4 text-center text-lg font-semibold text-gray-800">Notes</p>
  <template v-if="notes.loading">
    <Loading />
  </template>
  <template v-else-if="notes.data.length">
    <ul
      class="mx-auto mb-6 grid max-w-4xl grid-cols-1 gap-4 sm:grid-cols-2 lg:grid-cols-3"
    >
      <li
        v-for="note in notes.data"
        :key="note.id"
        class="relative min-h-45 -rotate-1 rounded-sm border border-yellow-200 bg-yellow-200 p-4 shadow-md"
      >
        <div
          class="absolute left-1/2 top-0 h-5 w-16 -translate-x-1/2 -translate-y-1/2 -rotate-3 bg-yellow-100/80 shadow-sm"
        />

        <p class="pb-12 text-sm leading-6 text-gray-800">
          {{ note.note }}
        </p>

        <button
          type="button"
          class="absolute bottom-3 right-3 not-[]:px-3 py-1 hover:opacity-50"
          @click="removeNote(note.id)"
        >
          ️
        </button>
      </li>
    </ul>
  </template>
  <template v-else>
    <p class="mb-6 text-center text-gray-500">No notes yet. Add one below!</p>
  </template>
  <AddNote />
</template>

• Notice we retrieve our notes on mounting, and we reset our notes signal on unmounting.
• Notes also need a loading state since they are a separate async function.

App Flow

We can login or register, and each user has their own todos!

Repo: GitHub

I don’t have a demo because the free Appwrite project will pause after a certain time, but this demo should be pretty easy to clone.

Happy coding!

In data-driven applications, it is common to want to display information dynamically and visually. However, there are times when we have doubts about which type of chart to use in our applications.

Choosing the wrong type of chart can cause users to become confused or even distort the information by displaying it incompletely or with a layout that doesn’t make much sense.

That is why this article is a roundup of the types of charts available in the Progress Telerik UI suite for Blazor and when to use each. Let’s get to it!

Chart Types in Telerik UI for Blazor

Let’s analyze the different types of charts available in Telerik UI for Blazor, as well as when to use them.

Column Chart

The first type of chart, column, is perhaps the simplest. With this chart we can display vertical bars in which the height represents the value of each category. It’s a quite versatile chart type, which is why it’s very common to see it in applications and elsewhere. The chart looks like the following:

This type of chart is useful when we want to compare values across categories, show rankings or classifications, and visualize data where order does matter.

Bar Chart

The bar chart is the equivalent of the column chart but in a horizontal format. In the Telerik component ChartSeriesType.Bar is used and the category axis is on the vertical axis instead of horizontal:

This chart can be used when category names are long and you need more space to display them, when you want to show a horizontal comparison between values, and when you want to emphasize the difference in values between categories.

Line Chart

The line chart displays a graph with connected points, which makes this chart ideal for showing trends over time. In the Telerik component it supports normal, step and smooth lines:

This chart is suitable when we want to visualize temporal trends, compare different evolutions within the same period and when continuity between data points is relevant.

Area Chart

This type of chart is similar to the line chart, with the difference that the space beneath the lines is filled with a semi-transparent color. This gives greater emphasis to the volume or magnitude of the data. In the Telerik component we can control the opacity using the Opacity property.

You can use this chart when you want to emphasize the volume of the data, their trend or when you want to show how different series overlap.

Pie Chart

The pie chart displays a circle divided into proportional slices for each value specified in the category. It only supports a single series, which makes it an ideal chart for showing the composition of a whole:

Some examples of when to use this type of chart are when you want to show a percentage distribution of data, while being mindful of the maximum number of slices so as not to overcrowd the chart. Likewise, when you want users to quickly understand portions of a whole and when you require the values to add up to 100%.

Donut Chart

This type of chart is similar to a pie chart but with a hole in the center. This hole can be used to display a highlighted data point or, as the Progress Telerik team has done, allow multiple series to be shown:

This chart is recommended for showing, in addition to the pie-chart scenarios, hierarchical relationships between data sets.

Scatter Chart

The scatter chart displays a series of points defined by the x and y axes, with these being numeric data:

This type of chart is ideal when you want to show a correlation between two numeric variables, such as the relationship between users connected in an application and a website’s load time. It is also useful for identifying patterns, clusters, scientific data, among others.

Bubble Chart

This chart is similar to the scatter chart in how it works, but adds a third dimension, which is the size of the bubble:

The third dimension is useful for comparing entities with multiple metrics simultaneously.

Scatter Line Chart

The scatter line chart is similar to the scatter chart, except that in this case the points are connected by lines:

This chart is convenient to use when you want to show the relationship between two variables while maintaining continuity in the data or trend.

Candlestick Chart

This candlestick-style chart is widely used in the financial sector, as it allows showing four values for a period: open, close, high and low. If we are talking about stocks in the securities market, the body of the candle represents the price from open to close, while the wicks, which are the thin lines above and below, show the period’s high and low:

This chart is suitable for showing financial movements or when you want to identify trading patterns.

OHLC Chart (Open-High-Low-Close)

This chart shows the same four values as the candlestick chart, but instead of using candle bodies, it uses horizontal marks. In this chart the horizontal values represent the open and close, while the lower and upper extremes show the maximum and minimum:

The use cases for this chart are the same as for the candlestick chart, but when you want a cleaner visualization. It is also ideal when you want to show many time periods, in which a candlestick chart would overlap the values.

Heatmap Chart

The heatmap displays a grid where color intensity represents the magnitude of a value across two dimensions:

If you are a software developer, you will surely recognize the image above, since GitHub shows a similar chart to display the commits you have made on an account. This demonstrates that the chart is ideal for showing an activity density in two dimensions and when you want to show behavior patterns across intersecting categories.

Radar Line Chart

This chart starts from a common center from which several axes radiate. Each axis represents a specific value, which are then connected to form a closed shape:

It is very useful when you want to make profile comparisons, such as variables between LLM models or when you want to make before/after comparisons.

Radar Area Chart

This radar area chart is similar to the radar line chart, with the difference that the space of the formed shape is filled with a color:

This chart works well to understand how different profiles overlap on the chart quickly.

Radar Column Chart

The radar column chart follows the same principle as the radar line and radar area charts, with the difference that it shows diagonal bars extending from the center:

By showing bars instead of connecting points, this chart is excellent for comparing individual values across categories and when an overlap in the radar area could make reading values difficult.

Range Area Chart

The range area chart shows an area defined between two continuous lines defining the range between a minimum and a maximum value, similar to the area chart but not starting from zero:

By displaying ranges, it is ideal in scenarios such as temperature ranges, error margins and when you need to emphasize a difference between continuous sequences of values.

Range Bar Chart

This chart lets you display ranges of values over a period of time using horizontal bars, whose position and length vary according to a from value and a to value:

This chart can help you show time ranges or durations, or compare ranges between categories or groups.

Range Column Chart

It is the vertical version of the range bar chart. In this chart vertical bars are displayed, which vary according to the from and to values:

This chart could be useful to show ranges of scores between periods or when you need to emphasize both the minimum and the maximum of each category.

Waterfall Chart

This chart is based on a series of bars that show a cumulative value of sequential positive and negative values. Each bar starts where the previous one ended, which allows you to see the value’s behavior after a period. In the Telerik component it is also possible to display columns with total or partial values:

Use cases for this chart include when you need to analyze cash flow over months, for budget and profitability analysis, among others.

Sankey Chart

This Telerik component TelerikSankey displays a set of entities and links to represent the flow between them. In addition, the thickness of each link shows the value, allowing users to easily see the entity-to-value flow:

Because of its flexibility, the Sankey chart is ideal for analyzing traffic distributions, breaking down budgets or redistributing resources.

Stock Chart

To use a stock chart, you should use the TelerikStockChart component, which is part of the Telerik UI for Blazor suite. This component is specifically designed for financial time series data. It supports types we’ve already covered such as candlestick and OHLC, with the difference that it includes a navigator to select a specific time period:

This component is useful when you need to navigate time periods in financial data or to create trading dashboards or investment analysis.

Trendline Chart

The last chart type we’ll analyze is the trendline type. This chart isn’t really a chart type where you define its own data; rather, it takes the data from an existing chart to reveal the trend of the data. The component supports several trend types: linear, average, exponential, logarithmic, among others:

Some use cases for this chart type include revealing the overall direction of the data, smoothing fluctuations, performing forecasts, as well as conducting statistical analyses and validating patterns over time.

Decision Tree for Selecting the Best Chart

After having analyzed the different types of charts that we can find in the Telerik UI for Blazor suite, I want to leave you a decision list that can help you select the best chart for your use case:

Comparison & Trends
- If there is time or continuity -> Use a line, area or scatter line chart
- If there are simple categories -> Use a column or bar chart
- If there are long category names -> Use a bar chart
- If you want to show underlying trends -> Add a trendline

Composition (Parts of a Whole)
- For a single series -> Use a pie or donut chart
- For multiple series -> Use a donut chart
- For flows between domains -> Use a Sankey diagram

Relationships & Distribution
- With 2 variables -> Use a scatter plot
- With 3 variables -> Use a bubble chart
- For 2D density -> Use a heatmap
- For multidimensional profiles -> Use a radar chart (area, column or line)

Ranges & Cumulative Changes
- To show the effect of changes -> Use a waterfall chart
- For continuous ranges -> Use a range area chart
- For time durations -> Use a range bar chart
- For vertical ranges -> Use a range column chart

Specialized Data
- For financial/price movement -> Use a candlestick or stock chart

This list should help you make a better decision about when to use each type of chart.

Conclusion

Throughout this article, we have taken a tour of the different types of charts that we can find in the Telerik suite for Blazor. This was aimed at understanding the structure of each one, how it looks and which are the best scenarios for their use. After this information, it’s your turn to present your users’ data in different ways, always keeping in mind that their interpretation should be as simple as possible.

Ready to experiment with all these chart types? Telerik UI for Blazor comes with a free 30-day trial:

Try Now

A few weeks ago, the Progress team headed to Amsterdam for React Summit and JSNation: two of the back-to-back biggest events on the JavaScript calendar.

Between the packed schedule, booth conversations, social events and time hanging out with a few hundred of your closest developer friends, it was a seriously week. Not to mention, our team finally got to spend some time together in-person—something that doesn’t happen very often when you’re scattered across the globe! Although we all left feeling exhausted (and at least in my case, wildly jet-lagged), it was absolutely worth the trip.

Our own Kiril Peyanski took the React Summit stage to deliver a talk on generative frontend, exploring a new paradigm where LLMs generate the logic that maps data to UI using React Server Components and Server Functions to make interfaces that adapt to the user. And when I tell you the room was packed, I mean literally standing room only and overflowing out the door!

As part of the conference, we also hosted a hackathon in partnership with GitNation, challenging attendees to build something that makes tech conferences better. We left the specifics up to our hackers. It could mean better for attendees, better for speakers, better for organizers or something else entirely. We wanted to see how creative folks would get, and the response blew us away. The hackathon lasted just 48 hours, and we had over 30 finished projects!

After judging (which, let me tell you, was a real challenge), three projects stood out from the crowd:

Our grand prize winners, HALLWAY: The team behind HALLWAY built a mobile-first app that turns the chaos of a conference day into a personalized, connected flow. Answer a few quick questions, and it builds your schedule, fills your free gaps with curated intros to the right people, and places you in a small group for the evening.

Our first runner-up, Conf Pilot: Conf Pilot is an MCP server that brings live conference schedules directly into AI chat. Ask "what’s next?" and instead of a wall of text, you get a fully interactive, themed widget with track filters, live countdown timers and calendar links—all without leaving your AI assistant. One of the first projects to use the new MCP Apps structured content pattern, and a seriously impressive build for a one-person submission!

Our second runner-up, Stuck Stack: Stuck Stack turns the conference into a live help marketplace. Post what you’re blocked on, find someone nearby who can help you in five minutes, and watch blockers move across a live board from Open → Matched → Solved. Organizers get a real-time dashboard that can even detect when enough attendees are stuck on the same thing and suggest a pop-up help clinic on the spot. Clever, useful and beautifully designed.

However, we couldn’t give prizes to everyone—as much as we wished we could! When I tell you the judging was a challenge, it’s because we had other submissions like these that were so, so impressive. While these unfortunately didn’t end up placing, we do want to make sure they get their time in the sun as well, so you can also appreciate their incredible work!

The Hallway took a new swing at the age-old problem of networking. Your AI agent walks into the conference before you do, negotiates with other attendees’ agents to find the right matches and only reveals identities once both humans consent.

Unison tackled something nobody else touched—language barriers. It dubs conference talks in real-time, letting speakers present in one language while every attendee hears it in their own, with no headsets and about a three-second lag. Two-way, too: attendees can ask questions in their language and the speaker receives them in theirs.

CrowdShift flipped the speaker experience on its head. Speakers normally prepare blind, with no idea who’s actually in the room. CrowdShift pulls registration data and builds a continuously updated audience brief, so a speaker can see that their crowd shifted from 65% senior to 55% junior and adapt their talk in real time.

ConferenceCast treated a multi-track conference like a TV broadcast: every room is a channel, and you get a personalized program guide with AI match scores, live session cards, countdown timers and a control-room dashboard for organizers to track what’s working in real time.

FireRaven Conference Hub went after a bigger problem: conference discovery is basically guesswork. Their platform gives speakers portable reputation profiles and lets attendees rate events across meaningful dimensions—expertise, clarity, practical impact and energy.

Nexo kept it focused: tell it your role, goals and interests, and it builds you a focused conference plan with a clear explanation for every recommendation. Sometimes, the best solutions are the simple ones.

Stage Deployer changes how you give talks. It lets speakers create small audience apps from a simple text prompt. Just type an idea, wait about two minutes, then share a QR code for the audience to scan. The interaction results appear live on the big screen as charts, rankings or word clouds.

We highly encourage you to check out all the submissions in the project gallery and see the incredible variety of things people built with Telerik and Kendo UI components from Progress Software.

Amsterdam delivered on all fronts: the venue was great, the crowd was friendly and the whole experience reminded us just how great it is to be able to spend time together with a bunch of folks all excited to geek out about the same stuff.

Huge congrats to all three of our hackathon winning teams, and a massive well done to every single person who submitted. More than 30 projects in a couple of days is no joke! We had a fantastic time, and we’re already looking forward to the next one.

Ready to build your next React app?

Explore KendoReact

Exceptions have been part of the .NET ecosystem since the earliest versions of the .NET Framework. Today, with the platform’s continuous evolution, their use is simpler and more integrated than ever. The problem, however, arises when they are used inappropriately or imprecisely.

In this post, we will explore in which situations the use of exceptions is truly recommended and when more appropriate alternatives should be considered. Furthermore, we will see in practice some of the most modern features available in ASP.NET Core for implementing exception handling aligned with best practices.

What Are Exceptions in the Context of ASP.NET Core?

In ASP.NET Core, exceptions are objects that represent unexpected events that occur during program execution and interrupt its normal flow. Common examples of flow interruption include null reference errors, invalid user input, and database connection problems.

In practice, when an exception is thrown, the .NET runtime starts looking for somewhere that knows how to handle it, typically a try/catch statement, as shown in the example below:

try
{
    var result = 10 / 0;
}
catch (Exception ex)
{
    throw new Exception("Error: " + ex.Message);
}

If this exception is not handled, it returns to the beginning of the execution and eventually reaches the ASP.NET Core pipeline, resulting in an HTTP error, usually a 500 - Internal Server Error.

When Should Exceptions Be Avoided?

One of the most common mistakes in backend applications is using exceptions for expected situations. If code already expects something to happen, then it’s not exceptional, it’s predictable.

The principle of exceptions is to reserve exceptions for unpredictable situations.

A common example of a situation where exceptions should be avoided is for input data validation. Data validation should never use exceptions as a rule. Note the example below:

if (string.IsNullOrEmpty(user.BankAccountNumber))
{
    throw new Exception("BankAccountNumber is required");
}

The problem here is that the system expects the client to send a user with invalid data. In other words, this is part of the normal flow, not an exception. In this case, the correct approach would be to treat this as data validation and simply return a 400 Bad Request:

if (string.IsNullOrEmpty(user.BankAccountNumber))
{
    return Results.BadRequest("BankAccountNumber is required");
}

When Does Using Exceptions Make Sense?

If exceptions shouldn’t be used in the normal flow, then when do they make sense? In backend applications like ASP.NET Core, exceptions should be used when something truly unexpected happens and the application cannot continue safely or should not continue at all.

Below, we’ll look at practical scenarios where exceptions actually make sense.

Infrastructure Failures

This is a very common scenario. If the database fails here, it’s not possible to proceed normally, meaning it’s an exception:

try
{
    var user = await dbContext.Users.FindAsync(id);
    return Results.Ok(user);
}
catch (Exception ex)
{
    return Results.InternalServerError($"Error retrieving user. Error details: {ex.Message}");
}