And while everyone is busy building AI agents — tweaking prompts, giving tool calls, focusing on model choice and parameters — there is one critical area most developers sometimes skip.

Tool harness and security.

Not the prompt. Not the model. The harness around your tools — how you design them, constrain them, and control what the agent can actually do with them.

And skipping this will cost you a lot in terms of both security and reliability.

What Even Is Tool Harness?

When you give an AI agent a tool, you're not just giving it a function. You're giving it a boundary. A set of rules about what it can touch, what it can't, and how it should behave when it acts.

Most of us don't think about it that way. We write the tool, attach it to the agent, and move on. The harness — the constraints, the access controls, the behavioral guardrails — gets left to the prompt.

That's the mistake.

Prompts can be overridden. Prompts can be manipulated. Prompts can be ignored. The harness needs to live at the code level, the execution level, the architecture level.

And here's how to build it properly. There are three layers.

Layer 1: Strip Identity Params — Inject Them Server-Side

The first layer is about access control. And it starts with your tool schema.

Let's say you're building a to-do app with an AI agent. You give it a list_tasks tool. Your schema looks like this:

{
  "name": "list_tasks",
  "parameters": {
    "user_id": "string",
    "filters": {
      "status": "string",
      "due_before": "string"
    }
  }
}

Looks fine, right?

It's not.

Because user_id is in the schema, the agent can pass any user ID it wants. A malicious prompt, a confused model, a prompt injection — any of these could have your agent fetching data it has absolutely no business touching. There's no authentication. There's no authorization.

The fix: strip all identity params from the schema. Things like user_id, account_id, workspace_id, knowledge_base_id — these define the scope of who sees what. The agent doesn't get to decide scope. You do.

{
  "name": "list_tasks",
  "parameters": {
    "filters": {
      "status": "string",
      "due_before": "string"
    }
  }
}

And when the tool executes, inject the identity yourself — from the authenticated session:

async function list_tasks(params: { filters: Filters }, session: Session) {
  const userId = session.userId; // you control this, not the agent
  return db.tasks.findMany({
    where: {
      userId,
      ...params.filters,
    },
  });
}

The agent says what it needs. You decide whose data gets touched. That's the harness. 💡

Layer 2: Enforce Behavioral Constraints at the Code Level

The second layer is about how your tools behave — not just what they can access.

If you've used Claude Code, you'd have seen this error:

"A file cannot be written before it has been read."

That's not a prompt instruction. That's a hard constraint baked into the tool itself. The developers at Claude Code took a very human behavior — open the file, read it, understand it, then edit it — and enforced it at the execution level.

That's exactly what we need to do with our own tools.

For example, if you have an update_task tool, don't let the agent call it cold. Enforce a read-first constraint at the code level:

async function update_task(params: UpdateTaskParams, session: Session) {
  const lastRead = await cache.get(`task_read:\({params.task_id}:\){session.userId}`);

  if (!lastRead || Date.now() - lastRead > 60_000) {
    throw new Error(
      "Task must be read before it can be updated. Call get_task first."
    );
  }

  return db.tasks.update({
    where: { id: params.task_id },
    data: params.updates,
  });
}

You can mention this in the prompt too — but the check has to live in code. Not just in a system prompt the model might miss or ignore. The execution layer is where the harness lives. 🔒

Layer 3: Pre-flight Validation with a Reasoning Agent

This one is more advanced. I haven't shipped it in my own product yet — but I know this will work.

The idea: before any tool call executes, require the agent to pass a reason — a short explanation of why it's calling that tool.

{
  "name": "list_tasks",
  "parameters": {
    "reason": "string",
    "filters": {
      "status": "string",
      "due_before": "string"
    }
  }
}

This forces the agent to think before it acts. It might actually realize the reason isn't valid and decide not to call the tool at all.

And you can take it further — spin up a lightweight validation agent running on a small, fast model that takes the tool name, the reason, and the conversation context, and decides whether the call is actually justified:

async function validateToolCall(toolName: string, reason: string, context: string) {
  const response = await llm.complete({
    model: "fast-small-model",
    prompt: `
      Tool requested: ${toolName}
      Reason given: ${reason}
      Conversation context: ${context}

      Is this tool call justified? Reply YES or NO with a brief explanation.
    `,
  });

  return response.text.startsWith("YES");
}

