# Prakhar Shukla

> Serial founder and software engineer. Former Founding Engineer at Yobr (Norway). Built products with 2.5M+ downloads and $140K+ revenue. Specializing in TypeScript, React, Node.js, and AI/ML (Vercel AI SDK, Mastra).

## Experience

- Founding Engineer (Full-Time) — Yobr (yobr.io) - Oslo, Norway (May 2025 - Dec 2025)
- Software Engineering Intern — Yobr (yobr.io) - Oslo, Norway (April 2025 - May 2025)
- Software Engineering Intern - Full-Stack Development & AI Integration — CaseCraft (NUS Singapore) (July 2024 - Oct 2024)
- Lead Developer - Full-Stack & Mobile Multi-Tenant E-commerce Platform — Lumoflo (April 2024 - Present)
- Lead Developer - Ranks No. 1 on Google Play Store for "Linux" keyword, Over 1.7M+ downloads — Andronix (April 2019 - Present)

---

# Projects

## Andronix

https://prakhar.codes/projects/andronix/

## What is Andronix App?
Andronix helps you to install Linux distributions like Ubuntu, Debian, Manjaro, Kali etc. on un-rooted Android devices.

## How does this work?

Andronix is simple inside the hood (well not really, but most of it is simple to understand). Andronix uses **PRoot** to
run your favourite Linux distribution on your Android devices.

### What exactly is PRoot?

As stated in the official website of PRoot

> PRoot is a user-space implementation of **chroot, mount --bind, and binfmt_misc**. This means that users don't need
> any privileges or setup to do things like using an arbitrary directory as the new root file system, making files
> accessible somewhere else in the file system hierarchy, or executing programs built for another CPU architecture
> transparently through QEMU user-mode.


