DEV Community: Ayomide olofinsawe

Your AI has no memory. Here's How to Add One with Node.js and Mem0

Ayomide olofinsawe — Thu, 19 Mar 2026 22:01:59 +0000

Every chat interface you've ever used feels like the AI remembers you. It doesn't. There's no memory, no session, no awareness of previous conversations. What you're seeing is your application feeding the entire conversation history back into every request. The model just processes whatever is in front of it and forgets everything the moment it responds.

That approach works, but it has real ceilings. The message array grows with every exchange, so longer conversations mean larger payloads and higher token costs. You'll hit context window limits eventually. And across sessions, everything is lost start a new conversation, and the user has to repeat themselves from scratch. There's also no intelligence to it: a throwaway message like "ok thanks" carries the same weight as "I'm building a fintech app in Node.js, and I hate ORMs."

What you actually want is a system that extracts the facts that matter, stores them, and retrieves only the relevant ones when needed without stuffing the entire conversation history into every request.

That's what Mem0 does. It sits between your application and your LLM as a dedicated memory layer: automatically pulling meaningful facts out of conversations, persisting them across sessions, and injecting the right context into future requests.

In this tutorial, we'll build a memory-aware REST API from scratch using:

Express and TypeScript for the API layer
Groq as the LLM provider (fast inference, generous free tier)
Mem0 as the memory layer that ties it all together By the end, you'll have a working API where a user can send a message, have relevant facts automatically extracted and stored, and receive responses informed by everything the system has learned about them across previous conversations.

Let's get into it.

What is Mem0 and How Does It Work

Mem0 is a memory layer for AI applications. The core idea is simple: instead of your application managing conversation history and replaying it on every request, Mem0 handles the memory side of things for you extracting what matters, storing it, and making it available when it's relevant.

How it differs from storing chat history

When you store chat history, you're storing everything every message, in order, as it happened. Nothing is filtered, nothing is prioritized, and the whole thing gets sent back to the model on the next request regardless of whether any of it is actually useful.
Mem0 works differently. After each exchange, it processes the conversation and pulls out meaningful facts things like user preferences, stated goals, technical context, or any detail worth remembering long term. Those facts are stored as discrete memory objects, not as raw messages. When a new request comes in, Mem0 retrieves only the memories that are relevant to it and surfaces them to your LLM as context.
The practical difference is significant. Instead of a growing message array that the model has to wade through, the model gets a compact, relevant summary of what it actually needs to know about the user.

Async processing and automatic fact extraction

Memory extraction in Mem0 happens asynchronously it doesn't block your API response. After your LLM replies, Mem0 processes the conversation in the background, extracts facts, and updates the memory store. It also handles deduplication, so if a user mentions the same detail across multiple conversations, Mem0 won't create redundant memory entries it updates the existing one instead.
This means your API stays fast, and the memory store stays clean over time without any extra work on your end.

Project Setup

In this section, we'll get the project initialized, install everything we need, and configure our environment variables. By the end of this section you should have a working foundation to start building on.

Prerequisites

Before getting started, make sure you have the following:

Node.js v18 or higher
A Groq account for the LLM API key
A Mem0 account for the memory layer API key

Installing dependencies

First, create your project folder and initialize it:

mkdir mem0-express-api && cd mem0-express-api
npm init -y

Then install the runtime dependencies:

npm install express mem0ai openai dotenv

And the dev dependencies:

npm install -D typescript ts-node nodemon @types/express @types/node

Finally, initialize TypeScript:

npx tsc --init

A quick note on the openai package: even though we're using Groq as our LLM provider, Groq's API is OpenAI-compatible, so the openai SDK works against it directly you just point it at Groq's base URL.

Add your scripts

Update your package.json scripts section to look like this:

"scripts": {
  "dev": "nodemon --exec ts-node src/index.ts",
  "build": "tsc",
  "start": "node dist/index.js"
}

Environment variables

Create a .env file at the root of your project:

GROQ_API_KEY=your_groq_api_key
MEM0_API_KEY=your_mem0_api_key
PORT=3000

You can grab your Groq API key from the Groq console and your Mem0 API key from the Mem0 dashboard. Never commit this file add it to your .gitignore.

Building the API

With the project set up, let's walk through the actual code. Here's how everything is structured:

mem0-express-api/
├── src/
│   ├── lib/
│   │   └── mem0.ts
│   ├── routes/
│   │   └── chat.ts
│   └── index.ts
├── .env
├── .gitignore
├── package.json
└── tsconfig.json

Go ahead and create the folders and files to match this structure before we start filling them in.

Setting up the entry point

src/index.ts is where the Express app is initialized. It loads environment variables, registers the chat router under the /chat path, and starts the server:

import "dotenv/config";
import express from "express";
import chatRouter from "./routes/chat";

const app = express();
const PORT = process.env.PORT || 3000;

app.use(express.json());
app.use("/chat", chatRouter);

app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Initializing the Mem0 client

src/lib/mem0.ts initializes the Mem0 client once and exports it for use across the app:

import { MemoryClient } from "mem0ai";

const client = new MemoryClient({
  apiKey: process.env.MEM0_API_KEY!,
});

export default client;

Keeping this in its own file means you initialize the client once and import it wherever you need it, rather than recreating it on every request.

The chat routes

All the route logic lives in src/routes/chat.ts. Here's the full file:

import { Router, Request, Response } from "express";
import OpenAI from "openai";
import mem0 from "../lib/mem0";

const router = Router();

const openai = new OpenAI({
  apiKey: process.env.GROQ_API_KEY!,
  baseURL: "https://api.groq.com/openai/v1",
});

// POST /chat/:userId
router.post("/:userId", async (req: Request, res: Response) => {
  const { userId } = req.params;
  const { message, sessionId } = req.body;

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

  try {
    const memories = await mem0.search(message, { user_id: userId } as any);
    const memoryContext = memories.map((m: any) => m.memory).join("\n");

    const systemPrompt = `You are a helpful assistant with memory of past interactions.${
      memoryContext ? `\nWhat you remember about this user:\n${memoryContext}` : ""
    }`;

    const completion = await openai.chat.completions.create({
      model: "llama-3.3-70b-versatile",
      messages: [
        { role: "system", content: systemPrompt },
        { role: "user", content: message },
      ],
    });

    const reply = completion.choices[0].message.content;

    const addOptions: any = { user_id: userId };
    if (sessionId) addOptions.run_id = sessionId;

    await mem0.add(
      [
        { role: "user", content: message },
        { role: "assistant", content: reply! },
      ],
      addOptions
    );

    res.json({ reply, userId, sessionId: sessionId || null });
  } catch (error: any) {
    res.status(500).json({ error: error.message });
  }
});

// GET /chat/:userId/memories
router.get("/:userId/memories", async (req: Request, res: Response) => {
  const { userId } = req.params;

  try {
    const memories = await mem0.getAll({ user_id: userId } as any);
    res.json({ userId, memories });
  } catch (error: any) {
    res.status(500).json({ error: error.message });
  }
});

// DELETE /chat/:userId/memories
router.delete("/:userId/memories", async (req: Request, res: Response) => {
  const { userId } = req.params;

  try {
    await mem0.deleteAll({ user_id: userId } as any);
    res.json({ message: `All memories cleared for user ${userId}` });
  } catch (error: any) {
    res.status(500).json({ error: error.message });
  }
});

// POST /chat/:userId/no-memory
router.post("/:userId/no-memory", async (req: Request, res: Response) => {
  const { userId } = req.params;
  const { message } = req.body;

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

  try {
    const completion = await openai.chat.completions.create({
      model: "llama-3.3-70b-versatile",
      messages: [
        { role: "system", content: "You are a helpful assistant." },
        { role: "user", content: message },
      ],
    });

    const reply = completion.choices[0].message.content;
    res.json({ reply, userId, memoryUsed: false });
  } catch (error: any) {
    res.status(500).json({ error: error.message });
  }
});

export default router;

Now let's break down what each route does.

POST /chat/:userId is the core route. When a message comes in, it first searches Mem0 for any memories relevant to that message and injects them into the system prompt. The LLM then responds with that context already in place. After the response is generated, the full exchange is passed to mem0.add() which processes it asynchronously and extracts facts worth remembering. The optional sessionId in the request body scopes the memory to a specific conversation thread via run_id useful if one user has multiple distinct conversation contexts.

GET /chat/:userId/memories returns everything Mem0 has stored for a given user. We'll use this in Section 6 to inspect what was actually extracted after a conversation.

DELETE /chat/:userId/memories wipes all stored memories for a user. Useful for resetting state during testing or giving users a clean slate.

POST /chat/:userId/no-memory is a control route that calls the same LLM with the same model but with no memory context at all just a plain system prompt. We'll use this in the next section to show the difference between a memory-aware response and a stateless one side by side.

How Mem0 Stores Memories