If the validation agent says no — the tool doesn't run.

This catches hallucinated tool calls, prompt injection attempts, and cases where the agent is just calling tools out of habit rather than necessity. 🛡️

Wrapping Up

We are designing so many agents today. And we're doing it fast. But the harness — the security, the constraints, the access controls — is getting left behind.

At the very least, we should be sure we're not giving an agent access to something it shouldn't have. That the tools we build have opinions about how they get used. That there are guardrails that exist at the architecture level, not just in a prompt.

Strip the identity params. Enforce behavioral constraints in code. Add a reasoning checkpoint before execution.

These three layers won't just make your agent more secure. They'll make it more reliable, more predictable, and way easier to debug when something goes wrong.

And trust me — something will go wrong. The question is whether your harness was ready for it.

Hope you liked the read, follow me on my socials for more tech content. See you in the next blog 👋🏻

But that's not the only reason. And honestly, it's not even the most interesting one.

About three months back, I started using Claude as my primary assistant for pretty much everything. And I noticed something that genuinely caught my attention.

When I ask Claude something simple, it responds in plain text. But when the answer is complex, or when there's a lot of information to show — it renders a UI right inside the Claude app. An interactive widget I can actually play with. Not just text. A real interface.

I started wondering — how are they doing this? 🤔

My First Guess Was Wrong

My initial assumption was that Anthropic had built a library of React components, given the LLM instructions on when and how to use each one, and when Claude responds, it generates a JSON payload that the frontend maps to those components.

That seemed reasonable to me.

I was completely wrong.

So I opened Claude on the web, pulled up the network tab, and inspected the actual response. I reverse engineered how Claude renders its UI.

What I found was surprising. 👀

What's Actually Happening

The response wasn't JSON. It wasn't a reference to any predefined component.

It was a plain HTML, CSS, and JavaScript file — with inline styles.

That's when it clicked. They're not using a component library to build the UI. They went a level below that. They provided Claude with a design system — the design principles, the basic styling rules, how a button should look and behave — and then asked Claude to generate HTML, CSS, and JavaScript on its own.

They take that single HTML file and render it in an iframe.

"They didn't build the UI. They taught Claude how to build it."

Think about what this means. LLMs write good code. Anthropic gave Claude a design system and said — generate the UI. And as the model gets smarter, the UI it generates gets better. Automatically. Without changing a single line of their own code. 🚀

Splitting the Hands from the Brain

I later came across a blog post from Anthropic that described this concept — splitting the hands from the brain.

The idea is this: most developers write prompts and instructions that are tightly coupled to a specific model. If a model doesn't do something well, you go in and patch the prompt. You hardcode workarounds. You over-instruct.

What Anthropic is doing instead is providing raw tools to the LLM and letting the model figure out how to use them.

"The instructions stay the same. The model just gets better at using them."

So if you're using Claude Sonnet 4.6, the UI it generates is solid. Move to Opus, it gets significantly better. Move to Mythos — it's on another level entirely. And Anthropic didn't have to touch their instructions. The model just got better at using the same tools.

That's the key insight. 💡

Why This Should Change How We Build LLM Apps

We have access to the same models Anthropic is using. But what are most of us doing? We're hardcoding logic into prompts. We're writing harness that's tightly coupled to a specific model's behavior. And the moment a smarter model ships, that harness becomes stale.

We should stop encoding specific instructions into prompts and start thinking about building better tools with clearer interfaces — tools that any LLM, today or two years from now, can pick up and use effectively.

"Stop writing instructions for the model. Start building tools for it."

It's Not as Simple as Writing a Good Prompt

I'll be honest — I used to think building LLM apps was straightforward. Give it a good prompt, tweak it when something breaks, move on.

That's not how it works.

Architecting an agent properly takes real thought. What Anthropic is doing is genuinely different from what most companies are doing right now. We're still treating AI like a rule-following system — developers trying to hardcode intelligence into a prompt instead of letting the model use its own.