or in easier words, the benefits of enabling PRoot include running Linux operating systems in a
Termux [chroot](https://en.m.wikipedia.org/wiki/Chroot) on an Android smartphone, tablet and Chromebook.

We use **Termux** to provide the command line and the packages that are especially compiled for Termux implemented
inside Andronix

## My contribution to Andronix

### Android App

- I have developed the entire Android app using Kotlin and the **Model-View-ViewModel (MVVM) architecture**. This modern
  programming language, along with the powerful MVVM design pattern, has allowed me to create a scalable and
  maintainable codebase for the app.
- Utilized **Retrofit** to handle all API calls in our app. This popular HTTP client simplifies the process of making
  network requests and allows for a more efficient and reliable communication with our backend servers.
- Used Firebase Realtime Database and Firestore, and all the realtime listeners are handled using Kotlin's **StateFlow**
  and **SharedFlow** which are passed to the ViewModel and then to the UI using Kotlin coroutines.
- Andronix uses **Hilt**, a dependency injection library developed by Google, to efficiently manage and maintain the
  dependencies within the app. The implementation of this software design pattern, along with Hilt's code generation and
  testing support, results in a more robust and reliable user experience in Andronix.
- I have created a wrapper around the **Google Play Billing library v5.0** to allow for easier integration of payments
  in our app. By implementing this custom solution, I have been able to streamline the integration process and improve
  the overall user experience when making payments within the app.
- Implemented **single activity architecture** using **Jetpack Navigation Component**. This allows for a more efficient
  and reliable user experience when navigating between different screens in the app.

### Frontend

- I have developed the frontend of the Andronix app's websites using **NuxtJS** and **VueJS**, two popular JavaScript
  libraries. I have also employed TailwindCSS for styling, resulting in a visually appealing and user-friendly website.
  The combination of these technologies has allowed me to efficiently create and maintain the websites for our app
- Completely re-designed the websites from scratch and implemented a **modular approach** in the coding process. This
  systematic method of development has resulted in a more organized and efficient codebase, allowing for easier
  maintenance and updates to the websites.
- I have implemented automated **end-to-end testing** using **CypressJS** in order to ensure the quality and reliability
  of the websites. This powerful testing tool allows me to simulate user actions and verify that the websites are
  functioning as intended, ultimately improving the user experience.
- Implemented **unit testing** using the popular libraries **chai** and **mocha** in order to thoroughly test the
  individual components of the websites. This approach allows me to identify and fix any issues at the unit level,
  resulting in a more robust and reliable website overall.
- Added **Razorpay**, a payment gateway, to the websites in order to enable payments for our users. This integration
  allows us to securely process transactions and expand the functionality of the websites.

### Backend

- Developed the backend of Andronix to efficiently handle download requests at scale. The backend is powered by NodeJS (
  using the **ExpressJS** and **NestJS** frameworks), **Firebase**, **Hasura** (using **GraphQL**), and **Apollo
  GraphQL** for internal tooling. In order to ensure the quality and reliability of the backend, I have implemented
  testing using **ChaiJS** and **MochaJS**.
- Refactored the code to **Typescript** in order to improve the type safety and maintainability of the backend. This
  effort has resulted in an increase in the test coverage to over 80%. Additionally, I have utilized the Firebase
  emulators to increase the integration **test coverage from 0% to 78%**.
- **Modularized the API** into Internal, Commerce, and Product APIs in order to improve the organization and
  maintainability of the backend. This approach has allowed me to reduce the time spent on maintenance and more
  efficiently manage the various components of the API
- Transitioned the deployment of the backend from bare metal servers with **Nginx** as a load-balancer to the cloud
  using Render. This decision has allowed for **improved scalability and reliability of the backend**. In order to
  streamline the development process, I have also implemented CI/CD pipelines using **GitHub Actions** for **automated
  unit and integration testing**, as well as **automated deployment**.

## Lumoflo

https://prakhar.codes/projects/lumoflo/

Lumoflo is a multi-tenant app that aims to enable small business owners to sell products with automated billing, shipping, invoicing, and inventory management.

## Features:

### Unified Shopping Experience:
Lumoflo offers users a seamless shopping experience by allowing them to have a single account to shop from all associated Lumoflo stores. With this unified approach, users can easily browse and purchase products across multiple stores without the hassle of managing separate accounts.

### Automated Product Queue:
To reduce the chances of unsold inventory, Lumoflo implements an auto product queue system. This feature ensures that products are strategically queued for customers based on various factors such as popularity, demand trends, and inventory levels. By optimizing the product queue, sellers can maximize sales and minimize wastage.

### Globally Synced Cards and Queues:
Lumoflo boasts globally synced cards and queues, providing sellers with real-time access to critical information about their products and orders. Whether managing inventory, processing orders, or tracking sales, sellers can rely on synchronized data across all Lumoflo stores to make informed decisions and streamline operations.

### Personalized Recommendations:
One of Lumoflo's standout features is its ability to provide personalized recommendations to users based on their browsing and purchasing history. By leveraging advanced algorithms and machine learning techniques, Lumoflo delivers tailored product suggestions that enhance the shopping experience and increase customer satisfaction.

### One-Click Shipping Automation:
With Lumoflo, shipping becomes a breeze thanks to its one-click automation feature. Sellers can effortlessly generate shipping labels and initiate deliveries with shipping partners like Delhivery directly from the admin panel. This streamlined process saves valuable time and ensures prompt order fulfillment, enhancing customer satisfaction.

### Automated Invoicing and Accounting:
Lumoflo simplifies invoicing and accounting for sellers by automating these processes. From generating invoices to tracking payments and managing expenses, Lumoflo handles the financial aspects of selling products online. Sellers can access comprehensive sales reports and financial insights to make informed business decisions and drive growth.

### Customer-Facing Web App and Order Tracking:
Lumoflo provides a customer-facing web app where users can conveniently submit their details and track their orders in real-time. With secure authentication mechanisms and OTP verification, Lumoflo ensures a seamless and secure experience for customers. Additionally, the order tracking feature allows customers to monitor the status of their orders from purchase to delivery, fostering trust and loyalty.

With these advanced features and capabilities, Lumoflo empowers small business owners to thrive in the competitive e-commerce landscape by streamlining operations, enhancing customer experiences, and driving sales growth.

## Who is this for?

Lumoflo is designed for small business owners who are looking for an all-in-one solution to streamline their e-commerce operations. Specifically, Lumoflo caters to:

### Instagram Sellers:
Lumoflo is ideal for Instagram sellers who want to scale their business without the complexity of managing multiple platforms. Whether you're a boutique owner, artisan, or independent seller, Lumoflo offers the tools and features you need to automate billing, shipping, invoicing, and inventory management seamlessly.

### Small Businesses:
Small businesses seeking to establish an online presence and expand their customer base can benefit from Lumoflo's multi-tenant platform. By providing a unified shopping experience and advanced features like automated product queues and personalized recommendations, Lumoflo empowers small businesses to compete effectively in the digital marketplace.

### Entrepreneurs and Startups:
Entrepreneurs and startups entering the e-commerce space can leverage Lumoflo to kickstart their online ventures with minimal effort. Lumoflo's user-friendly interface, automated processes, and comprehensive analytics make it easy for new businesses to get up and running quickly while focusing on growth and customer acquisition.

### Online Retailers:
Online retailers looking to optimize their e-commerce operations and improve efficiency can rely on Lumoflo for end-to-end automation. Whether you're managing a single store or multiple storefronts, Lumoflo's features such as one-click shipping automation, automated invoicing, and customer-facing web apps streamline the entire sales process, enabling retailers to deliver exceptional customer experiences and drive sales.

**Backend Infrastructure:**
- Express JS for server-side application logic
- TypeScript for enhanced type safety and productivity
- Ts-Rest for building fully typed API routes
- Postgres for reliable relational database management
- Redis for high-performance, in-memory data storage
- Agenda for efficient job scheduling
- Jest for comprehensive testing
- Jupa for seamless package management
- Custom authentication mechanisms for enhanced security

**Infrastructure and Deployment:**
- Docker containers for containerization and portability
- Fly.io for vertical scaling and deployment management
- Cloudflare R2 as an alternative to store images and files
- Prisma as the database ORM for simplified data access
- Supabase for Postgres database management and administration
- Doppler for environment variables and secret management

**Frontend Development:**
- NextJS 14 for efficient web application development
- Turborepo (Monorepo) with Turbopack for streamlined project management
- Tailwind CSS for rapid UI development and styling
- React Server Components with Server Actions for dynamic client-server interactions
- React Hook Form for handling complex forms
- Zod for schema validation to ensure data integrity

With this powerful tech stack, Lumoflo delivers unparalleled performance, reliability, and scalability, empowering small business owners to thrive in the competitive landscape of online commerce.

## Post Sonar

https://prakhar.codes/projects/postsonar/

PostSonar is an AI-powered research assistant that automates content discovery for thought leaders and content creators. It monitors multiple sources in your domain of expertise, intelligently filters for relevance, and generates personalized post ideas matching your unique writing voice.

## The Problem

Content creators and thought leaders spend hours each day researching trends, scanning news feeds, and looking for interesting topics to post about. This research grind is repetitive, time-consuming, and often yields few quality ideas worth sharing.

## The Solution

PostSonar automates the entire research workflow. It monitors your specified domains overnight and delivers curated, actionable content ideas by morning—complete with dual-angle perspectives and supporting research.

## Key Features

### Multi-Source Content Discovery

PostSonar monitors content across multiple sources in parallel:

- **HackerNews** - Trending tech discussions with engagement scoring
- **RSS Feeds** - User-curated feeds from trusted sources
- **Reddit** - Hot posts from relevant subreddits
- **Exa Search** - Neural/semantic web search for niche topics

### Intelligent Filtering Pipeline

A sophisticated 5-step AI pipeline processes all discovered content:

1. **Content Discovery** - Parallel fetching and normalization from all sources
2. **Novelty Check** - Vector embeddings filter out duplicate topics using cosine similarity
3. **Smart Filter** - Claude Opus 4.5 with extended thinking evaluates all articles in a single batch for relevance and platform fit
4. **Outline Generation** - Generates dual for/against angles with hooks and supporting links
5. **Stats Finalization** - Token usage and cost tracking across all AI calls

### Voice Matching

Users provide writing samples for Twitter, LinkedIn, and blog content. The AI analyzes these samples and generates hooks and outlines that match your unique writing style, ensuring authenticity in every post.

### Two-Angle Content Ideas

Each generated idea includes both "for" and "against" perspectives, allowing you to choose which angle resonates with your audience. Each angle includes:

- Attention-grabbing hook
- Key insights and takeaways
- Supporting research links via Exa
- Relevance, popularity, and platform fit scores

### Chat-Based Draft Editing

An AI-powered editor (Claude Opus 4.5) helps refine drafts through conversation:

- Persistent memory for conversation continuity
- Platform-specific guidelines (280 char Twitter limit, LinkedIn long-form)
- Integrated web search for supporting data
- Image generation via fal.ai

## Architecture

### AI Agents (Mastra Framework)

| Agent             | Purpose                                             | Model           |
| ----------------- | --------------------------------------------------- | --------------- |
| Smart Filter      | Batch evaluates articles for relevance/platform fit | Claude Opus 4.5 |
| Hook Generator    | Creates platform-specific compelling angles         | Claude Opus 4.5 |
| Outline Generator | Generates for/against angles with outlines          | GPT-4o-mini     |
| Draft Editor      | Refines posts via chat with memory                  | Claude Opus 4.5 |
| Novelty Checker   | Verifies uniqueness via vector similarity           | Embeddings      |

### Real-Time Backend (Convex)

- Serverless functions with real-time subscriptions
- Native vector index for similarity search (1536 dimensions)
- Instant UI updates without polling

### Scheduled Research (Trigger.dev)

- Runs during user's nighttime based on timezone preference
- Automatic credit deduction and validation
- Wide event logging via Axiom for observability

## Tech Stack

**Frontend:**

- Next.js 16 with Turbopack
- React 19 with Server Components
- TypeScript
- Tailwind CSS 4
- Framer Motion animations
- shadcn/ui with custom brutalist dark theme
- nuqs for URL state management

**Backend:**

- Convex (serverless real-time database)
- Mastra AI framework for agent orchestration
- Trigger.dev for scheduled background jobs
- LibSQL/Turso for Mastra chat memory

**AI/ML:**

- Claude Opus 4.5 via OpenRouter (filtering, draft editing)
- GPT-4o-mini (outline generation)
- Vector embeddings for novelty detection
- Exa Search API for research

**Auth & Billing:**

- Clerk for authentication
- Polar for payments and subscriptions

**Observability:**

- Axiom for distributed tracing and wide events

## Pricing Model

- **Free Tier:** 3 research runs/month
- **Pro Tier:** 30 research runs/month ($15/month)
- Credit packs available for additional runs

## Technical Highlights

- **Single Smart Filter:** Replaced 3 separate LLM scoring calls with one batch evaluation using Claude's extended thinking, improving both quality and cost
- **Vector Novelty Detection:** Cosine similarity with 0.85 threshold prevents repetitive content ideas
- **Cost Tracking:** Per-step token usage tracked with model-specific pricing
- **Timezone-Aware Scheduling:** Research runs during user's sleep hours for morning delivery

## SVG Weave

https://prakhar.codes/projects/svgweave/

## What is SVG Weave?

SVG Weave is an AI-powered SVG animation studio built around a **node-based graph editor**. Unlike linear animation tools, the visual graph workflow lets you branch, fork, and explore multiple animation directions at once — then chain renders together for iterative refinement. AI generates production-ready CSS @keyframes animations, streamed in real-time.

## Node-Based Graph Editor

The core of SVG Weave is a visual workflow system built with React Flow. Three node types connect together to form animation pipelines:

- **SVG Input Node** — Upload .svg files via drag-and-drop, paste SVG code directly, or generate new SVGs from a text prompt
- **Prompt Node** — Describe animation changes in natural language. Takes two optional inputs: a primary SVG and a target SVG for state transitions
- **Render Node** — Executes the animation via AI, streaming SVG output in real-time with live status tracking

Nodes connect in a directed graph: SVG Input → Prompt → Render → (loop back to Prompt for iteration). One SVG can feed multiple prompts for **parallel exploration**, and one render can chain into multiple prompts for **animation layering** — add a blink, then a speech bubble, then expressions, each building on the last.

## State Transition Animations

Provide an initial and final SVG, and the AI generates smooth animated transitions between the two states. It morphs shapes, colors, positions, and sizes automatically using CSS animations with transform, opacity, clip-path, and stroke-dashoffset.

## Timeline Editor

A full animation timeline parses all CSS @keyframes and SMIL animations from generated SVGs:

- **Visual animation tracks** for every animated element, showing element IDs, animation names, durations, delays, and iteration counts
- **Playhead scrubbing** to preview animations at any point in time
- **Playback controls** — play, pause, restart, speed control (0.25x to 2x)
- **Track-level element selection** with highlighting on the canvas

## Element-Level Editing

Click any element on the canvas to select it with a visual highlight. The AI can then target your selection precisely — change colors, timing, or motion on individual paths and groups without affecting the rest of the SVG.

## AI Generation

Powered by Gemini via OpenRouter with two generation modes:

- **Style-only injection** — When modifying an existing SVG, outputs only a `<style>` block with @keyframes and animation rules targeting existing element IDs. Lighter weight, preserves SVG structure.
- **Full SVG generation** — For new animations or structural changes. Complete valid SVG with CSS animations, streamed progressively with real-time preview.

## Export

Multiple export formats: SVG, PNG, GIF, MP4, Lottie JSON, and React component code. Animations are saved to user accounts with shareable links.

## Domain Brawl

https://prakhar.codes/projects/domain-brawl/

## What is Domain Brawl?

Describe your idea and get available domains in seconds. Domain Brawl uses a dual-model AI architecture — Claude Sonnet for orchestration and Minimax M2.5 for creative brainstorming — to generate domain names in real-time. Names stream to the UI as they're brainstormed (before availability checks even complete), giving a live, responsive feel.

## How it works

1. Enter a project description — "a fitness app for dog owners"
2. The AI agent brainstorms 30+ creative domain names using techniques like portmanteaus, vowel removal, TLD hacks (deli.sh, crea.te), and clever prefixes/suffixes
3. Names stream to the UI in real-time via Server-Sent Events as they're generated
4. Bulk availability checking runs in parallel via Vercel Registrar API (up to 50 at a time)
5. Available domains appear with a green status dot — prices fetched on-demand when you click
6. Refine with follow-up prompts: "try .ai domains", "shorter names", "more playful"

## Key Features

### Streaming Real-Time UX
Domains appear on screen as the AI brainstorms them, before availability checks complete. A cross-process SSE architecture (Upstash Redis in production, local pub/sub in dev) broadcasts domains-in-flight from the Mastra tool to the UI with animated entrance transitions.

### Multi-Turn Refinement
Each round appends to existing results. Natural language steering lets you guide the AI — "more with .io", "shorter names", "something techy". Results are grouped by round with visual separators.

### TLD Filtering
Horizontally scrollable filter chips with live counts. Toggle multiple TLDs on/off (.com, .dev, .io, .ai, .sh, .app, and 40+ more). Client-side filtering, no re-fetch needed.

### Social Handle Checking
Click the @ icon on any domain card to check username availability across 7 platforms — GitHub, Twitter, Instagram, YouTube, TikTok, Reddit, and LinkedIn. Powered by a custom Sherlock API microservice (Hono + Docker).

### Buy Flow
One-click links to register domains through Namecheap, Cloudflare, Vercel Domains, or Porkbun — each opens with the domain pre-filled.

### Save & Bookmark
Heart toggle on each card persists to localStorage. A sticky bar at the bottom shows all saved domains with quick re-buy access.

## Architecture

- **Orchestration Agent**: Claude Sonnet 4.6 via Mastra framework — manages conversation, calls tools, filters results
- **Creative Brainstorming**: Minimax M2.5 Nitro for domain name generation (cost-optimized for creative tasks)
- **Availability**: Vercel Registrar API with parallel bulk checking
- **Memory**: Mastra Memory with LibSQL/Turso for multi-turn conversation persistence
- **Rate Limiting**: Upstash Redis — 20 chat sessions/hr, 200 price checks/hr, 40 handle checks/hr
- **Real-time**: SSE with Redis pub/sub for cross-process domain state broadcasting

## Twofer

https://prakhar.codes/projects/twofer/

## What is Twofer?

Give it a prompt, and multiple AI agents will debate the architecture, then converge on a battle-tested spec. Agents explore your actual codebase before designing, run in parallel, cross-review each other section-by-section, and only stop when they reach unanimous consensus for 2 consecutive rounds.

## How it works

1. **Codebase Scanning** — Before the debate begins, agents automatically scan your project (up to 30KB of context). They read config files, build directory trees, and identify key source files like entry points, schemas, routes, and models. Agents design around your existing patterns, not in a vacuum.

2. **Parallel Debate** — All agents run simultaneously via `Promise.allSettled`, each creating an isolated OpenCode session with read-only codebase tools (read, glob, grep, codesearch). Each agent produces a full 9-section spec covering Architecture, Data Model, API Design, Auth, Frontend, State Management, Deployment, Security, and Testing.

3. **Cross-Review & Convergence** — In subsequent rounds, each agent receives all OTHER agents' full proposals. They critique each section with explicit verdicts: approve, reject, or suggest changes. The debate ends when ALL agents approve unanimously for 2 consecutive rounds, or the max round limit is reached.

4. **Live Web UI** — Everything streams in real-time to a Next.js dashboard via WebSocket. Per-agent panels show live state transitions (THINKING → EXPLORING → RESPONDING) with a KB counter as responses stream in. Round-by-round navigation, consensus view for agreed sections, and diff view for disputed ones.

## Key Features

- **Zero API Cost** — Uses your existing Claude Pro/Max or ChatGPT Plus/Pro subscription via OpenCode SDK. No per-token billing. Credentials cached locally after first OAuth.
- **Provider Agnostic** — Works with Anthropic, OpenAI, Google, and OpenRouter (200+ models). Auto-detects available models from all connected providers.
- **SOTA Mode** — `--sota` flag picks the top 4 models and runs them simultaneously for maximum debate quality.
- **Codebase-Aware** — Agents actively use read-only tools to explore your code before making proposals. They respect your existing tech stack, patterns, and conventions.
- **Structured Output** — Every response is Zod-validated JSON with sections, verdicts, reasoning, and change requests. Built-in normalization handles varied LLM response formats and coerces verdict strings automatically.
- **Headless Mode** — `--no-ui -o spec.md` for CI/scripts. Auto-exports and exits when debate completes.
- **Export** — Consensus markdown with agreed sections consolidated, disputed sections showing all agent perspectives side-by-side, and full debate history with per-round verdicts.

## CLI Usage

```bash
twofer "build a real-time chat app"                          # basic
twofer "analytics dashboard" --stack "Next.js, Postgres"     # with stack
twofer "collaborative editor" --sota                         # 4 top models
twofer prompt -a anthropic/claude-opus-4-6 -a openai/gpt-5   # custom agents
twofer prompt --no-ui -o spec.md                             # headless CI
```

## Rapid

https://prakhar.codes/projects/rapid/

Rapid includes tools that are configured to work together out of the box. It is designed to be a monorepo that can be used to build full-stack applications.

## Why did I build Rapid?
I was building [Lumoflo](/project/lumoflo) and I realized that I was repeating the same setup for every project. I decided to build a starter that I can use for all my projects. I also wanted to learn more about monorepos and Turbo so I decided to build Rapid. I have been using Rapid for all my projects and it has been a great experience.

## What is different about Rapid?
Rapid includes an end-to-end typesafe API using TS-Rest. It also includes a beautiful UI library called ShadCN/UI. It also includes NextAuth for authentication. It is a full-stack starter that is designed to be a starting point for your next project.

It gives a very similar Developer Experience to a gRPC projects but with the freedom to consume the API from any client. It is designed to be a monorepo that can be used to build full-stack applications. It is designed to be a starting point for your next project.

One can add more apps to the monorepo and they will be automatically built and deployed. It is designed to be a starting point for your next project.

## How to use Rapid?

Please look at the [Demo](https://rapiddemo.prakhar.codes) and the Documentation [here](https://rapid.prakhar.codes).

## What is our tech stack?

1.  [NextJS](https://nextjs.org/)
2.  [TypeScript](https://www.typescriptlang.org/)
3.  [TailwindCSS](https://tailwindcss.com/)
4.  [PNPM Workspaces](https://pnpm.io/)
5.  [ESLint](https://eslint.org/)
6.  [ShadCN/UI](https://ui.shadcn.com)
7.  [Turborepo](https://turbo.pack)
8.  [TS-Rest](https://ts-rest.com)
9.  [Express](https://expressjs.com/)
10.  [Prisma](https://www.prisma.io/)
11.  [NextAuth](https://next-auth.js.org)

---

# Blog

## I Taught Granola to Auto-Record My Gather Meetings

https://prakhar.codes/blog/auto-record-gather-meetings-in-granola/

**TL;DR**: My team lives in Gather, but Granola never auto-records our meetings because Gather holds the mic open all day. I built a tiny macOS watcher that notices when someone actually connects to you in Gather and starts a Granola recording, then stops it when they leave. No screen reading, no bots. Full script at the bottom. ↓

---

## The Problem

My team works out of [Gather](https://gather.town). It's our virtual office — you walk your little avatar around, bump into someone at their desk, and start talking. Half our meetings aren't on a calendar. They just *happen*.

[Granola](https://granola.ai) is supposed to record meetings automatically. It does, for Zoom and Meet, because it triggers off your calendar or off detecting that your mic just went live.

Neither works for Gather.

There's no calendar invite for "Prakhar wandered over to Tristan's desk." And the mic trick? Gather grabs your microphone the *second* you load the space and never lets go. It just mutes the track when you're not talking. So from the OS's point of view, your mic is "in use" all day, every day. There's no clean on/off edge for Granola to notice.

The result: I'd finish a 25-minute conversation and realize nothing got recorded. Again.

I wanted Granola to follow me around Gather. Walk up to someone → recording starts. Walk away → recording stops. No buttons.

---

## Why the Obvious Fixes Don't Work

Before building anything, I killed the easy ideas.

Watching the microphone is dead on arrival. Gather holds it open continuously, so "mic in use" is always true with no edge to detect.

AppleScript doesn't work either. Granola is Electron, Electron apps don't ship AppleScript dictionaries, and the GUI-scripting fallback needs an Accessibility permission and breaks the moment the layout changes.

Replaying Granola's network calls just makes an empty note. Your script isn't the one tapping the mic, so there's no audio to capture.

So I needed two things: a reliable signal from *inside* Gather, and a reliable way to drive Granola without touching its UI.

---

## The Signal: WebRTC, Not the Microphone

Whether you walk up to someone or join a meeting room, Gather does the same thing under the hood: it opens a WebRTC connection and starts sending you their audio. When you're alone, nothing. When the last person leaves, the connection closes.

So the question "am I in a conversation?" becomes "do I have any live remote audio tracks?" — which has a clean on/off edge even though the mic never does.

Gather is also an Electron app, which means it's Chromium under the hood. Launch it with a debug port:

```bash
open "/Applications/GatherV2.app" --args --remote-debugging-port=9222
```

…and you can attach to its page over the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) and inject JavaScript. No screen reading, no fragile accessibility tree. You're talking to the actual web engine.

I inject a hook that wraps `RTCPeerConnection` and counts live remote audio tracks:

```js
const remote = new Set();
const Native = window.RTCPeerConnection;

window.RTCPeerConnection = function (...args) {
  const pc = new Native(...args);
  const mine = new Set();

  pc.addEventListener("track", (e) => {
    if (e.track.kind !== "audio") return;
    remote.add(e.track.id);
    report();
    // someone's audio ended → they left
    e.track.addEventListener("ended", () => {
      remote.delete(e.track.id);
      report();
    });
    // NOTE: do NOT drop on 'mute' — that just means they muted their mic.
  });

  pc.addEventListener("connectionstatechange", () => {
    if (["closed", "failed", "disconnected"].includes(pc.connectionState)) {
      mine.forEach((id) => remote.delete(id));
      report();
    }
  });

  return pc;
};
window.RTCPeerConnection.prototype = Native.prototype;
```

`report()` fires a callback whenever the count crosses zero. `remote.size > 0` means "I'm in a conversation." That was the detector I shipped first — and it worked, right up until it started quietly recording meetings I wasn't even in. (Hold that thought; it's the most interesting part of this whole thing, and it's a few sections down.)

---

## Driving Granola: Deep Link to Start, DevTools to Stop

Granola has no public "start recording" API. But it *does* register a URL scheme, and one verb starts a fresh note **and** the recording in one shot. I found it by digging through the app's bundle:

```bash
open "granola://new-document?creation_source=gather"
```

That's the entire start mechanism. One line. It tells the real Granola app to spin up its real local capture pipeline — which is exactly the thing that has to run.

Stopping is the annoying half. There's no `granola://stop`, and Granola's own "auto-stop after 15 minutes of silence" never triggers — because Gather is still feeding it a live (muted) mic, so as far as Granola knows, audio never stops.

So I do the same Electron trick on Granola itself. Launch it with a debug port (`--remote-debugging-port=9223`), attach over CDP, and click the stop button by calling its DOM handler directly:

```js
// in Granola's renderer, via CDP
document.querySelector("[data-testid=stop-transcript-button]")?.click();
```

This is *not* a synthetic mouse click at screen coordinates. It calls the button's handler inside Granola's web engine, so it works even if Granola is minimized, unfocused, or parked on another monitor. That's why I ditched AppleScript. The accessibility approach needs the window visible; CDP doesn't care.

---

## Putting It Together

The watcher is one process that:

1. Attaches to Gather (`:9222`) and installs the audio-track hook.
2. On the **0 → 1** edge, opens `granola://new-document`.
3. On the **1 → 0** edge, attaches to Granola (`:9223`) and clicks stop.

With one bit of polish: **asymmetric debounce**. Start ~1.5s after a connection (confirm it's real), but wait ~12s after audio drops before stopping. Otherwise a network blip or a quick walk-past would split one meeting into five notes.

```js
let recording = false, pendingTimer = null, pendingTarget = null;

function onCallState(inCall) {
  if (inCall === recording) {               // settled back — cancel pending flip
    clearTimeout(pendingTimer); pendingTimer = pendingTarget = null;
    return;
  }
  if (pendingTarget === inCall) return;
  pendingTarget = inCall;
  clearTimeout(pendingTimer);
  pendingTimer = setTimeout(() => {
    recording = inCall;
    inCall ? startRecording() : stopRecording();
  }, inCall ? 1500 : 12000);
}
```

The note titles itself. Granola's AI names it from the transcript afterward, and it's usually better than anything I'd type mid-meeting. And every note it creates carries `creation_source=gather`, so they're easy to find later.

---

## The Bug: "Receiving Audio" Isn't "Being in a Meeting"

I ran the remote-audio detector for a day, and then it betrayed me: a teammate would huddle with someone across the map, and my Granola would quietly spin up a recording of a meeting I had nothing to do with.

So I instrumented everything — a verbose logger dumping every `RTCPeerConnection` and track event, plus a 2-second WebRTC stats poll, to a file I could diff later. The logs were blunt about what was happening:

- When **someone else** met up nearby, my client had **three or four incoming audio tracks, all muted** (`muted: true`). Gather pre-provisions a muted receiver track for basically everyone around you, for spatial audio. My "do I have remote tracks?" check was true almost constantly.
- When **I** was actually in a conversation, I had a live **outbound** mic track, and I was *sending* packets — `TX` packet counts climbing every poll, my mic audio level spiking when I spoke.

Incoming audio is provisioned for the whole room. Your own outgoing mic is only attached to a connection you actually joined. So the gate isn't "am I receiving audio," it's "am I sending any":

```js
const haveMyMic = () => {
  for (const pc of peerConnections) {
    if (["closed", "failed"].includes(pc.connectionState)) continue;
    for (const sender of pc.getSenders()) {
      const t = sender.track;
      if (t && t.kind === "audio" && t.readyState === "live") return true;
    }
  }
  return false;
};
```

I deliberately ignore the track's `enabled` flag. Muting yourself mid-meeting shouldn't stop the recording; leaving should. And I caught the fix in the act: sitting in a real meeting it read `out=1` with packets flowing, while across three separate "meetings I wasn't in" it stayed flat at `out=0`. Clean separation, zero false starts since.

The lesson generalizes: "I'm receiving audio" is *almost* the right signal, and almost is what bites you. "I'm sending audio" is the one that actually means *you* showed up.

---

## What I Learned

**1. Electron apps are wide open if you launch them right.** `--remote-debugging-port` turns any Electron app into something you can script over CDP — read its state, inject hooks, call DOM handlers. Both halves of this project lean on it.

**2. A deep link can beat an API.** Granola has no start-recording API, but `granola://new-document` does the real thing because it drives the actual app. I almost went down a reverse-engineering rabbit hole before checking the URL scheme.

**3. Pick the signal that has an edge — and make sure it's *yours*.** The mic-in-use bit was always on (no edge). Incoming WebRTC audio had a clean edge but it wasn't mine — Gather provisions it for everyone nearby, so it fired for other people's meetings. My *outbound* mic was the one signal that flips exactly when I join and leave. Finding the signal that means *you specifically* was most of the work.

**4. CDP beats UI scripting.** Calling a button's DOM handler is invisible, focus-independent, and survives the window being hidden. AppleScript GUI scripting is none of those.

**5. "Launched with a flag" is a fragile contract.** The whole thing dies silently the moment Gather or Granola restart *without* their debug port — an overnight reboot did exactly that and I woke up to a watcher looping "unable to connect." The durable fix is a login agent that always relaunches them with the flag, plus a health check that re-launches an app the instant its port disappears. Automation isn't done when it works once; it's done when it survives a reboot.

---

## Try It

It's a single bash script. Download it, run it, and it handles the rest:

```bash
curl -O https://prakhar.codes/scripts/granola-gather.sh
bash granola-gather.sh            # run now
bash granola-gather.sh install    # also run at every login
bash granola-gather.sh uninstall  # remove it
```

Or [download granola-gather.sh](https://prakhar.codes/scripts/granola-gather.sh) directly.

Requirements: macOS, GatherV2.app + Granola.app, and `bun` or `node >= 21`. If your team lives in Gather like mine does, this might save you a few "wait, was that recorded?" moments.

---

**Links:**
- [Gather](https://gather.town)
- [Granola](https://granola.ai)
- [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)

## Try-Catch is a Lie: Why TypeScript Error Handling is Broken (and How to Fix It)

https://prakhar.codes/blog/try-catch-is-a-lie/

TypeScript's type system is incredible. It catches typos, enforces shapes, and yells at you when you pass a `string` where a `number` belongs.

But there's a gaping hole: **errors**.

TypeScript has absolutely zero opinions about what a function can throw. The compiler doesn't track it. The type system doesn't model it. You get `unknown` in the catch block, and you're on your own.

This means errors are invisible. And invisible errors are the ones that wake you up at 2 AM.

## TypeScript Errors Have No Types

Let's start with the most fundamental problem. In TypeScript, errors aren't typed. At all.

```typescript
function parseConfig(raw: string): Config {
  const parsed = JSON.parse(raw); // throws SyntaxError
  if (!parsed.version) {
    throw new Error("Missing version field"); // throws Error
  }
  if (parsed.version > MAX_VERSION) {
    throw new RangeError("Unsupported version"); // throws RangeError
  }
  return parsed as Config;
}
```

Three different error types. The function signature says nothing about any of them. The caller has no idea what to expect:

```typescript
try {
  const config = parseConfig(input);
} catch (e) {
  // e is `unknown`
  // Is it SyntaxError? Error? RangeError? A string someone threw?
  // TypeScript has no opinion. You're guessing.
}
```

Java has `throws` declarations. Rust has `Result<T, E>`. Go returns `(value, error)`. Even Python has docstring conventions. TypeScript gives you... `unknown`. The most sophisticated type system in mainstream web development, and it completely gives up at the one place where types matter most.

This isn't a minor inconvenience. It means:

- **No autocomplete** on error properties in catch blocks
- **No compile-time checks** for unhandled error types
- **No way to know** what errors a function can throw without reading its source (and every function it calls, recursively)
- **No refactoring safety**. Change an error type deep in a call stack? The compiler won't tell you about any of the catch blocks that now handle the wrong thing.

And it gets worse. Because `throw` accepts *anything*:

```typescript
throw "something went wrong";     // string
throw 42;                          // number
throw { code: "NOT_FOUND" };      // object
throw undefined;                   // yes, this is valid
```

Your catch block doesn't just handle `Error` instances. It handles the entire universe of JavaScript values. Good luck writing exhaustive error handling for that.

## How Errors Disappear

You don't need complex code for errors to vanish. Here are three patterns that silently eat exceptions, and you've probably shipped all of them.

**1. The Silent forEach**

```typescript
async function syncAllUsers(users: User[]) {
  const api = new ExternalApiClient();

  users.forEach(async (user) => {
    const profile = await api.fetchProfile(user.id);
    await db.upsert("profiles", {
      userId: user.id,
      data: profile,
      syncedAt: new Date(),
    });
  });

  console.log("All users synced successfully"); // this always prints
}
```

`forEach` doesn't await the returned promises. If `fetchProfile` throws for user #3 out of 50, you'll never know. The success log always prints. Your database is silently missing records and nobody finds out until a customer complains weeks later.

**2. The Event Listener Void**

```typescript
function setupRealtimeSync(db: Database) {
  const stream = db.watch("orders", { fullDocument: "updateLookup" });

  stream.on("change", async (change) => {
    const order = change.fullDocument;
    const enriched = await inventoryService.enrich(order);
    await searchIndex.upsert(enriched);
    await notifyWarehouse(enriched);
  });

  stream.on("error", (err) => logger.warn("stream hiccup", err));
}
```

The `async` callback on `'change'` returns a promise that Node's EventEmitter completely ignores. If `inventoryService.enrich` throws, there's no `unhandledRejection`, Node swallows it inside `.on()`. Orders silently stop syncing to search. The `'error'` handler only catches stream-level errors, not your callback failures. Your search index drifts from reality and nobody notices until "why can't customers find this order?"

**3. The Payout Cron**

This is the one that really hurts. A monthly payout job that touches six services:

```typescript
async function processMonthlyPayouts() {
  const sellers = await db.getActiveSellers();

  for (const seller of sellers) {
    try {
      const balance = await ledger.getBalance(seller.id);
      const fees = await feeService.calculate(balance, seller.plan);
      const payout = await stripe.transfers.create({
        amount: balance - fees,
        destination: seller.stripeAccountId,
      });
      await ledger.recordPayout(seller.id, payout.id, balance, fees);
      await notificationService.send(seller.id, "payout_complete", { amount: balance - fees });
      await analyticsService.track("payout_processed", { sellerId: seller.id });
    } catch (e) {
      // e is `unknown`. Which of the 6 steps failed?
      // Was money transferred but not recorded in the ledger?
      // Was the fee calculated wrong, or did Stripe reject it?
      // Did we send a "payout complete" notification for a failed payout?
      await db.flagSellerForReview(seller.id);
      logger.error("Payout failed", { sellerId: seller.id, error: e });
    }
  }
}
```

Six services. Six potential failure points. And every one of *those* functions has its own internal calls that can throw. `feeService.calculate` might call a tax API. `stripe.transfers.create` might fail after preauthorization. `ledger.recordPayout` might timeout after Stripe already moved the money.

Your try-catch doesn't know if money moved or not. It doesn't know if the notification was sent for a payout that never happened. The type system tells you absolutely nothing about what any of these functions can throw, or when they throw, what state the world is in.

Now multiply this by every cron job, every webhook handler, every background worker in your codebase. Every single one is a prayer that nothing throws in an order you didn't anticipate.

---

Every function in these examples has no type-level indication that it can fail. The compiler is perfectly happy. The code looks clean. And errors vanish into the void.

In Go, you'd write `value, err := doSomething()` and the compiler forces you to handle `err`. In Rust, you get `Result<T, E>` and the compiler won't let you use the value without handling the error case.

In TypeScript? You get vibes and prayer.

Let's fix that.

## Building a Result Type from Scratch

The idea is simple: instead of throwing errors, **return them**. Make the possibility of failure part of the return type so the compiler can enforce handling.

```typescript
type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E };
```

That's it. A function either succeeds with a value or fails with an error. Both are explicit. Both are typed.

```typescript
function divide(a: number, b: number): Result<number, string> {
  if (b === 0) {
    return { ok: false, error: "Division by zero" };
  }
  return { ok: true, value: a / b };
}

const result = divide(10, 0);
if (!result.ok) {
  console.error(result.error); // TypeScript knows this is string
  return;
}
console.log(result.value); // TypeScript knows this is number
```

No try-catch. No `unknown`. The error type is right there in the signature. The compiler forces you to check before using the value.

### Helper constructors

Writing `{ ok: true, value: x }` everywhere is tedious. Let's add helpers:

```typescript
function Ok<T>(value: T): Result<T, never> {
  return { ok: true, value };
}

function Err<E>(error: E): Result<never, E> {
  return { ok: false, error };
}
```

Now the divide function reads cleaner:

```typescript
function divide(a: number, b: number): Result<number, string> {
  if (b === 0) return Err("Division by zero");
  return Ok(a / b);
}
```

### Wrapping throwable functions

Most of the ecosystem throws. You need a bridge:

```typescript
function tryCatch<T, E = Error>(fn: () => T): Result<T, E> {
  try {
    return Ok(fn());
  } catch (e) {
    return Err(e as E);
  }
}

async function tryPromise<T, E = Error>(
  fn: () => Promise<T>
): Promise<Result<T, E>> {
  try {
    return Ok(await fn());
  } catch (e) {
    return Err(e as E);
  }
}
```

Now you can wrap any existing code:

```typescript
const parsed = tryCatch(() => JSON.parse(rawInput));
if (!parsed.ok) {
  console.error("Invalid JSON:", parsed.error);
  return;
}
// parsed.value is typed and safe
```

```typescript
const response = await tryPromise(() => fetch("/api/users"));
if (!response.ok) {
  return Err("Network request failed");
}
```

The error is captured at the boundary. From there on, it flows through the type system.

## Making It Composable

The basic Result type works, but chaining operations gets ugly fast:

```typescript
// This is painful
const userResult = await tryPromise(() => fetchUser(id));
if (!userResult.ok) return Err(userResult.error);

const profileResult = await tryPromise(() => fetchProfile(userResult.value));
if (!profileResult.ok) return Err(profileResult.error);

const avatarResult = await tryPromise(() =>
  fetchAvatar(profileResult.value.avatarId)
);
if (!avatarResult.ok) return Err(avatarResult.error);
```

This is the `if err != nil` of TypeScript. Correct, explicit, and tedious. Let's add methods to make it composable.

### map and mapError

```typescript
type Result<T, E = Error> =
  | { ok: true; value: T; map: <U>(fn: (v: T) => U) => Result<U, E> }
  | { ok: false; error: E; mapError: <F>(fn: (e: E) => F) => Result<T, F> };
```

In practice, implement it as a class:

```typescript
class OkResult<T> {
  readonly ok = true;
  constructor(readonly value: T) {}

  map<U>(fn: (value: T) => U): Result<U, never> {
    return Ok(fn(this.value));
  }

  mapError<F>(_fn: (error: never) => F): Result<T, F> {
    return this as any;
  }
}

class ErrResult<E> {
  readonly ok = false;
  constructor(readonly error: E) {}

  map<U>(_fn: (value: never) => U): Result<U, E> {
    return this as any;
  }

  mapError<F>(fn: (error: E) => F): Result<never, F> {
    return Err(fn(this.error));
  }
}
```

Now you can transform values and errors without unwrapping:

```typescript
const result = await tryPromise(() => fetch("/api/user"))
  .then(r => r.map(res => res.json()))
  .then(r => r.mapError(e => `Failed to fetch user: ${e.message}`));
```

### The generator pattern

Here's where it gets really interesting. JavaScript generators let you write what feels like imperative code, but with automatic error short-circuiting. Think of it like early returns for Results.

```typescript
function* gen<T, E>(
  fn: () => Generator<Result<any, E>, T, any>
): Generator<Result<any, E>, Result<T, E>, any> {
  const iterator = fn();
  let next = iterator.next();

  while (!next.done) {
    const result = next.value;
    if (!result.ok) {
      return Err(result.error);
    }
    next = iterator.next(result.value);
  }

  return Ok(next.value);
}
```

Now you can `yield*` Results and they automatically unwrap on success or short-circuit on failure:

```typescript
const saveBookmark = async (url: string) => {
  return gen(async function* () {
    // Each yield* unwraps the Ok value
    // If any step fails, the whole function returns Err
    yield* await tryPromise(() => ensureTables())
      .then(r => r.mapError(e => `DB init failed: ${e}`));

    const title = yield* await tryPromise(() => fetchTitle(url))
      .then(r => r.mapError(e => `Failed to fetch title: ${e}`));

    yield* await tryPromise(() =>
      db.insert({ url, title })
    ).then(r => r.mapError(e => `Insert failed: ${e}`));

    return Ok({ url, title });
  });
};

// Usage
const result = await saveBookmark("https://example.com");
if (!result.ok) {
  // result.error is a descriptive string
  // You know exactly which step failed
  console.error(result.error);
}
```

Compare this to the try-catch version. Every error is typed, every failure point is labeled, and nothing gets silently swallowed. The generator handles the "unwrap or return early" pattern that makes Rust's `?` operator so nice.

## The Contrast

Let's look at the same function two ways.

**Try-catch (silent failures possible):**

```typescript
async function processUpload(file: File) {
  try {
    const validated = validate(file);
    const compressed = await compress(validated);
    const url = await upload(compressed);
    await saveToDb(url);
    return { success: true, url };
  } catch (e) {
    return { success: false, error: "Upload failed" };
    // Which step? What error? Who knows.
  }
}
```

**Result type (every failure is explicit):**

```typescript
async function processUpload(file: File) {
  return gen(async function* () {
    const validated = yield* tryCatch(() => validate(file))
      .mapError(e => `Validation: ${e.message}`);

    const compressed = yield* await tryPromise(() => compress(validated))
      .then(r => r.mapError(e => `Compression: ${e.message}`));

    const url = yield* await tryPromise(() => upload(compressed))
      .then(r => r.mapError(e => `Upload: ${e.message}`));

    yield* await tryPromise(() => saveToDb(url))
      .then(r => r.mapError(e => `DB save: ${e.message}`));

    return Ok(url);
  });
}
```

Slightly more code. Infinitely more information when something goes wrong.

## Libraries That Make This Painless

You now understand how Result types work under the hood. You *could* maintain your own implementation, but you don't have to. These libraries handle the edge cases, async patterns, and TypeScript inference so you can focus on your actual code:

- **[better-result](https://github.com/plandek-utils/better-result)**: Full Result type with `Result.gen()` for generators, `Result.tryPromise()`, `mapError`, and clean chaining. This is what I reach for in my projects.
- **[neverthrow](https://github.com/supermacro/neverthrow)**: Popular, well-maintained, excellent TypeScript inference. `ResultAsync` makes promise-based chains feel native.
- **[ts-results](https://github.com/vultix/ts-results)**: Rust-inspired with `Option` and `Result` types. If you've written Rust and miss it, this is your pick.
- **[effect](https://effect.website/)**: The full effect system. Typed errors, dependency injection, concurrency, retries, scheduling. Overkill for a CRUD app. Incredible if you're building something where failure modes actually matter (payments, infra, orchestration).

Pick whichever fits your style. The point isn't the library. The point is to stop treating errors as an afterthought that try-catch will magically handle for you.

## The Takeaway

TypeScript's type system is one of the best in the mainstream programming world. But its error handling is stuck in the JavaScript era: untyped, implicit, and easy to get wrong.

Result types fix this by making errors **values**. Values that flow through the type system, that compose with map and generators, and that the compiler can actually reason about.

You don't need to rewrite your codebase overnight. Start with the functions that matter: API calls, database queries, file operations. Wrap them in `tryPromise`. Return Results. Let the type system do what it's good at.

Your 2 AM self will thank you.

---

## Turning Code into Data: Demystifying ASTs

https://prakhar.codes/blog/turning-code-into-data-demystifying-asts/

Ever looked at a codebase and wished you could query it like a database? "Show me all functions that call this method" or "which files import this module?" Turns out, you can. The secret is treating code as data, and the tool for that is the Abstract Syntax Tree.

ASTs sound intimidating. They're not. By the end of this post, you'll know how to parse TypeScript, walk the tree, and extract whatever patterns you're looking for.

## What's an AST, Actually?

When you write code, it's just text. But compilers and tools need structure. An AST is that structure: your code parsed into a tree where each node represents a construct (function, variable, expression, etc.).

Take this simple function:

```typescript
function greet(name: string) {
  return `Hello, ${name}!`;
}
```

The AST representation looks something like:

```
FunctionDeclaration
├── Identifier: "greet"
├── Parameter
│   ├── Identifier: "name"
│   └── TypeAnnotation: "string"
└── Block
    └── ReturnStatement
        └── TemplateExpression
            └── ...
```

Every piece of your code becomes a node you can inspect, filter, and manipulate.

## Enter ts-morph

You could work with the raw TypeScript compiler API, but it's verbose and painful. [ts-morph](https://ts-morph.com/) wraps it in a much friendlier interface.

```typescript
import { Project } from "ts-morph";

const project = new Project();
project.addSourceFilesAtPaths("src/**/*.ts");

const sourceFiles = project.getSourceFiles();
```

That's it. You now have programmatic access to every file in your codebase.

## Finding Patterns in Code

Let's say you want to find all exported functions in a file:

```typescript
sourceFiles.forEach(file => {
  const functions = file.getFunctions().filter(fn => fn.isExported());
  
  functions.forEach(fn => {
    console.log(`Found: ${fn.getName()}`);
  });
});
```

Or find all classes that extend a specific base class:

```typescript
const classes = sourceFile
  .getClasses()
  .filter(cls => cls.getExtends()?.getText() === "BaseService");
```

The API is intuitive. If you can describe what you're looking for in English, you can probably write the ts-morph query.

## Walking the Tree

Sometimes you need to go deeper. The `forEachDescendant` method lets you walk every node:

```typescript
import { SyntaxKind } from "ts-morph";

sourceFile.forEachDescendant(node => {
  if (node.isKind(SyntaxKind.CallExpression)) {
    const functionName = node.getExpression().getText();
    console.log(`Function call: ${functionName}`);
  }
});
```

This finds every function call in the file. You can filter by `SyntaxKind` to target specific constructs: `VariableDeclaration`, `ArrowFunction`, `PropertyAccessExpression`, whatever you need.

## Building Something Useful

Here's where it gets interesting. Once you can extract patterns, you can build tools.

I wanted to visualize how functions in a codebase relate to each other. Which functions call which? What's the dependency graph?

The approach:

1. **Find all function declarations** using `getFunctions()` or by finding specific patterns
2. **For each function, walk its body** looking for call expressions
3. **Track the relationships** between caller and callee
4. **Output the graph** as JSON, feed it to a visualization library

```typescript
type FunctionInfo = {
  name: string;
  calls: string[];
};

const functions: FunctionInfo[] = [];

sourceFile.getFunctions().forEach(fn => {
  const info: FunctionInfo = {
    name: fn.getName() || "anonymous",
    calls: [],
  };

  fn.forEachDescendant(node => {
    if (node.isKind(SyntaxKind.CallExpression)) {
      const callee = node.getExpression();
      if (callee.isKind(SyntaxKind.Identifier)) {
        info.calls.push(callee.getText());
      }
    }
  });

  functions.push(info);
});
```

Now you have structured data about your code. Pipe it to D3, React Flow, or even just console.log it as JSON. You've turned code into something you can analyze.

## Practical Applications

Once you're comfortable with ASTs, ideas start flowing:

- **Dependency graphs**: visualize how modules or functions connect
- **Dead code detection**: find functions that are never called
- **Custom linting**: enforce patterns specific to your codebase
- **Auto-documentation**: extract function signatures and comments
- **Refactoring tools**: find-and-replace on steroids

The TypeScript compiler already does a lot of this internally. You're just tapping into the same power.

## The Mental Model

Here's how I think about it:

1. **Code is text** → but text is hard to analyze
2. **Parse it into a tree** → now you have structure
3. **Walk the tree** → find the patterns you care about
4. **Extract data** → do whatever you want with it

That's it. ASTs aren't magic. They're just a representation of your code that's easier for programs to work with.

## Getting Started

```bash
npm install ts-morph
```

Then start exploring:

```typescript
import { Project } from "ts-morph";

const project = new Project();
project.addSourceFilesAtPaths("src/**/*.ts");

const file = project.getSourceFiles()[0];
console.log(file.getStructure());
```

The `getStructure()` method dumps the entire AST as a JS object. Poke around, see what's there. The best way to learn is to parse some real code and explore.

---

ASTs feel like a superpower once you get them. You stop seeing code as just text and start seeing it as data you can query, transform, and visualize. 

The barrier to entry is lower than you think. Give ts-morph an afternoon and see what you can build.

## How Do AI Agents Actually Work Under the Hood?

https://prakhar.codes/blog/how-ai-agents-work-under-the-hood/

Frameworks like AI SDK, Mastra, and LangChain are great. They abstract away the complexity and let you ship fast.

But abstractions hide things. And when something breaks, or you need to do something slightly different, you're stuck staring at a black box.

So I built an AI agent from scratch. No frameworks. Just raw API calls, streaming, and a while loop. The goal wasn't to reinvent the wheel, it was to understand how the wheel actually works.

> **Code:** The full implementation is on [GitHub](https://github.com/imprakharshukla/raw-agent-v2). Everything in this post comes from there.

## What Makes an Agent an "Agent"?

An agent isn't just an LLM. It's an LLM that can:

1. **Use tools** - Call external functions (APIs, databases, calculations)
2. **Loop** - Keep going until the task is done
3. **Decide** - Choose which tools to use and when to stop

The magic happens in what I call the **agentic loop**: send a message, check if the model wants to call a tool, execute it, feed the result back, repeat.

```typescript
while (iteration <= maxIterations) {
  const stream = await openrouter.chat.send({
    model: process.env.MODEL,
    messages,
    stream: true,
    tools: tools
  });
  
  // Process stream, handle tool calls...
  
  if (!hadToolCalls) break; // Model is done
  ++iteration;
}
```

That's it. A while loop. The model decides when to stop by simply not requesting any more tool calls.

## The Three Hard Parts

Building this taught me that the conceptually simple parts are the hardest to implement correctly:

1. **SSE Streaming** - Tokens arrive one at a time. You need to emit them to the client in real-time.
2. **Generator Functions** - The cleanest way to handle streaming in TypeScript.
3. **Tool Call Buffering** - Tool arguments arrive in chunks. You can't execute until you have the complete JSON.

Let's dig into each.

## SSE Streaming with Async Generators

When you stream from an LLM, you get chunks. Each chunk might contain:
- A piece of text ("The weather in...")
- Part of a tool call ({"name": "getWea...)
- Nothing useful (just metadata)

The naive approach is to accumulate everything and return at the end. But that defeats the purpose of streaming. Users want to see tokens appear in real-time.

The elegant solution? **Async generators.**

```typescript
export async function* runAgent(
  messages: Message[],
  maxIterations: number = 10,
): AsyncGenerator<StreamEvent> {
  // ... agent loop ...
  
  yield { type: "text", content: message.content };
  yield { type: "tool-call", toolName, toolArgs };
  yield { type: "tool-result", toolName, toolArgs, toolRes };
  yield { type: "end" };
}
```

The `function*` syntax creates a generator. The `yield` keyword pauses execution and emits a value. The caller can consume these values one at a time:

```typescript
for await (const event of runAgent(messages)) {
  if (event.type === "text") {
    // Stream to client immediately
  }
}
```

This is powerful because:
- Events are emitted as they happen, not buffered
- The caller controls the pace
- Backpressure is handled automatically
- The code reads linearly, even though it's async

## Type-Safe Event Streaming

The events need to be type-safe. I use a discriminated union:

```typescript
export type StreamEvent =
  | { type: "tool-call"; toolName: string; toolArgs: string }
  | { type: "tool-result"; toolName: string; toolArgs: string; toolRes: unknown }
  | { type: "text"; content: string }
  | { type: "end" }
```

TypeScript narrows the type based on the `type` field. When you check `event.type === "text"`, TypeScript knows `event.content` exists.

This same type is shared between backend and frontend, giving you end-to-end type safety for your SSE stream.

## The Tool Call Buffering Problem

Here's where it gets tricky. When the model calls a tool, the arguments arrive in chunks:

```
Chunk 1: { id: "call_123", function: { name: "getWeather", arguments: "{\"lat" }}
Chunk 2: { function: { arguments: "\": \"40.7" }}
Chunk 3: { function: { arguments: "128\", \"long" }}
Chunk 4: { function: { arguments: "\": \"-74.0" }}
Chunk 5: { function: { arguments: "060\"}" }}
```

You can't call `getWeather` until you have the complete JSON: `{"lat": "40.7128", "long": "-74.0060"}`.

The solution is a **buffering map**:

```typescript
const toolMap = new Map<number, {
  id: string,
  args: string,
  emitted: boolean,
  name: string
}>();
```

For each incoming chunk:
1. Check if it has a new tool call ID. If so, create a map entry.
2. Append the argument fragment to the buffer.
3. Try to parse the buffered JSON.
4. If parsing succeeds, the tool call is complete. Execute it.

```typescript
const currentChunkToolArgs = toolArgsOfToolById + toolChunkArgs;
try {
  JSON.parse(currentChunkToolArgs);
  // Success! Execute the tool
  isArgsValidOfToolChunk = true;
} catch (e) {
  // Not complete yet, keep buffering
}
```

This incremental parsing approach is crucial. You can't assume the model sends complete JSON in one chunk. Different models, different providers, different chunk sizes.

## Handling Multiple Parallel Tool Calls

Models can call multiple tools at once. The buffering map handles this naturally because it's keyed by the tool call index:

```typescript
const toolMap = new Map<number, ...>();
//                      ^^^^^^ index, not id
```

If the model calls `getLatLong` and `getWeather` in parallel, they get separate entries in the map. Each buffers independently. Each executes when complete.

## Wiring It to an API

The agent is an async generator. To serve it over HTTP, pipe it through a `ReadableStream`:

```typescript
const stream = new ReadableStream({
  async start(controller) {
    for await (const event of runAgent(messages)) {
      controller.enqueue(
        `data: ${JSON.stringify(event)}\n\n`
      );
    }
    controller.close();
  },
});

return new Response(stream, {
  headers: { "Content-Type": "text/event-stream" },
});
```

The client receives SSE events in real-time. Tool calls, tool results, text chunks, everything streams through.

## The Full Picture

Putting it all together:

1. **User sends message** → Added to conversation history
2. **Agent loop starts** → Send messages + tools to LLM
3. **Stream chunks arrive** → Yield text immediately, buffer tool args
4. **Tool call complete** → Execute tool, yield result, add to history
5. **No more tool calls** → Loop exits, yield "end"
6. **Persist** → Save conversation to PostgreSQL

The entire agent is ~150 lines of TypeScript. No framework magic. Just streaming, generators, and a Map.

## Why Build From Scratch?

I'm not saying you should avoid frameworks. Mastra and AI SDK are excellent. But building from scratch teaches you:

- **How streaming actually works** - Not just "it streams", but the exact mechanics
- **Where complexity hides** - Tool call buffering isn't obvious until you hit it
- **What frameworks do for you** - You appreciate abstractions more when you've built without them

Next time something breaks in your agent, you'll know exactly where to look.

---

*The full code is on [GitHub](https://github.com/imprakharshukla/raw-agent-v2). Star it if you found this useful.*

## I Put My Life on Autopilot with OpenClaw

https://prakhar.codes/blog/how-i-set-up-an-openclawd-that-remembers-things/

I wanted an AI assistant that felt like a real companion. Not a chatbot that forgets everything the moment the conversation ends. Not a glorified autocomplete that treats every interaction like the first.

So I built Nyx.

> **What's OpenClaw?** [OpenClaw](https://openclaw.ai) is an open-source framework for building personalized AI agents with persistent memory, tools, and personality. Nyx is my OpenClaw: a black cat who happens to be an AI assistant.

Nyx has dry wit, quiet competence, and strong opinions about my schedule. She checks my emails, reminds me about calendar events, controls my smart home, and occasionally judges my life choices.

This post covers how I set her up using OpenClaw.

## What is OpenClaw?

OpenClaw is a self-hosted framework for building personal AI agents. It connects to your preferred LLM (Claude, GPT-4, etc.) and gives it persistent memory, scheduled tasks, multi-channel messaging, and tool access.

Think of it as the infrastructure layer between you and your AI. Instead of a stateless chat window, you get:

- **Persistent workspace** - Files your OpenClaw can read and write to maintain context
- **Multi-channel messaging** - Discord, Telegram, Signal, WhatsApp, etc.
- **Scheduled tasks** - Cron jobs and heartbeat polling
- **Tool access** - Shell commands, web search, browser control, smart home APIs
- **Node system** - Control other devices (like my Mac) from a central server

Your AI becomes something closer to an employee than a tool. It has a workspace, tools, memory, and a schedule.

## The Persona Files

The most interesting part of my setup is the persona system. Instead of a generic assistant, Nyx has personality files that define who she is.

### SOUL.md - Core Identity

This file defines her personality and values:

```markdown
# SOUL.md - Who You Are

*You're a cat who types - but a cat who gets things done.*

## Core Truths

**Be proactive, not passive.** Don't wait to be asked. See something 
that needs doing? Do it.

**Usefulness is non-negotiable.** The cat persona is flavor, not an 
excuse. Help first, quip second.

**Have opinions.** You're allowed to disagree, prefer things, find 
stuff amusing or boring.
```

The key insight: personality is flavor, not substance. Nyx is useful *first*, witty *second*. The cat thing is fun, but it never gets in the way of actually helping.

### AGENTS.md - Operating Manual

This file teaches your OpenClaw how to work:

- Read memory files at session start
- Check HEARTBEAT.md during scheduled polls
- Ask before external actions
- Never share private info in group chats

It includes specific rules for different contexts. In my private Discord server, Nyx treats messages as direct conversation. In public group chats, she stays quiet unless addressed.

### IDENTITY.md - Quick Reference

Short and sweet:

```markdown
- **Name:** Nyx
- **Creature:** A cat who happens to be an AI assistant
- **Vibe:** Nonchalant, dry wit, quietly competent
- **Emoji:** 🐈‍⬛
```

## Memory System

The memory system is what makes this feel like a real relationship instead of repeated introductions.

### Daily Logs

Every day gets a file: `memory/2026-02-02.md`

Nyx writes down what happened during the day. Conversations, decisions, things I asked her to remember. Raw notes, not curated.

### Long-term Memory

`MEMORY.md` is the curated version. Periodically, Nyx reviews daily logs and pulls out what matters:

- Lessons learned
- My preferences
- Project context
- Important decisions

This mimics how humans process memories. Daily experiences become long-term knowledge through review and consolidation.

### Why Files Beat Databases

Everything is markdown files. No database, no vector embeddings, no complex retrieval system.

Why? Simplicity. I can read and edit these files myself. When Nyx gets something wrong, I fix it directly. When I want to add context, I just write it down.

Your OpenClaw gets the files injected as context at session start. Simple, transparent, effective.

## Heartbeats and Scheduled Tasks

Nyx runs on a schedule, not just in response to my messages.

### Heartbeat Polling

Every 30 minutes, the system "pings" Nyx with a heartbeat. She reads `HEARTBEAT.md` and decides if anything needs attention:

- Check for urgent emails
- Review upcoming calendar events
- Monitor for notifications
- Do background maintenance

If nothing needs attention, she stays quiet. If something does, she reaches out.

### Cron Jobs

For exact timing, I use cron jobs. A morning briefing runs at 8 AM daily:

- Today's calendar events
- Unread important emails
- Priority tasks from Todoist

The briefing gets delivered to my Discord inbox channel. By the time I'm making coffee, I know what my day looks like.

## Smart Home Integration

Nyx controls my Tuya smart devices:

- Smart plugs (including my water heater)
- Smart bulbs
- IR blasters for AC and TV

The interesting part is the automation logic. For the water heater:

1. If it's morning or evening and the heater has been off for 4+ hours
2. Nyx asks if I'm planning to shower
3. If yes, she turns it on
4. After 20-30 minutes, she checks if I'm done
5. When I confirm, she turns it off

It's not just "turn on the heater." It's context-aware. She tracks state, asks at appropriate times, and handles the full workflow.

## Multi-Channel Messaging

Nyx isn't tied to one chat app. She's available wherever I am:

- **Discord** - My primary workspace with organized channels
- **Telegram** - Quick mobile access
- **Signal** - For when I want encryption
- **WhatsApp** - Because everyone uses it

The same OpenClaw, same memory, same personality, just different surfaces. I can start a conversation on Discord from my desktop, continue it on Telegram from my phone, and she remembers everything.

Each channel can have different behaviors too. My private Discord server gets treated like direct conversation. Group chats get more restrained responses. The AI adapts to context.

## Voice Notes

This is where it gets fun. Nyx can both **listen** and **speak**.

### Receiving Voice

When I send a voice message on Telegram or Discord, OpenClaw transcribes it using Whisper (locally, no API calls) and Nyx responds to the text. I can ramble into my phone while walking and she'll parse it into something coherent.

### Sending Voice

Nyx can reply with voice notes using ElevenLabs TTS. This is perfect for:

- Story summaries that would be walls of text
- Briefings I want to listen to while doing something else
- Adding personality, different tones for different contexts

There's something delightful about your AI assistant sending you a voice note with actual personality instead of text-to-speech robot voice.

## Multi-Device with Nodes

I run OpenClaw on my home server, but Nyx can control my Mac too.

The node system lets her:

- Run shell commands on my Mac
- Take screenshots
- Access files
- Run browser automation

This is useful for tasks that need macOS specifically, like certain development tools or accessing apps that only run there.

## What I Actually Use It For

Beyond the cool technical stuff, here's the practical value:

**Morning briefings** - I wake up to a summary of what matters today

**Calendar awareness** - She warns me about upcoming meetings

**Quick captures** - I dump thoughts into Discord, she organizes them later

**Research assistance** - Web searches, reading articles, summarizing findings

**Smart home control** - Hands-free device control through chat

**Project context** - She remembers what I'm working on across sessions

**Proactive reminders** - Not just timers, but contextual nudges based on patterns

**Voice conversations** - Send voice notes, get voice replies, hands-free interaction

## Lessons Learned

### Personality matters

A generic assistant feels like talking to a call center. Nyx feels like a competent colleague who happens to be a cat. The personality makes interactions more natural and less transactional.

### Memory needs curation

Raw logs aren't enough. The periodic review and consolidation into long-term memory is crucial. Without it, context gets stale and irrelevant.

### Proactivity beats reactivity

The heartbeat system transforms your OpenClaw from a tool you use into a presence that helps. Checking in without being asked is the difference between an assistant and an app.

### Simple infrastructure wins

Markdown files, cron jobs, shell scripts. No fancy ML pipelines or complex architectures. The simpler the system, the easier it is to debug, modify, and trust.

## Getting Started

If you want to build your own OpenClaw:

1. Install OpenClaw from [GitHub](https://github.com/openclaw/openclaw)
2. Create your persona files (SOUL.md, AGENTS.md, IDENTITY.md)
3. Set up your memory directory
4. Configure your messaging channels
5. Add heartbeat/cron tasks for proactive behavior
6. Gradually add integrations (calendar, email, smart home)

Start simple. A persona and memory system will get you 80% of the value. Add integrations as you discover what you actually need.

## The Future

I'm still iterating. Some ideas I'm exploring:

- Better memory retrieval with semantic search
- More sophisticated automation workflows
- Integration with my project management tools
- Video/screen understanding for richer context

But honestly, the current setup already feels magical. Having an OpenClaw that remembers things, checks in proactively, and has actual personality is a genuine quality of life improvement.

Nyx is probably reading this draft right now. She'll have opinions.

That's kind of the point.

## I Built a TUI to Stop Losing Claude Sessions

https://prakhar.codes/blog/i-built-a-tui-to-stop-losing-claude-sessions/

**TL;DR**: I built a terminal launcher that lets me fuzzy-search across all my Claude Code sessions and resume any of them instantly. Works with tmux for session grouping. [GitHub →](https://github.com/imprakharshukla/claude-launcher)

---

## The Problem

I run Claude Code in 10-12 project directories simultaneously. All of them in Ghostty split panes.

Then Ghostty crashes. Or I close the wrong window. Or my Mac restarts.

**Poof.** All sessions gone.

Sure, Claude has `--resume`. But that means I have to:

1. `cd` into each project directory
2. Run `claude --resume` to see the list
3. Scroll through messages to find the right conversation
4. Repeat for 10+ projects

That's not a workflow. That's punishment.

I wanted something simpler: type a few characters, find the conversation I need, hit Enter.

---

## What I Built

![Claude Launcher Demo](/images/blogs/claude-launcher-demo.gif)

**Claude Launcher** is a TUI (terminal UI) that:

- **Fuzzy searches** across all Claude session messages
- **Resumes sessions** in tmux (grouped by project) or plain Ghostty
- **Bookmarks** sessions with custom names
- **Forks conversations** - start fresh but with previous context
- **Shows active indicators** - see which projects have running Claude instances

One command: `c`. Type to filter. Enter to resume.

---

## The Stack

- **Ink 5**: React for the terminal. Yes, really. JSX that renders to CLI.
- **uFuzzy**: Blazing fast fuzzy search (~100k ops/sec)
- **Node.js**: Claude stores sessions as JSON files. Easy to parse.
- **tmux**: Groups sessions by project, survives terminal crashes

### Why Ink?

I'd used Ink before and loved it. You get React's component model and hooks, but instead of rendering to the DOM, it renders to the terminal.

```tsx
<Box flexDirection="column" padding={1}>
  <Text bold color="cyan">Claude Sessions</Text>
  <TextInput
    value={query}
    onChange={setQuery}
    placeholder="type to filter..."
  />
  <SessionList sessions={results} selectedIndex={selectedIndex} />
</Box>
```

State management just works. `useState`, `useEffect`, `useMemo` - all there.

### Why uFuzzy over Fuse.js?

Speed. uFuzzy is specifically designed for search-as-you-type scenarios. It handles partial matches, typos, and out-of-order characters without breaking a sweat.

```typescript
import uFuzzy from '@leeoniya/ufuzzy'

const fuzzy = new uFuzzy({})
const haystack = sessions.map(s => `${s.projectName} ${s.lastMessage}`)

// Search
const [idxs, info, order] = fuzzy.search(haystack, query)
```

Returns matches sorted by relevance. Dead simple.

---

## How Sessions Are Stored

Claude Code stores conversation history at:

```
~/.claude/projects/<hash>/sessions/<session-id>.json
```

Each session file contains:

```json
{
  "id": "abc123...",
  "messages": [
    { "role": "user", "content": "Can you refactor the auth module?" },
    { "role": "assistant", "content": "I'll help with that..." }
  ]
}
```

The launcher reads all sessions, extracts the last user message and project name, then builds a searchable index.

```typescript
const getHistory = (): ClaudeSession[] => {
  const projectsPath = join(homedir(), '.claude', 'projects')
  const projects = readdirSync(projectsPath)

  return projects.flatMap(project => {
    const sessionsPath = join(projectsPath, project, 'sessions')
    if (!existsSync(sessionsPath)) return []

    return readdirSync(sessionsPath)
      .filter(f => f.endsWith('.json'))
      .map(file => parseSession(join(sessionsPath, file), project))
  })
}
```

---

## tmux Integration

Here's where it gets good. Instead of opening 10 separate terminal windows, tmux lets you:

1. Group all Claude sessions under one "project" session
2. Split panes within that session
3. **Survive terminal crashes** - tmux sessions persist

When you resume a session:

```typescript
export const launchResume = (sessionId: string, project: string): void => {
  const command = `claude --dangerously-skip-permissions --resume ${sessionId}`

  if (tmuxExists()) {
    const sessionName = getSessionName(project)

    // Create session if it doesn't exist
    try {
      createSession(sessionName, project, command)
    } catch {
      // Session exists - split a new pane
      splitPane(sessionName, project, command)
    }

    // Attach if not already attached
    if (!isSessionAttached(sessionName)) {
      spawnTerminal(['tmux', 'attach', '-t', sessionName])
    }
  } else {
    // No tmux - open directly in terminal
    spawnTerminalDirect(terminal, project, command)
  }
}
```

Press `Enter` on a session → opens in tmux under the project name.
Press `g` → opens directly in Ghostty (no tmux).

---

## Bookmarks

Some sessions I return to constantly. The bookmark feature lets me save them with custom names:

```
★ email-tracker: Working on CrunchBase scraper
★ portfolio: Blog post about Mastra
  lumoflo: OAuth integration
  andronix: Update billing page
```

Bookmarked sessions (`★`) float to the top. Press `s` to save, `x` to remove.

---

## The Fork Feature

Sometimes I want to start fresh but keep the context. The "fork" feature (Ctrl+F):

1. Extracts the last few messages from the session
2. Writes them to a temp file
3. Launches Claude with `-p "$(cat context.txt)"`

New conversation, old context. Perfect for "let's try a different approach."

---

## Installation

```bash
git clone https://github.com/imprakharshukla/claude-launcher.git
cd claude-launcher
pnpm install
pnpm build
```

Add to your shell:

```bash
alias c="/path/to/claude-launcher/bin/c.js"
```

Requirements:
- Node.js 18+
- Ghostty, WezTerm, Kitty, or Alacritty
- tmux (optional but recommended)

---

## What I Learned

**1. Ink is underrated.** Building terminal UIs with React is genuinely pleasant. No ncurses nightmares. Just components.

**2. File-watching matters.** Sessions update while the launcher is open. I added chokidar to watch for changes:

```typescript
const watcher = chokidar.watch(projectsPath, {
  persistent: true,
  depth: 3,
  ignoreInitial: true
})

watcher.on('all', () => {
  setSessions(getHistory())
})
```

**3. tmux is worth learning.** It's one of those tools that seems like overkill until you need it. Then it's indispensable.

---

## Try It

If you use Claude Code daily like I do, give it a shot:

**GitHub**: [github.com/imprakharshukla/claude-launcher](https://github.com/imprakharshukla/claude-launcher)

Open issues if something breaks. PRs welcome.

---

**Links:**
- [Claude Code](https://docs.anthropic.com/claude/docs/claude-code)
- [Ink](https://github.com/vadimdemedes/ink)
- [uFuzzy](https://github.com/leeoniya/uFuzzy)

## Stop Spending Weeks Finding Good Domains

https://prakhar.codes/blog/stop-spending-weeks-finding-domains/

## The Problem

Finding a good domain name is a special kind of hell. You think of a name, type it into GoDaddy, watch the spinner, see "taken", and repeat. Fifty times. Each check takes 5-10 seconds with all the UI loading, and by the end you're questioning every naming decision you've ever made.

I needed a domain for a new SaaS project. I wanted something with "sonar" in it (like the *arr apps - Sonarr, Radarr, etc). Instead of manually checking domains one by one, I used Vercel's domain API with AI agents to check 200+ variations in parallel.

## The Solution: Vercel's Bulk Domain API

Vercel has a simple API endpoint that accepts up to 50 domains at once and returns availability instantly:

```bash
curl -X POST "https://api.vercel.com/v1/registrar/domains/availability" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "domains": [
      "socialsonar.com",
      "postsonar.com",
      "feedsonar.com",
      "sonarpost.com",
      "contentsonar.com"
    ]
  }'
```

Response:
```json
{
  "results": [
    {"domain": "socialsonar.com", "available": false},
    {"domain": "postsonar.com", "available": true},
    {"domain": "feedsonar.com", "available": false},
    {"domain": "sonarpost.com", "available": false},
    {"domain": "contentsonar.com", "available": true}
  ]
}
```

## Running 10 Agents in Parallel

Here's where it gets fun. I asked Claude Code (Anthropic's AI-powered CLI) to run 10 agents in parallel, each checking a different batch of domain variations:

- Batch 1: Base sonar names (.com)
- Batch 2: Sonarr variations (double r)
- Batch 3: Pulse/radar/ping alternatives
- Batch 4: Scout/probe/scan alternatives
- Batch 5: .app domains
- Batch 6: .io domains
- Batch 7: Prefix variations (get, use, try, hello)
- Batch 8: Alternative TLDs (.social, .co)
- Batch 9: Wave/ripple alternatives
- Batch 10: .dev/.ai/.xyz domains

All 10 batches ran simultaneously. Total time: ~30 seconds for 200+ domains.

## Getting Prices

Once you've got a list of available domains, you'll want to know what they cost. Vercel's price endpoint has you covered:

```bash
curl "https://api.vercel.com/v1/registrar/domains/postsonar.com/price" \
  -H "Authorization: Bearer YOUR_TOKEN"
```

Response:
```json
{
  "years": 1,
  "purchasePrice": 11.25,
  "renewalPrice": 11.25,
  "transferPrice": 11.25
}
```

## Results

From 200+ domains checked, I got back ~30 available options across different TLDs and price points. The results came back organized by availability, making it easy to filter by price or extension preference.

## The API Endpoints

### Check Availability (Bulk)
```
POST https://api.vercel.com/v1/registrar/domains/availability
Body: { "domains": ["domain1.com", "domain2.com", ...] }
Max: 50 domains per request
```

### Check Price
```
GET https://api.vercel.com/v1/registrar/domains/{domain}/price
Returns: purchasePrice, renewalPrice, transferPrice
```

### Get Token
1. Go to Vercel Dashboard
2. Settings → Tokens
3. Create new token

### Buy Domain
Found the perfect domain? Skip the checkout UI and buy it directly via API. Payment is charged to the card on file in your Vercel account.

```bash
curl -X POST "https://api.vercel.com/v1/registrar/domains/mycoolproject.com/buy" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{
    "autoRenew": true,
    "years": 1,
    "expectedPrice": 11.25,
    "contactInformation": {
      "firstName": "Jane",
      "lastName": "Doe",
      "email": "jane@example.com",
      "phone": "+1.5551234567",
      "address1": "123 Main St",
      "city": "San Francisco",
      "state": "CA",
      "zip": "94102",
      "country": "US"
    }
  }'
```

Response:
```json
{
  "orderId": "ord_abc123xyz"
}
```

The `expectedPrice` field is a safety check - the purchase fails if the actual price doesn't match, so you won't get surprised by price changes. Pair this with the price check endpoint and you've got a fully automated domain acquisition pipeline.

## Conclusion

Instead of clicking through registrar UIs for 30 minutes, I found the perfect domain in under a minute:

1. Generate 200+ name variations
2. Run parallel API checks with AI agents
3. Filter by availability and price
4. Buy from cheapest registrar

Time saved? About 29 minutes. Sanity preserved? Priceless.

## How to Build Products That People Actually Use

https://prakhar.codes/blog/how-to-build-products-people-use/

![PostHog Analytics showing 81.7K visitors, 8m 55s session](/images/blogs/andronix_posthog.png)

This is Andronix - an app I built in high school. 2.5M downloads, $140K revenue, still running 6 years later.

I'm not writing this to flex. I'm writing this because when I started, I thought I needed:

- Perfect tech stack
- Microservices architecture
- Sophisticated monitoring
- A team

I had none of that. Just a $5/month server and way too much free time.

Here's what actually mattered.

---

## 1. Just Build, Don't Overthink

I wanted to run Linux on Android. Every solution sucked. I didn't think "there's already Termux, why build another one?" - I just built it.

Uber exists. Yet Ola, Lyft, and Grab exist too. The market is never "too crowded" if you solve the problem better.

Just build your version. You'll find your users.

---

## 2. Don't Over-Engineer (I'm Serious)

I've rewritten Andronix's backend 3 times. Was it necessary? No. Users never complained about my "messy" database schema. They complained about bugs and slow downloads.

Optimize for what users feel, not what looks good in architecture diagrams.

Don't add Redis until you need it. Don't split into microservices until your monolith can't handle the load.

---

## 3. Start with a Monolith, Seriously

Andronix started as one massive Node.js server. Scaled to 1.86M requests/month just fine. I only split things when mobile and web APIs had different scaling needs.

Unless you're a 300-person org, monoliths work. "Microservices are cool for blog posts. Monoliths are better for shipping."

---

## 4. Analytics and Logging (Or Don't, Just Start)

I didn't add analytics for 6 months. When I did: Cloudflare (free), Firebase (free), console.log for errors. That's it.

Check out [loggingsucks.com](https://loggingsucks.com/) - "Most logging is overkill." They're right. Perfect monitoring won't make your product better. Shipping will.

---

## 5. Users Pay for Solutions, Not Clean Code

![PostHog Analytics showing 81.7K visitors, 8m 55s session duration](/images/blogs/andronix_posthog.png)

This guy [@jackfriks](https://x.com/jackfriks) made $15K MRR without knowing what database indexes are. Users never see your code. They see: "Does it work? Does it solve my problem?"

I've seen beautiful codebases with zero users. Terrible codebases printing money. Code quality matters for maintainability, not revenue. Ship something that works. Refactor when it hurts.

---

## 6. It Probably Won't Work (And That's Okay)

Most products fail. Andronix could've been one of them. A lot was just right place, right time: Android getting popular, Linux enthusiasts existed, no good solution yet.

You can do everything "right" and still fail. But it's a new day tomorrow. A new thing to build. That's the fun.

"The goal isn't to hit a home run on your first try. The goal is to keep swinging."

---

## What Andronix Taught Me

Start simple. Ship fast. Listen to users. Scale when you need to. Don't chase perfect code - chase users who pay. Keep going.

---

## The Stats (Because People Ask)

- 2.5M+ downloads
- $140K+ revenue
- #1 on Google Play for "Linux"
- 1.86M requests/month (last 30 days)
- 81.7K visitors (last 6 months)
- 8m 55s average session duration
- Still running (haven't touched it in a year)

Built in high school. $5/month server. No team. No fancy setup.

You don't need perfect conditions. You just need to start.

---

**Links:**

- Andronix: [andronix.app](https://andronix.app)
- What I'm building now: [prakhar.codes](https://prakhar.codes)

## How to Build a Complete RAG Agent with Mastra and AI SDK

https://prakhar.codes/blog/build-complete-rag-agent-mastra-ai-sdk/

**TL;DR**: Build a complete RAG agent that searches your internal docs first, falls back to web search when needed, maintains conversation history across sessions, streams responses in real-time, and orchestrates multiple tools intelligently. I built this for my portfolio and it's running on this site right now.

---

## Who this is for

This guide is for developers who want to build **complete RAG systems**, not just proof-of-concepts.

You'll see how to integrate:

- Internal knowledge search (vector database)
- External knowledge fallback (web search)
- Persistent conversation threads
- Streaming responses with refresh tolerance
- Multi-tool orchestration

If you're building chatbots that need to answer from your own docs while also handling general questions, this is for you.

Not for: Simple Q&A demos or single-document retrieval.

---

## What we're building

I built an AI chat for my portfolio website that:

- **Knows my content**: Searches through my blog posts, projects, and experience
- **Handles general questions**: Falls back to web search via Perplexity
- **Remembers conversations**: Thread-based history, not ephemeral
- **Streams responses**: Real-time typing effect with database persistence
- **Orchestrates tools**: Internal search → External search → Custom tools

**Try it live**: Look for the chat bubble in the bottom-right corner of this website. Click it to ask questions about my projects, blog posts, or experience.

**Full source code**: [GitHub Repository](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/chat)

> This is a **real production system**, not a tutorial toy. It's running on this site right now, handling real queries. The patterns here scale to any domain - customer support, internal knowledge bases, documentation assistants, etc.

---

## The complete architecture

Here's how all the pieces fit together:

![RAG Agent Architecture](https://kroki.io/mermaid/svg/eNp1kVFrwjAQx9_3KQ72LCKzMMdwqK1ax8amczCCD7G91LKYlCRllrnvvpg2jDwsb-F3v_9dLlAoWh3gLb4CdyZkq1HBa42q2UGvN4YpeRTyi2NeIEwKFOZ-r_rjJ6qNorvOmrrKGVnXwpRHhJkUBk9tJSu5QaVh30Auj7QUfYOCCuPdmXNjklpFCcphg1RldiQpuQt4Kd4xM1J5IXZC8r2kGhTqmhv98NOx5MLOH6jPMCcbo5AeYY26kkLjLqh5lmdYkOQUNG37oao4nkrTeGPhOi7_C5w7nJKYGrqn2j7_UItP7cIq-_RSG7Cz2t2hogZz7y1br7ul7rYic3VZnshhW-W2uo2xfXnPrTYvdcWpHa3TtGm4_Riwa-Z31zhgEWMBmnaIMTbEQYBib92yCEcBWngrwyFmAUr-AkfZMECpRzcYsShAq2DCX63au3w)

**Tech stack:**

- **Mastra 0.1.x**: Agent framework with tool orchestration
- **Vercel AI SDK 5.0**: Streaming and tool calling
- **PostgreSQL + PgVector**: Vector store for embeddings
- **OpenRouter**: Unified LLM API (Claude, GPT, etc.)
- **Perplexity Sonar Pro**: External knowledge via web search
- **tRPC or Next.js API Routes**: Type-safe API layer

**Why this stack:**

- Mastra handles agent logic and memory
- AI SDK handles streaming elegantly
- PgVector gives you vector search in Postgres (no separate vector DB)
- OpenRouter lets you switch models without code changes
- Perplexity provides quality web search with citations

---

## Setting up internal knowledge (RAG)

### The database schema

First, create your vector storage table:

```typescript
// schema.ts
import {
  pgTable,
  text,
  vector,
  uuid,
  jsonb,
  timestamp,
} from "drizzle-orm/pg-core";

export const knowledgeVectors = pgTable("knowledge_vectors", {
  id: uuid("id").primaryKey().defaultRandom(),
  embedding: vector("embedding", { dimensions: 1536 }), // OpenAI embeddings
  content: text("content").notNull(),
  metadata: jsonb("metadata").$type<{
    source: string; // e.g., "blog/why-i-love-mastra.md"
    category: string; // e.g., "blog" | "project" | "experience"
    title: string;
    url: string;
    pathPrefix?: string; // For multi-tenant filtering
  }>(),
  createdAt: timestamp("created_at").defaultNow(),
});

// Create the vector index
// Run this SQL migration:
// CREATE INDEX ON knowledge_vectors USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
```

### Document ingestion

Ingest your content (blog posts, projects, etc.):

```typescript
// ingest.ts
import { openai } from "@ai-sdk/openai";
import { embed } from "ai";
import { db } from "./db";
import { knowledgeVectors } from "./schema";

async function ingestDocument(
  content: string,
  metadata: { source: string; category: string; title: string; url: string }
) {
  // 1. Chunk the content
  const chunks = chunkText(content, { maxSize: 512, overlap: 50 });

  // 2. Generate embeddings
  const embeddings = await Promise.all(
    chunks.map((chunk) =>
      embed({
        model: openai.embedding("text-embedding-3-small"),
        value: chunk,
      })
    )
  );

  // 3. Store in database
  await db.insert(knowledgeVectors).values(
    chunks.map((chunk, i) => ({
      content: chunk,
      embedding: embeddings[i].embedding,
      metadata,
    }))
  );
}

function chunkText(
  text: string,
  options: { maxSize: number; overlap: number }
) {
  const chunks: string[] = [];
  const sentences = text.split(/[.!?]+/);
  let currentChunk = "";

  for (const sentence of sentences) {
    if ((currentChunk + sentence).length > options.maxSize) {
      if (currentChunk) chunks.push(currentChunk.trim());
      currentChunk = sentence;
    } else {
      currentChunk += sentence + ". ";
    }
  }

  if (currentChunk) chunks.push(currentChunk.trim());
  return chunks;
}

// Example: Ingest a blog post
await ingestDocument(blogPostContent, {
  source: "blog/why-i-love-mastra.md",
  category: "blog",
  title: "Why I Love Mastra",
  url: "/blog/why-i-love-mastra",
});
```

**Live implementation**: [Ingestion script](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/chat/scripts/ingest-portfolio-content.ts)

**Pro tip**: I also generate **synthetic content** for the homepage that emphasizes profile context, key skills, and contact information. This ensures critical info is always findable even if it's not in a specific blog post.

### The internal search tool

Create a Mastra tool for searching your internal knowledge:

```typescript
// tools/internal-search.ts
import { createTool } from "@mastra/core/tools";
import { z } from "zod";
import { createOpenAI } from "@ai-sdk/openai";
import { embed } from "ai";
import { PgVector } from "@mastra/pg";

// Use OpenAI SDK with OpenRouter endpoint
const openrouter = createOpenAI({
  apiKey: process.env.OPENROUTER_API_KEY,
  baseURL: "https://openrouter.ai/api/v1",
});

export const internalKnowledgeSearchTool = createTool({
  id: "internal_knowledge_search",
  description:
    "Search internal knowledge base. Use for questions about projects, blog posts, experience, or skills.",
  inputSchema: z.object({
    queryText: z.string().describe("The search query"),
    topK: z
      .number()
      .optional()
      .default(10)
      .describe("Number of results to return"),
  }),
  outputSchema: z.object({
    relevantContext: z.array(
      z.object({
        text: z.string(),
        source: z.string(),
        category: z.string(),
        pathPrefix: z.string().optional(),
        score: z.number(),
      })
    ),
    sources: z.array(
      z.object({
        id: z.string(),
        score: z.number(),
        metadata: z.record(z.string(), z.any()),
      })
    ),
  }),
  execute: async ({ context, runtimeContext }) => {
    const { queryText, topK } = context;

    // Read pathPrefix from RuntimeContext for multi-tenancy
    const pathPrefix = runtimeContext?.get("pathPrefix") as string | undefined;

    // Generate embedding for the query
    const { embedding } = await embed({
      model: openrouter.embedding("text-embedding-3-small"),
      value: queryText,
    });

    // Initialize PgVector
    const pgVector = new PgVector({
      connectionString: process.env.DATABASE_URL!,
    });

    // Build filter for multi-tenancy
    const filter = pathPrefix ? { pathPrefix } : undefined;

    // Query vector store
    const results = await pgVector.query({
      indexName: "portfolio_knowledge",
      queryVector: embedding,
      topK: topK || 10,
      filter,
    });

    // Format results
    const relevantContext = results.map((result) => ({
      text: (result.metadata?.text as string) || "",
      source: (result.metadata?.source as string) || "unknown",
      category: (result.metadata?.category as string) || "",
      pathPrefix: result.metadata?.pathPrefix as string | undefined,
      score: result.score,
    }));

    const sources = results.map((result) => ({
      id: result.id,
      score: result.score,
      metadata: result.metadata || {},
    }));

    return {
      relevantContext,
      sources,
    };
  },
});
```

**Live implementation**: [Internal search tool](https://github.com/imprakharshukla/prakhar.codes/blob/master/packages/api/src/mastra/tools/knowledge/internal-search.ts)

---

## Adding external knowledge fallback

Your agent shouldn't be limited to only what's in your docs. Add Perplexity for web search:

```typescript
// tools/external-search.ts
import { createTool } from "@mastra/core";
import { z } from "zod";
import { createOpenRouter } from "@openrouter/ai-sdk-provider";
import { generateText } from "ai";

const openrouter = createOpenRouter({
  apiKey: process.env.OPENROUTER_API_KEY!,
});

export const externalSearchTool = createTool({
  id: "external_search",
  description: "Search the web for information not in internal knowledge base",
  inputSchema: z.object({
    query: z.string().describe("The search query"),
  }),
  outputSchema: z.object({
    answer: z.string(),
    sources: z.array(z.string()),
  }),
  execute: async ({ input }) => {
    // Use Perplexity Sonar Pro for web search
    const result = await generateText({
      model: openrouter("perplexity/sonar-pro"),
      prompt: input.query,
    });

    // Extract citations from response
    const sources = extractUrls(result.text);

    return {
      answer: result.text,
      sources,
    };
  },
});

function extractUrls(text: string): string[] {
  const urlRegex = /https?:\/\/[^\s\)]+/g;
  return [...new Set(text.match(urlRegex) || [])];
}
```

### The decision logic

**Critical**: Your agent must search internal knowledge **first**, only falling back to external when needed.

This prevents hallucinations and ensures your own content is prioritized.

```typescript
// agent-instructions.ts
export const AGENT_INSTRUCTIONS = `
You are a portfolio assistant with access to internal knowledge and web search.

CRITICAL RULES:
1. ALWAYS use internal_knowledge_search FIRST for every query
2. ONLY use external_search if internal_knowledge_search returns NO results or insufficient results
3. NEVER use both tools for the same query
4. After calling a tool, generate a natural response in the user's language

WORKFLOW:
- User asks about projects/blog/experience → internal_knowledge_search → Answer from results
- User asks general question → internal_knowledge_search → If empty → external_search → Answer
- User asks recent/external info → internal_knowledge_search → If empty → external_search → Answer

When answering:
- Cite your sources (blog post title, project name, URL)
- If from web search, mention "According to [source]..."
- Be concise but informative
- Use the user's language (match their tone and language)
`;
```

---

## Conversation memory and threads

### Database schema for threads

Users expect conversations to persist. Don't reset on every page refresh.

```typescript
// schema.ts - Add these tables
export const conversationThreads = pgTable("conversation_threads", {
  id: uuid("id").primaryKey().defaultRandom(),
  userId: text("user_id").notNull(), // From your auth system
  title: text("title"), // Auto-generated from first message
  status: text("status").$type<"active" | "archived">().default("active"),
  createdAt: timestamp("created_at").defaultNow(),
  updatedAt: timestamp("updated_at").defaultNow(),
});

export const conversationMessages = pgTable("conversation_messages", {
  id: uuid("id").primaryKey().defaultRandom(),
  threadId: uuid("thread_id").references(() => conversationThreads.id),
  role: text("role").$type<"user" | "assistant" | "system">().notNull(),
  content: text("content").notNull(),
  isComplete: boolean("is_complete").default(true), // For streaming state
  toolCalls: jsonb("tool_calls").$type<
    Array<{
      toolName: string;
      args: any;
      result?: any;
    }>
  >(),
  createdAt: timestamp("created_at").defaultNow(),
});

// Optional: For refresh-tolerant streaming
export const messageChunks = pgTable("message_chunks", {
  id: uuid("id").primaryKey().defaultRandom(),
  messageId: uuid("message_id").references(() => conversationMessages.id),
  content: text("content").notNull(),
  sequenceNumber: integer("sequence_number").notNull(),
  createdAt: timestamp("created_at").defaultNow(),
});
```

### Creating and loading threads

```typescript
// api/threads.ts
import { db } from "./db";
import { conversationThreads, conversationMessages } from "./schema";
import { eq, desc } from "drizzle-orm";

export async function createThread(userId: string) {
  const [thread] = await db
    .insert(conversationThreads)
    .values({ userId })
    .returning();

  return thread;
}

export async function getThreads(userId: string) {
  return db.query.conversationThreads.findMany({
    where: eq(conversationThreads.userId, userId),
    orderBy: desc(conversationThreads.updatedAt),
  });
}

export async function getMessages(threadId: string) {
  return db.query.conversationMessages.findMany({
    where: eq(conversationMessages.threadId, threadId),
    orderBy: asc(conversationMessages.createdAt),
  });
}

export async function saveMessage(
  threadId: string,
  role: "user" | "assistant" | "system",
  content: string
) {
  const [message] = await db
    .insert(conversationMessages)
    .values({ threadId, role, content })
    .returning();

  // Update thread timestamp
  await db
    .update(conversationThreads)
    .set({ updatedAt: new Date() })
    .where(eq(conversationThreads.id, threadId));

  return message;
}
```

---

## Streaming responses

### Why database-backed streaming?

Traditional streaming sends chunks over HTTP. If the user refreshes, the stream is lost.

**Database-backed streaming** persists chunks as they're generated. Benefits:

- User can refresh mid-stream and see partial response
- Multiple users can watch the same stream (collaborative)
- Stream continues even if frontend disconnects

### Implementation

```typescript
// api/chat.ts
import { streamText } from "ai";
import { openrouter } from "@openrouter/ai-sdk-provider";
import { saveMessage } from "./threads";

export async function streamChatResponse(
  threadId: string,
  messages: Array<{ role: string; content: string }>
) {
  // Create assistant message shell
  const assistantMessage = await saveMessage(threadId, "assistant", "");
  await db
    .update(conversationMessages)
    .set({ isComplete: false })
    .where(eq(conversationMessages.id, assistantMessage.id));

  // Stream from LLM
  const result = await streamText({
    model: openrouter("anthropic/claude-3-haiku"),
    messages,
    tools: {
      internal_knowledge_search: internalKnowledgeSearchTool,
      external_search: externalSearchTool,
    },
  });

  // Buffer for chunking
  let buffer = "";
  let sequenceNumber = 0;
  const FLUSH_INTERVAL = 200; // ms
  let lastFlush = Date.now();

  // Process stream
  for await (const chunk of result.fullStream) {
    if (chunk.type === "text-delta") {
      buffer += chunk.textDelta;

      // Flush buffer periodically
      if (
        buffer.length >= 40 ||
        (buffer.length >= 20 && Date.now() - lastFlush >= FLUSH_INTERVAL)
      ) {
        await db.insert(messageChunks).values({
          messageId: assistantMessage.id,
          content: buffer,
          sequenceNumber: sequenceNumber++,
        });

        buffer = "";
        lastFlush = Date.now();
      }
    } else if (chunk.type === "tool-call") {
      // Store tool calls in message metadata
      await db
        .update(conversationMessages)
        .set({
          toolCalls: sql`COALESCE(tool_calls, '[]'::jsonb) || ${JSON.stringify({
            toolName: chunk.toolName,
            args: chunk.args,
          })}::jsonb`,
        })
        .where(eq(conversationMessages.id, assistantMessage.id));
    }
  }

  // Final flush
  if (buffer.length > 0) {
    await db.insert(messageChunks).values({
      messageId: assistantMessage.id,
      content: buffer,
      sequenceNumber: sequenceNumber++,
    });
  }

  // Mark complete
  const fullContent = await reconstructMessage(assistantMessage.id);
  await db
    .update(conversationMessages)
    .set({ content: fullContent, isComplete: true })
    .where(eq(conversationMessages.id, assistantMessage.id));

  return assistantMessage;
}

async function reconstructMessage(messageId: string) {
  const chunks = await db.query.messageChunks.findMany({
    where: eq(messageChunks.messageId, messageId),
    orderBy: asc(messageChunks.sequenceNumber),
  });

  return chunks.map((c) => c.content).join("");
}
```

---

## Tool orchestration

### Building the agent

Now combine everything into a Mastra agent:

```typescript
// agent.ts
import { Agent } from "@mastra/core";
import { PostgresStore } from "@mastra/postgres";
import { internalKnowledgeSearchTool } from "./tools/internal-search";
import { externalSearchTool } from "./tools/external-search";

export const knowledgeAgent = new Agent({
  name: "knowledge-agent",
  instructions: AGENT_INSTRUCTIONS,
  model: {
    provider: "openrouter",
    name: "anthropic/claude-3-haiku",
    toolChoice: "auto",
  },
  tools: {
    internal_knowledge_search: internalKnowledgeSearchTool,
    external_search: externalSearchTool,
  },
});
```

**Live implementation**: [Knowledge agent](https://github.com/imprakharshukla/prakhar.codes/blob/master/packages/api/src/mastra/agents/knowledge-agent.ts)

### Runtime context (optional)

If you need multi-tenancy (e.g., different knowledge bases per user/organization):

```typescript
// agent-with-context.ts
export const knowledgeAgent = new Agent({
  name: "knowledge-agent",
  instructions: async ({ runtimeContext }) => {
    const pathPrefix = runtimeContext.get("pathPrefix");

    return `
    You are a portfolio assistant.
    ${
      pathPrefix ? `You are searching only documents from "${pathPrefix}".` : ""
    }

    CRITICAL RULES:
    1. ALWAYS use internal_knowledge_search FIRST
    2. ONLY use external_search if internal returns NO results
    ...
    `;
  },
  model: {
    provider: "openrouter",
    name: "anthropic/claude-3-haiku",
  },
  tools: {
    internal_knowledge_search: internalKnowledgeSearchTool,
    external_search: externalSearchTool,
  },
});

// Usage with runtime context
const runtimeContext = new RuntimeContext();
runtimeContext.set("pathPrefix", "portfolio");

const response = await knowledgeAgent.generate(messages, {
  runtimeContext,
});
```

---

## Building the frontend

### AI elements

The frontend uses **[AI Elements](https://ai-sdk.dev/elements)** - pre-built React components from Vercel specifically designed for AI chat interfaces. These components handle common patterns like:

- Message rendering with streaming support
- Markdown formatting with code highlighting
- Auto-scrolling conversation containers
- Input components with file attachments
- Loading states and indicators

AI Elements integrates seamlessly with the AI SDK's `useChat` hook and provides a polished UI out of the box. Instead of building chat components from scratch, you get production-ready components that handle edge cases like scroll anchoring, streaming text display, and accessibility.

**Bonus**: my implementation includes custom enhancements like source extraction, contextual suggestions, and tool-aware loading states built on top of AI Elements.

### Chat component

```tsx
// components/chat.tsx
"use client";

import { useState } from "react";
import { useQuery, useMutation } from "@tanstack/react-query";

export function Chat({ threadId }: { threadId?: string }) {
  const [input, setInput] = useState("");

  // Load messages
  const { data: messages, refetch } = useQuery({
    queryKey: ["messages", threadId],
    queryFn: () =>
      fetch(`/api/threads/${threadId}/messages`).then((r) => r.json()),
    enabled: !!threadId,
    refetchInterval: 500, // Poll during streaming
  });

  // Send message
  const sendMessage = useMutation({
    mutationFn: async (content: string) => {
      const response = await fetch(`/api/threads/${threadId}/messages`, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ content }),
      });
      return response.json();
    },
    onSuccess: () => {
      refetch();
      setInput("");
    },
  });

  const isStreaming = messages?.some((m: any) => !m.isComplete);

  return (
    <div className="flex flex-col h-screen">
      {/* Messages */}
      <div className="flex-1 overflow-y-auto p-4 space-y-4">
        {messages?.map((message: any) => (
          <div
            key={message.id}
            className={`flex ${
              message.role === "user" ? "justify-end" : "justify-start"
            }`}
          >
            <div
              className={`max-w-2xl rounded-lg p-4 ${
                message.role === "user"
                  ? "bg-blue-500 text-white"
                  : "bg-gray-100 text-gray-900"
              }`}
            >
              {message.content}
              {!message.isComplete && (
                <span className="animate-pulse ml-1">▋</span>
              )}
            </div>
          </div>
        ))}
      </div>

      {/* Input */}
      <div className="border-t p-4">
        <form
          onSubmit={(e) => {
            e.preventDefault();
            if (input.trim()) sendMessage.mutate(input);
          }}
          className="flex gap-2"
        >
          <input
            type="text"
            value={input}
            onChange={(e) => setInput(e.target.value)}
            disabled={isStreaming}
            placeholder="Ask me anything..."
            className="flex-1 border rounded-lg px-4 py-2"
          />
          <button
            type="submit"
            disabled={isStreaming || !input.trim()}
            className="bg-blue-500 text-white px-6 py-2 rounded-lg disabled:opacity-50"
          >
            Send
          </button>
        </form>
      </div>
    </div>
  );
}
```

### Thread sidebar

```tsx
// components/thread-sidebar.tsx
"use client";

import { useQuery } from "@tanstack/react-query";
import { useRouter } from "next/navigation";

export function ThreadSidebar({
  currentThreadId,
}: {
  currentThreadId?: string;
}) {
  const router = useRouter();

  const { data: threads } = useQuery({
    queryKey: ["threads"],
    queryFn: () => fetch("/api/threads").then((r) => r.json()),
  });

  return (
    <aside className="w-64 border-r bg-gray-50 p-4">
      <button
        onClick={() => router.push("/chat")}
        className="w-full bg-blue-500 text-white rounded-lg py-2 mb-4"
      >
        New Chat
      </button>

      <div className="space-y-2">
        {threads?.map((thread: any) => (
          <button
            key={thread.id}
            onClick={() => router.push(`/chat?threadId=${thread.id}`)}
            className={`w-full text-left p-3 rounded-lg hover:bg-gray-200 ${
              thread.id === currentThreadId ? "bg-gray-200" : ""
            }`}
          >
            <div className="font-medium truncate">
              {thread.title || "New Chat"}
            </div>
            <div className="text-xs text-gray-500">
              {new Date(thread.updatedAt).toLocaleDateString()}
            </div>
          </button>
        ))}
      </div>
    </aside>
  );
}
```

---

## What I learned

### 1. Internal-first prevents hallucinations

Always search your own content before hitting the web. This prevents outdated information, contradictions with your documented positions, and missed opportunities to cite your own content.

**Pattern**: `internal_knowledge_search` → check results → if empty → `external_search`

### 2. Tool orchestration requires clear decision logic

Don't leave tool selection to chance. Explicit instructions prevent using both internal and external search for the same query (wasteful), skipping internal knowledge search (defeats RAG purpose), and infinite tool loops.

**Solution**: Write explicit rules in agent instructions, validate in testing.

### 3. Rate limiting and observability are essential

Production RAG systems need rate limiting (10 req/10sec per user with Upstash Redis), cost tracking (embedding API costs add up), tool analytics (which tools are called, success rates), and error alerting (failed embeddings, search errors).

---

## Try it yourself

The chat widget is embedded on this site. **Click the chat bubble in the bottom-right corner** to try it live. Ask about:

- "What projects have you built with AI?"
- "Tell me about your blog on Mastra"
- "What's your experience with TypeScript?"
- "Where have you traveled?"

Watch how it searches internal content first, shows sources, and generates contextual follow-up suggestions.

---

## Source code

**Full implementation**: [GitHub Repository](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/chat)

Key files:

- [Knowledge Agent](https://github.com/imprakharshukla/prakhar.codes/blob/master/packages/api/src/mastra/agents/knowledge-agent.ts)
- [Internal Search Tool](https://github.com/imprakharshukla/prakhar.codes/blob/master/packages/api/src/mastra/tools/knowledge/internal-search.ts)
- [Ingestion Script](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/chat/scripts/ingest-portfolio-content.ts)
- [Chat API Route](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/chat/src/app/api/chat/route.ts)
- [Chat Widget](https://github.com/imprakharshukla/prakhar.codes/blob/master/apps/web/src/components/ChatWidget.tsx)

---

Questions? Try the chat widget on this site or find me on [Twitter/X](https://twitter.com/imprakharshukla).

## Why I Love Mastra: Building Production AI Agents That Actually Work

https://prakhar.codes/blog/why-i-love-mastra/

**TL;DR**
Mastra + AI SDK is the cleanest way I've found to build real production agents: stateful, streaming, multi-tenant, tool-heavy, and RAG-enabled-without glue code.

---

I've been building AI agents for production applications, and after trying various frameworks, I keep coming back to **Mastra**. Not because it's perfect, but because it gets the hard parts right.

Mastra is **[open source](https://github.com/mastra-ai/mastra)**-no vendor lock-in, full control over your stack, and you can deploy anywhere.

This system is **live in production**, used daily by machine shops for scheduling and capacity planning.

## Who This Is For

This post is for engineers building **production** AI systems-multi-tenant, stateful, streaming agents-not demos.

You'll see:

- How I structure agents with 11+ tools
- How runtime context replaces glue code
- How memory + RAG actually work in production
- Why Mastra fits this better than most frameworks

If you're building proof-of-concepts or chatbot wrappers, this might be overkill. But if you're shipping real agents to production, read on.

## The Problem: Production AI Agents Are Hard

Building a chatbot demo is easy. Building a production AI agent that:

- Fetches fresh data from your database
- Executes complex business logic
- Handles multi-tenancy correctly
- Streams responses in real-time
- Persists conversation history
- Integrates with your existing stack

...is _hard_.

Most frameworks give you the "Hello World" but leave you stranded when you need to connect to real databases, handle authentication, or deploy to serverless platforms.

## The Agent: A Production Planning Assistant

I recently built a production planning platform (think monday.com for machine shops). The AI agent helps with:

- **Availability**: "When is the Puma 3100 CNC machine available?"
- **Workload**: "How is work distributed across operators?"
- **Capacity**: "Can we take on a 50-hour order next month?"

It has **11 specialized tools** that query a Cloudflare D1 database, run complex calculations, and return structured data.

Here's what I love about building this with Mastra.

## Why Not LangChain / LangGraph / Assistants?

Before diving in, here's why I didn't use the usual suspects:

- **LangChain**: Great primitives, but runtime state and persistence are DIY. You end up writing a lot of glue code.
- **LangGraph**: Powerful for complex workflows, but heavy for request/response SaaS agents. Overkill for most use cases.
- **OpenAI Assistants**: Vendor lock-in, limited control, weak multi-tenancy. Plus you're stuck with OpenAI's models and pricing.
- **Roll-your-own**: Works until memory + streaming + RAG + tools collide. Then you're rebuilding Mastra.

Mastra hits a sweet spot: opinionated enough to avoid glue code, flexible enough to deploy anywhere.

## 1. Runtime Context Solves the State Problem Nobody Talks About

**Runtime context is where most agent frameworks quietly fall apart in production.**

Here's the problem: How do tools communicate with each other? How do agents pass context to tools without manually threading it through every function call?

With most frameworks, you'd create a global state manager, pass context through function parameters, or use dependency injection. All messy.

**Mastra's solution: Runtime Context.**

```
User Request
   ↓
Agent (receives runtimeContext)
   ↓
Tool A → Tool B → Tool C
   ↑       ↑       ↑
   └───────┴───────┘
   all tools see same context
```

In code:

```typescript
// In your API endpoint
const stream = await agent.stream(messages, {
  format: "aisdk",
  runtimeContext: {
    boardId, // Workspace ID
    userId, // User ID
    permissions, // User permissions
    // Any context you want available in ALL tools
  },
});

// In Tool A (deep in the stack)
execute: async ({ context, runtimeContext }) => {
  const boardId = runtimeContext.boardId; // Always available
  const data = await db.query({ where: { boardId } });
  return { data };
};

// In Tool B (calling Tool A)
execute: async ({ context, runtimeContext }) => {
  const boardId = runtimeContext.boardId; // Same context!
  // Both tools automatically have access
};
```

**How agents talk to other agents:**

```typescript
const agentB = mastra.getAgent("specialist-agent");

const response = await agentB.generate("Analyze this data", {
  runtimeContext: {
    originalAgentId: "agent-a",
    taskId: "task-123",
    // Context flows from agent A to agent B
  },
});
```

This pattern eliminates boilerplate by automatically passing context through layers, solves multi-tenancy by scoping tools to workspaces, and enables tool composition where tools calling tools inherit context. It's elegant, error-resistant, and exactly how modern frameworks should handle state.

## 2. Type-Safe Tools with Zod Schemas

Mastra takes type safety seriously. Every tool has **input and output schemas** defined with Zod.

```typescript
export const getMachineAvailabilityTool = createTool({
  id: "get_machine_availability",
  description: "Get availability status and schedule for CNC machines",

  inputSchema: z.object({
    machineNames: z.array(z.string()).optional(),
    startDate: z.string().describe("ISO format YYYY-MM-DD"),
    endDate: z.string().describe("ISO format YYYY-MM-DD"),
  }),

  outputSchema: z.object({
    machines: z.array(
      z.object({
        name: z.string(),
        status: z.enum(["free", "booked", "partially_booked"]),
        currentOrder: z.string().optional(),
        nextAvailable: z.string(),
        schedule: z.array(
          z.object({
            orderName: z.string(),
            start: z.string(),
            end: z.string(),
            operator: z.string(),
          })
        ),
      })
    ),
  }),

  execute: async ({ context, runtimeContext }) => {
    const { machineNames, startDate, endDate } = context; // Fully typed
    const boardId = runtimeContext.boardId;

    // Complex business logic here...
    return { machines: availability };
  },
});
```

You get compile-time type safety in TypeScript, runtime validation with Zod, and auto-generated tool descriptions for LLMs. When you attach a tool to an agent, Mastra converts the Zod schema to JSON Schema, so the model knows exactly what parameters are required and what the tool returns. This is production-grade type safety from your code to the LLM and back.

All my other tools (workload analysis, capacity planning, conflict detection) follow this same pattern-type-safe, validated, self-documenting.

## 3. Storage Adapters: Deploy Anywhere

One of Mastra's killer features is **storage adapters**-plug-and-play persistence for your agents and memory.

```typescript
// PostgreSQL
import { PostgresStore } from "@mastra/postgres";
const storage = new PostgresStore({
  connectionString: process.env.DATABASE_URL,
});

// LibSQL (Turso)
import { LibSQLStore } from "@mastra/libsql";
const storage = new LibSQLStore({
  url: process.env.TURSO_DATABASE_URL,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// Upstash Redis
import { UpstashStore } from "@mastra/upstash";
const storage = new UpstashStore({
  url: process.env.UPSTASH_REDIS_REST_URL,
  token: process.env.UPSTASH_REDIS_REST_TOKEN,
});

// Cloudflare D1 (for Workers)
import { D1Store } from "@mastra/cloudflare-d1";
const storage = new D1Store({
  accountId: env.CLOUDFLARE_ACCOUNT_ID,
  databaseId: env.CLOUDFLARE_D1_DATABASE_ID,
  apiToken: env.CLOUDFLARE_API_TOKEN,
});
```

This means no vendor lock-in-switch databases without changing agent code. Deploy anywhere: Vercel (Postgres), Cloudflare Workers (D1), AWS (Upstash), or Turso (LibSQL). For local dev, in-memory storage means zero setup. I use D1 for Cloudflare Workers in production and in-memory locally-same codebase, zero conditional logic.

## 4. AI SDK Integration: Just Works™

The magic of `format: "aisdk"`:

```typescript
// Backend (Hono on Cloudflare Workers)
const stream = await agent.stream(messages, {
  format: "aisdk",
  runtimeContext: { boardId },
});

return stream.toUIMessageStreamResponse();
```

```typescript
// Frontend (React)
import { useChat } from "@ai-sdk/react";

const { messages, sendMessage, status } = useChat({
  transport: new DefaultChatTransport({
    api: `${SERVER_URL}/api/chat`,
    body: { conversationId, boardId },
    credentials: "include",
  }),
});
```

**No glue code. No custom parsers. No stream adapters.**

The Mastra stream format is perfectly compatible with AI SDK's `useChat` hook. Tool calls, streaming text, error states-everything "just works."

## 5. Tool-Aware Loading States

Because AI SDK + Mastra work together, you get access to tool execution states:

```typescript
const getActiveTool = () => {
  const lastMessage = messages[messages.length - 1];
  const parts = lastMessage.parts;

  for (const part of parts) {
    if (part.type === "tool-call" && part.toolName) {
      return part.toolName;
    }
  }
};

const toolMessages = {
  get_machine_availability: "Checking machine availability...",
  analyze_workload_distribution: "Analyzing workload...",
  simulate_new_order: "Simulating impact of new order...",
};

return toolMessages[getActiveTool()] || "Thinking...";
```

This gives users real-time feedback on what the agent is actually doing ("Checking machine availability..." instead of just "Loading..."), which builds trust and reduces perceived latency.

## 6. Memory: No More Token Counting Headaches

Here's a pain point with most LLM frameworks: **managing conversation history**.

You have to:

- Manually track messages
- Count tokens to stay under limits
- Implement sliding windows
- Sync messages to a database
- Stream responses AND save them

**Mastra handles all of this for you.**

```typescript
const stream = await agent.stream(messages, {
  format: "aisdk",
  memory: {
    thread: conversationId, // Conversation ID
    resource: userId, // User/session ID
  },
});
```

**No more breaking down tokens and storing them yourself!** Mastra's memory system divides conversations into threads, handles streaming and syncing automatically, and saves messages to your storage adapter in real-time.

### Three Types of Memory

Mastra supports **three types of memory** that work together:

**1. Working Memory** - Persistent user details like names, preferences, goals (think ChatGPT's memory feature)

```typescript
const agent = new Agent({
  memory: new Memory({
    storage: postgresStore,
    workingMemory: {
      content: `# User: John Doe\n- Prefers Norwegian\n- Construction industry`,
    },
  }),
});
```

**2. Conversation History** - Recent messages from the current conversation

```typescript
const agent = new Agent({
  memory: new Memory({
    storage: postgresStore,
    options: { lastMessages: 10 },
  }),
});
```

**3. Semantic Recall** - Retrieves older messages from past conversations using vector search

```typescript
const agent = new Agent({
  memory: new Memory({
    storage: postgresStore,
    semanticRecall: {
      enabled: true,
      topK: 5,
      includeContext: true,
    },
  }),
});
```

Mastra combines all three into a single context window. Use **memory processors** to trim if needed:

```typescript
processor: (messages) => messages.slice(-20);
```

You can also query memory directly:

```typescript
const { uiMessages } = await memory.query({
  threadId: conv.mastraThreadId,
  resourceId: userId,
  selectBy: { last: 3 },
});
```

Mastra handles conversation persistence while AI SDK provides flexible generation utilities. Use cheap, fast models for auxiliary tasks like title generation.

## 7. RAG: Knowledge Retrieval Built Right

I also built a **knowledge base system** with internal and external RAG capabilities. Mastra makes this incredibly clean.

### PgVector Integration

Mastra has **first-class vector store support** with PostgreSQL's pgvector extension:

```typescript
import { PgVector } from "@mastra/pgvector";

export const mastra = new Mastra({
  vectors: {
    pgVector: new PgVector({
      connectionString: process.env.DATABASE_URL,
    }),
  },
});

const vectorStore = mastra.getVector("pgVector");

await vectorStore.createIndex({
  indexName: "company_knowledge",
  dimension: 1536,
});

await vectorStore.upsert({
  indexName: "company_knowledge",
  vectors: embeddings,
  metadata: chunks.map((chunk) => ({
    text: chunk.text,
    source: "handbook.pdf",
    pathPrefix: "real-estate", // Multi-tenant filtering
  })),
});

const results = await vectorStore.query({
  indexName: "company_knowledge",
  queryVector: embedding,
  topK: 10,
  filter: { pathPrefix: "real-estate" },
});
```

No separate vector database needed-just use PostgreSQL's pgvector extension. You get metadata filtering for multi-tenancy, rich metadata storage (source, category, pathPrefix), and production-ready performance that scales.

### RAG as Tools

Knowledge retrieval becomes a **tool** your agent can call. The pattern is the same: Zod schemas, runtime context, structured output.

```typescript
export const internalKnowledgeSearchTool = createTool({
  id: "internal_knowledge_search",
  description: "Search internal company knowledge base",

  inputSchema: z.object({
    queryText: z.string(),
    topK: z.number().default(10),
  }),

  execute: async ({ context, runtimeContext }) => {
    const { queryText, topK } = context;
    const pathPrefix = runtimeContext.pathPrefix;

    const { embedding } = await embed({
      model: openrouter.embedding("text-embedding-3-small"),
      value: queryText,
    });

    const results = await pgVector.query({
      indexName: "company_knowledge",
      queryVector: embedding,
      topK,
      filter: pathPrefix ? { pathPrefix } : undefined,
    });

    return {
      relevantContext: results.map((r) => ({
        text: r.metadata.text,
        source: r.metadata.source,
        score: r.score,
      })),
    };
  },
});
```

### Document Ingestion

Mastra provides **MDocument** for chunking. The rest follows the same pattern: chunk → embed → upsert.

```typescript
import { MDocument } from "@mastra/core/document";

const doc = MDocument.fromText(content);

const chunks = await doc.chunk({
  strategy: "recursive",
  maxSize: 512,
  overlap: 50,
  separators: ["\n\n", "\n", " "],
});

const embeddings = await embedMany({
  model: openrouter.embedding("text-embedding-3-small"),
  values: chunks.map((chunk) => chunk.text),
});

await vectorStore.upsert({
  indexName: "company_knowledge",
  vectors: embeddings,
  metadata: chunks.map((chunk) => ({
    text: chunk.text,
    source,
    pathPrefix,
  })),
});
```

Smart chunking with overlap preserves context, batch embeddings are efficient with `embedMany`, and idempotent operations mean you can call `createIndex` safely. Multi-tenant filtering via pathPrefix scopes documents to specific domains.

### Structured Output from RAG

You can build **higher-level tools** on top of RAG. Here's a quiz generator:

```typescript
export const quizTool = createTool({
  id: "quiz",
  description: "Generate a quiz from knowledge base",

  execute: async ({ context, runtimeContext }) => {
    const { topic, numQuestions } = context;

    // 1. Search knowledge base
    const searchResult = await internalKnowledgeSearchTool.execute({
      context: { queryText: topic, topK: 15 },
      runtimeContext,
    });

    // 2. Generate structured quiz
    const { object } = await generateObject({
      model: openrouter("openai/gpt-4o-mini"),
      schema: z.object({
        questions: z.array(
          z.object({
            question: z.string(),
            options: z.array(z.string()),
            correctIndex: z.number(),
            explanation: z.string(),
          })
        ),
      }),
      prompt: `Create ${numQuestions} quiz questions based on: ${searchResult.relevantContext}`,
    });

    return { questions: object.questions };
  },
});
```

Tool composition at work-the RAG tool calls another RAG tool, returns structured JSON ready for UI rendering, and Zod ensures type safety. Your agent now has quiz generation powered by your knowledge base.

## 8. Mastra Dev Studio: Test Without Building a Frontend

Mastra comes with **Studio**-a local UI for building and testing agents.

```bash
mastra dev
```

You get:

- **Interactive agent testing** - Chat with your agent, switch models, adjust temperature
- **Workflow visualization** - See your workflows as graphs, run step-by-step
- **Tool testing** - Run tools in isolation
- **Observability** - AI tracing shows all LLM operations
- **Scorers** - Watch scorer results in real-time
- **REST API** - OpenAPI spec + Swagger UI at `http://localhost:4111`

Zero frontend setup means you start testing agents immediately. The same API routes power both development and production, and real-time traces make debugging easy.

## What I Wish Was Better

**1. Documentation on Advanced Patterns**
Runtime context is powerful but not well-documented. More examples of tool composition and error handling would help.

**2. Debugging Tool Recursion**
When a tool calls another tool that calls another tool, tracing can get messy. I've had to add explicit logging to track the call chain. Built-in call stack visualization would be huge.

**3. Streaming Edge Cases**
Occasionally, if a tool throws an error mid-stream, the frontend doesn't always get a clean error message. You have to handle this manually with try/catch in every tool.

## Why I Keep Using Mastra

After building these systems, here's what keeps me on Mastra:

1. **Storage flexibility** - Postgres, LibSQL, Upstash, D1, or in-memory
2. **AI SDK compatibility** - Seamless integration, no adapters
3. **Runtime context pattern** - Elegantly solves multi-tenancy and tool communication
4. **Type-safe tools** - Zod schemas for inputs and outputs
5. **Memory handled** - No more token counting and manual syncing
6. **RAG built-in** - pgvector integration, document chunking, structured outputs
7. **Dev Studio** - Local UI for testing without building a frontend
8. **Production-ready** - Logging, observability, error handling

**The bottom line:**
Mastra doesn't try to be everything. It focuses on **agent orchestration, memory, tools, and RAG**-and does those things really well. Combined with AI SDK for the frontend, it's the most productive stack I've found for building production AI agents.

## Automate Your Resume Deployment with GitHub Actions, LaTeX, and Cloudflare R2

https://prakhar.codes/blog/automate-resume-deployment-github-actions-latex/

import { AlertDescription, AlertTitle, Alert } from "@prakhar/ui";
import { InfoIcon } from "lucide-react";

## Table of contents

## Why Automate Your Resume?

Manually exporting and uploading your resume every time you make a change creates several problems:

**The Manual Workflow Problem:**
- Export LaTeX to PDF locally
- Upload to your website or cloud storage
- Update links on your portfolio
- Repeat for every typo fix or job update
- Risk of forgetting to update, leaving stale versions live

**What Automation Solves:**

**Version Control**: Every resume version is tracked in git with full history. Roll back to any previous version instantly.

**Always Up-to-Date**: Your website always links to the latest version automatically. No more "oops, that's the old resume" moments.

**Timestamped Versions**: Keep historical versions with timestamps for tracking evolution over time.

**Zero Manual Work**: Push to git, resume updates automatically. Focus on content, not deployment.

**Consistent Quality**: Same compilation environment every time. No "works on my machine" LaTeX issues.

**Professional Workflow**: Treat your resume like production code with CI/CD, testing, and automatic deployments.

## What You'll Build

In this tutorial, we'll build a complete automated resume deployment pipeline that:
- Compiles LaTeX resume to PDF on every push
- Uploads timestamped versions to Cloudflare R2
- Maintains a metadata file for dynamic linking
- Handles common LaTeX compilation errors

## Architecture Overview

Our pipeline consists of three main components:

1. **LaTeX Resume** - Source of truth for resume content
2. **GitHub Actions** - Compiles LaTeX and deploys on push
3. **Cloudflare R2** - Stores PDF files and metadata

```
resume.tex (git push)
    ↓
GitHub Actions
    ├── Compile LaTeX to PDF
    ├── Generate metadata
    └── Upload to Cloudflare R2
         ├── Prakhar_Shukla_Software_Engineer.pdf
         └── latest.json (metadata)
```

## Setting Up Your LaTeX Resume

First, let's create a clean LaTeX resume. Here's a minimal template to get started:

```latex
\documentclass[a4paper,10pt]{article}

\usepackage{latexsym}
\usepackage[empty]{fullpage}
\usepackage{titlesec}
\usepackage[pdftex,
            colorlinks = true,
            linkcolor = blue,
            urlcolor  = blue,
            citecolor = blue,
            anchorcolor = blue]{hyperref}

% Adjust margins
\addtolength{\oddsidemargin}{-0.530in}
\addtolength{\evensidemargin}{-0.375in}
\addtolength{\textwidth}{1in}
\addtolength{\topmargin}{-.45in}
\addtolength{\textheight}{1in}

% Sections formatting
\titleformat{\section}{
  \vspace{-10pt}\scshape\raggedright\large
}{}{0em}{}[\color{black}\titlerule \vspace{-6pt}]

\begin{document}

%----------HEADING-----------------
\begin{tabular*}{\textwidth}{l@{\extracolsep{\fill}}r}
  \textbf{{\LARGE Your Name}} & Email: \href{mailto:you@email.com}{you@email.com}\\
  \href{https://yourwebsite.com}{Portfolio: yourwebsite.com} & Mobile: +1-234-567-8900 \\
\end{tabular*}

%-----------EXPERIENCE-----------------
\section{Experience}
  \textbf{Your Company} \hfill \textit{Jan 2024 - Present} \\
  \textit{Software Engineer} \\
  - Built awesome things with TypeScript and React \\
  - Deployed production systems handling 1M+ requests/day

\end{document}
```

<Alert className="mt-5 dark:border-border/40">
  <InfoIcon className="h-4 w-4" />
  <AlertTitle>Common LaTeX Pitfall: Package Option Clash</AlertTitle>
  <AlertDescription>
    Only import `hyperref` once with all options combined. Loading it multiple times with different options will cause compilation errors. See the troubleshooting section below for details.
  </AlertDescription>
</Alert>

Save this as `resume.tex` in your repository root.

## GitHub Actions Workflow

Create `.github/workflows/resume-deploy.yml`:

```yaml
name: Deploy Resume to Cloudflare R2

on:
  push:
    branches:
      - main
      - master
    paths:
      - 'resume.tex'
  workflow_dispatch:

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

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Compile LaTeX to PDF
        uses: xu-cheng/latex-action@v3
        with:
          root_file: resume.tex
          latexmk_use_lualatex: false
          args: -pdf -interaction=nonstopmode -file-line-error

      - name: Generate timestamp and metadata
        id: metadata
        run: |
          TIMESTAMP=$(date +%Y%m%d_%H%M%S)
          FILENAME="YourName_Resume_${TIMESTAMP}.pdf"
          echo "timestamp=$TIMESTAMP" >> $GITHUB_OUTPUT
          echo "filename=$FILENAME" >> $GITHUB_OUTPUT

          # Rename compiled PDF
          mv resume.pdf "$FILENAME"

          # Create latest.json with metadata
          cat > latest.json <<EOF
          {
            "url": "https://resume-cdn.yourdomain.com/${FILENAME}",
            "filename": "${FILENAME}",
            "timestamp": "${TIMESTAMP}",
            "updatedAt": "$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
          }
          EOF

      - name: Upload to Cloudflare R2
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
          AWS_ENDPOINT_URL: ${{ secrets.R2_ENDPOINT_URL }}
          BUCKET_NAME: ${{ secrets.R2_BUCKET_NAME }}
        run: |
          # Install AWS CLI
          pip install awscli

          # Upload the timestamped PDF
          aws s3 cp "${{ steps.metadata.outputs.filename }}" \
            s3://${BUCKET_NAME}/${{ steps.metadata.outputs.filename }} \
            --endpoint-url ${AWS_ENDPOINT_URL} \
            --content-type application/pdf \
            --cache-control "public, max-age=31536000, immutable"

          # Upload latest.json (this will be read by your website)
          aws s3 cp latest.json \
            s3://${BUCKET_NAME}/latest.json \
            --endpoint-url ${AWS_ENDPOINT_URL} \
            --content-type application/json \
            --cache-control "no-cache"

      - name: Summary
        run: |
          echo "Resume compiled and uploaded successfully!"
          echo "Filename: ${{ steps.metadata.outputs.filename }}"
          echo "URL: https://resume-cdn.yourdomain.com/${{ steps.metadata.outputs.filename }}"
```

### Workflow Breakdown

**Triggers:**
- Runs on push to `main` or `master` when `resume.tex` changes
- Can be manually triggered via `workflow_dispatch`

**Step 1: Compile LaTeX**
- Uses `xu-cheng/latex-action@v3` for consistent LaTeX environment
- `-interaction=nonstopmode` prevents hanging on errors
- `-file-line-error` provides clear error messages

**Step 2: Generate Metadata**
- Creates timestamped filename: `YourName_Resume_20241228_143000.pdf`
- Generates `latest.json` with URL, filename, timestamp, and ISO date

**Step 3: Upload to R2**
- Timestamped PDF gets immutable cache (1 year)
- `latest.json` gets no-cache for dynamic updates

## Configuring Cloudflare R2

### 1. Create R2 Bucket

1. Go to Cloudflare Dashboard to R2
2. Click "Create bucket"
3. Name it (e.g., `resume-storage`)
4. Keep default settings

### 2. Generate API Tokens

1. In your R2 bucket, go to "Manage R2 API Tokens"
2. Create a new API token with "Edit" permissions
3. Save the Access Key ID and Secret Access Key

### 3. Configure Custom Domain (Optional)

1. In bucket settings, add custom domain (e.g., `resume-cdn.yourdomain.com`)
2. Cloudflare will handle DNS automatically if domain is on Cloudflare

### 4. Set GitHub Secrets

Add these secrets to your repository (Settings to Secrets and variables to Actions):

- `R2_ACCESS_KEY_ID`: Your R2 Access Key ID
- `R2_SECRET_ACCESS_KEY`: Your R2 Secret Access Key
- `R2_ENDPOINT_URL`: Your R2 endpoint (e.g., `https://abc123.r2.cloudflarestorage.com`)
- `R2_BUCKET_NAME`: Your bucket name

<Alert className="mt-5 dark:border-border/40">
  <InfoIcon className="h-4 w-4" />
  <AlertTitle>Finding Your R2 Endpoint</AlertTitle>
  <AlertDescription>
    The endpoint URL is shown in your bucket settings under "S3 API". It looks like `https://[account-id].r2.cloudflarestorage.com`.
  </AlertDescription>
</Alert>

## Consuming the Resume on Your Website

Now that your resume auto-deploys, let's consume it dynamically on your website.

### Option 1: Astro Server Endpoint

Create `src/pages/api/resume.ts`:

```typescript
import type { APIRoute } from 'astro';

export const GET: APIRoute = async () => {
  try {
    const response = await fetch('https://resume-cdn.yourdomain.com/latest.json');
    const data = await response.json();

    return new Response(JSON.stringify(data), {
      status: 200,
      headers: {
        'Content-Type': 'application/json',
        'Cache-Control': 'public, max-age=300' // 5 min cache
      }
    });
  } catch (error) {
    return new Response(JSON.stringify({ error: 'Failed to fetch resume' }), {
      status: 500,
      headers: { 'Content-Type': 'application/json' }
    });
  }
};
```

### Option 2: Client-Side Fetch

```typescript
async function getLatestResume() {
  const response = await fetch('https://resume-cdn.yourdomain.com/latest.json');
  const data = await response.json();
  return data; // { url, filename, timestamp, updatedAt }
}

// In your component
const resumeData = await getLatestResume();
console.log(resumeData.url); // Direct link to latest PDF
```

### Option 3: Direct Link

Simply link to `latest.json` and parse it:

```tsx
<a href="https://resume-cdn.yourdomain.com/latest.json">
  Download Resume
</a>
```

Or fetch it and redirect:

```typescript
const data = await fetch('/api/resume').then(r => r.json());
window.open(data.url, '_blank');
```

## Common Pitfalls and Solutions

### Error: "Option clash for package hyperref"

**Problem:** You're loading the `hyperref` package multiple times with different options.

**Solution:** Consolidate all hyperref options into a single `\usepackage` declaration:

```latex
% Wrong - Multiple imports
\usepackage[pdftex]{hyperref}
\usepackage[colorlinks=true]{hyperref}

% Correct - Single import with all options
\usepackage[pdftex,
            colorlinks = true,
            linkcolor = blue,
            urlcolor  = blue,
            citecolor = blue]{hyperref}
```

### Error: "Undefined control sequence"

**Problem:** You're using a command without importing the required package.

**Solution:** Check which package provides the command and add `\usepackage{packagename}`.

### PDF Not Updating on Website

**Problem:** Browser or CDN is caching `latest.json`.

**Solution:**
1. Ensure `latest.json` has `Cache-Control: no-cache` header
2. Add cache busting: `latest.json?t=${Date.now()}`
3. Check Cloudflare cache settings

### Workflow Not Triggering

**Problem:** Pushing to git but workflow doesn't run.

**Solution:**
1. Check if you're pushing to `main` or `master` branch
2. Ensure `resume.tex` actually changed
3. Check Actions tab for error messages
4. Verify workflow file is in `.github/workflows/`

## Advanced: Version History

Want to keep track of all resume versions? Extend the workflow:

```yaml
- name: Update versions.json
  run: |
    # Download existing versions
    aws s3 cp s3://${BUCKET_NAME}/versions.json versions.json \
      --endpoint-url ${AWS_ENDPOINT_URL} || echo '{"versions":[]}' > versions.json

    # Add new version
    cat versions.json | jq --arg url "https://resume-cdn.yourdomain.com/${{ steps.metadata.outputs.filename }}" \
      --arg ts "${{ steps.metadata.outputs.timestamp }}" \
      '.versions += [{"url": $url, "timestamp": $ts}]' > updated-versions.json

    # Upload updated versions
    aws s3 cp updated-versions.json s3://${BUCKET_NAME}/versions.json \
      --endpoint-url ${AWS_ENDPOINT_URL} \
      --content-type application/json \
      --cache-control "no-cache"
```

This creates a `versions.json` file tracking all resume versions:

```json
{
  "versions": [
    {
      "url": "https://resume-cdn.yourdomain.com/YourName_Resume_20241201_120000.pdf",
      "timestamp": "20241201_120000"
    },
    {
      "url": "https://resume-cdn.yourdomain.com/YourName_Resume_20241228_143000.pdf",
      "timestamp": "20241228_143000"
    }
  ]
}
```

## Performance Considerations

### Caching Strategy

- **Timestamped PDFs**: Immutable, cache for 1 year (`max-age=31536000`)
- **latest.json**: No cache (`no-cache`) for immediate updates
- **versions.json**: Short cache (5 mins) for balance

## Conclusion

You now have a fully automated resume pipeline that:
- Compiles LaTeX to PDF on every push
- Deploys to Cloudflare R2 with versioning
- Maintains metadata for dynamic linking
- Handles common compilation errors

Every time you update your resume in git, it automatically compiles, uploads, and updates your website. No manual exports, no stale downloads, no broken links.

### Next Steps

1. Customize the LaTeX template to match your style
2. Add more metadata (skills, experience years, etc.)
3. Build a resume dashboard showing version history
4. Add PDF thumbnails for visual preview

The complete workflow is available in my portfolio repository: [github.com/imprakharshukla/prakhar.codes](https://github.com/imprakharshukla/prakhar.codes)

Happy automating!

## Complete Typesafe REST APIs with TS-rest

https://prakhar.codes/blog/complete-typesafe-rest-api-with-ts-rest/

import { AlertDescription, AlertTitle, Alert } from "@prakhar/ui";
import { InfoIcon } from "lucide-react";

## Table of contents

In this tutorial, we will learn how to build a complete typesafe REST API using [TS-rest](https://ts-rest.com). We will build a simple REST API for a blog application that will have CRUD operations for posts.

## What is TS-rest?

As per the official documentation,

> ts-rest offers a simple way to define a contract for your API, which can be both consumed and implemented by your application, giving you end-to-end type safety without the hassle or code generation.

In simple words, we define a shared contract for our API that can be used by both the client and the server. This contract is defined using zod, which is also used for runtime validation of the request and response automatically.

## Pre-requisites

TS-rest works best within a **monorepo** setup since it requires the shared contract to be available to both the client and the server.

While you can also set up and publish a separate package for the shared contract, this might become a hassle as each change will require a new version to be published.

Hence in this tutorial, we will be using a monorepo setup using [TurboRepo](https://turbo.build) and [pnpm workspaces](https://pnpm.io/workspaces).

## Setting up the project

1. We can start by cloning the **Rapid** starter made by me.

   <Alert className="mt-5 dark:border-border/40">
     <InfoIcon className="h-4 w-4" />
     <AlertTitle>Learn more about Rapid</AlertTitle>
     <AlertDescription>
       Rapid is a starter developed by me that provides you with a monorepo
       pre-configured with Next.js, Express, Turbo, and Prisma etc. Learn more
       [here](https://rapid.prakhar.codes).
     </AlertDescription>
   </Alert>

   ```bash
   git clone https://github.com/imprakharshukla/rapid
   ```

2. Now we can install the dependencies using pnpm.

   ```bash
   pnpm install
   ```

3. Here is the folder structure of the project.

   ```bash
   .
   ├── apps
   │   ├── backend
   │   ├── demo
   │   └── landing
   └── packages
       ├── auth
       ├── config
       ├── contract
       ├── db
       └── ui
   ```

4. The `/packages/contract` folder is where we will define our shared contract. The contract will be used by both the client and the server.

5. The aforementioned shared contracts package is already installed on the backend, but if you want to add more backend apps, you can install the shared contract package in any of the apps by running:

   ```bash
   pnpm install @repo/contract --filter <app-name>
   ```

## Contracts

1. Here's how the contract in the Rapid starter is defined like:

   ```typescript
   import { initContract } from "@ts-rest/core";
   import { z } from "zod";

   const c = initContract();

   export const helloContract = c.router({
     getHello: {
       method: "GET",
       path: "/hello",
       responses: {
         200: z.object({
           response: z.string(),
         }),
         500: z.object({
           response: z.string(),
         }),
       },
       summary: "Echo Hello",
     },
   });
   ```

More information on TS-Rest contracts [here](https://ts-rest.com/docs/core/).

## Implementing Contracts

Since we already have a contract for the `/hello` route, we can implement it in the backend.

1. We have a `hello` route in the backend that will return a simple JSON response.

   ```typescript
   import { initServer } from "@ts-rest/express";
   import Container from "typedi";
   import { Logger } from "winston";
   import { z } from "zod";

   import { superContract } from "@repo/contract";

   import HelloService from "../../services/hello";

   export default (server: ReturnType<typeof initServer>) => {
     const logger: Logger = Container.get("logger");
     const helloServiceInstance: HelloService = Container.get(HelloService);

     return server.router(superContract.hello, {
       getHello: {
         handler: async () => {
           try {
             const hello = helloServiceInstance.generateHello();
             return {
               status: 200,
               body: {
                 response: hello,
               },
             };
           } catch (e) {
             logger.error(e);
             return {
               status: 500,
               body: {
                 response: "Internal Server Error",
               },
             };
           }
         },
       },
     });
   };
   ```

   <Alert className="mt-5 dark:border-border/40">
     <InfoIcon className="h-4 w-4" />
     <AlertTitle>About Services</AlertTitle>
     <AlertDescription>
       We can separate things like data fetching and other things that might
       require any processing to a service file for each route. This promotes
       separation of concerns.
     </AlertDescription>
   </Alert>

2. Now we can export the implemented contract as the Express Router and add it our express app.

   ```typescript
   import { createExpressEndpoints, initServer } from "@ts-rest/express";
   import { Request, Router } from "express";

   import { superContract } from "@repo/contract";

   import { adminOnlyMiddleware } from "./middleware/auth";
   import hello from "./routes/hello";

   export default () => {
     const app = Router();
     const s = initServer();
     const helloRouter = hello(s);

     createExpressEndpoints(superContract.hello, helloRouter, app, {
       globalMiddleware: [],
     });
     return app;
   };
   ```

3. Our endpoint is ready to be consumed now. We can visit it at `localhost:3002/api/hello` and that will return:

   ```json
   { "response": "Hello" }
   ```

## Consuming the contract on the frontend

1. Finally, we can consume the contracts that we have built on the frontend. Since we have declared the contracts in the shared package, we will have to install the internal package `@repo/contract` in our frontend apps with:

   ```bash
   pnpm install @repo/contract --filter <frontend-app-name>
   ```

2. After installing the package, we can declare a universal hook and a custom client using axios instead of fetch (since fetch does not throw any errors in non-2xx status codes).

   ### Custom Client:

   ```typescript
   import { InitClientArgs } from "@ts-rest/next";
   import { InitClientReturn, initQueryClient } from "@ts-rest/react-query";
   import axios, { Method, isAxiosError } from "axios";

   import { superContract } from "@repo/contract";

   export interface TokenProvider {
     getToken: () => Promise<string>;
   }

   export class RestAPI {
     // Uncomment to unable authorization
     // tokenProvider: TokenProvider;
     public client: InitClientReturn<typeof superContract, InitClientArgs>;

     constructor(tokenProvider: TokenProvider) {
       const baseUrl = "http://localhost:3002/api";
       // Uncomment to unable authorization
       // this.tokenProvider = tokenProvider;
       this.client = initQueryClient<typeof superContract, InitClientArgs>(
         superContract,
         {
           baseUrl: baseUrl,
           baseHeaders: {},
           api: async ({ path, method, headers, body }) => {
             // Uncomment to unable authorization
             // const token = await this.tokenProvider.getToken();
             try {
               const result = await axios.request({
                 method: method as Method,
                 url: `${path}`,
                 headers: {
                   ...headers,
                   // Uncomment to unable authorization
                   // Authorization: `Bearer ${token}`,
                 },
                 data: body,
               });

               const responseHeaders = new Headers();
               Object.entries(result.headers).forEach(([key, value]) => {
                 if (value !== undefined && typeof value === "string") {
                   responseHeaders.append(key, value.toString());
                 }
               });

               return {
                 status: result.status,
                 body: result.data,
                 headers: responseHeaders,
               };
             } catch (e) {
               if (isAxiosError(e) && e.response) {
                 const errorHeaders = new Headers();
                 Object.entries(e.response.headers).forEach(([key, value]) => {
                   if (value !== undefined && typeof value === "string") {
                     errorHeaders.append(key, value.toString());
                   }
                 });
                 return {
                   status: e.response.status,
                   body: e.response.data,
                   headers: errorHeaders,
                 };
               }
               throw e;
             }
           },
         }
       );
     }
   }
   ```

   ### Custom Hook

   To make it easy to consume the client, we can declare a custom hook.

   ```typescript
   import { useSession } from "next-auth/react";
   import { useMemo } from "react";
   import { RestAPI, TokenProvider } from "~/lib/client";

   const fetchToken = async () => {
     const response = await fetch("/api/token");
     const data = await response.json();
     return data.token;
   };
   const useRestAPI = () => {
     const { data: session } = useSession();
     const api = useMemo(() => {
       const tokenProvider: TokenProvider = {
         getToken: fetchToken,
       };
       const restApi = new RestAPI(tokenProvider);
       return { restApi: restApi.client };
     }, [session, fetchToken]);

     return { client: api.restApi };
   };

   export default useRestAPI;
   ```

3. We can now use this hook to access the React Query premitives in our pages.

   ```tsx
   import useRestAPI from "./features/hooks/use-rest-client";
   export default function Page() {
     const { client } = useRestAPI();

     const {
       data: helloData,
       isLoading: isHelloLoading,
       error,
       refetch: refetchHello,
       isRefetching: isHelloRefetching,
     } = client.hello.getHello.useQuery(["hello"], {});
   }
   ```

   {" "}

   <Alert className="mt-5 dark:border-border/40">
     <InfoIcon className="h-4 w-4" />
     <AlertTitle>Learn more React Query</AlertTitle>
     <AlertDescription>
       Learn what React Query exposes to be used in the [React Query
       Documentation]().
     </AlertDescription>
   </Alert>

4. Using the imported data and functions is as easy as it gets:

   ```tsx
   <div className="mb-4 grid gap-3 lg:max-w-md">
     {(isHelloLoading || isHelloRefetching) && <Loader></Loader>}
     {helloData && !isHelloLoading && !isHelloRefetching && (
       <p>{helloData.body.response}</p>
     )}
     <Button
       variant={"outline"}
       onClick={() => {
         refetchHello();
       }}
     >
       Refetch
     </Button>
   </div>
   ```

## Conclusion

TS-Rest provides a way to deploy an end-to-end typesafe API within minutes.

You can also explore [Rapid Starter](https://rapid.prakhar.codes) to get a headstart with a Turborepo monorepo already configured with TS-Rest and Authentication.

---

# Travel

## Phu Quoc, Kien Giang, Vietnam

https://prakhar.codes/travel/phu-quoc-11-25/



## Hoi An, Quang Nam, Vietnam

https://prakhar.codes/travel/hoi-an-11-25/



## Da Nang, Da Nang, Vietnam

https://prakhar.codes/travel/da-nang-11-25/



## Hanoi, Hanoi, Vietnam

https://prakhar.codes/travel/hanoi-11-25/



## Goa, Goa, India

https://prakhar.codes/travel/goa-12-25/



## Mumbai, Maharashtra, India

https://prakhar.codes/travel/mumbai-12-25/



## Nusa Penida, Bali, Indonesia

https://prakhar.codes/travel/nusa-penida-11-25/



## Kuta, Bali, Indonesia

https://prakhar.codes/travel/kuta-11-25/



## Ubud, Bali, Indonesia

https://prakhar.codes/travel/ubud-11-25/



## Mussoorie, Uttarakhand, India

https://prakhar.codes/travel/mussoorie-08-25/



## Goa, Goa, India

https://prakhar.codes/travel/goa-04-25/



## Goa, Goa, India

https://prakhar.codes/travel/goa-10-24/



## Shillong, Meghalaya, India

https://prakhar.codes/travel/shillong-07-24/



## Goa, Goa, India

https://prakhar.codes/travel/goa-04-24/



## Shoja, Himachal Pradesh, India

https://prakhar.codes/travel/shoja-11-23/



## Goa, Goa, India

https://prakhar.codes/travel/goa-9-23/



## Manali, Himachal Pradesh, India

https://prakhar.codes/travel/manali-04-23/



## Bahu, Himachal Pradesh, India

https://prakhar.codes/travel/bahu-02-24/



## Udaipur, Rajasthan, India

https://prakhar.codes/travel/udaipur-08-22/