When you call mem0.add() after an exchange, Mem0 doesn't just save the raw messages. It processes the conversation, pulls out the facts that matter, and stores them as structured memory objects. Here's what that actually looks like.

After a few conversations as user123, calling GET /chat/user123/memories returns something like this:

{
  "userId": "user123",
  "memories": [
    {
      "id": "a9a14f57-e0ae-4533-82a1-c5e93364fb7b",
      "memory": "Ayomide loves table tennis and enjoys trying different foods",
      "user_id": "user123",
      "categories": ["sports", "food"],
      "created_at": "2026-03-19T05:38:37-07:00",
      "updated_at": "2026-03-19T05:38:41.614883-07:00",
      "structured_attributes": {
        "day": 19,
        "hour": 12,
        "year": 2026,
        "month": 3,
        "day_of_week": "thursday"
      }
    },
    {
      "id": "f0c175d5-1b9a-462a-bf17-88d287271df0",
      "memory": "Ayomide is building an API platform called APIblok",
      "user_id": "user123",
      "categories": ["professional_details", "technology"],
      "created_at": "2026-03-18T11:19:19-07:00",
      "updated_at": "2026-03-18T11:19:17.557120-07:00",
      "structured_attributes": {
        "day": 18,
        "hour": 18,
        "year": 2026,
        "month": 3,
        "day_of_week": "wednesday"
      }
    },
    {
      "id": "ea262dae-72af-48d9-a8e8-4b18cdefa9a5",
      "memory": "Ayomide has 3 years of experience with Node.js and prefers using TypeScript",
      "user_id": "user123",
      "categories": ["professional_details", "technology"],
      "created_at": "2026-03-18T10:55:20-07:00",
      "updated_at": "2026-03-18T10:56:45.972173-07:00",
      "structured_attributes": {
        "day": 18,
        "hour": 17,
        "year": 2026,
        "month": 3,
        "day_of_week": "wednesday"
      }
    }
  ]
}

A few things worth noticing here.

The memory field is a clean, distilled fact not a raw message. Mem0 didn't store "hey I love table tennis and I also like trying new foods", it stored "Ayomide loves table tennis and enjoys trying different foods". The extraction is deliberate and concise.

Categories are automatically assigned. Each memory object comes with a categories array ["sports", "food"], ["professional_details", "technology"] and so on. Mem0 figures these out on its own without any configuration from you. This is what makes retrieval intelligent — when a new message comes in, Mem0 knows which memories are actually relevant to surface.

Deduplication happens automatically. If the user mentions the same detail across multiple conversations, Mem0 won't create a new memory entry every time it updates the existing one instead. You can see this in the updated_at field, which can differ from created_at when a memory has been refined over time.

structured_attributes adds temporal context — recording when the memory was created down to the hour and day of week. This gives Mem0 the ability to reason about recency when deciding what to retrieve.

You can also view and manage all of this visually from the Mem0 dashboard:

The dashboard gives you a real-time view of what's been extracted for each user, which is particularly useful when you're debugging or want to verify that the right facts are being stored.

Testing the API

With the project set up, you'll need two terminal windows open simultaneously for this section. In the first terminal, start the dev server:

npm run dev

You should see Server running on http://localhost:3000. Leave this terminal running — the server needs to stay alive to handle requests. Open a second terminal window to send the curl commands. If you're on Windows, use Command Prompt (cmd) for both terminals rather than PowerShell. PowerShell maps curl to its own Invoke-WebRequest command, which won't work with these examples. If you prefer Git Bash, that works too — it ships with Git for Windows and handles curl correctly.

Windows cmd users: The multiline curl commands below use \ for line continuation, which is a macOS/Linux convention. Windows cmd doesn't support it if you run them as-is, you'll get curl: (3) URL rejected: Bad hostname errors after each line. The request itself will still go through, but to avoid the noise, collapse each command onto a single line. For example:

  curl -X POST http://localhost:3000/chat/user123 -H "Content-Type: application/json" -d "{\"message\": \"Your message here\"}"

Sending your first message

Start with a message that gives the model something worth remembering — some personal or technical context:

curl -X POST http://localhost:3000/chat/user123 \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"Hey, I'm Ayomide. I have 3 years of experience with Node.js and I prefer TypeScript over plain JavaScript.\"}"

You should get back something like:

{
  "reply": "Hi Ayomide! That's a solid background — 3 years with Node.js and a preference for TypeScript is a great combo. TypeScript's type safety really pays off in larger codebases. What are you working on?",
  "userId": "user123",
  "sessionId": null
}

The response itself is unremarkable the model is working with just what you sent it. What matters is what's happening in the background: Mem0 is processing this exchange and extracting facts from it asynchronously.
Wait a few seconds, then send another message to give Mem0 time to finish processing:

curl -X POST http://localhost:3000/chat/user123 \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"I'm currently building an API platform called APIblok.\"}"

Now check what Mem0 has stored:

curl http://localhost:3000/chat/user123/memories

You should see something like:

{
  "userId": "user123",
  "memories": [
    {
      "id": "ec30b7df-38f5-411d-af13-4d42befe4a3e",
      "memory": "Ayomide is currently building an API platform called APIblok.",
      "user_id": "user123",
      "categories": null,
      "created_at": "2026-03-19T14:08:07-07:00",
      "updated_at": "2026-03-19T14:08:07-07:00",
      "structured_attributes": {
        "day": 19,
        "hour": 21,
        "year": 2026,
        "month": 3,
        "day_of_week": "thursday"
      }
    },
    {
      "id": "b0217d62-f54d-4b7e-bca1-e6cf528ee09a",
      "memory": "Ayomide has 3 years of experience with Node.js and prefers TypeScript over plain JavaScript.",
      "user_id": "user123",
      "categories": ["professional_details", "technology"],
      "created_at": "2026-03-19T14:07:18-07:00",
      "updated_at": "2026-03-19T14:08:26.222857-07:00",
      "structured_attributes": {
        "day": 19,
        "hour": 21,
        "year": 2026,
        "month": 3,
        "day_of_week": "thursday"
      }
    }
  ]
}

Mem0 didn't store your raw messages. It extracted the facts that actually matter your experience level, your tech preferences, what you're building and stored them as clean, discrete memory objects. That's the extraction step working exactly as intended.

The before/after comparison

To make the difference concrete, the API has a /no-memory route that hits the same LLM with the same model but with zero memory context. Let's use it.

First, send a follow-up question through the memory-aware route:

curl -X POST http://localhost:3000/chat/user123 \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"What framework would you recommend for my project?\"}"

Sample Response:

{
  "reply": "Given that you're building APIblok an API platform  and you're comfortable with TypeScript, I'd recommend sticking with Express if you want something minimal and flexible, or looking at Fastify if performance is a priority. Both have strong TypeScript support. Hono is also worth a look if you're targeting edge runtimes.",
  "userId": "user123"
}

The response is specific. It knows what you're building, knows you're a TypeScript person, and gives a recommendation that fits your actual context.

Now send the exact same message through the stateless route:

curl -X POST http://localhost:3000/chat/user123/no-memory \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"What framework would you recommend for my project?\"}"

Sample Response:

{
  "reply": "To provide a framework recommendation that fits your needs, I'd love to know more about your project. Here are a few questions to get started:\n\n1. What type of project is it?\n2. What programming languages are you planning to use?\n3. What are the main features and functionalities?\n4. Do you have any specific requirements or constraints?\n5. Are there any particular technologies you're interested in integrating with?",
  "userId": "user123",
  "memoryUsed": false
}

Same model, same question and instead of an answer, you get an interrogation. The stateless route has no idea who you are, what you're building, or what language you use, so it fires back five clarifying questions asking you to repeat everything you've already told it. The memory-aware route answered directly because it already had the context it needed.
This is the ceiling that plain conversation history hits across sessions. Memory context closes that gap without any extra work from the user.

What the memory objects look like

If you've been following along, the memory objects from GET /chat/:userId/memories should look familiar — we walked through the full structure in the previous section. But now that you've seen them generated live from real conversations, the structure makes more sense in context.
A few things worth reinforcing:
The memory field is a distilled fact, not a raw message. Mem0 didn't store "hey I have 3 years with Node and I prefer TypeScript" it stored "Ayomide has 3 years of experience with Node.js and prefers using TypeScript". The extraction is deliberate and concise.

Categories are assigned automatically. Mem0 decided ["professional_details", "technology"] without any configuration from you. This is what makes retrieval intelligent when a new message comes in, Mem0 knows which memories are actually relevant to surface rather than dumping everything into the context.
Deduplication happens in the background. Try sending the same kind of detail twice across two separate requests:

curl -X POST http://localhost:3000/chat/user123 \
  -H "Content-Type: application/json" \
  -d "{\"message\": \"Just a reminder — I work primarily in TypeScript.\"}"