Here's a better way to think about it: imagine you're handed a fixed set of components and told to build something. No flexibility, no room to think. You just assemble what's given.

Now imagine instead someone hands you a design system — guidelines, principles, a foundation — and says, make it look great, adapt as needed. Suddenly there's room for judgment. For creativity. For the model to actually do what it's good at.

"Give a model components, and it assembles. Give it a design system, and it creates."

That's what Anthropic figured out. And I think it's worth all of us taking a step back and rethinking how we're building.

Hope you like the read, see you on the next blog!

One is my office account with the Pro plan. Another is a shared account I use with my colleagues on the Max plan.

At first, I assumed this would be simple.

Log out. Log in. Maybe switch profiles. Done.

But that is not how Claude Code works.

Every time I switched accounts, I either lost my project history, lost my custom commands, or had to keep setting everything up again.

And the worst part?

The only thing that actually needed to be different between accounts was the authentication.

Everything else — my project history, my commands, my MCP setup, my CLAUDE.md instructions, my settings — should have stayed the same.

Instead, Claude Code treats everything as one giant config folder.

So if you want multiple accounts, you end up duplicating everything.

That quickly becomes painful.

The Actual Problem

Claude Code stores almost everything inside a single config directory.

That includes:

• Authentication

• Settings

• Project history

• Custom commands

• MCP configuration

• CLAUDE.md instructions

The issue is that authentication is account-specific.

But the rest is not.

I do not want separate project histories for every account. I do not want to recreate the same custom commands three times. I definitely do not want to copy-paste the same CLAUDE.md file every time I make a change.

After a few switches, my setup looked like this:

• One account had the latest commands

• Another had the right MCP config

• A third one had the actual project history I wanted

Everything was fragmented.

And every time I switched accounts, something would silently stop working.

The Setup That Actually Works

The fix was separating authentication from everything else.

Instead of giving every account its own full Claude config, I created:

• One shared folder for everything common

• One small folder per account containing only auth

My setup now looks like this:

The fix was separating authentication from everything else.

Instead of giving every account its own full Claude config, I created:

• One shared folder for everything common

• One small folder per account containing only auth

My setup now looks like this:

~/.claude-shared/
  settings.json
  CLAUDE.md
  projects/
  commands/
  mcp.json

~/.claude-office-pro/
  auth.json
  settings.json -> ~/.claude-shared/settings.json
  CLAUDE.md -> ~/.claude-shared/CLAUDE.md
  projects -> ~/.claude-shared/projects
  commands -> ~/.claude-shared/commands
  mcp.json -> ~/.claude-shared/mcp.json

~/.claude-shared-max/
  auth.json
  settings.json -> ~/.claude-shared/settings.json
  CLAUDE.md -> ~/.claude-shared/CLAUDE.md
  projects -> ~/.claude-shared/projects
  commands -> ~/.claude-shared/commands
  mcp.json -> ~/.claude-shared/mcp.json

The only real file that is different between accounts is auth.json.

Everything else is shared using symlinks.

Which means:

• I log into each account once

• All accounts use the same project history

• All accounts use the same commands

• All accounts use the same CLAUDE.md instructions

• Changing something in one place updates it everywhere

This was the first setup that actually felt usable.

Setting It Up

First, create the shared folder and separate account folders.

mkdir -p ~/.claude-shared
mkdir -p ~/.claude-office-pro
mkdir -p ~/.claude-shared-max

Then move all the common files into the shared folder.

mv ~/.claude/settings.json ~/.claude-shared/
mv ~/.claude/CLAUDE.md ~/.claude-shared/
mv ~/.claude/projects ~/.claude-shared/
mv ~/.claude/commands ~/.claude-shared/
mv ~/.claude/mcp.json ~/.claude-shared/

Now create symlinks inside each account folder.

ln -s ~/.claude-shared/settings.json ~/.claude-office-pro/settings.json
ln -s ~/.claude-shared/CLAUDE.md ~/.claude-office-pro/CLAUDE.md
ln -s ~/.claude-shared/projects ~/.claude-office-pro/projects
ln -s ~/.claude-shared/commands ~/.claude-office-pro/commands
ln -s ~/.claude-shared/mcp.json ~/.claude-office-pro/mcp.json