{
  "reply": "I recall that you prefer working with TypeScript over plain JavaScript, and that you have around 3 years of experience with Node.js. You're also currently building an API platform called APIblok. How can I assist you with your TypeScript or APIblok project today?",
  "userId": "user123",
  "sessionId": null
}

The model already knows. Now check the memories endpoint you won't find a new entry for TypeScript. Mem0 recognized it as information it already had and updated the updated_at timestamp on the existing memory rather than creating a redundant one. The store stays clean automatically, with no deduplication logic on your end.
To reset your state between test runs, hit the DELETE endpoint:

curl -X DELETE http://localhost:3000/chat/user123/memories

This wipes all stored memories for user123 and gives you a clean slate to test from scratch.

Conclusion

Most AI applications treat memory as an afterthought they replay conversation history on every request and call it context. That works until it doesn't: context windows fill up, costs climb, and the moment a user starts a new session, everything they've told the system is gone. The problem isn't the LLM. It's the architecture around it.

What we built here takes a different approach. By adding Mem0 as a dedicated memory layer, the API extracts what matters from each conversation, stores it as structured facts, and retrieves only what's relevant on the next request. The result is a system that gets more useful over time — not one that forgets everything the moment a session ends.

To recap what we covered: setting up an Express and TypeScript API with Groq as the LLM provider, initializing Mem0 and wiring it into the request lifecycle, building routes for memory-aware chat, memory retrieval, memory deletion, and a stateless control route for comparison, and testing the whole thing end to end to see extraction, retrieval, and deduplication working in practice.

From here, a few natural directions to explore: scope memories to specific conversation threads using run_id, swap the Mem0 cloud client for a self-hosted instance if you need full data control, or wire this API into a frontend to build a chat interface that actually remembers its users.
The full source code for this tutorial is available on GitHub: [https://github.com/techsplot/mem0-express-api]

Building Reliable Systems in Elixir: The "Let It Crash" Philosophy

Ayomide olofinsawe — Wed, 18 Feb 2026 13:16:49 +0000

Software systems fail. A background job crashes, a request throws an error, or a small bug causes part of an application to stop working. Often, a single failure can affect the entire system.

Most programming languages try to prevent crashes by handling errors everywhere using checks, conditionals, and exceptions to keep the program running.

Elixir takes a different approach. Instead of trying to stop every failure, Elixir assumes that crashes will happen and focuses on ensuring the system can recover quickly when they do.

Elixir runs on the BEAM, a runtime originally designed for systems that must stay online even when parts fail. Rather than letting one error bring everything down, BEAM isolates problems and keeps the rest of the system running.

In this article, we’ll explore how Elixir handles errors, what “let it crash” really means, and how you can use these ideas to build reliable applications.

Why Traditional Error Handling Breaks Down

In many programming languages, handling errors often means trying to prevent failures from happening in the first place. Techniques include:

Input validation
Conditional checks
Exception handling

While this works for small programs, it becomes difficult to manage as systems grow larger and more complex.

Common Challenges

Shared state and dependencies

Components often rely on each other. A failed database call might block a request handler, slowing down the whole system. In worst-case scenarios, a single unhandled error can crash everything.
Accumulation of defensive code

Functions filled with checks and special cases become harder to read, maintain, and reason about. Ironically, this extra complexity can introduce new bugs.

As applications scale, trying to prevent every crash becomes less practical. Instead, some systems focus on containing failures, ensuring that when something goes wrong, the damage is limited.

Elixir embraces this containment-focused approach. Crashes are treated as isolated incidents that can be managed and recovered from.

This leads to one of the most well-known concepts in Elixir: “Let it crash.”

The Elixir Philosophy: “Let It Crash”

At first, “let it crash” may sound reckless. Most developers are taught to prevent crashes at all costs. In Elixir, it means:

Don’t hide serious problems.

If a process encounters an error it cannot safely recover from, let it stop completely.
Use supervisors to recover.

A separate supervisor can restart the failed process in a clean state.

Simply put:

If something is badly broken, don’t keep using it restart it.

Real-World Analogy

Think about your phone. If an app freezes, what do you do?

Force close it
Reopen it

You don’t try to debug it while it’s stuck. Elixir builds systems that work in the same way automatically: crashes are contained, the rest of the system keeps running, and recovery happens cleanly.

Understanding Elixir Processes: Why Failures Stay Isolated

One of the key reasons Elixir can safely “let it crash” is how it runs tasks: each task runs in its own lightweight process.

Characteristics of Elixir Processes

Each process has its own workspace.
Processes don’t share memory directly with others.
Each process handles a specific job independently.

If a process crashes, it does not affect other processes. The rest of the system continues running as if nothing happened.

Analogy: Office Workers

Imagine an office where each worker sits in their own cubicle:

One worker makes a mistake on a task.
That mistake doesn’t spread to others because workspaces are separate.
A manager (the supervisor) notices the error and assigns a new worker.

Why It Matters

Crashes are contained and predictable.
Systems are more reliable.
Developers can focus on building features rather than defensive error handling everywhere.

In short:

Isolated processes + supervision = fault-tolerant systems

Supervisors: How Elixir Recovers Automatically

In Elixir, supervisors watch over processes. Think of a supervisor as a monitoring system for background jobs or microservices.

Supervisors don’t do the work themselves.
Their job is to ensure each process runs correctly.
If a process fails, the supervisor restarts it automatically, keeping the application running smoothly.

Programming Analogy: Job Queue Workers

Imagine a web app with multiple background workers:

Sending emails
Generating reports
Processing user uploads

Each worker runs in its own process:

One worker crashes due to a corrupted file.
The supervisor restarts a fresh worker.
Other workers continue without interruption.

This is similar to job queues like Sidekiq or Celery — but in Elixir, the restart mechanism is built-in.

Key Points About Supervisors

They manage failures, not prevent them.
Can be arranged in hierarchies to watch multiple processes.
Different restart strategies exist depending on the process’s importance.

Takeaway:

Processes crash → supervisors restart them → the app continues running automatically. This is the backbone of Elixir’s “let it crash” philosophy.

Why This Approach Works in Practice

The combination of isolated processes and supervisors makes Elixir applications truly resilient.

Benefits

Crashes are contained

One process crashing doesn’t take down the whole application.
Automatic recovery

Supervisors detect failures and restart processes without developer intervention.
Simpler code

Developers can write straightforward code without defensive clutter.
Scalability and concurrency

Thousands of independent tasks can run simultaneously, thanks to lightweight processes.

Example: Web Application Workers

Worker A: Image uploads
Worker B: Email notifications
Worker C: Report generation

If Worker B fails due to a temporary network issue:

Worker B stops.
Supervisor restarts a fresh Worker B.
Workers A and C continue uninterrupted.

✅ Key takeaway:

Elixir doesn’t try to prevent all failures — it manages them intelligently for reliability and maintainability.

Common Misconceptions and Beginner Mistakes

Overusing try/rescue

Catching every error defeats the purpose of supervisors.
Ignoring supervision trees

Skipping supervisors or using ad-hoc processes leads to fragile systems.
Trying to prevent every failure

Elixir assumes failures are inevitable. Handle them at the system level, not everywhere in code.
Confusing “let it crash” with sloppy coding

It doesn’t mean ignoring logic errors or poor design. It means isolating failures safely.

✅ Key takeaway:

Understand these pitfalls to use Elixir’s fault-tolerant features effectively.

Example Applications Where “Let It Crash” Shines

Messaging Platforms

Thousands of simultaneous messages; one process failing doesn’t crash the system.
Real-Time Analytics and Event Processing

Single faulty events don’t stop the entire pipeline; supervisors restart failed workers.
Background Job Processing

Jobs like email sending or image resizing run independently; failures are restarted automatically.
IoT or Embedded Systems

Each sensor/device runs independently; crashes don’t compromise the rest of the system.

Key Insight:

Elixir’s approach is practical, especially for concurrent, fault-tolerant, high-reliability systems.

Conclusion + Next Steps

Elixir’s approach to error handling — isolated processes, supervisors, and “let it crash” philosophy — provides a new way to build reliable applications.

Key Takeaways

Isolated processes: Crashes don’t affect the whole system.
Supervisors: Automatically monitor and restart failed processes.
Let it crash: Recovering cleanly is often better than over-handling errors.
Real-world impact: Messaging platforms, analytics pipelines, background jobs, and IoT applications all benefit.

Next Steps for Developers

Learn about OTP (Open Telecom Platform)

Provides core abstractions for fault-tolerant Elixir apps.
Experiment with Supervision Trees

Build small apps where supervisors manage multiple processes.
Study real applications

Explore open-source Elixir projects like Phoenix or Nerves to see these concepts in action.

By embracing these ideas, developers can build highly concurrent, reliable, and maintainable systems without writing overly defensive or complex code.

Why Learning Elixir (and programming) Still Matters in the AI Era

Ayomide olofinsawe — Mon, 09 Feb 2026 15:14:05 +0000

For a while now, it feels like nobody talks about programming languages anymore.

Everywhere you look, it’s AI agents, workflows, and tools that can write code almost instantly. The language underneath the code feels invisible almost irrelevant.

So it’s fair to ask:

Why learn a language like Elixir now?

Especially when AI can autocomplete functions, generate examples, and even explain errors.

What Confused Me When I First Met Elixir

Coming from a JavaScript background, diving into Elixir felt like stepping into a whole new world. It wasn’t just the syntax it was the way of thinking.

Concepts like immutability, pattern matching, and functional programming weren’t just unfamiliar; they actively challenged how I was used to writing code.

In JavaScript, I could change a variable whenever I wanted. In Elixir, that same idea felt almost wrong. I had to retrain my brain to think in terms of transforming data instead of changing state.

Functions became first-class citizens, recursion replaced loops, and I realized that side effects were something to be carefully managed, not ignored.

Even simple things like updating a map or handling a conditional made me pause and ask:

“Am I approaching this the Elixir way, or am I forcing JavaScript habits onto it?”

It was confusing. Sometimes frustrating. But it was also the kind of confusion that forces you to build better mental models for programming.

What Made Me Doubt Learning Elixir in the AI Era

What made me doubt learning Elixir wasn’t even Elixir itself it was programming languages in general.

With AI being able to write code, autocomplete logic, and suggest solutions, I started wondering if spending time learning a new language still made sense.

I kept asking myself:

Should I focus on learning a programming language, or should I focus on other things AI can’t easily replace?

From that mindset, learning Elixir felt risky. It’s not as mainstream as JavaScript, and it doesn’t dominate AI conversations.

But that doubt revealed something important.

The hard part wasn’t typing code it was understanding what the code is doing and why it’s structured that way.

AI could generate solutions, but it couldn’t give me intuition. It couldn’t replace the mental shift required to reason about state, failure, and concurrency.

What AI Doesn’t Fully Replace

When I tried to figure out what AI didn’t help me with while learning Elixir, I realized something uncomfortable I couldn’t point to a clear example yet.

Not because AI was doing everything, but because I was still early in the learning process.

AI could explain syntax, generate examples, and suggest solutions. What it couldn’t do was make things feel intuitive immediately.

I still had to sit with concepts like immutability and functional thinking until they slowly made sense.

That gap between seeing an answer and actually getting it is where learning still happens.

AI can shorten the distance, but it can’t skip it.

Learn the Right Way

If there’s one thing I’d tell someone unsure about learning a programming language today, it’s this:

Learn the right way. Learn the basics syntax, core concepts, and mental models then move on to implementation.

Don’t skip the foundation.

AI can fill in code snippets and autocomplete logic, but it can’t replace understanding. That understanding knowing why things work is what makes code reliable and systems easier to reason about.

Learning Elixir isn’t just about writing functions. It’s about training your brain to think clearly about data, state, and failure skills that will still matter no matter how advanced AI becomes.

I am still kinda new to the elixir space looking forward to writing more about elixir and my learning generally

Jess

Ayomide olofinsawe — Wed, 21 Jan 2026 16:36:53 +0000

From Local Model to Production API: A Practical CI/CD Workflow for Machine Learning

Ayomide olofinsawe — Thu, 15 Jan 2026 18:03:41 +0000

Machine learning projects rarely fail because the model is bad they fail when it hits production. A model might run perfectly on your laptop, but moving it into a stable, repeatable environment is a different story. Ad-hoc Docker commands, manual server setup, repeated SSH sessions, and fragile deployment processes turn every code change into a risky, time-consuming operation slowing iteration and making infrastructure management overshadow actual model improvement.

Most ML deployment guides assume access to GPUs, Kubernetes, or specialized MLOps platforms. They often gloss over the real-world headaches of shipping a model that just works. This tutorial takes a different approach: you’ll deploy a CPU-optimized ML API on a single cloud server, bake the model into a Docker container at build time, and automate updates with GitHub Actions. The result is a repeatable, reliable, low-cost workflow that works in real production not just in a notebook or local environment.

In this guide, you’ll build a production-ready deployment pipeline for a lightweight sentiment analysis API using FastAPI and Hugging Face, provision a Vultr Cloud Compute instance, and set up a CI/CD workflow that automatically updates your deployment on every push. By the end, you’ll have a workflow capable of taking any ML model from local development to a live, continuously deployed API.

Prerequisites

To follow along with this tutorial, ensure you have the following in place:

Access to an Ubuntu 24.04 server as a non-root user with sudo privileges
Docker installed on both your local machine and the server
A Docker Hub account for storing container images
A GitHub account with GitHub Actions enabled
Basic familiarity with FastAPI, Docker, and Git-based workflows

This guide focuses on automating machine learning deployments rather than covering server provisioning or Docker installation. Refer to the Vultr documentation if you need assistance preparing your environment.

NOTE
This tutorial focuses on CPU-based deployment. The FastAPI service and Hugging Face model are configured to run on CPU only, making it suitable for cost-effective Vultr Cloud Compute instances without GPU support.

Build a Sample ML Model API

Before automating deployment, you need a machine learning service that behaves predictably in production. In this section, you’ll build a CPU-only sentiment analysis API using FastAPI and Hugging Face Transformers, designed specifically for containerized deployment on Vultr.

The application performs inference only. The model is downloaded once, stored locally, and loaded at startup to ensure fast and reliable requests.

Project Structure

Use the following project layout:

deployment_ml/
├─ app/
│  ├─ main.py
│  ├─ model.py
├─ download_model.py
├─ requirements.txt
└─ models/

This structure keeps the API logic, model artifacts, and dependency management clearly separated.

Define Python Dependencies

Create a requirements.txt file with the following contents:

--extra-index-url https://download.pytorch.org/whl/cpu

fastapi==0.115.6
uvicorn[standard]==0.30.6

torch==2.9.1
transformers>=4.46.3

pydantic>=2.7,<3
python-dotenv==1.0.1

This configuration ensures:

CPU-only PyTorch wheels are used
Compatibility with FastAPI and Pydantic v2
Predictable dependency resolution during Docker builds

Download the Model Locally

Instead of downloading the model at runtime, the application uses locally stored model artifacts. This improves startup time and avoids network dependencies during deployment.

Create a script named download_model.py:

from transformers import AutoModelForSequenceClassification, AutoTokenizer
import os

MODEL_NAME = "distilbert-base-uncased-finetuned-sst-2-english"
LOCAL_PATH = "./models/distilbert-sst2"

os.makedirs(LOCAL_PATH, exist_ok=True)

model = AutoModelForSequenceClassification.from_pretrained(MODEL_NAME)
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)

model.save_pretrained(LOCAL_PATH)
tokenizer.save_pretrained(LOCAL_PATH)

print(f"Model downloaded and saved to {LOCAL_PATH}")

Run the script once to populate the models/ directory.

Implement the Model Wrapper

Create app/model.py to load the model and handle inference:

from transformers import pipeline
import os
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

DEVICE = -1  # Force CPU usage

LOCAL_MODEL_PATH = os.path.join(
    os.path.dirname(__file__),
    "../models/distilbert-sst2"
)

class SentimentModel:
    def __init__(self):
        logger.info(f"Loading sentiment model from {LOCAL_MODEL_PATH} ...")
        self.pipeline = pipeline(
            task="sentiment-analysis",
            model=LOCAL_MODEL_PATH,
            tokenizer=LOCAL_MODEL_PATH,
            device=DEVICE
        )
        logger.info("Sentiment model loaded successfully.")

    def predict(self, text: str):
        result = self.pipeline(text)[0]
        return {
            "sentiment": result["label"].lower(),
            "confidence": round(result["score"], 4)
        }

sentiment_model = SentimentModel()

def predict_sentiment(text: str):
    return sentiment_model.predict(text)

The model is initialized once at application startup, ensuring consistent performance under load.

Create the FastAPI Application

Create app/main.py:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
from app.model import predict_sentiment
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

app = FastAPI(
    title="ML Sentiment Analysis API",
    description="CPU-only ML API deployed with CI/CD on Vultr",
    version="1.0.0"
)

class PredictionRequest(BaseModel):
    text: str = Field(..., min_length=1, example="I love this product")

class PredictionResponse(BaseModel):
    sentiment: str
    confidence: float

@app.get("/")
def health_check():
    return {"status": "Hello from the automated ML deployment!"}

@app.post("/predict", response_model=PredictionResponse)
def predict(request: PredictionRequest):
    try:
        return predict_sentiment(request.text)
    except Exception as e:
        logger.error(f"Prediction failed: {e}")
        raise HTTPException(
            status_code=500,
            detail="Sentiment prediction failed."
        )

Install Dependencies and Run the API

Create a virtual environment