ln -s ~/.claude-shared/settings.json ~/.claude-shared-max/settings.json
ln -s ~/.claude-shared/CLAUDE.md ~/.claude-shared-max/CLAUDE.md
ln -s ~/.claude-shared/projects ~/.claude-shared-max/projects
ln -s ~/.claude-shared/commands ~/.claude-shared-max/commands
ln -s ~/.claude-shared/mcp.json ~/.claude-shared-max/mcp.json

Then create aliases so switching accounts becomes one command.

alias claude-office='CLAUDE_CONFIG_DIR=~/.claude-office-pro claude'
alias claude-shared='CLAUDE_CONFIG_DIR=~/.claude-shared-max claude'

Now when I want to use my office Pro account, I run:

claude-office

And when I want to switch to the shared Max account that I use with my colleagues:

claude-shared

That is it.

No logging in again. No copying files. No broken commands.

The Bigger Lesson

This looked like a Claude Code problem.

But it is actually a common problem with developer tools.

Most tools bundle:

• Identity

• Configuration

• User data

Into one folder.

That works fine until you need multiple accounts.

Then suddenly the thing you actually want to isolate — authentication — is tied to a bunch of things that should have been shared.

The best setups separate those concerns.

Authentication should be isolated. Everything else should be reusable.

Once I changed my Claude setup to follow that idea, switching accounts stopped feeling like context switching.

It finally felt like the same workspace, just with a different login.

And honestly, that is probably how it should have worked in the first place.

Strong suggestion: don’t copy my workflow — read through the failures, mistakes, and learnings, and use them to craft a workflow that works for you.

If you want to jump straight to my current workflow, go here →
👉 Iteration 7: My Current Workflow (What Finally Worked)

I’ve been thinking about writing this for a while.

I’m still learning, but over the past year, I’ve been coding with AI almost every day — both in personal projects and in production systems at work. I’m not claiming this is the best way to use AI, but this is the workflow that helped me compress what usually takes three weeks into two days.

This blog isn’t about a single “aha” moment.
It’s about iterations — where things worked, where they broke, and what each failure taught me.

Iteration 1: AI Felt Like Magic

When I first started coding with AI, I was honestly impressed.

Things that used to take real mental effort were getting done effortlessly:

• Solving a LeetCode problem

• Creating Simple UI with React and Stylings

• Writing a simple API to CRUD a model

AI handled all of this extremely well.

At this stage, I was mostly using Cursor for personal projects. These projects were small, the codebase was tiny, and the AI had very little context to reason about.

Naturally, I assumed:

“If this works so well for personal projects, it should work even better for office projects.”

That assumption didn’t last long.

Iteration 2: Production Codebases Change Everything

Around 6–8 months ago, my company gave me a paid Cursor license.
I started using it on our actual product codebase.

The difference was immediate.

Same prompts.
Same workflow.
Completely different results.

In personal projects, the AI was dealing with hundreds or a few thousand lines of code.
In production, it had to reason about tens of thousands of lines, multiple modules, and years of architectural decisions.

That’s when things started breaking.

Iteration 3: Ask → Plan → Build (Worked… Until It Didn’t)

To regain control, I introduced structure.

Before implementing any feature, I started doing this:

1. Switch Cursor to Ask mode

2. Ask it to understand specific folders or modules

3. Explain the feature I wanted to build

4. Ask it to give me a plan

5. Switch to Agent mode and ask it to implement the plan

This was before Cursor even had a dedicated Plan mode.

And honestly — it worked really well.

I completed multiple backend-heavy features using this approach, and I was genuinely surprised by how well the AI understood the code and executed changes.

Until I hit a full-stack feature.

Iteration 4: Full-Stack Complexity Broke the Workflow

The next feature involved everything:

• Frontend

• Backend

• Queues and background jobs

• Socket events

• Real-time UI updates

• State management

The number of moving parts exploded.

I followed the same workflow.

The output was bad.

• TypeScript types replaced with any and unknown

• Method signature mismatches

• Code written just to “make it work”

• Hidden bugs everywhere

That’s when I realized something important:

The workflow didn’t change.
The task complexity did.

Iteration 5: Treating AI Like a Fresh Developer

I asked myself a simple question:

“If I were giving this task to a fresh developer, how would I do it?”

I wouldn’t explain everything at once.

So I split the feature into independent chunks:

1. Backend

2. Frontend

The backend agent didn’t know about the frontend.
The frontend agent only knew the API contract.

For the backend, I gave very clear instructions:

• Queue behaviour

• API design

• Event flow

Then I handed the API contract to the frontend.

This worked beautifully.

Until I tried spinning up a new microservice.

Iteration 6: Plan Mode Enters (And Still Fails at Scale)

Around this time, Cursor launched Plan mode, and naturally, I started using it heavily.

On paper, this felt like the missing piece.

The idea was simple:

• Create a detailed plan in markdown

• Let the agent refer to it instead of holding everything in memory

• Execute step by step

For medium-sized features, this worked really well.

But then I hit a much bigger task.

This feature involved:

• Creating a new microservice

• Linking it with existing services

• Implementing cutting edge tools

• Adopting modern Node.js and TypeScript patterns

• Handling cross-service communication

I brainstormed deeply with the AI and created a pixel-perfect plan.

The plan itself was solid.

The execution wasn’t.

• any everywhere

• Interface mismatches

• Build failures

• Runtime issues

That’s when I finally understood the real problem:

Even with Plan mode, a single massive plan is still too much context.

Plan mode helped — but it didn’t remove the need to break the problem down further.

Why This Fails (Even for Humans)

Imagine your CTO hands you:

• An 800–900 page tech requirement document, includes

• Multiple microservices

• Multiple protocols like Kafka or gRPC

• Multiple external dependencies

…and asks you to implement everything in a single go.

You wouldn’t be productive.

That’s why we have:

• Epics

• User stories

• Tasks

But when it comes to AI, we forget this and treat it like a supernatural entity.

It’s not.

It has limits.

Iteration 7: My Current Workflow (What Finally Worked)

This is the workflow that actually stuck.

Step 1: Start With High-Level Architecture

No function signatures.
No deep implementation details.

Just:

• Models

• Responsibilities

• Clear system boundaries

Step 2: Let AI Propose Mid-Level Phases

I ask the AI to break the feature into phases.

Usually, I get something like:

• 8 phases

• Each phase with 4–5 bullet points

Now the big feature is split into manageable chunks.

Step 3: Create a Separate Plan for Each Phase

Each phase gets its own plan:

• Separate document

• Less than ~500 lines

• Focused and crisp

A 5,000-line plan is no better than no plan.

Step 4: Manual Review Is Mandatory

Before building anything, I review each plan:

• Fix naming

• Correct modeling flaws

• Adjust structure

You cannot blindly trust AI.
You still own the architecture.

Step 5: Build Phase by Phase

Slow.
Deliberate.
Controlled.

Phase 1 → Build
Phase 2 → Build
…
Phase 8 → Build

This is where everything finally clicked.

The Result

The entire feature was completed in 2–3 days.

Without this workflow, it would have easily taken weeks.

The code was:

• Clean

• Strongly typed

• No unnecessary any

• Easy to reason about and maintain

Final Thoughts

AI productivity gains are real — but only if you respect its limits.

Think of AI as:

A very fast fresh developer who needs clear, scoped, precise instructions

This is my 7th iteration of this workflow, and it’ll iterate as the complexity increases.

If you think I missed something, tell me.
If you’ve found a better approach, share it.

Let’s learn from each other and write better code with AI, not just more code.

Cheers!

People are obsessed with TypeScript, and I don't say it's wrong.

But when it's used incorrectly (without proper clean code principles), even it'll cause a disaster instead of saving us.

Let me give you an example:

The Problem

const getLogs = (
  userId: string,
  from?: Date,
  to?: Date,
  sort?: Map<string, number>,
  limit?: number,
  lastLogId?: string
) => {};

This function might look fine at first glance, but it's not.

Now think about the consumer:

How will they know the order of all those optional parameters?

Having this many parameters in a function not only makes it harder to maintain but also makes it prone to errors.

The Solution

Here's a cleaner approach:

interface LogsOptions {
  interval?: {
    from?: Date;
    to?: Date;
  };
  pagination?: {
    limit?: number;
    lastLogId?: string;
  };
  sort?: Map<string, number>;
}

const getLogs = (userId: string, options?: LogsOptions) => {};

This approach is:
✅ Cleaner
✅ Easier to maintain
✅ Less prone to errors

Consumers can immediately understand what parameters are available without guessing.

Moral of the story

TypeScript alone won't save your product. Regardless of the language or framework you use, clean code principles play a vital role in your product's longevity.

Frameworks and languages come and go, but the fundamentals stay the same.

💬 What practices do you follow to keep your product alive? Share your thoughts in the comments!

Cheers,
Navayuvan Subramanian

I used to believe that small PRs were the cleanest and best way to develop.

But in recent times, I've realized this approach doesn't always work.

This might be effective for companies moving at a slower pace.

However, for startups pushing out at least one release a week, this can slow things down significantly. 🐢

In most startups, developers own large chunks of features.

Splitting these into smaller tasks and raising separate PRs not only wastes time but also makes reviewers lose context about the feature as a whole. 😵‍💫

But then, reviewing a PR with 100+ file changes is no walk in the park either. So, what's the solution?

Here's what works for me:

Provide a clear description of the changes.

You don't need to be overly detailed, but a high-level summary of the changes goes a long way.

Avoid unnecessary changes

Skip alignment changes or edits unrelated to the feature you're working on.

Annotate unrelated changes

If some unrelated changes are unavoidable, add comments explaining why they're included. This helps reviewers stay on track.

Streamline priority reviews.

Let's be real---no one jumps to review a massive PR immediately. If it's a priority, set up a quick call with the reviewers to explain the changes. It makes the review process faster and more efficient.

Respect the reviewer's time

Ask your reviewers when they can reasonably review the PR and follow up after the deadline. Respecting their time is key.

Follow up without annoying

Reviewers have their own priorities, and forgetting your PR is natural. Gently remind them without being pushy to get it reviewed.

This is how I approach or request PR reviews at my workplace.

How do you handle your PR reviews? Let me know in the comments! 💬

And don't forget to follow Navayuvan Subramanian for more tech insights! 🚀

Let me make it clear with an example: Todoist.

It's a simple to-do app with a monthly subscription of $5.

Now, we might think, "I can develop that app myself." But, hear me out!

The payment we provide them includes:
👉 The research they've done to make a feature usable.
👉 The efforts they've put in to integrate with other applications. (Slack, G-Cal, etc.)
👉 Client app support across multiple platforms (browser extensions, desktop, web apps, etc.).
👉 Constant improvement of existing features or the development of new ones.
👉 And many more.

Now, can we do all of this consistently just to save $5? Absolutely not! 🙅‍♂️

The efforts involved in doing these are enormous, and there's an entire company dedicated to it. So, instead of building it ourselves, paying for the subscription seems like a smarter choice. 💡

Does that mean we should never build an app for ourselves? Not at all. 🙌

Here's when it makes sense to build the app ourselves:
- When there are no apps on the market suitable for our needs.
- When the amount we'd pay for an app is less than or equal to the value of the time we save by not developing it ourselves.
- When the existing apps in the market have major pain points, solving them could even lead to a new startup or business idea.

If any of these criteria are met, then building it ourselves might be the way to go! 🚀

In the end, it's all about balancing time and effort. ⚖️

So, the next time you think about building an app yourself, take a moment to reflect on whether it's really worth the time and effort you're about to invest. Then, decide wisely! ✅

And, don't forget to follow me. I'll be dropping some interesting stuffs soon 😉

Your fellow developer,
Navayuvan Subramanian

Let’s explore building a robust HTTP Client in React TypeScript, integrating caching with Tanstack Query (formerly React Query), and creating custom hooks that streamline your API calls.

🌐 Understanding HTTP APIs

HTTP (HyperText Transfer Protocol) is the universal language systems use to communicate. Whether it’s fetching data, updating a resource, or deleting something from the server, HTTP has got us covered. Here’s a quick refresher on the HTTP methods:

• GET: Grabs the data you need from the server.

• POST: Sends data to create something new on the server.

• PUT: Updates an existing resource entirely.

• PATCH: Updates a part of an existing resource.

• DELETE: Removes something from the server.

Each method is like a tool in your toolbox—pick the right one for the job, and your APIs will be a joy to work with.

💡 Why Axios?

So, why are we using Axios for our HTTP Client? Imagine having a personal assistant who handles all the boring tasks like adding headers, dealing with JSON, and managing timeouts—Axios does just that! It’s a library that simplifies HTTP requests, making our code cleaner and easier to maintain.

🛠️ Creating the HTTP Client

Step 1: Installing Axios

Before we dive into the fun stuff, let’s install Axios:

npm install axios

Step 2: Setting Up the HTTP Client

Now, let’s set up our HTTP Client to make API calls a breeze.

import axios, { AxiosInstance, AxiosRequestConfig, AxiosResponse } from "axios";

class HttpClient {
  private instance: AxiosInstance;

  constructor(baseURL: string) {
    this.instance = axios.create({
      baseURL,
      withCredentials: true,
    });

    this.instance.interceptors.request.use(this.handleRequest);
    this.instance.interceptors.response.use(this.handleResponse);
  }

  private handleRequest = (config: AxiosRequestConfig): AxiosRequestConfig => {
    const token = localStorage.getItem("authToken"); // Replace with your token logic
    if (token) {
      if (!config.headers) {
        config.headers = {
          Authorization: `Bearer ${token}`,
        };
        return config;
      }

      config.headers["Authorization"] = `Bearer ${token}`;
    }
    return config;
  };

  private handleResponse = (response: AxiosResponse): AxiosResponse => {
    return response;
  };

  public get<T>(
    url: string,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.get<T>(url, config);
  }

  public post<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.post<T>(url, data, config);
  }

  public put<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.put<T>(url, data, config);
  }

  public patch<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.patch<T>(url, data, config);
  }

  public delete<T>(
    url: string,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.delete<T>(url, config);
  }
}

const httpClient = new HttpClient("https://jsonplaceholder.typicode.com");
export default httpClient;

Create a User Model

export interface Address {
  street: string;
  suite: string;
  city: string;
  zipcode: string;
  geo: {
    lat: string;
    lng: string;
  };
}

export interface Company {
  name: string;
  catchPhrase: string;
  bs: string;
}

export interface User {
  id: number;
  name: string;
  username: string;
  email: string;
  address: Address;
  phone: string;
  website: string;
  company: Company;
}

🔄 Handling API Requests

Creating a User

const createUser = async (userData: UserData) => {
  const response = await httpClient.post<User>('/users', userData);
  return response.data;
};

Fetching Users

const fetchUsers = async () => {
  const response = await httpClient.get<User[]>('/users');
  return response.data;
};

Updating a User

const updateUser = async (userId: string, userData: UserData) => {
  const response = await httpClient.put<User>(`/users/${userId}`, userData);
  return response.data;
};

Deleting a User

const deleteUser = async (userId: string) => {
  const response = await httpClient.delete(`/users/${userId}`);
  return response.data;
};

🗄️ The Power of Caching with Tanstack Query

When consuming APIs, one of the biggest challenges is managing the state of the data—especially when it comes to caching. Caching allows us to store responses so that repeated requests for the same data can be served faster, improving the overall performance of our application. This is where Tanstack Query comes in. Tanstack Query is a powerful data-fetching library that makes it simple to manage server-state in your React apps, with built-in caching, synchronization, and more.

Installation

To get started, install Tanstack Query:

npm install @tanstack/react-query

⚙️ Creating Custom Hooks for API Requests

Creating custom hooks makes your API calls reusable and easier to manage. For each type of request (fetch, create, update, delete), we'll create a custom hook using Tanstack Query and the HttpClient we built earlier.

Setting Up Query Keys

First, let's define some constants for our query keys:

// queryKeys.ts
export const QUERY_KEYS = {
  USERS: 'users',
  USER: (userId: string) => ['user', userId],
};

Custom Hooks Examples

Fetching Users