$ python -m venv .venv 
$ source .venv/bin/activate

install all dependencies and update pip

 pip install --upgrade pip
 pip install -r requirements.txt

Download the model:

 python download_model.py

This will create a ./models/distilbert-sst2 folder containing the pretrained Hugging Face model and tokenizer.

Start the API:

 uvicorn app.main:app --host 0.0.0.0 --port 8000

Test the service:

Health check: Confirm the API is running

curl http://localhost:8000/

Output:

{
  "status": "Hello from the automated ML deployment!"
}

Sentiment prediction: Send a test request

curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"text": "This deployment workflow is impressive"}'

Expected outcome: The API should return a JSON object with the predicted sentiment and confidence score, for example:
A successful response confirms the API is ready for containerization.

{
  "sentiment": "positive",
  "confidence": 0.9987
}

Outcome

At this point, you have:

A CPU-optimized ML inference API
Locally packaged Hugging Face model artifacts
Deterministic dependency management
A service ready to be containerized and deployed automatically

Dockerize the ML API

To deploy your ML service reliably on Vultr, we need to containerize the API. Docker ensures that the environment is consistent, reproducible, and isolated, which is essential for CI/CD pipelines and automated deployments.

This section will show you how to:

Create a Docker image that includes your API and model
Bake in the Hugging Face model to avoid runtime downloads
Expose the service port for external access

Create the Dockerfile

In the root of your project directory, create a file named Dockerfile and paste the following content:

# ---- Base image ----
FROM python:3.14-slim

# ---- Environment variables ----
ENV PYTHONDONTWRITEBYTECODE=1
ENV PYTHONUNBUFFERED=1
ENV TRANSFORMERS_CACHE=/app/.hf_cache

# ---- Set working directory ----
WORKDIR /app

# ---- System dependencies ----
RUN apt-get update && apt-get install -y \
    git \
    && rm -rf /var/lib/apt/lists/*

# ---- Install Python dependencies ----
COPY requirements.txt ./
RUN pip install --upgrade pip \
    && pip install --no-cache-dir -r requirements.txt

# ---- Copy application code ----
COPY app ./app
COPY download_model.py ./download_model.py

# ---- Download model at build time ----
RUN python download_model.py

# ---- Expose port ----
EXPOSE 8000

# ---- Run the app ----
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Key Notes:

TRANSFORMERS_CACHE points to a local folder for Hugging Face caching.
download_model.py runs during build, so the container already includes the model.
Port 8000 is exposed for API access.
--no-cache-dir ensures Python packages don’t increase image size unnecessarily.

Create the .dockerignore File

In the root of your project directory, create a file named .dockerignore and paste the following content:

.venv
__pycache__
*.pyc
*.pyo
*.pyd
.git
.gitignore
.env
.cache
models/

[!NOTE]
models/ is ignored because download_model.py ensures the model is downloaded inside the container at build time.

Build the Docker Image

Run the following command in your project root:

 docker build -t sentiment-api .

[!NOTE]
The Docker image name sentiment-api is used throughout this tutorial for simplicity. You can rename it to anything you like, ust make sure to use the same name consistently in subsequent commands, including GitHub Actions workflows or Docker Hub pushes.

Output

The image is created with your Python dependencies and ML model
Logs during build show Loading… and Model downloaded and saved to /app/models/distilbert-sst2
The image size is optimized due to .dockerignore and --no-cache-dir

Run the Docker Container

Start the API in a container:

 docker run -p 8000:8000 sentiment-api

Output

The API runs inside the container
Health check:

 curl http://localhost:8000/

Output:

{"status": "Hello from the automated ML deployment!"}

Test prediction:

 curl -X POST http://localhost:8000/predict \
  -H "Content-Type: application/json" \
  -d '{"text": "Dockerized deployment is smooth!"}'

Output:

{
  "sentiment": "positive",
  "confidence": 0.9981
}

Provision a Vultr Instance

Before deploying your Dockerized ML API, ensure you have access to an Ubuntu 24.04 server as a non-root user with sudo privileges (as noted in the prerequisites).

This section shows how to add your SSH key to Vultr when creating or managing an instance and how to install Docker on your server.

Create an SSH Key (If You Don’t Have One)

If you don’t already have an SSH key, generate one on your local machine:

 ssh-keygen -t ed25519 -C "your_email@example.com"

Press Enter to accept the default file location.
Optionally, set a passphrase for added security.

Your public key will be saved as:

~/.ssh/id_ed25519.pub

Copy Your Public Key

Run:

cat ~/.ssh/id_ed25519.pub

The public key will appear in the terminal.
Select and copy the entire line (starts with ssh-ed25519 and ends with your email or usename).
This is the key you will add to your Vultr server for secure SSH access.

Add SSH Key to Your Vultr Instance

When creating a new Vultr Cloud Compute instance or managing an existing one:

Log in to your Vultr dashboard.
Navigate to Account.
Under SSH Keys, click Add SSH Key.
Paste your public key from Step 2.

Once the server is deployed, note the IP address — you’ll use it to connect via SSH.

Connect via SSH

Use your existing sudo-enabled user to log in:

 ssh username@YOUR_VULTR_IP

Replace username with your sudo-enabled user.
You are now ready to install Docker and deploy your ML API.

Install Docker

Run each command line by line as your sudo user:

Update package lists:

 sudo apt update

Install Docker and Docker Compose:

 sudo apt install -y docker.io docker-compose

Enable Docker to start on boot:

 sudo systemctl enable docker

Start Docker:

 sudo systemctl start docker

Verify installation:

 docker --version

Output:

Docker version 29.1.4, build 0e6fee6

Set up firewall rules for port 8000:

 ufw allow 8000/tcp
 ufw enable

Optional — Test Docker

Run a quick test container:

 docker run hello-world

You should see a confirmation message that Docker is installed and running correctly.

Set Up GitHub Actions Workflow

We’ll automate deployment using GitHub Actions. The workflow will:

Build the Docker image
Push it to Docker Hub
SSH into your Vultr server and deploy the container

Before setting up the workflow, make sure you can push code to GitHub via SSH.

First-Time SSH Setup for GitHub

To push your project over SSH, GitHub needs your SSH public key added to your account (only required once per machine).

Copy your public key:

 cat ~/.ssh/id_ed25519.pub

Copy the entire output (starts with ssh-ed25519 and ends with your email).
Add the SSH key to GitHub:

Log in to GitHub → click your profile → Settings → SSH and GPG keys → New SSH key.
Give it a descriptive title (e.g., “Laptop key”).
Paste your public key in the Key field and click Add SSH key.

Test the connection:

 ssh -T git@github.com

Output:

Hi your-username! You've successfully authenticated, but GitHub does not provide shell access.

You’re now ready to push code to GitHub securely.

Create a GitHub Repository

Go to GitHub and create a new repository for your project.
In your local project folder, initialize Git (if not already done):

 git init

Push Your Project to GitHub

Add your files, commit, and push to the new repository:

 git add .
 git commit -m "Initial commit"
 git branch -M main
 git remote add origin git@github.com:your-username/ml-api.git
 git push -u origin main

Replace your-username and ml-api with your GitHub username and repository name.

Add Repository Secrets

GitHub Actions needs secrets for Docker Hub and your Vultr server:

Secret	Description
`DOCKER_USERNAME`	Your Docker Hub username
`DOCKER_PASSWORD`	Your Docker Hub password
`VULTR_HOST`	Vultr server IP
`VULTR_USER`	SSH username (sudo-enabled user)
`VULTR_SSH_KEY`	Private SSH key corresponding to the public key on the server
`VULTR_PORT`	SSH port (default 22)

Add them via Settings → Secrets and Variables → Actions → New repository secret.

Create the Workflow File

In your project root, create the directory and file:

.github/workflows/deploy.yml

Paste the following workflow code:

name: CI/CD Deploy to Vultr

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Verify Docker username
        run: |
          if [ -z "${{ secrets.DOCKER_USERNAME }}" ]; then
            echo "Error: DOCKER_USERNAME secret is empty!"
            exit 1
          fi
          echo "Docker username is set ✅"

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build and Push Docker Image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ secrets.DOCKER_USERNAME }}/sentiment-api:latest
            ${{ secrets.DOCKER_USERNAME }}/sentiment-api:${{ github.run_number }}

      - name: Deploy to Vultr
        uses: appleboy/ssh-action@v0.1.6
        with:
          host: ${{ secrets.VULTR_HOST }}
          username: ${{ secrets.VULTR_USER }}
          key: ${{ secrets.VULTR_SSH_KEY }}
          port: ${{ secrets.VULTR_PORT }}
          script: |
            docker pull ${{ secrets.DOCKER_USERNAME }}/sentiment-api:latest
            docker stop sentiment-api || true
            docker rm sentiment-api || true
            docker run -d \
              --name sentiment-api \
              -p 8000:8000 \
              --restart always \
              ${{ secrets.DOCKER_USERNAME }}/sentiment-api:latest

Push Workflow to Trigger Deployment

 git add .
 git commit -m "Add CI/CD workflow"
 git push origin main

GitHub Actions will automatically run the workflow.
Your Dockerized ML API will be built, pushed, and deployed to your Vultr server.

Test Automatic Deployment

With the GitHub Actions workflow in place, you can now verify that your Dockerized ML API deploys automatically to your Vultr server whenever you push changes.

Make a Code Change

For example, you can update the health check message in app/main.py:

@app.get("/", tags=["Health"])
def health_check():
    return {"status": "Hello from the automated ML deployment! tested and trusted ✅"}

Save your changes locally.
This minor update is enough to trigger the CI/CD workflow.

Commit and Push

 git add .
 git commit -m "Update health check message"
 git push origin main

GitHub Actions will automatically detect the push.
The workflow will build the Docker image, push it to Docker Hub, and deploy it to your Vultr server.

Monitor Deployment

Go to your repository → Actions tab.
Click on the latest workflow run.
You’ll see step-by-step logs:
Checkout repository ✅
Set up Docker Buildx ✅
Log in to Docker Hub ✅
Build and push Docker image ✅
Deploy to Vultr ✅

Any errors will appear in the logs, making debugging straightforward.

Verify on Vultr

Once the workflow completes, check your API:

 curl http://YOUR_VULTR_IP:8000/

Output

{
  "status": "Hello from the automated ML deployment! ✅"
}

Next, test the prediction endpoint:

 curl -X POST http://YOUR_VULTR_IP:8000/predict \
-H "Content-Type: application/json" \
-d '{"text": "I love this product!"}'

Output:

{
  "sentiment": "positive",
  "confidence": 0.9987
}

This confirms the latest code changes are live on your Vultr server.
Each subsequent push to main will automatically deploy updated containers.

Pro Tips:

If the workflow fails, check the Actions logs for errors in Docker build, push, or SSH deployment.
You can rename your container in the workflow if you want multiple APIs on the same server.
For safety, consider adding a rollback strategy (optional) if a deployment introduces a bug.

Add a Rollback Strategy (Optional)

In case a deployment introduces an issue, you can quickly roll back to a previous version of the API using Docker image tags.

Each deployment pushes two tags to Docker Hub:

latest – the most recent deployment
A numbered tag (for example, sentiment-api:42) representing a specific build

If the latest deployment fails, you can redeploy a previous version directly on your Vultr server.

SSH into your server
Stop and remove the current container
Run a previous image tag

Stop and remove the current container:

docker stop sentiment-api
docker rm sentiment-api

Run the previous stable image:

docker run -d \
  --name sentiment-api \
  -p 8000:8000 \
  --restart always \
  your-docker-username/sentiment-api:42

This immediately restores the last stable version without rebuilding or modifying the CI/CD pipeline.

Conclusion

Automating machine learning deployments is often the missing link between experimentation and production. By combining Docker, GitHub Actions, and Vultr Cloud Compute, you can turn a local ML model into a continuously deployed, production-ready API with minimal operational overhead.

In this tutorial, you:

Built a CPU-efficient ML API using FastAPI and Hugging Face
Containerized the application for consistent deployments
Prepared a Vultr server for hosting Dockerized workloads
Implemented a CI/CD pipeline that deploys automatically on every push
Verified live updates and added a lightweight rollback option

Vultr’s straightforward infrastructure and predictable pricing make it an excellent platform for deploying ML services—whether you’re shipping a prototype, running internal tools, or serving real users in production.

With this foundation in place, you can confidently extend the workflow to support additional models, environments, or scaling strategies as your MLOps needs grow.

🛡️ AgentGuard: Secure and Govern Your AI Agents with Auth0 for AI

Ayomide olofinsawe — Mon, 27 Oct 2025 03:54:47 +0000

This is a submission for the Auth0 for AI Agents Challenge

What I Built

AgentGuard is a security and governance platform for AI agents — designed to protect how enterprise AI agents interact with external APIs, tools, and sensitive data.

Today, organizations build powerful AI assistants that can access Slack, Stripe, HR systems, or internal APIs. But what happens when one of these agents tries to access a resource it shouldn’t?
That’s where AgentGuard steps in.

The Problem:
AI agents often operate without proper guardrails — no authentication for users prompting them, no authorization boundaries for tools they access, and no audit logs for compliance teams.

The Solution:
AgentGuard acts as a control layer between humans, AI agents, and external APIs. It authenticates users, authorizes agent actions, and provides real-time governance through Auth0’s identity and policy management system.

With AgentGuard, every agent action is:

Authenticated (user identity verified with Auth0)

Authorized (checked against a policy engine)

Audited (logged for compliance visibility)

Demo

🔗 GitHub Repository: https://github.com/techsplot/Agentguard_new

🖼️ Screenshots

Agent Dashboard: Register and monitor agents securely.

Chat Interface: Interact with AI agents safely, backed by Auth0 authentication.

Logs View: Real-time audit of agent activities and policy checks.

(Attach screenshots or screen recordings of the UI — dashboard, logs, chat, etc.)

How I Used Auth0 for AI Agents

This project was purpose-built to showcase Auth0 for AI’s three core capabilities:
Authentication, Authorization, and Token Control — all integrated seamlessly into an AI-agent-driven architecture.

🧱 1. User Authentication

Users sign in via Auth0’s Universal Login to access the AgentGuard dashboard.
Protected routes ensure only authenticated users can register or interact with agents.

🧩 2. Token Vault Simulation

Before an agent can call an external API (like Slack or Stripe), AgentGuard generates a short-lived access token through a mock Auth0 Token Vault.
Each token:

Is tied to a specific agent and action.

Expires after a short period.

Is logged for traceability.

This prevents agents from misusing permanent credentials or accessing unauthorized resources.

🛡️ 3. Fine-Grained Authorization (FGA)

A Policy Engine checks if each action is allowed for the given agent:

{
"agent": "Stripe Bot",
"allowedTools": ["Stripe"],
"restrictedActions": ["refundOver500USD"]
}

If an agent tries something beyond its defined scope, the action is denied — and the attempt is logged for review.

🧠 4. AI Interaction via Gemini

AgentGuard uses Gemini 2.5 Flash to power intelligent agent responses.
Every response is mediated through Auth0’s guardrails — ensuring only authorized actions trigger model calls.

Lessons Learned and Takeaways

AgentGuard embodies a vision where AI agents operate responsibly — always within defined limits, fully observable, and entirely secure.

As AI becomes more autonomous, tools like Auth0 for AI Agents will be the backbone of trustworthy AI ecosystems.

devchallenge for googleaichallenge and it is an ai powered app that allows you to get summary fom video and questions to answer based on that video also there is the amazing feature for writer and also generate blog ideas from the video

Ayomide olofinsawe — Thu, 02 Oct 2025 01:00:47 +0000

Ayomide olofinsawe

Sep 15 '25

Lecture lab AI: Transform Lectures into Summaries, Questions, and Blog Ideas

#devchallenge #googleaichallenge #ai #gemini

218

Comments 28

2 min read

🌍AI-Powered Disaster Relief Dashboard with KendoReact, Twilio, and Gemini

Ayomide olofinsawe — Mon, 29 Sep 2025 05:17:54 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

I built a Disaster Relief Resource Dashboard – a React web app designed to help NGOs, volunteers, and aid coordinators manage disaster response operations more effectively.

The app solves three key problems during disaster response:

Resource Tracking → Manage critical resources like food, water, medicine, and shelter, and keep stock levels up-to-date.
Volunteer Scheduling → Register and assign volunteers to shifts and locations, with an integrated notification system (via Twilio SMS).
Impact Visualization → Use interactive charts to visualize resource distribution, aid progress, and overall relief impact.

🔮 Bonus Feature: A contextual AI Assistant Widget, powered by Google Gemini + KendoReact Conversational UI. The AI assistant can answer questions like:

“How many food packs do we still have left?”
“Which volunteers are free tomorrow?”
“What’s the biggest gap in our current resource stock?”

The assistant uses contextual information (selected disaster type + available resources) to provide more accurate and actionable answers.

This project demonstrates how KendoReact free components + AI integration can be used to solve a real-world problem in disaster management.

Demo

github link
Live url

here are some ui flow of the app

this is the dahboard that showing all the pages we have and also how you can see resources available

this ui is responsible for adding diaster

this is the voulunteer page wheree voulunteer can be added and a notification is sent to them via sms in real time using twillo

here is the proof that the sms is been sent to a real number

The analysis dahboard help in analysing and seeing chart of voulteers and also resources

the ai ui which is powered by gemini enable context based answers and can update pages based on prompt from user e.g i can tell it to increase the number of resources in a disater or all disaster and i can tell it otherwise

KendoReact Components Used

I used a wide range of KendoReact components (well above the 10 required):

Grid → Resource management table.
DropDownList → Filter resources by category.
NumericTextBox → Update stock quantities.
Upload → Upload delivery proof documents.
Button → Save actions and trigger updates.
Scheduler → Assign volunteers to shifts/locations.
Form → Register new volunteers.
DatePicker → Assign shifts/dates.
Chart (bar/line) → Distribution by region.
PieChart → Aid breakdown by category.
Card → Quick relief stats.ProgressBar → Show progress toward aid targets.

[Optional: Code Smarter, Not Harder prize category] AI Coding Assistant Usage

I used GitHub Copilot and the KendoReact AI extension to speed up development.

Copilot generated starter code for each page (Resources, Volunteers, Analytics).
I provided prompts to contextualize the AI assistant, ensuring it always reads the selected disaster type and available resources.
The AI assistant was built as a floating widget using Copilot-generated boilerplate, refined with Kendo UI components.

This saved significant time, allowing me to focus on the logic and integration instead of writing every component from scratch.

[Optional: RAGs to Riches prize category] Nuclia Integration

❌ Not integrated (I explored Nuclia RAG but couldn’t proceed due to account setup limitations).
✅ Instead, I used Google Gemini as the AI backend, making the AI Assistant widget functional and contextual without RAG for now.

Thanks dor reading

Lecture lab AI: Transform Lectures into Summaries, Questions, and Blog Ideas

Ayomide olofinsawe — Mon, 15 Sep 2025 03:49:46 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I built an AI-powered lecture assistant that transforms lengthy lecture transcripts into concise summaries, generates questions for self-assessment, and even crafts content ideas for blogs or learning journals on platforms like Medium, Dev.to, or personal blogs.

This web app operates in two phases:

Lecture Analysis & Summarization:

Accepts raw lecture text input
Sends it to a custom AI workflow built in Google AI Studio
Instantly returns a clean, easy-to-digest summary

Content & Learning Assistance:

Generates self-assessment questions based on the lecture
Provides article and content ideas so learners can document their study journey or share insights online It’s a lightweight, accessible tool designed for students and content creators who want to learn, review, and share knowledge efficiently.

Demo

Originally, I planned to deploy the app using Google Cloud Run, but due to card verification issues, I switched to Netlify for hosting so reviewers can still access the live demo seamlessly.

Live Demo (Hosted on Netlify): Netlify
GitHub Repository: Github repo
AI Studio Workflow File: View Saved File

And also here is the link to the full demo video on Youtube.
Video link

Screenshots:
here are the screen shot of some of the ui:

this is the landing page:

here is the search box and the result:

Selected video :

How I Used Google AI Studio

I used Google AI Studio to:

Design and test the AI prompt for summarizing lecture transcripts
Fine-tune the response formatting for clarity and conciseness
Export the workflow so it could be integrated into a simple web application

The saved AI Studio file above verifies the use of the platform and allows others to see exactly how the workflow was built.

Multimodal Features

Our system transforms lecture content into interactive, multimodal learning experiences through the following stages:

Audio/Video → Text → Structured Modules
Gemini-2.5-Flash converts lectures into accurate transcripts, then organizes them into learning modules with quizzes, flashcards, and AI-generated practice questions.
Text → Image Storytelling
Imagen-4.0-Generate-001 brings story-driven learning segments to life as engaging visuals, creating strong memory cues for students.
Text ↔ Image Matching Challenges
Learners complete interactive matching exercises before lessons begin—pairing terms with images to build active recall and conceptual understanding.
Text → Speech Narration
Using the Web Speech API, summaries and story scenes are turned into clear, natural-sounding audio to support auditory learners and improve accessibility.

Conclusion

This project demonstrates how Google AI Studio can be combined with a simple frontend to deliver practical, student-focused solutions in a short amount of time.

All source code, demo links, and workflow files are available above for anyone to explore or extend.

How to Connect Your Name.com Domain to Netlify: A Beginner’s Guide

Ayomide olofinsawe — Sun, 14 Sep 2025 13:29:58 +0000

I have to admit something upfront: before this, I had zero experience with domain configuration. I always thought connecting a domain to a hosting platform was just a matter of a few clicks. Turns out, it’s not always that simple—especially if you make a mistake like I did.
Recently, I bought a domain on Name.com and deployed a project on Netlify. My goal was simple: connect my shiny new domain to my Netlify site so it would look professional. But the process wasn’t as smooth as I expected.
In this article, I’ll share exactly what happened, the mistakes I made, and how I finally got it right. Hopefully, this will save you from the headaches I had.

Step 1: Buying My Domain on Name.com

This part was straightforward. I searched for my desired domain name, saw it was available, and bought it. Within minutes, I had access to the Name.com dashboard where all my domain settings live.

"Here’s what my Name.com dashboard looked like after buying the domain. This is where all the DNS settings live."

Step 2: Deploying My Site on Netlify

I already had my site deployed on Netlify (via GitHub integration). Netlify automatically gives you a temporary URL like your-site.netlify.app.
The goal was to replace that with my custom domain: mydomain.com.

Step 3: Adding the Custom Domain in Netlify

Inside the Netlify dashboard:
I clicked on Domain Settings → Custom domains.

Added my new domain name (e.g., mydomain.com).

"In Netlify, I went to Domain Settings → Custom domains and typed in my new domain name here."
Netlify then provided me with DNS records to add on Name.com—CNAME, A records, and sometimes TXT records for verification.

"After adding the domain, Netlify provided these DNS records that I needed to add on Name.com."

Step 4: The Big Mistake—Changing Name Servers Instead of DNS Records

This is where things went wrong.
Instead of adding only the DNS records Netlify gave me, I went ahead and changed the name servers on Name.com to point to Netlify.
What happened?
My email stopped working because changing name servers moved all domain control to Netlify.

My domain wasn’t resolving properly because I didn’t set up email or DNS records correctly on Netlify.

I learned the hard way:
If you only want to connect your website but keep your email working, don’t change name servers. Only add the records Netlify asks for under DNS management on Name.com.

"This was my mistake: instead of just adding DNS records, I changed the name servers to point to Netlify—and my email stopped working."

Step 5: Fixing the DNS on Name.com

After some research (and frustration), I realized what I needed to do:
Revert the name servers back to the default Name.com ones.

Add the CNAME and A records provided by Netlify in the DNS records section.

"Here’s the correct way: I reverted to Name.com’s default name servers and added the CNAME and A records provided by Netlify."
Once saved, it took about 30–60 minutes for everything to propagate.

Step 6: The “It Finally Worked” Moment

After refreshing (and waiting a bit), my site finally showed up on my custom domain. Email started working again, and I learned a lot in the process.

"After waiting for DNS propagation, my site finally loaded on my custom domain—mission accomplished!"

Optional: Confirming DNS Propagation

To be extra sure, I used a tool like WhatsMyDNS to confirm that my DNS changes had propagated globally before celebrating.

"I used a tool like WhatsMyDNS to confirm my domain changes were fully propagated before celebrating."
Lessons I Learned
Don’t change name servers unless you know exactly what you’re doing.

Stick to DNS record updates when pointing your domain to hosting providers.

Propagation takes time—sometimes up to 24 hours. Don’t panic if things don’t work instantly.

Conclusion

What started as a simple task turned into a learning experience. But in the end, I now have a professional domain connected to my Netlify site—and my email works too.
If you’re setting this up for the first time, follow the steps carefully, avoid changing name servers unnecessarily, and be patient during DNS propagation.

What I learned building a GraphQL API with Prisma, SQLite & Node.js (Part 1)

Ayomide olofinsawe — Wed, 14 May 2025 10:37:37 +0000

Introduction

Have you ever wanted to build your own backend API but felt overwhelmed by terms like GraphQL, resolvers, and databases? Good news — you’re in the right place!
In the world of APIs, REST has been the traditional choice for a long time. However, GraphQL is becoming increasingly popular because it allows clients to request exactly the data they need — no more, no less. Instead of multiple endpoints like in REST, GraphQL gives you one smart endpoint that does exactly what you ask.

Why Choose GraphQL Over REST?

Traditional REST APIs can become bulky with multiple endpoints and overfetching data. GraphQL solves this by providing a single flexible endpoint where clients can ask for exactly what they need, making APIs more efficient and developer-friendly. Companies like GitHub, Shopify, and Facebook use GraphQL in production for this very reason.
In this article, I'll walk you through what I learned while building my first GraphQL API using Node.js, Prisma ORM, and SQLite. Whether you're new to GraphQL or just curious about a different way to build APIs, this guide is for you.
By the end, you’ll have a running GraphQL server that can create and fetch task data — and you'll truly understand the core concepts behind it. Even better, you’ll walk away with a working backend that you can connect to a frontend project later!
Let's dive in and make backend development fun and simple!

Why This Project Matters

Learning GraphQL and Prisma together is a superpower for modern developers. Many real-world applications — from simple todo apps to complex booking systems — rely on APIs to manage and share data.
By mastering how to build a GraphQL API with Prisma, you're opening the door to:

Building fullstack applications faster
Writing cleaner and more efficient backend code
Creating projects you can showcase in your portfolio

We’ll keep it practical by building a simple "Task Manager" API. You’ll be able to:

Create new tasks
Mark them as completed
Fetch all tasks easily

What I Learned

Building this project was not just about writing code; it was about understanding the underlying architecture and how modern APIs function.

Here are some of the key lessons I took away:

GraphQL is powerful because it gives clients control. Instead of relying on multiple endpoints like REST, I could get exactly the data I needed.
Prisma makes database operations simpler. Defining models and generating a client in just a few commands felt incredibly efficient.
SQLite is perfect for quick prototyping. I didn’t need a heavy setup, and yet I had a real database running within minutes.
Error messages like Unexpected end of input are common when a script is incomplete — in my case, I had missed a closing bracket in server.js. Debugging is part of the process!
This hands-on experience helped me appreciate the modern tools that simplify backend development.

Prerequisites

Before we dive in, make sure you have the following:

Node.js installed (v16 or higher) ➔ Download Node.js
Basic command-line knowledge
Code editor (like VS Code)
Postman or GraphQL Playground installed (or VS Code extension)
(Optional) SQLite Browser ➔ Download SQLite Browser Don't worry — I’ll explain every step so you can follow along easily!

Project Setup

Create a new project folder

mkdir graphql-prisma-api
cd graphql-prisma-api

Initialize a Node.js project

npm init -y

Install dependencies

npm install express graphql express-graphql prisma @prisma/client sqlite3 dotenv

Initialize Prisma

npx prisma init

This will create a new prisma folder and a .env file.
Your project folder should now look like:
graphql-prisma-api/
├── node_modules/
├── prisma/
│ └── schema.prisma
├── .env
├── package.json
└── package-lock.json

Setting Up the Database with Prisma and SQLite

Configure your .env file Replace the value of DATABASE_URL with:

DATABASE_URL="file:./dev.db"

Define your Prisma model Replace the contents of prisma/schema.prisma with:

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

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

model Task {
  id          Int      @id @default(autoincrement())
  title       String
  description String
  completed   Boolean  @default(false)
  createdAt   DateTime @default(now())
}

Migrate the database and generate the client

npx prisma migrate dev --name init

This creates a dev.db SQLite file and generates the Prisma client for database access.
You now have a real database ready to store tasks!

Building the GraphQL Server

Create a server.js file

touch server.js

Add the following code to server.js

const express = require('express');
const { graphqlHTTP } = require('express-graphql');
const { buildSchema } = require('graphql');
const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient();
const app = express();

const schema = buildSchema(`
  type Task {
    id: Int!
    title: String!
    description: String!
    completed: Boolean!
    createdAt: String!
  }

  type Query {
    getTasks: [Task!]!
  }

  type Mutation {
    createTask(title: String!, description: String!): Task!
    completeTask(id: Int!): Task!
  }
`);

const root = {
  getTasks: async () => await prisma.task.findMany(),
  createTask: async ({ title, description }) => {
    return await prisma.task.create({
      data: { title, description },
    });
  },
  completeTask: async ({ id }) => {
    return await prisma.task.update({
      where: { id },
      data: { completed: true },
    });
  },
};

app.use('/graphql', graphqlHTTP({
  schema,
  rootValue: root,
  graphiql: true,
}));

const PORT = process.env.PORT || 4000;
app.listen(PORT, () => {
  console.log(`🚀 Server running at http://localhost:${PORT}/graphql`);
});

Run the server

node server.js

Visit: http://localhost:4000/graphql

Testing the API

You can test your API using GraphiQL in your browser.

1.Fetch all tasks

{
  getTasks {
    id
    title
    description
    completed
    createdAt
  }
}

2.Create a new task

mutation {
  createTask(title: "Write article", description: "Finish GraphQL tutorial") {
    id
    title
    completed
  }
}

3.Complete a task

mutation {
  completeTask(id: 1) {
    id
    title
    completed
  }
}

Why GraphQL Is So Efficient

One of the coolest things I learned while building this project is how GraphQL optimizes data fetching. Unlike REST APIs that use multiple endpoints, GraphQL uses a single smart endpoint that serves as the parent node. From there, it dynamically moves to fetch only the specific child nodes (fields) you request.
GraphQL operates kind of like a breadth-first search algorithm, scanning through the structure of your schema tree level by level. It doesn’t fetch unnecessary data — just what you ask for. This makes responses faster, reduces payload size, and improves performance overall.

Conclusion

Congratulations! You've just built your first GraphQL API using Node.js, Prisma, and SQLite. You now have:

A working GraphQL server
A real SQLite database
The ability to create and fetch tasks

This is a great foundation for fullstack development. In the next part, we’ll improve this setup with TypeScript, Prisma validation, and real-time subscriptions.

Coming Next:
Level Up Your GraphQL Server: TypeScript, Prisma, and Real-Time Features
Thanks for reading! 🚀

Learn More

Here are some helpful resources if you'd like to dive deeper:

GraphQL Official Docs
Prisma Documentation
SQLite Documentation
Node.js Docs
Express GraphQL

How I Optimized Database I/O from 100 Seconds to 3ms Using Multi-Level Indexing

Ayomide olofinsawe — Sat, 15 Feb 2025 15:52:53 +0000

Introduction

As a software developer, I recently learned how to optimize database performance, particularly focusing on improving the efficiency of reading 1 million records from a hard disk. Initially, this process took 100 seconds, but by implementing multi-level indexing, I was able to reduce the read time to just 3 milliseconds.

This article documents my learning process and the steps I took to achieve this optimization. I will:

Explain how data is stored on a hard disk and how database queries interact with storage.
Implement multi-level indexing to optimize search performance.
Calculate the disk access cost and optimize the I/O operation time to 3ms.
Compare performance improvements before and after indexing.

Understanding Data Storage on Hard Disks

A hard disk consists of circular platters divided into concentric tracks and further subdivided into pie-shaped sectors. The intersection of a track and a sector form a file block.

Key Definitions:

File Block Size: Approximately 4KB.
I/O Operations: Read/write operations occur in terms of file blocks.

How Data is Read from a Hard Disk
Before this optimization, I had a limited understanding of how data is read from a hard disk. I discovered that when an I/O operation is performed:

The entire file block is loaded into RAM.
The RAM processes the data.
The processed data is returned to the hard disk if updated.

Hard Disk Structure Representation

Diagrammatic representation of hard disk

Performance Analysis: Reading 1 Million Records

Given:

Each record size = 400 bytes
Each file block size = 4KB (4000 bytes)
Number of records per block = 4000 / 400 = 10 records per block
Total records = 1,000,000
Number of required file blocks = 1,000,000 / 10 = 100,000 (10^5) blocks
Disk read time per block = 1 ms
Total time to read all records = 100,000 ms = 100 sec

Problem Statement:
After realizing that reading 1 million records in 100 seconds was inefficient, I started researching ways to optimize search operations and reduce read time to 3 ms.

Optimizing Search with Multi-Level Indexing

Step 1: Creating an Index Table
To reduce the number of blocks that need to be scanned, I created an index table that acts as a shortcut to access file blocks more efficiently.

Each index entry requires 10 bytes, and since each block stores 4KB (4000 bytes), it can hold:
4000 / 10 = 400 index entries per block

Step 2: Reducing Block Access with Indexing

Initially, 100,000 blocks needed to be scanned.
The index table reduced this to 250 blocks.
Searching the index table takes 250 ms.
An additional 1 ms is required to read the corresponding data block.

- Total optimized time = 251 ms.

Step 3: Implementing Multi-Level Indexing

I then discovered that a multi-level indexing approach could further optimize search efficiency. By introducing a second-level index, I could reduce block access even further.

Each block stores 400 index entries.
The first index table contains 250 entries.
A second-level index table is created, requiring only 1 block.

Now, the search process follows these steps:

Read the second-level index (1 ms).
Find the correct block in the first-level index (1 ms).
Access the actual data (1 ms).

Multi-Level Index Table Representation

Final Optimized Time

Total read operations: 3 ms (compared to 100 sec initially).
This technique, called Multi-Level Indexing, is implemented using a B-tree structure.

Conclusion

Throughout this process, I learned how indexing is crucial role in optimizing database search performance. Using multi-level indexing, I successfully reduced the read time for 1 million records from 100 sec to 3 ms. This method significantly improves search performance in large datasets by minimizing disk I/O operations.
This was a fascinating deep dive into database optimization, and I now have a much stronger understanding of indexing and search performance tuning.

If you want to learn more about database check out this video click here