import { useQuery } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useFetchUsers = () => {
  return useQuery<User[]>({
    queryKey: [QUERY_KEYS.USERS],
    queryFn: () => httpClient.get<User[]>("/users").then((res) => res.data),
  });
};

Creating a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useCreateUser = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (newUser: Omit<User, "id">) =>
      httpClient.post<User>("/users", newUser),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
    },
  });
};

Updating a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useUpdateUser = (userId: number) => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (updatedUser: Partial<Omit<User, "id">>) =>
      httpClient.put<User>(`/users/${userId}`, updatedUser),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
      queryClient.invalidateQueries({
        queryKey: [QUERY_KEYS.USER(userId.toString())],
      });
    },
  });
};

Deleting a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';

const useDeleteUser = (userId: number) => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: () => httpClient.delete(`/users/${userId}`),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
    },
  });
};

Consumption of Hooks!

Here's a sample of how you can consume those hooks. We're using jsonplaceholder for mock APIs. You can see it in HttpClient file.

const App: React.FC = () => {
  const { data: users } = useFetchUsers();
  const createUser = useCreateUser();
  const updateUser = useUpdateUser(1); // Example user ID
  const deleteUser = useDeleteUser(1); // Example user ID

  return (
      <div>
        <h1>Users</h1>
        <button onClick={() => createUser.mutate(newUser)}>Create User</button>
        <button
          onClick={() =>
            updateUser.mutate({
              name: "Updated User",
            })
          }
        >
          Update User
        </button>
        <button onClick={() => deleteUser.mutate()}>Delete User</button>

        <ul>
          {users?.map((user: User) => (
            <li key={user.id}>
              {user.id} - {user.name}
            </li>
          ))}
        </ul>
      </div>
  );
};

📦 Wrapping It Up

Efficiently consuming APIs is crucial for building performant and scalable applications. By setting up a robust HTTP Client with Axios, handling state with Tanstack Query, and creating custom hooks for each API request, you’ll be well on your way to mastering API consumption in React TypeScript.

Remember, the key is to keep your code modular and reusable. As your application grows, these practices will help you maintain a clean and efficient codebase.

Have you ever missed an important task because your reminder got buried in the avalanche of notifications? I used to struggle with this too, until I developed something that completely transformed how I manage tasks.

Like many of you, I relied on standard reminder apps, but they just weren’t cutting it. Sure, they send notifications with a sound, but with the constant barrage of alerts, spotting the right one can feel like finding a needle in a haystack.

I needed something more—a reminder that not only grabs my attention but refuses to be ignored until I act on it. After searching for an app that could do this and coming up empty-handed, I decided to create my own solution.

While building a full-fledged app like Todoist was beyond my immediate scope, I developed a helper application to complement it: NeverForget.

The idea is simple yet powerful: when you add a task to Todoist with a date and time, NeverForget will notify you at the perfect moment.

But here’s the game-changer—the notification is persistent and can’t be cleared until you tap “Done.”

For the past four months, NeverForget has helped me remember and complete tasks I would have otherwise overlooked. 📝

Let me show you how it works.

How to Add Reminders in NeverForget

First things first: You can’t directly add and manage tasks in NeverForget. It’s designed to be a helper application.

If you’re a Todoist user, adding tasks with specific properties will trigger notifications in NeverForget. Here’s how you can set it up.

Connect Todoist with NeverForget

1. Download NeverForget from the Play Store and create an account or log in.

2. If you’re a new user, you’ll be prompted to "Connect to Todoist."

3. Click on that option and proceed to log into your Todoist account.

4. Once your accounts are connected, you’ll land on the Empty Home page.

Add a Reminder from Todoist to NeverForget

1. Open Todoist and create a label named "Reminder" or "Reminders."

2. To add a reminder, ensure your task meets two criteria:

   1. It includes the “Reminder” label we just created.

   2. It has a due date and time to trigger the notification.

And that’s it! Once you’ve set this up, NeverForget will ensure you never miss an important task again.

What’s Next?

We’re excited to announce that more integrations, like Google Calendar, are on the way! Stay tuned as we continue to expand NeverForget’s capabilities, making it even easier to stay on top of your tasks across multiple platforms.