DEV Community: David Essien

Code Fingerprinting: Detecting Duplicate Submissions Without Losing Your Mind (or Your API Budget)

David Essien — Tue, 02 Jun 2026 09:00:00 +0000

While building LogicVisor's review system, I was faced with a question I hadn't thought about before: what would happen if users submitted duplicate algorithm solutions?

I decided to test it myself. I submitted a solution to a simple palindrome challenge. The request went through, my solution was reviewed correctly. Normal happy stuff. Then I submitted the exact same solution a second time. And the normal happy stuff happened again. But I was far from happy.

That duplicate submission meant more tokens spent, more database memory consumed, more remote procedure calls, more AI calls, and more waiting time. For a problem that had already been solved.

I shuddered at the thought of a bad actor effectively DOS-ing my site or running up my AI bill just by hammering the same solution repeatedly. Rate limiting controls the number of requests per client — but it has nothing to do with the content of those requests. A user could stay well within their rate limit and still abuse the system by submitting the same code over and over.

This wasn't going to work. I needed a way to identify duplicate submissions and return a cached response instead of processing everything from scratch. Which led me to a more interesting question: how do you actually detect identical code?

The Problem With "Identical"

Programming by its very nature allows us to solve the same problem in multiple ways. But even a single solution can be written in an infinite number of ways.

User A could create a function that takes and returns a string, and name it strawberries. User B could write the exact same function with the exact same logic and name it bananas. Different names, same implementation, same result.

For LogicVisor's purposes, these should be counted as duplicates. But how do you get a computer to see past the surface differences and recognize that two pieces of code are structurally the same?

I started thinking about it from first principles. At the end of the day, programming languages get compiled down to binary and then to electrical pulses. If two solutions solve the same problem the same way, they're ultimately firing the same set of pulses at the machine level. Variable names be damned.

So the question became: can I strip a solution down to its most fundamental representation and compare that?

Enter the Abstract Syntax Tree

More research led me to the Abstract Syntax Tree — something my OS professor had mentioned in school that I'd filed away as "probably never useful in web dev." No knowledge is wasted.

An Abstract Syntax Tree (AST) is a hierarchical, tree-shaped data structure that represents the syntactic structure of source code. It strips away superficial syntax — semicolons, curly braces, whitespace, comments — and keeps only the structural and semantic skeleton of the code. The shape of what you wrote, not the clothing it's wearing.

This was it. But I hit a wall almost immediately: I can't store and index an entire AST reliably in PostgreSQL. It's a complex nested structure, not a scalar value you can slap an index on.

Then I remembered an article about handling duplicate file uploads in Express with Multer. The trick was generating a SHA-256 hash of the file's content. A hash is a fixed-length fingerprint — the same input always produces the same output, and different inputs produce different outputs. Perfect.

The plan crystallized:

Parse the submitted code into an AST
Normalize the AST (rename variables, strip comments, etc.)
Hash the normalized output with SHA-256
Store and index that hash
On every new submission, compute the hash and check if it already exists

If the hash is in the database, return the cached review. No AI call. No wasted tokens. No waiting.

Two Parsers for the Price of One

LogicVisor supports eight languages: JavaScript, TypeScript, Python, Java, C, C++, Go, and Rust. Getting an AST for all of them required two different tools, each with their own approach to the world.

Babel Parser (for JavaScript and TypeScript)

Babel is something most JavaScript developers know as a transpiler — the thing that converts modern JS to something older browsers can run. But under the hood, Babel has a full-featured parser that produces a detailed AST of your JavaScript or TypeScript code. The @babel/parser package exposes this directly.

I'd used Babel's output for years but never touched the parser API directly. It's surprisingly clean. You hand it source code and options, and it gives you back a structured AST you can traverse and manipulate.

What made Babel the right choice for JS/TS specifically:

Native TypeScript support via a plugin — no separate toolchain
JSX support out of the box
The @babel/traverse package lets you walk the AST and modify nodes in place, which is exactly how I rename identifiers
@babel/generator converts the modified AST back to compact source code

The JS/TS canonicalization path: parse with Babel → traverse the AST and rename all non-builtin identifiers to generic names (v0, v1, v2...) → optionally sort top-level declarations → regenerate compact source → hash it.

Tree-sitter (for everything else)

Tree-sitter is a different beast. It's a parser generator — a tool for building fast, incremental, error-tolerant parsers for programming languages. You might have encountered it without knowing it: if you've used Neovim with syntax highlighting that actually understands your code structure (my first encounter with the tool), that's Tree-sitter. Same if you've used editors where renaming a variable highlights every reference correctly. It's doing real parsing, not just regex matching.

What makes Tree-sitter interesting for this use case is that it has community-maintained grammars for a huge range of languages — C, C++, Go, Rust, Java, Python, and many more. Each grammar is a separate package that teaches Tree-sitter how to parse that language. You install the grammar, set it on a parser instance, and Tree-sitter gives you a concrete syntax tree you can walk.

I hadn't really understood what Tree-sitter was before this. I'd seen it referenced in Neovim config files and assumed it was some Vim-specific thing. It's not — it's a general purpose parsing library with bindings for multiple languages including Node.js via the node-tree-sitter package.

The Tree-sitter path: parse the source → walk the resulting syntax tree with a DFS traversal → collect all identifier nodes by their byte ranges → build a name mapping (first-occurrence order) → apply replacements from the end of the file backwards (so byte indices don't shift) → normalize whitespace → hash it.

The backwards-replacement trick is worth calling out. When you're doing string replacements by index, if you replace something early in the file, every subsequent index is now wrong. By sorting replacements by start position descending and working from the end, you avoid that entire class of bug.

The Implementation

Here's how it all fits together.

The Simple Canonicalization (Pre-AST)

Before I landed on the AST approach, I had a simpler version that just handled whitespace and comments:

export function canonicalizeCode(code: string): string {
  // Remove multi-line comments
  let cleanedCode = code.replace(/\/\*[\s\S]*?\*\//g, "");

  // Remove single-line comments
  cleanedCode = cleanedCode.replace(/\/\/.*$/gm, "");

  // Normalize all whitespace to a single space
  cleanedCode = cleanedCode.replace(/\s+/g, " ").trim();

  return cleanedCode;
}

This catches the obvious cases — same code with different formatting or comments. But it falls apart the moment someone renames a variable. The AST approach handles that.

The Router

The main entry point checks the language and dispatches to the right parser:

export async function canonicalizeCodeAST(
  code: string,
  language: LanguageKey,
  options?: CanonicalizeOptions
): Promise<string> {
  const opts = { ...defaultOptions, ...(options || {}) };

  if (language === "javascript" || language === "typescript") {
    return canonicalizeJS(code, opts);
  }

  // C/C++/Go/Rust/Java/Python go through Tree-sitter
  return canonicalizeWithTreeSitter(code, language, null);
}

The Babel Path (JS/TS)

function canonicalizeJS(
  code: string,
  opts: Required<CanonicalizeOptions>
): string {
  const plugins: any[] = ["jsx"];
  if (opts) plugins.push("typescript");

  const ast = babelParser.parse(code, {
    sourceType: "module",
    plugins,
    allowReturnOutsideFunction: true,
  });

  // Rename all non-builtin identifiers to generic names
  const nameMap = new Map<string, string>();
  let counter = 0;

  traverse(ast as any, {
    Identifier(path) {
      if (!opts.normalizeVariableNames) return;

      const name = path.node.name;
      if (isBuiltinJsName(name)) return;

      if (!nameMap.has(name)) {
        nameMap.set(name, `v${counter++}`);
      }

      path.node.name = nameMap.get(name)!;
    },
  });

  // Optionally sort top-level declarations for order-independent comparison
  if (
    opts.sortTopLevel &&
    (ast as any).program &&
    Array.isArray((ast as any).program.body)
  ) {
    (ast as any).program.body.sort((a: any, b: any) => {
      const aStr = generate(a).code;
      const bStr = generate(b).code;
      return aStr.localeCompare(bStr);
    });
  }

  // Regenerate compact source from the modified AST
  return generate(ast as any, {
    comments: !opts.removeComments,
    compact: true,
  }).code;
}

The Tree-sitter Path (Everything Else)

function canonicalizeWithTreeSitter(
  code: string,
  language: LanguageKey,
  opts: Required<CanonicalizeOptions> | null
): string {
  const LangCtor = (treeSitterMap as any)[language];

  if (!LangCtor) {
    throw new Error(`Unsupported language for tree-sitter: ${language}`);
  }

  const parser = new Parser();
  parser.setLanguage(LangCtor);

  const tree = parser.parse(code);
  const root = tree.rootNode;

  const identifierNodeTypes = identifierTypeMap[language] || ["identifier"];
  const idNodes: { start: number; end: number; text: string }[] = [];
  const commentNodes: { start: number; end: number }[] = [];

  // DFS traversal to collect identifier and comment nodes
  const stack = [root];
  while (stack.length) {
    const node = stack.pop()!;
    const type = node.type;

    if (type.includes("comment") && opts?.removeComments) {
      commentNodes.push({ start: node.startIndex, end: node.endIndex });
    }

    if (identifierNodeTypes.includes(type) || /identifier|name/i.test(type)) {
      const text = code.slice(node.startIndex, node.endIndex);
      idNodes.push({ start: node.startIndex, end: node.endIndex, text });
    }

    for (let i = 0; i < node.childCount; i++) {
      stack.push(node.child(i) as SyntaxNode);
    }
  }

  // Build name mapping in first-occurrence order
  const nameMap = new Map<string, string>();
  let counter = 0;

  for (const n of idNodes) {
    const orig = n.text;
    if (isLanguageBuiltinName(orig, language)) continue;
    if (!nameMap.has(orig)) {
      nameMap.set(orig, `v${counter++}`);
    }
  }

  // Build replacement list
  const replacements: { start: number; end: number; replacement: string }[] = [];

  if (opts?.removeComments) {
    for (const c of commentNodes) {
      replacements.push({ start: c.start, end: c.end, replacement: "" });
    }
  }

  if (opts?.normalizeVariableNames) {
    for (const id of idNodes) {
      const mapped = nameMap.get(id.text);
      if (mapped) {
        replacements.push({ start: id.start, end: id.end, replacement: mapped });
      }
    }
  }

  // Apply replacements from end to start so byte indices stay valid
  replacements.sort((a, b) => b.start - a.start);

  let out = code;
  for (const r of replacements) {
    out = out.slice(0, r.start) + r.replacement + out.slice(r.end);
  }

  return out.trim();
}

Hashing the Canonical Form

Once we have the normalized source, hashing is straightforward:

export async function createCanonicalHash(canonicalCode: string): Promise<string> {
  const encoder = new TextEncoder();
  const data = encoder.encode(canonicalCode);
  const hashBuffer = await crypto.subtle.digest("SHA-256", data);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map((b) => b.toString(16).padStart(2, "0")).join("");
}

SHA-256 gives us a fixed 64-character hex string regardless of how long the original code was. That's what gets stored and indexed in PostgreSQL.

Putting It All Together in the Request Handler

let canonicalCode;
try {
  canonicalCode = await canonicalizeCodeAST(solution, preferred_language);
} catch (error) {
  console.error("Canonicalization error:", error);
  return NextResponse.json(
    {
      success: false,
      error: {
        code: "BAD_USER_INPUT",
        message: "Unable to parse your code. Please check for syntax errors and try again.",
      },
    },
    { status: 400 }
  );
}

const canonicalHash = await createCanonicalHash(
  typeof canonicalCode === "string" ? canonicalCode : ""
);

// Check cache before touching the AI provider
const cachedReview = await getCachedAIReview(
  preferred_model.id + "-" + canonicalHash
);

if (cachedReview) {
  return NextResponse.json(
    { success: true, data: cachedReview },
    { status: 201 }
  );
}

// No cache hit — proceed with AI review and store the result

The model ID is included in the cache key because the same code reviewed by Gemini and Groq will produce different outputs. You don't want to serve a Gemini review to someone who selected Groq.

Does It Actually Work?

Here's the test that proved it out. Five TypeScript implementations of the same palindrome algorithm — different variable names, different formatting, different comments, and one with operand order swapped:

// Solution 1 — clean, descriptive names
function isPalindrome(x: number): boolean {
  let originalNum = x;
  let reversedNum = 0;
  while (originalNum > 0) {
    let lastDigit = originalNum % 10;
    reversedNum = (reversedNum * 10) + lastDigit;
    originalNum = Math.floor(originalNum / 10);
  }
  return x === reversedNum;
}

// Solution 2 — different variable names
function isPalindrome(n: number): boolean {
  let temp = n;
  let result = 0;
  while (temp > 0) {
    let digit = temp % 10;
    result = (result * 10) + digit;
    temp = Math.floor(temp / 10);
  }
  return n === result;
}

// Solution 3 — compressed formatting + comments
function isPalindrome(x: number): boolean{
  // Store original
  let originalNum=x;let reversedNum=0;
  while(originalNum>0){
    let lastDigit=originalNum%10; /* get digit */
    reversedNum=(reversedNum*10)+lastDigit;
    originalNum=Math.floor(originalNum/10);
  }
  return x===reversedNum;
}

// Solution 4 — addition operands swapped
function isPalindrome(x: number): boolean {
  let originalNum = x;
  let reversedNum = 0;
  while (originalNum > 0) {
    let lastDigit = originalNum % 10;
    reversedNum = lastDigit + (reversedNum * 10); // addition order changed
    originalNum = Math.floor(originalNum / 10);
  }
  return reversedNum === x; // comparison order changed
}

// Solution 5 — completely different algorithm
function isPalindrome(x: number): boolean {
  const str = x.toString();
  return str === str.split('').reverse().join('');
}

And the test harness:

export async function testDuplicateDetection() {
  const solutions = [ /* ...the five solutions above... */ ];

  console.log("Code hash comparison:");

  solutions.forEach(async (code, index) => {
    const canonicalized = await canonicalizeCodeAST(code, "typescript");
    const hash = await createCanonicalHash(canonicalized);
    console.log(`\nSolution ${index + 1}:`);
    console.log(`Hash: ${hash.substring(0, 12)}...`);
    console.log(
      `Canonical: ${
        typeof canonicalized === "string" ? canonicalized.substring(0, 100) : ""
      }...`,
    );
  });

  // Canonicalize before hashing — not after
  const hashes = await Promise.all(
    solutions.map(async (code) => {
      const canonicalized = await canonicalizeCodeAST(code, "typescript");
      return createCanonicalHash(canonicalized);
    }),
  );
  const uniqueHashes = new Set(hashes);

  console.log(`\nOriginal solutions: ${solutions.length}`);
  console.log(`Unique hashes: ${uniqueHashes.size}`);
  console.log(`Duplicates detected: ${solutions.length - uniqueHashes.size}`);
}

The output:

Code hash comparison:

Solution 1:
Hash: f7142f71e35a...
Canonical: function v0(v1:number):boolean{let v2=v1;let v3=0;while(v2>0){let v4=v2%10;v3=v3*10+v4;v2=Math.v5(v2...

Solution 2:
Hash: f7142f71e35a...
Canonical: function v0(v1:number):boolean{let v2=v1;let v3=0;while(v2>0){let v4=v2%10;v3=v3*10+v4;v2=Math.v5(v2...

Solution 3:
Hash: f7142f71e35a...
Canonical: function v0(v1:number):boolean{let v2=v1;let v3=0;while(v2>0){let v4=v2%10;v3=v3*10+v4;v2=Math.v5(v2...

Solution 4:
Hash: da8268fe24dd...
Canonical: function v0(v1:number):boolean{let v2=v1;let v3=0;while(v2>0){let v4=v2%10;v3=v4+v3*10;v2=Math.v5(v2...

Solution 5:
Hash: e3d2696010ad...
Canonical: function v0(v1:number):boolean{const v2=v1.v3();return v2===v2.v4('').v5().v6('');}...

Original solutions: 5
Unique hashes: 3
Duplicates detected: 2

Solutions 1, 2, and 3 collapse to the same hash — variable names, whitespace, and comments are all stripped away during canonicalization, leaving identical ASTs. Solution 4 gets a distinct hash because operand order (lastDigit + reversedNum * 10 vs reversedNum * 10 + lastDigit) is a syntactic difference the AST preserves — commutativity is math, not structure, and the canonicalizer doesn't evaluate expressions. Solution 5 is correctly identified as a genuinely different algorithm.
Two duplicates detected. Working as intended.

The Tradeoffs Worth Knowing

This approach isn't magic. A few things it doesn't catch:

Semantic equivalence across algorithms. Two completely different implementations that produce the same result — bubble sort vs. merge sort, for example — will have different hashes. This system detects structural duplicates, not algorithmic equivalence. That's actually the right behavior for a code review platform.

Heuristic identifier detection in Tree-sitter. The identifier node types vary between language grammars, and I'm using pattern matching (/identifier|name/i) as a fallback. It works well in practice but it's not exhaustive. If a grammar names its identifier nodes something unusual, you might miss some.

Builtin lists are incomplete. The isBuiltinJsName and isLanguageBuiltinName functions cover the most common builtins but aren't exhaustive. If a user names their variable fetch or setTimeout, those won't be normalized. Not a critical flaw, but worth knowing.

What I Took Away From This

The part I didn't expect: how much I'd enjoy it. This was one of those problems that pulled me away from the normal web dev loop of "call an API, render some data" and into something that felt closer to computer science. Parsers, ASTs, tree traversal — things I'd learned in school that felt abstract at the time suddenly had a real home in a real production system.

The other thing I took away: sometimes the right caching strategy isn't about time-to-live or cache invalidation. Sometimes it's about recognizing that two requests are asking for the same thing, even when they look different on the surface. That realization changed how I thought about a whole class of optimization problems.

If you're building anything that takes code as input — a linter, a reviewer, a plagiarism detector, an interview platform — the AST + hash pattern is worth having in your toolkit.

LogicVisor is an AI-powered tool that reviews your algorithmic code, breaks down time and space complexity, and gives you the kind of feedback you'd want before a technical interview. You can try it at logicvisor.vercel.app.

Why I Move AI Model Calls to the Server — Security, Performance, and Everything In Between

David Essien — Tue, 26 May 2026 12:00:00 +0000

When I was building Logicvisor — an AI-powered tool that reviews your algorithmic code, breaks down time and space complexity, and gives you the kind of feedback you'd want before a technical interview — I had to make a foundational architectural decision early on.

Where do the AI calls actually live?

It sounds simple. It really isn't. And I think it's a decision a lot of developers make too quickly, usually defaulting to whatever gets something running fastest. So I want to walk through how I thought about it, what the tradeoffs actually look like in practice, and why for Logicvisor — and honestly most production projects I work on — the answer was never really up for debate.

The Case for Client-Side AI Calls
Why Client-Side Breaks Down in Production
The Case for Server-Side AI Calls
How This Played Out in Logicvisor
- Performance
- Security
- Authentication
- Caching
- Provider Abstraction
- AI Response Processing
So Was It Ever Really a Debate?

First, Let's Establish What We're Even Choosing Between

When your app needs to talk to an AI model — Gemini, Claude, GPT, whatever — that HTTP request to the model provider has to originate somewhere. You have two options:

Client-side: The browser makes the call directly to the AI provider's API.

Server-side: The browser calls your server, your server calls the AI provider, and the response comes back through your infrastructure.

That's the whole decision. But the consequences of each branch run deep.

The Case for Client-Side AI Calls

Let's be fair to the other side first, because client-side AI calls aren't just laziness — there are legitimate reasons to reach for them.

Zero backend overhead. If you're prototyping, building an MVP, or hacking something together for a weekend project, standing up a server just to proxy AI calls adds friction you might not need yet. The client calls the API, gets a response, done.

One less network hop. Client → AI provider is a straight line. Client → your server → AI provider is also a straight line, but a longer one. Every additional hop is a potential source of latency, and if your server is not geographically close to the AI provider, that gap compounds.

Fast iteration during development. Tweak a prompt, refresh the page, see the result. No redeployment cycle, no server restart. For the early exploratory phase of building with AI, this feedback loop is genuinely valuable.

Fine for purely client-facing tools. If you're building something that doesn't touch your own database, doesn't need user sessions, and doesn't have sensitive business logic — a personal productivity tool, a browser extension, an internal utility — client-side calls can be perfectly appropriate.

So that's the honest upside. Now here's where it falls apart.

Why Client-Side AI Calls Break Down in Production

The API Key Problem

This is the most obvious one, but it's worth being precise about why it's as bad as it is.

When you make an API call from the browser, your API key has to be in that request. There's no way around this — the provider needs to authenticate you. And since that request is made from the browser, the key is accessible to anyone who opens DevTools, intercepts traffic, or extracts it from your bundled JavaScript.

The consequence isn't just that someone can see your key. It's that they can use it. At your expense. Without your knowledge. AI API billing is usage-based, which means a single bad actor with your key can run up a bill that drains your account before your monitoring even fires an alert — if you have monitoring at all.

Key rotation helps, but it's reactive. The damage is usually already done.

Your Prompt Engineering Is Public

This one gets less attention but matters more than people realize.

The prompts you write are often where your actual product value lives. If you've spent time crafting a system prompt that makes your AI reviewer give structured, consistent, high-quality feedback on algorithmic code — that prompt is the product. Client-side calls expose it completely. A competitor can open DevTools, read your system prompt, and replicate your core feature in an afternoon.

On the server, your prompts never leave your infrastructure. The client sends input; the server decides what to do with it.

You Have No Control Over Abuse

On the client side, there's nothing stopping a user from writing a script that hammers your AI endpoint in a loop. Every one of those requests hits the AI provider and costs you tokens. You have no rate limiting, no request validation, no way to enforce quotas per user.

You're not just vulnerable to malicious actors either — a bug in your own frontend code that causes unintended re-fetching can silently burn through your API budget.

No Caching

AI API calls cost money per token. If multiple users ask your tool to review functionally identical code, why would you want to pay for that same inference three hundred times?

On the client side, you can't cache at the API level. Every identical request goes to the provider, incurs latency, and costs tokens. On the server, you can cache responses intelligently — hash the input, check your cache layer, return the cached result. You pay once.

You're Flying Blind in Production

Without server-side infrastructure, you have no centralized view of how your AI layer is actually being used. Which prompts are performing well? Which inputs are producing garbage responses? Which users are hitting rate limits? Where is your token spend going?

Client-side AI calls mean you're guessing at all of this. Logs, monitoring, and observability — the basic instrumentation of a production system — require a server in the loop.

The Case for Server-Side AI Calls

With that context established, here's what you actually get when the AI calls live on the server.

The API Key Never Touches the Client

Your key lives in an environment variable on the server. The client has zero knowledge of it, zero access to it, and zero ability to extract it. This is the minimum acceptable security posture for any application that will see real users.

You Control Rate Limiting

You decide how many requests a given user can make in a given window. You can enforce this per account, per IP, per session — whatever your threat model calls for. Abuse becomes something you manage rather than something that happens to you.

export async function enforceAIRateLimit(
    userId: string,
    request?: NextRequest
): Promise<RateLimitResult> {
    const tierLimits = await getUserTierLimits(userId);

    if (!tierLimits) {
        throw new RateLimitError("Unable to determine user tier limits");
    }

    // Free/Pro users: per-minute limits
    if (tierLimits.ai_requests_per_minute !== null) {
        const minuteLimit = await checkRateLimit(userId, "ai_request", "minute");

        if (!minuteLimit.isAllowed) {
          await logRateLimitViolation(userId, "ai_request", "minute", ...);
          throw new RateLimitError(``Rate limit exceeded. Resets at ${minuteLimit.resetTime.toISOString()}``);
        }

        return minuteLimit;
    }

    // Admin users: daily + monthly
    const dailyLimit = await checkRateLimit(userId, "ai_request", "daily");
    // ...monthly check follows same pattern
}

Response Caching Becomes Possible

Identical or near-identical inputs can return cached results, cutting both latency and cost. For a tool like Logicvisor where multiple users might submit similar sorting algorithm implementations, the savings on repeated inferences compound quickly.

// Normalize the code to a canonical form before hashing
// so that formatting differences don't result in cache misses
const canonicalCode = await canonicalizeCodeAST(solution, preferred_language);
const canonicalHash = await createCanonicalHash(
  typeof canonicalCode === "string" ? canonicalCode : ""
);

// Check cache before hitting the AI provider
const cachedReview = await getCachedAIReview(
  preferred_model.id + "-" + canonicalHash
);
if (cachedReview) {
  return NextResponse.json(
    { success: true, data: cachedReview },
    { status: 201 }
  );
}

You Can Inject Server-Side Context Into Prompts

This is where things get architecturally interesting. The client sends raw input — code, a question, a request. But your server knows things the client doesn't: who the user is, what their history looks like, what tier they're on, what language they've selected, what results they've already received. All of that context can be injected into the prompt before it ever leaves your infrastructure.

The client can't fake or manipulate that context because it never touches it.

Full Observability

Every request is logged. Every response is traceable. You can monitor token usage, flag anomalous behavior, track which prompts produce the best results, and debug production issues with actual data. This is what running software in production looks like.

await updateAPIUsageAnalytics("/api/internal", true, responseTime, aiTokensUsed, estimatedCost, user.id, {
  modelName: modelUsed,
  modelProvider,
  inputTokens,
  outputTokens,
  totalTokens: aiTokensUsed,
  actualCostUsd,
});

The BFF Argument — One Round Trip Instead of Many

There's a broader architectural win here that goes beyond just AI calls. Without a server in the middle, the client has to orchestrate everything itself: call the AI, wait for the response, then maybe hit your database, wait again, then update the UI. Each of those is a visible pause for the user.

With a Backend for Frontend (BFF) pattern, the client makes one request. The server handles the AI call, processes the response, queries the database if needed, applies any business logic, and returns a single resolved payload. The user feels one network round trip instead of a cascading waterfall of them.

Architecture Diagrams

Before getting into the implementation specifics, here's the architectural difference visualised.

Client-Side AI Calls — The Problem

Browser → AI Provider directly · API key exposed in transit

Server-Side AI Calls — The Solution

Browser → API Route → [Cache · Rate Limiter · AI Provider · DB] → Browser

How This Played Out in Logicvisor

Let me get concrete. Here's what moving the AI layer to the server actually looked like in practice.

Performance — Collapsing the Waterfall

Logicvisor uses Supabase on the backend. At various points in the app, I need to pull data from multiple tables, run the AI review, and return everything the page needs in one shot.

If this were all happening on the client, you'd be looking at: call Supabase for user context → wait → call the AI provider → wait → call Supabase again for historical reviews → wait → render. Each of those waits is visible to the user, and each one is an opportunity for something to fail mid-chain.

On the server, those calls happen in close proximity to each other and to the data. The AI call, the database queries, and any necessary transformations all resolve server-side, and the client gets one clean response. The user experiences a single loading state, not a series of UI flickers.

There's also the matter of compute. Parsing and processing a large AI response — stripping JSON fences, validating structure, transforming the output into the format the UI expects — is work that browsers are not well-suited for. Browsers are memory and CPU constrained by design, and they're competing with the DOM, with other tabs, with everything the user has open. A server doesn't have those constraints.

Security — API Obfuscation as a Feature

Moving calls to the server means the client's entire interaction is scoped to your own API. It calls your endpoint, gets a response, done. It has no visibility into what your server does with that request internally — which external APIs it calls, what keys those calls carry, or how the response was constructed.

This isn't security through obscurity; the obfuscation is a structural property of the architecture. OS-level network tools could theoretically expose some of this, but you've dramatically raised the bar for what an attacker needs to do to compromise your stack.

Your system prompts — the part of the product that actually encodes your domain knowledge and review methodology — never leave the server. That's not a small thing.

Authentication — Stateless and Seamless

A server in the loop makes proper auth architecture dramatically cleaner. I was able to set HttpOnly cookies, attach signed JWT tokens, and build a stateless authentication and authorization system that the client participates in without controlling.

Without a server, you end up storing tokens in localStorage or client-side state, which is a well-documented attack surface. The session becomes something the client manages, which means it's something an attacker can manipulate.

Caching — Paying for Inference Once

Token costs are real. For Logicvisor, where users might submit variations of common algorithm patterns — bubble sort, binary search, dynamic programming problems — I can cache AI responses keyed on a normalized hash of the input. A user submitting a well-known algorithm implementation gets a fast, cached response. The AI provider gets called once.

This also improves response times for cached queries significantly. The round trip to an AI provider is the most expensive part of the request by a wide margin. Eliminating it for repeat queries is the single highest-leverage performance optimization available to you.

Provider Abstraction — Switching Models Without Touching the Client

Here's something the client-side approach makes nearly impossible: swapping AI providers without your frontend caring at all.

Logicvisor supports both Gemini and Groq depending on the user's selected model. Gemini for deeper analysis with its thinking budget and Google Search grounding, Groq for speed. Two different SDKs, two different response shapes, two different token counting strategies, two different pricing models. The client knows none of this. It sends a request, it gets a review back.

That abstraction only works because the AI calls live on the server:

switch (modelProvider.toLowerCase()) {
  case "google":
    // Gemini — thinking budget + Google Search grounding
    const response = await ai.models.generateContent({
      model: preferred_model.id,
      config: {
        thinkingConfig: { thinkingBudget: prompt.estimatedTokens },
        tools: [{ googleSearch: {} }],
        seed: SEED,
        temperature: TEMPERATURE,
      },
      contents,
    });
    aiReviewText = response.text ?? "";
    // Extract actual token counts from usageMetadata
    inputTokens = response.usageMetadata?.promptTokenCount || 0;
    outputTokens = response.usageMetadata?.candidatesTokenCount || 0;
    break;

  case "groq":
    // Llama 3.3 70B — forces structured JSON response
    const groqResponse = await groq.chat.completions.create({
      messages: [{ role: "user", content: prompt.content }],
      model: groqModel,
      temperature: TEMPERATURE,
      seed: SEED,
      response_format: { type: "json_object" },
      stream: false,
    });
    aiReviewText = groqResponse.choices[0].message.content ?? "";
    inputTokens = groqResponse.usage?.prompt_tokens || 0;
    outputTokens = groqResponse.usage?.completion_tokens || 0;
    break;
}

If I wanted to add a third provider tomorrow — say, Claude for a specific model tier — that's a new case block on the server. The client contract doesn't change. No frontend deployment, no API key exposure, no breaking changes for users mid-session.

Try doing this cleanly when the calls are in the browser. You'd be shipping provider-specific SDK logic, API keys, and token counting math directly to the client — and every provider swap would mean a frontend change. The server is the only place this kind of abstraction is clean.

This also matters for cost tracking. Notice that each branch extracts token counts differently — Gemini from usageMetadata, Groq from usage. That per-provider normalization feeds into the analytics pipeline downstream, giving you a consistent view of cost across providers regardless of how each SDK reports it. That's only possible because all the provider-specific handling is in one place.

AI Response Processing — Cleaning Up the Model's Output

Here's the unglamorous part that doesn't get written about enough: AI models don't always return clean output.

Gemini, for example, sometimes wraps JSON responses in markdown fences even when you've explicitly told it not to. If your UI is trying to parse that response and render structured data, you need to clean it before it gets anywhere near the client.

On the server, I handle all of that: strip the fences, validate the JSON structure, handle the cases where the model returned something unexpected, and only send a clean, predictable payload to the client. If something goes wrong at this layer, I can log it, inspect it, and fix the prompt. The client just sees a well-structured response or a proper error.

export function extractJSONFromMarkdown(markdownString: string) {
  try {
    // Remove the ```json wrapper
    let jsonString = markdownString.trim();

    // Remove ```json from start
    if (jsonString.startsWith("```json")) {
      jsonString = jsonString.substring(7);
    }

    // Remove ``` from end
    if (jsonString.endsWith("```")) {
      jsonString = jsonString.substring(0, jsonString.length - 3);
    }

    // Parse the JSON
    const parsedData: PromptResult = JSON.parse(jsonString.trim());

    // Extract and decode the markdown_review field
    let markdownReview = parsedData.markdown_review;
    if (markdownReview) {
      // Decode JSON escape sequences
      markdownReview = markdownReview
        .replace(/\\n/g, "\n")   // Convert \n to actual newlines
        .replace(/\\t/g, "\t")   // Convert \t to actual tabs
        .replace(/\\r/g, "\r")   // Convert \r to carriage returns
        .replace(/\\"/g, '"')    // Convert \" to actual quotes
        .replace(/\\\\/g, "\\"); // Convert \\ to actual backslashes

      return { parsedData, markdownReview };
    } else {
      console.log("No markdown_review field found");
      return null;
    }
  } catch (error) {
    console.error("Error parsing JSON:", error);
    return null;
  }
}

If this processing happened on the client, every user's browser would be doing it — inconsistently, with no visibility, and with no way to fix edge cases without a frontend deployment.

So Was It Ever Really a Debate?

Honestly, not for Logicvisor.

Client-side AI calls are a valid tool in specific, narrow contexts — personal tools, internal utilities, quick prototypes where security is not a concern and scale is not a goal. The moment you have real users, real API costs, and real data flowing through your system, the calculus changes completely.

Security, performance, observability, and maintainability all point in the same direction. The extra infrastructure is real overhead. But it's the kind of overhead that pays for itself the first time an abuse attempt hits your rate limiter instead of your API bill.

For any production system where AI inference is part of the core product — keep it on the server. Build the client thin. Let the backend do the heavy lifting.

How to Authenticate Users with Solana Wallets in NestJS

David Essien — Mon, 19 Jan 2026 07:00:00 +0000

Let's talk about wallet based auth in NestJS. What this is, is basically an auth system where the user is authenticated and authorized based on their web3 wallet. We'll be doing this with a Solana wallet. The process is quite straightforward:

User requests a nonce (a single-use random number that prevents replay attacks)
Backend sends the nonce
User signs the nonce with their wallet address and returns the signed nonce back to the backend
Backend verifies that the nonce was signed by the right address

From this point on it's your regular auth flow and you can hook this up to any existing JWT or session auth system you've implemented.

One thing to note is that a frontend is required for this or at least some way for the client to sign nonces with their web3 wallet. We'll be using @solana/kit SDK for this as it's the modern implementation of the @solana/web3.js SDK and recommended for production use by Anza.

Backend

The backend's job is to generate unique challenges (nonces), verify that signatures were created by the claimed wallet address, and issue JWT tokens on successful authentication.

We'll need to install @solana/kit as well as redis since we will be using that to store our nonces. Redis is ideal here because it provides fast in-memory storage with built-in TTL (time-to-live) expiration, automatically cleaning up old nonces without manual intervention.

npm install @solana/kit redis

Redis Service

Let's set up our redis client and service.

In NestJS, when you're working with non-class instances like Redis clients, you can't use the standard class-based dependency injection. Instead, you use string tokens as injection identifiers. The Redis client is created by a factory function (not instantiated via new RedisService()), so TypeScript can't use the class itself as a token. String constants provide a unique identifier that NestJS can use to register and retrieve the instance.

This is why we define REDIS_CLIENT as a constant string token that we'll use to register and inject our Redis client throughout the application.

//redis.constants.ts
export const REDIS_CLIENT = 'REDIS_CLIENT';

We need two specific methods here. The setNonce method stores the nonce with a 5-minute expiration using Redis's EX option, which automatically cleans up old nonces and prevents replay attacks.

The getAndDeleteNonce method atomically retrieves and deletes the nonce in one operation, ensuring each nonce can only be used once for verification. This pattern prevents an attacker from reusing a previously signed nonce.

//redis.service.ts
import { Inject, Injectable } from '@nestjs/common';
import { REDIS_CLIENT } from './redis.constants';
import type { RedisClientType } from 'redis';

@Injectable()
export class RedisService {
  constructor(@Inject(REDIS_CLIENT) private readonly redis: RedisClientType) {}

  // Store nonce with 5-minute expiration
  async setNonce(address: string, nonce: string): Promise<void> {
    await this.redis.set(`nonce:${address}`, nonce, { EX: 300 });
  }

  // Retrieve and immediately delete nonce to prevent replay attacks
  async getAndDeleteNonce(address: string): Promise<string | null> {
    const nonce = await this.redis.get(`nonce:${address}`);

    if (nonce) {
      await this.redis.del(`nonce:${address}`);
    }

    return nonce;
  }
}

We're using NestJS's ConfigService to manage environment variables in a type-safe way. This is better than directly accessing process.env because it centralizes configuration, provides validation, and makes testing easier. You can validate required variables at startup (fail fast), type-check them, and mock them in tests without polluting the global process object.

The @Global() decorator makes this module available throughout your application without needing to import it into every module. Make sure to set up ConfigModule in your AppModule like this:

// app.module.ts
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
// ... other imports

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true, // Makes ConfigModule available globally
    }),
    // ... other modules
  ],
  // ... controllers and providers
})
export class AppModule {}

Now we can set up our Redis module:

//redis.module.ts
import { Global, Module } from '@nestjs/common';
import { RedisService } from './redis.service';
import { REDIS_CLIENT } from './redis.constants';
import { ConfigService } from '@nestjs/config';
import { createClient } from 'redis';

@Global()
@Module({
  providers: [
    {
      provide: REDIS_CLIENT,
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const client = createClient({
          url: configService.get<string>('REDIS_URL'),
        });

        client.on('error', (err) => console.error('Redis client error', err));

        await client.connect();

        return client;
      },
    },
    RedisService,
  ],
  exports: [REDIS_CLIENT, RedisService],
})
export class RedisModule {}

Auth Service

With Redis configured to handle nonce storage, we can build the authentication logic. The auth service will generate nonces, create SIWS-compliant messages, verify signatures, and issue JWT tokens. Let's implement our service logic.

We need to provide a way for the frontend to request a nonce. We also need to use our redis methods to store the nonce we provide to be used during verification later.

We use randomBytes from Node's crypto module to generate cryptographically secure random values. The 16 bytes of random data are then converted to base64url encoding, which is URL-safe and produces a string without padding characters. This encoding ensures the nonce can be safely included in URLs and JSON without escaping issues, while 16 bytes provides sufficient entropy (2^128 possible values) to prevent collision attacks. This gives us a unique, unpredictable nonce for each authentication attempt.

import { randomBytes } from 'crypto';

generateNonce(): string {
  return randomBytes(16).toString('base64url');
}

The message format follows the Sign-In with Solana (SIWS) standard, which is analogous to Sign-In with Ethereum (SIWE). This standardized format includes the domain requesting authentication, the user's wallet address, a human-readable message, the unique nonce, and a timestamp. This structure ensures the user knows exactly what they're signing and prevents phishing attacks where a malicious site might try to get users to sign messages intended for other domains.

async getChallenge(address: string) {
  const nonce = this.generateNonce();

  await this.redisService.setNonce(address, nonce);

  // Standard SIWS message format for wallet authentication
  const message = `titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}`;

  return { message, nonce };
}

The signature verification method is the heart of the authentication system. It retrieves the stored nonce, reconstructs the exact message that was signed, and uses Solana's cryptographic primitives to verify that the signature was created by the private key corresponding to the claimed wallet address. If any part of this fails, authentication is rejected.

import { getAddressFromPublicKey, getBase58Decoder, getBase58Encoder } from '@solana/kit';

async verifySolanaSignature(data: {
  address: string;
  signatureBase58: Uint8Array;
  message: Uint8Array;
  nonce: string;
}): Promise<boolean> {
  const { address, signatureBase58, message, nonce } = data;

  // Retrieve and delete the nonce to prevent replay attacks
  const storedNonce = await this.redisService.getAndDeleteNonce(address);

  if (!storedNonce || storedNonce !== nonce) {
    return false;
  }

  try {
    // Decode the signature and message from base58
    const signature = getBase58Decoder().decode(signatureBase58);
    const messageBytes = getBase58Decoder().decode(message);

    // Verify the signature matches the address
    const publicKey = getAddressFromPublicKey(
      getBase58Decoder().decode(address)
    );

    // Use Solana's signature verification
    const isValid = await verifySignature(publicKey, messageBytes, signature);

    return isValid;
  } catch (error) {
    console.error('Signature verification error:', error);
    return false;
  }
}

The validateUserWithWallet method either finds an existing user by wallet address or creates a new one. This is where you'd integrate with your user management system. In this example, we're using Prisma to handle database operations, but you could adapt this to any ORM or database layer.

async validateUserWithWallet(address: string): Promise<UserEntity | null> {
  // Find existing user by wallet address
  let user = await this.prisma.user.findUnique({
    where: { walletAddress: address },
  });

  // If no user exists, create one
  if (!user) {
    user = await this.prisma.user.create({
      data: {
        walletAddress: address,
      },
    });
  }

  return user;
}

The login function creates JWT tokens after successful authentication. We build a payload containing the user's ID and device information, then conditionally add email and wallet address if they exist. The function returns both an access token for immediate use and a refresh token for obtaining new access tokens when the current one expires. The refresh token is handled by a separate service that manages longer-lived tokens with different expiration rules.

async login(
  user: UserEntity,
  deviceInfo: string,
  walletAddress?: string,
): Promise<{
  access_token: string;
  refresh_token: string;
}> {
  const payload = {
    sub: user.id,
    deviceInfo,
  };

  if (user.email) {
    payload['email'] = user.email;
  }

  if (walletAddress) {
    payload['walletAddress'] = walletAddress;
  }

  const refresh_token = await this.jwtRefreshService.create(payload);

  return {
    access_token: this.jwtService.sign(payload),
    refresh_token,
  };
}

Wallet Auth Guard

Now we need a way to protect our login endpoint. NestJS guards intercept incoming requests before they reach the controller, making them perfect for authentication logic.

The guard is responsible for intercepting requests to protected endpoints and verifying that the wallet signature is valid before allowing the request to proceed. It extracts the signed data from the request body, verifies the signature using our auth service, finds or creates the user, and attaches both the user entity and wallet address to the request object for use in the controller.

// guards/wallet-auth.guard.ts
import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { AuthService } from '../auth.service';
import { UnauthorizedException } from '@nestjs/common';

@Injectable()
export class LocalWalletAuthGuard implements CanActivate {
  constructor(private readonly authService: AuthService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const { address, signatureBase58, message, nonce } = request.body;

    // Verify signature first
    const isValid = await this.authService.verifySolanaSignature({
      address,
      signatureBase58,
      message,
      nonce,
    });

    if (!isValid) {
      throw new UnauthorizedException('Invalid signature');
    }

    // Find or create user
    const user = await this.authService.validateUserWithWallet(address);

    if (!user) {
      throw new UnauthorizedException('Could not validate user');
    }

    // Attach user and address to request for use in controller
    request.user = user;
    request.address = address;

    return true;
  }
}

Auth Controller

With our guard handling verification, the controller becomes simple. It just needs to provide nonces to unauthenticated users and issue tokens after the guard confirms valid signatures.

In the controller, we have two endpoints. The loginWithWallet endpoint uses our LocalWalletAuthGuard which verifies the signature and attaches both the user entity and wallet address to the request object. By the time we reach this controller method, we know the authentication is valid. We extract device information from the user-agent header, call the login service, set the refresh token as an httpOnly cookie for security, and return the access token. The getChallenge endpoint is marked with @Public() decorator since users need to request a nonce before they can authenticate. It simply returns the SIWS message and nonce for the given wallet address.

@Post('login-with-wallet')
@UseGuards(LocalWalletAuthGuard)
async loginWithWallet(
  @Request() req: RequestType & { user: UserEntity; address: string },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
    req.address,
  );

  // Set refresh token as httpOnly cookie for security
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
  });

  return { access_token };
}

@Public()
@Get('nonce/:address')
@ApiOperation({ summary: 'Request nonce for wallet-based authentication' })
@ApiResponse({
  description: 'Nonce and SIWS message sent successfully.',
  status: 200,
  example: {
    message:
      'titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}',
    nonce: '1234xlrhex',
  },
})
async getChallenge(@Param('address') address: string) {
  return await this.authService.getChallenge(address);
}

Backend Summary

That covers the backend implementation. We've set up a Redis-backed nonce system that generates unique challenges for each authentication attempt, an auth service that creates SIWS-compliant messages and manages JWT token generation, a guard that verifies signatures using Solana's cryptographic primitives, and controller endpoints that handle the nonce request and login flow. The signature verification ensures that only the holder of the wallet's private key can authenticate, while the nonce system prevents replay attacks.

Frontend

The backend is now ready to issue nonces and verify signatures. The frontend's job is to request these nonces, get the user to sign them with their wallet's private key (which never leaves their browser), and send the signed message back for verification. Now let's implement the frontend of our auth system.

Now let's implement the frontend of our auth system. The user needs to sign our message with their private key. It is important this private key stays secure and never leaves the frontend. A tool that facilitates this is a wallet. Since we're using Solana we'll be using the Phantom wallet.

The setup steps are straightforward. First, install Phantom as a browser extension. Once installed, create a new wallet or import an existing one. Then navigate to Settings, go to Developer Settings, and enable Testnet mode. In Testnet mode, select Solana Devnet. You could use Localnet if you have a test validator running locally or Testnet for a shared testing environment, but Devnet provides a good balance of accessibility and realistic network conditions.

Once all this is done we can start hacking. We'll spin up a small React frontend. This is just for speed and general accessibility. You can implement this in any frontend stack as long as you understand the core steps. I used Vite to set up my React project with TypeScript and Tailwind. We should also install the @solana/kit package, which automatically includes @solana/react and other necessary dependencies, along with @wallet-standard/react-core.

npm install @solana/kit @wallet-standard/react-core

After we're done with project setup, the first thing we want to do is define our Solana client instance. This will be used to communicate with the Solana chain via its RPC endpoints.

// lib/solana-client.ts
import type {
  Rpc,
  RpcSubscriptions,
  SolanaRpcApi,
  SolanaRpcSubscriptionsApi,
} from "@solana/kit";

export type Client = {
  rpc: Rpc<SolanaRpcApi>;
  rpcSubscriptions: RpcSubscriptions<SolanaRpcSubscriptionsApi>;
};

// lib/helpers.ts
import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
import type { Client } from "./solana-client";

let client: Client | undefined;

export function createClient(): Client {
  if (!client) {
    client = {
      rpc: createSolanaRpc(`${import.meta.env.SOLANA_RPC_URL}`),
      rpcSubscriptions: createSolanaRpcSubscriptions(
        `${import.meta.env.SOLANA_RPC_SUBSCRIPTIONS_URL}`
      ),
    };
  }

  return client;
}

Make sure your .env file contains the Devnet URLs:

SOLANA_RPC_URL=https://api.devnet.solana.com
SOLANA_RPC_SUBSCRIPTIONS_URL=wss://api.devnet.solana.com

With the Solana client configured, we need functions to communicate with our backend. In our features/auth/api folder, we'll create two API calls: one to request a nonce and another to submit the signed message. Let's define them both.

// features/auth/types
export type RequestNonceOutput = {
  message: string;
  nonce: string;
};

export type VerifyNonceInput = {
  address: string;
  signatureBase58: Uint8Array<ArrayBufferLike>;
  message: Uint8Array<ArrayBufferLike>;
  nonce: string;
};

export type LoginResponse = {
  access_token: string;
};

// features/auth/api/requestNonce.ts
import type { RequestNonceOutput } from "../types";

export async function requestNonce(
  address: string
): Promise<RequestNonceOutput> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/nonce/${address}`
  );

  if (!response.ok) {
    throw new Error(`Failed to request nonce: ${response.statusText}`);
  }

  const data = await response.json();

  // Validate response structure
  if (!data.message || !data.nonce) {
    throw new Error('Invalid response format from nonce endpoint');
  }

  return data as RequestNonceOutput;
}

// features/auth/api/loginWithWallet.ts
import type { VerifyNonceInput, LoginResponse } from "../types";

export async function loginWithWallet(
  signedData: VerifyNonceInput
): Promise<LoginResponse> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/login-with-wallet`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(signedData),
    }
  );

  if (!response.ok) {
    const errorData = await response.json().catch(() => ({}));
    throw new Error(
      errorData.message || `Login failed: ${response.statusText}`
    );
  }

  const data = await response.json();

  // Validate response contains access token
  if (!data.access_token) {
    throw new Error('Invalid response format from login endpoint');
  }

  return data as LoginResponse;
}

These are going to serve as our connection to the backend we made previously.

Before we build the UI components, we need to manage wallet connection state across the app. React Context provides a clean way to share the selected wallet without prop drilling.

As this is only an auth demonstration it's not going to be anything fancy, just enough to implement the authentication flow and some state to show we're logged in.

First off, our wallet account context. You can use some other way to manage context in your application. Here we'll be using the React Context API.

// src/context/SelectedWalletAccountContext.tsx
import { createContext } from "react";
import type { UiWallet, UiWalletAccount } from "@wallet-standard/react-core";

export type SelectedWalletAccountState = UiWalletAccount | undefined;

export const SelectedWalletAccountContext = createContext<
  readonly [
    selectedWalletAccount: SelectedWalletAccountState,
    setSelectedWalletAccount: React.Dispatch<
      React.SetStateAction<SelectedWalletAccountState>
    >,
    selectedWallet: UiWallet | undefined
  ]
>([
  undefined,
  function setSelectedWalletAccount() {
    /* empty */
  },
  undefined,
]);

The wallet account context provider handles persistence and synchronization of the selected wallet across sessions. When a user selects a wallet, we save a storage key composed of the wallet name and account address to localStorage. On subsequent visits, the provider attempts to restore the previously selected wallet if it's still available. The provider also handles cleanup when wallets disconnect and ensures the selected account stays synchronized with the actual connected wallets from the Wallet Standard registry.

// src/context/SelectedWalletAccountContextProvider.tsx
import { useEffect, useMemo, useState } from "react";
import {
  SelectedWalletAccountContext,
  type SelectedWalletAccountState,
} from "./SelectedWalletAccountContext";
import {
  getUiWalletAccountStorageKey,
  uiWalletAccountBelongsToUiWallet,
  uiWalletAccountsAreSame,
  useWallets,
  type UiWallet,
  type UiWalletAccount,
} from "@wallet-standard/react-core";

const STORAGE_KEY = "solana-wallet-standard-react:selected-wallet-and-address";

let wasSetterInvoked = false;

// Attempts to restore previously selected wallet from localStorage
function getSavedWalletAccountAndWallet(
  wallets: readonly UiWallet[]
):
  | { account: UiWalletAccount | undefined; wallet: UiWallet | undefined }
  | undefined {
  // Stop auto-selecting after user makes explicit choice
  if (wasSetterInvoked) {
    return;
  }

  const savedWalletNameAndAddress = localStorage.getItem(STORAGE_KEY);
  if (
    !savedWalletNameAndAddress ||
    typeof savedWalletNameAndAddress !== "string"
  ) {
    return;
  }

  const [savedWalletName, savedAccountAddress] =
    savedWalletNameAndAddress.split(":");

  if (!savedWalletName || !savedAccountAddress) {
    return;
  }

  // Find matching wallet and account in current connected wallets
  for (const wallet of wallets) {
    if (wallet.name === savedWalletName) {
      for (const account of wallet.accounts) {
        if (account.address === savedAccountAddress) {
          return { account, wallet };
        }
      }
    }
  }
}

export function SelectedWalletAccountContextProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const wallets = useWallets();

  const [selectedWalletAccount, setSelectedWalletAccountInternal] =
    useState<SelectedWalletAccountState>(
      () => getSavedWalletAccountAndWallet(wallets)?.account
    );

  const [selectedWallet, setSelectedWalletInternal] = useState<
    UiWallet | undefined
  >(() => getSavedWalletAccountAndWallet(wallets)?.wallet);

  // Wrapper that saves selection to localStorage
  const setSelectedWalletAccount: React.Dispatch<
    React.SetStateAction<SelectedWalletAccountState>
  > = (setStateAction) => {
    setSelectedWalletAccountInternal((prevSelectedWalletAccount) => {
      wasSetterInvoked = true;
      const nextWalletAccount =
        typeof setStateAction === "function"
          ? setStateAction(prevSelectedWalletAccount)
          : setStateAction;

      const accountKey = nextWalletAccount
        ? getUiWalletAccountStorageKey(nextWalletAccount)
        : undefined;

      if (accountKey) {
        localStorage.setItem(STORAGE_KEY, accountKey);
      } else {
        localStorage.removeItem(STORAGE_KEY);
      }

      return nextWalletAccount;
    });
  };

  // Restore saved wallet on mount
  useEffect(() => {
    const savedWalletAccount = getSavedWalletAccountAndWallet(wallets)?.account;
    const savedWallet = getSavedWalletAccountAndWallet(wallets)?.wallet;

    if (savedWalletAccount && savedWallet) {
      setSelectedWalletAccountInternal(savedWalletAccount);
      setSelectedWalletInternal(savedWallet);
    }
  }, [wallets]);

  // Keep selected account synchronized with connected wallets
  const walletAccount = useMemo(() => {
    if (selectedWalletAccount) {
      for (const uiWallet of wallets) {
        for (const uiWalletAccount of uiWallet.accounts) {
          if (uiWalletAccountsAreSame(selectedWalletAccount, uiWalletAccount)) {
            return uiWalletAccount;
          }
        }

        // If selected account's wallet is connected, use its first account
        if (
          uiWalletAccountBelongsToUiWallet(selectedWalletAccount, uiWallet) &&
          uiWallet.accounts[0]
        ) {
          return uiWallet.accounts[0];
        }
      }
    }
  }, [selectedWalletAccount, wallets]);

  const wallet = useMemo(() => {
    if (selectedWallet) {
      for (const uiWallet of wallets) {
        if (uiWallet.name === selectedWallet.name) {
          return uiWallet;
        }
      }
    }
  }, [selectedWallet, wallets]);

  // Clear selection if wallet disconnects
  useEffect(() => {
    if (selectedWalletAccount && !walletAccount) {
      setSelectedWalletAccountInternal(undefined);
    }
  }, [selectedWalletAccount, walletAccount]);

  return (
    <SelectedWalletAccountContext.Provider
      value={useMemo(
        () => [walletAccount, setSelectedWalletAccount, wallet],
        [walletAccount, wallet]
      )}
    >
      {children}
    </SelectedWalletAccountContext.Provider>
  );
}

Once our context is set up we can import and use it like so:

// src/main.tsx
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";
import { SelectedWalletAccountContextProvider } from "./context/SelectedWalletAccountContextProvider.tsx";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <SelectedWalletAccountContextProvider>
      <App />
    </SelectedWalletAccountContextProvider>
  </StrictMode>
);

Wallet List

With context set up to track wallet state, we can build the UI. Users need a way to see available wallets and connect them to our app. The Wallet Standard exposes all compatible browser wallets, so we'll create a dialog that lists them. We'll start with the wallet list item.

// features/auth/components/wallet_list_item.tsx
import { Button } from "@/components/ui/button"
import { SelectedWalletAccountContext } from "@/context/SelectedWalletAccountContext";
import { useConnect, type UiWallet } from "@wallet-standard/react-core";
import { useContext } from "react";

type Props = {
  wallet: UiWallet;
  setOpen: () => void;
};

export const WalletListItem = ({ wallet, setOpen }: Props) => {
  const [isConnecting, connect] = useConnect(wallet);
  const [_, setSelectedWalletAccount] = useContext(
    SelectedWalletAccountContext
  );

  const handleConnect = () => {
    try {
      // Connect returns array of accounts, we select the first one
      connect().then((res) => {
        setSelectedWalletAccount(res[0]);
      });
    } catch (error) {
      console.error("Failed to connect:", error);
    } finally {
      setOpen();
    }
  };

  if (!wallet) return;

  return (
    <li>
      <Button
        variant="outline"
        disabled={isConnecting}
        onClick={handleConnect}
        className="flex flex-row p-4 items-center justify-start gap-3 w-full"
      >
        <img alt="wallet logo" src={wallet.icon} className="w-6 h-6" />
        <p className="text-lg font-semibold">{wallet.name}</p>
      </Button>
    </li>
  );
};

One thing to note is that while we can fetch all wallets connected to the browser, you often only want the ones that support the chain your application is based on. To do this we can create a hook to fetch and filter these wallets for us. You can extend this to work for multiple chains if need be. Extracting this logic into a custom hook is production-grade because it encapsulates the filtering logic in a reusable, testable unit. It makes your components cleaner by separating concerns, and if you need to add more complex filtering logic later or support multiple chains, you only need to modify this one hook rather than hunting through multiple components.

// features/auth/hooks/useFilteredWallets.tsx
import { useWallets } from "@wallet-standard/react-core";

export function useFilteredWallets() {
  const wallets = useWallets();

  // Filter wallets that support Solana chains
  const solanaWallets = wallets.filter((uiWallet) =>
    uiWallet.chains.some((chain) => chain.startsWith("solana:"))
  );

  return solanaWallets;
}

Now we can implement the actual wallet list to render all connected wallets that match our base chain.

// features/auth/components/wallet_list.tsx
import { Button } from "@/components/ui/button";
import {
  DialogHeader,
  Dialog,
  DialogTrigger,
  DialogContent,
  DialogTitle,
  DialogDescription,
} from "@/components/ui/dialog";
import { WalletListItem } from "./wallet_list_item";
import { useFilteredWallets } from "../hooks/useFilteredWallets";
import { useState } from "react";

export const WalletList = () => {
  const [open, setOpen] = useState(false);
  const solanaWallets = useFilteredWallets();

  return (
    <Dialog open={open} onOpenChange={setOpen}>
      <form>
        <DialogTrigger asChild>
          <Button variant="outline">View Wallets</Button>
        </DialogTrigger>

        <DialogContent className="sm:max-w-106.25">
          <DialogHeader>
            <DialogTitle>Select Wallet</DialogTitle>
            <DialogDescription>
              Select the wallet you want to connect to Titan.
            </DialogDescription>
          </DialogHeader>

          <ul className="flex flex-col gap-2">
            {solanaWallets.map((wallet, idx) => (
              <WalletListItem
                key={idx}
                wallet={wallet}
                setOpen={() => setOpen(false)}
              />
            ))}
          </ul>
        </DialogContent>
      </form>
    </Dialog>
  );
};

Sign-In Button

Once a wallet is connected, we need to authenticate the user. This is where the full flow comes together: request nonce, sign it, send to backend. This is just going to be a simple button that triggers the auth flow.

The first thing that will happen on click is that we request a nonce from our backend. Immediately after we get the nonce we use the useSignIn hook to sign our message. We then extract the results we need and send them in our login request.

// features/auth/components/auth_buttons.tsx
import { useSignIn } from "@solana/react";
import { Button } from "@/components/ui/button";
import { requestNonce } from "../api/requestNonce";
import { loginWithWallet } from "../api/loginWithWallet";
import type { UiWallet } from "@wallet-standard/react-core";

type SignInProps = {
  address: string;
  wallet: UiWallet;
};

export const SignInButton = ({ wallet, address }: SignInProps) => {
  const signIn = useSignIn(wallet);

  if (!wallet) return;

  const handleSignIn = async () => {
    try {
      // Request nonce from backend
      const res = await requestNonce(address);

      // Sign the message with wallet's private key
      const { account, signedMessage, signature } = await signIn({
        nonce: res.nonce,
        domain: import.meta.env.VITE_APP_DOMAIN || "localhost:5173",
      });

      // Send signed data to backend for verification
      const loginResponse = await loginWithWallet({
        address: account.address,
        signatureBase58: signature,
        message: signedMessage,
        nonce: res.nonce,
      });

      // Store access token (you might want to use a state management solution)
      localStorage.setItem('access_token', loginResponse.access_token);

      console.log('Successfully authenticated!');
    } catch (error) {
      console.error("Failed to sign in:", error);
      // You might want to show this error to the user via a toast or alert
    }
  };

  return <Button onClick={handleSignIn}>Sign In</Button>;
};

Our finished App.tsx looks like this.

// App.tsx
import { useContext } from "react";
import { WalletList } from "./features/auth/components/wallet_list";
import { SelectedWalletAccountContext } from "./context/SelectedWalletAccountContext";
import { SignInButton } from "./features/auth/components/auth_buttons";

function App() {
  const [selectedWalletAccount, _, selectedWallet] = useContext(
    SelectedWalletAccountContext
  );

  return (
    <div className="flex gap-3 min-h-svh flex-col items-center justify-center">
      <div>
        <p className="text-lg font-semibold">
          Active account: {selectedWalletAccount?.address || 'None'}
        </p>
      </div>

      <WalletList />

      {selectedWalletAccount && selectedWallet && (
        <SignInButton
          address={selectedWalletAccount.address}
          wallet={selectedWallet}
        />
      )}
    </div>
  );
}

export default App;

Frontend Summary

That wraps up the frontend implementation. We've built a wallet connection system that integrates with the Wallet Standard to support any compatible Solana wallet, not just Phantom. The context provider manages wallet selection persistence across sessions, while the sign-in flow requests a nonce from the backend, prompts the user to sign it with their wallet, and sends the signed message back for verification. The private key never leaves the user's wallet, ensuring security throughout the process.

Conclusion

We've implemented a complete wallet-based authentication system for Solana. The backend generates unique nonces with Redis-backed storage, creates SIWS-compliant challenge messages, verifies signatures using Solana's cryptographic primitives, and manages JWT token generation after successful verification. The frontend leverages the Wallet Standard to support multiple wallet providers and handles the signing flow securely within the user's wallet extension.

This auth pattern is fundamentally different from traditional username/password authentication because the user proves ownership of their wallet through cryptographic signatures rather than shared secrets. The nonce prevents replay attacks, the standardized message format prevents phishing, and the time-limited Redis storage ensures old challenges can't be reused. You can extend this system by adding additional user data to the JWT payload, implementing token refresh logic, or supporting multiple blockchain networks with minimal modifications to the core flow.

Building Secure JWT Auth in NestJS: Argon2, Redis Blacklisting, and Token Rotation

David Essien — Mon, 12 Jan 2026 08:55:38 +0000

Imagine you've just watched your first tutorial on authentication. You spin up a login flow, add some JWTs, and call it done. Then you push to production and realize those tutorials skipped the hard parts—token revocation, session management, replay attacks.

It's not enough to have a login endpoint. Production auth means thinking like an attacker and handling edge cases that basic tutorials ignore. Let's talk about what actually secure authentication looks like in NestJS and how to implement it without the security holes.

When a developer says they are "implementing auth," they are usually talking about two distinct but inseparable concepts: Authentication and Authorization. When building robust systems, these go hand in hand.

Authentication (AuthN) vs. Authorization (AuthZ)

Authentication is about identity. It answers "Who are you?" using credentials like email/password, passkeys, or biometrics.
Authorization is about permissions. It answers "What can you do?" Once we know who you are, we use strategies like Role-Based Access Control (RBAC) to ensure you only touch the resources you're allowed to.

The NestJS Toolkit: Passport and Guards

In the NestJS ecosystem, we don't reinvent the wheel. We use Passport.js, the industry standard for Node.js authentication. NestJS wraps this in @nestjs/passport and provides AuthGuards.

Guards are the "bouncers" of your application. When a request hits a protected route, the Guard intercepts it, extracts the token, and validates it before the request ever reaches your controller logic.

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  constructor(
    private readonly reflector: Reflector,
    private readonly redis: RedisService,
  ) {
    super();
  }

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);

    if (isPublic) return true;

    const request = context.switchToHttp().getRequest();
    if (!request.headers['authorization']) return false;

    const token = request.headers['authorization'].split(' ')[1] as string;

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    const result = super.canActivate(context);
    return result instanceof Promise ? result : (result as boolean);
  }
}

Secure Onboarding: Why Argon2?

For sign-up, you need to store passwords. I chose Argon2 over the more common Bcrypt. Argon2 was the winner of the Password Hashing Competition for a reason: it's memory-intensive.

Unlike older algorithms, Argon2 allows you to configure memory usage, making it significantly harder to crack using specialized hardware like GPUs or ASICs. It essentially punishes brute-force attempts with slow, high-resource computation.

Registration (Hashing)

When a user signs up, the plain-text password is transformed into a hash before being stored in the database.

// UsersService
import { hash } from '@node-rs/argon2';

async create(data: CreateUserDto): Promise<User> {
  let userData = { ...data };
  if (data.password) {
    const passwordHash = await hash(data.password); //
    userData = { ...userData, password: passwordHash };
  }
  return await this.prisma.user.create({ data: userData });
}

Login (Verification)

Crucially, we never "decrypt" a password. When a user logs in:

We retrieve the stored hash from the DB.
We take the plain-text password provided in the login form.
We run the provided password through the same hashing process (including the "salt" stored within the hash).
If the resulting hash matches the stored one, the user is verified.

import { verify } from '@node-rs/argon2';

// AuthService
async validateUser(email: string, password: string): Promise<UserEntity | undefined> {
  const user = await this.usersService.findOneByEmail(email);
  if (user && user.password) {
    /* The verify function automatically creates a hash of the plain
password and compares it against our stored password hash */
    const isPasswordValid = await verify(user.password, password);
    if (isPasswordValid) return new UserEntity(user);
    throw new UnauthorizedException('Password is not valid');
  }
}

The Dual-Token Strategy

Once verified, we generate two tokens.

1. The Access Token (Short-lived & Stateless)

Signed with a secret key, this contains the user’s ID and metadata. We set this to 15 minutes. This is the industry standard because it limits the "blast radius"—if a token is stolen, it’s only useful for a tiny window.

2. The Refresh Token (Long-lived & Stateful)

Signed with a completely different secret (this is vital for security), we set this to 7 days. Unlike the access token, we store this in our database (Prisma) because it needs to be stateful. We also attach a unique JTI (JWT ID) when signing the token to allow for efficient database lookups after decoding the JWT.

By storing it, we gain a "Kill Switch." If we detect suspicious activity, we can manually revoke that specific token in the DB, preventing it from ever being used to generate a new access token. Here's how we create and store the refresh token in our database:

import { randomUUID } from 'node:crypto';

// JwtRefreshService
async create(payload: CreateRefreshTokenDto): Promise<string> {
  const tokenId = randomUUID(); // Unique ID for this token
  const refresh_token = this.jwtService.sign(
    { ...payload, jti: tokenId },
    {
      secret: this.configService.get('JWT_REFRESH_SECRET'),
      expiresIn: '7d',
    },
  );

  const hashed_refresh_token = await hash(refresh_token);

  await this.prisma.refreshToken.create({
    data: {
      id: tokenId,
      token: hashed_refresh_token,
      userId: payload.sub,
      absolute_limit_at: new Date(Date.now() + 90 * 24 * 60 * 60 * 1000), // Hard session limit
      isRevoked: false,
    },
  });

  return refresh_token;
}

Solving the "Stateless Revocation" Problem with Redis

The biggest flaw in JWTs is that they are stateless. If a user logs out, their Access Token is still technically valid until those 15 minutes are up.

To fix this without destroying performance, we use Redis.

Redis is an in-memory key-value store. Because it lives in RAM, it provides the sub-millisecond read/writes we need to check every single incoming request without slowing down the API. On logout, we "blacklist" the access token in Redis for the remainder of its lifespan. Our JwtAuthGuard then checks Redis on every request: if the token is in the blacklist, access is denied. When the user logs out, we calculate how long until the access token would naturally expire and blacklist it for exactly that duration:

// RedisService implementation
async blacklistToken(token: string, ttl: number): Promise<void> {
  await this.redis.set(`blacklist:${token}`, '1', { EX: ttl }); //
}

async isTokenBlacklisted(token: string): Promise<boolean> {
    const result = await this.redis.exists(`blacklist:${token}`);
    return result === 1;
 }

// JwtAuthGuard
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
    // existing authorization logic

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    // return result
  }
}

// Logout logic
async logout(data: { userId: string; access_token: string; refresh_token: string }) {
  const access_token_payload = await this.jwtService.verifyAsync(data.access_token);
  const ttl = access_token_payload.exp - Math.floor(Date.now() / 1000);

  if (ttl > 0) {
    await this.redisService.blacklistToken(data.access_token, ttl); //
  }
  // ... proceed to revoke refresh token
}

Refresh Token Rotation & Absolute Limits

What if a refresh token is stolen? An attacker could theoretically stay logged in for 7 days. We solve this with Refresh Token Rotation.

Every time a user uses a Refresh Token to get a new Access Token, we:

Invalidate the old Refresh Token.
Issue a brand-new Refresh Token.

The Absolute Time Limit

To prevent a session from being kept alive forever by rotation, we implement an Absolute Time Limit (e.g., 90 days). This is set at the initial login. Every time a token rotates, that original 90-day timestamp is carried forward. Once we hit that date, no more rotations are allowed—the user must log in with their password again.

// rotateRefreshToken logic
async rotateRefreshToken(payload: RotateRefreshTokenDto) {
  const { old_refresh_token_id, time_limit, sub, email, deviceInfo } = payload;

  await this.revokeRefreshToken(old_refresh_token_id); // Invalidate old

  const new_refresh_token = this.jwtService.sign(
        {
          email,
          sub,
          deviceInfo,
        },
        {
          secret: this.configService.get<string>('JWT_REFRESH_SECRET'),
          expiresIn: '7d',
        },
      );

  // Create new token record with the original time_limit
  await this.prisma.refreshToken.create({
    data: {
      token: await hash(new_refresh_token),
      userId: sub,
      absolute_limit_at: time_limit, // Carry forward absolute limit
      isRevoked: false,
    },
  });
}

  async revokeRefreshToken(token_id: string) {
    try {
      await this.prisma.refreshToken.update({
        where: {
          id: token_id,
        },
        data: {
          isRevoked: true,
        },
      });
    } catch (error) {
      if (error instanceof Prisma.PrismaClientKnownRequestError) {
        if (error.code === 'P2025') {
          throw new NotFoundException('Token not found');
        }
      }
      throw error;
    }
  }

  @Public()
  @UseGuards(JwtRefreshAuthGuard)
  @Post('refresh')
  async refresh(
    @Request()
    req: RequestType & {
      user: { email: string; id: string; refreshToken: string };
    },
    @Response({ passthrough: true }) res: ResponseType,
  ) {
    if (req.user) {
      const tokens = await this.authService.refreshTokens({
        userId: req.user.id ?? '',
        email: req.user.email ?? '',
        token: req.user.refreshToken ?? '',
      });

      res.cookie('titan_refresh_token', tokens?.refresh_token, {
        httpOnly: true,
        secure: true,
        sameSite: 'strict',
      });

      return { access_token: tokens?.access_token };
    }
  }

Reuse Detection (The "Nuclear" Option)

If a token that was already revoked is used, it signals a potential theft. The system responds by revoking all tokens for that user.

// validateToken snippet
if (storedToken?.isRevoked) {
  // Nuke 'em
  await this.prisma.refreshToken.updateMany({
    where: { userId: payload.userId },
    data: { isRevoked: true }, // Revoke all active sessions for this user
  });
  throw new UnauthorizedException('Token reuse detected. Please login again');
}

One thing to note is that while we return the access token to the user in the response body, we have to set the refresh token as a http-only cookie.

  @Post('login')
@UseGuards(LocalAuthGuard)
async login(
  @Request() req: RequestType & { user: UserEntity },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
  );

  // Securely set the Refresh Token as a cookie
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true, // Prevents JS from reading the cookie
    secure: true,   // Only sent over HTTPS
    sameSite: 'strict', // Protects against CSRF
    path: '/auth/refresh', // Optional: Only send cookie to the refresh endpoint
  });

  // Send the Access Token in the body for the frontend to store in memory
  return { access_token };
}

The reason for this is to make the refresh token invisible to the client-side javascript. Even if an attacker successfully runs a script on your page, they cannot "read" the refresh token. We also set secure: true (ensuring it's only sent over HTTPS) and sameSite: strict to protect against CSRF attacks.

As for the access token, the frontend receives it in the JSON response and typically stores it in memory (a variable). While it's still technically vulnerable to XSS, because it isn't persisted in storage, it's much harder to exfiltrate, and its short 15-minute lifespan limits the damage if it is compromised

Conclusion

At the end of the day, writing code alone doesn't build a secure authentication system. We need to constantly balance security, speed, and user experience. By thinking like an attacker, we can turn standard JWTs into a fortified system using tools like Redis and techniques like Refresh Rotation. It takes a bit more effort to set up, but the peace of mind knowing you’ve accounted for edge cases like token theft or stale sessions is well worth the complexity, especially in sensitive applications.

Summary of our Security Workflow

Memory-Hard Hashing: Used Argon2 to ensure passwords are resistant to GPU-based cracking.
Dual-Token Architecture: Balanced security with short-lived (15 min) access tokens and long-lived (7 day) refresh tokens.
Real-time Revocation: Leveraged Redis for sub-millisecond access token blacklisting upon logout.
Session Lifecycle Management: Implemented 90-day absolute time limits to ensure no session lasts forever.
Automatic Breach Detection: Enabled Refresh Token Rotation with a "nuclear" reuse detection trigger that invalidates all user sessions if a stolen token is detected.

Technical Stack Overview

Tool	Purpose	Key Feature
NestJS	Backend Framework	Modular architecture and robust dependency injection.
Passport.js	Auth Logic	Industry-standard middleware for handling JWT strategies.
Argon2	Password and Token Hashing	Memory-intensive hashing
Prisma	Database ORM	Type-safe interaction with our stateful Refresh Token storage.
Redis	In-Memory Store	Rapid read/write operations for stateless token revocation (blacklisting).
JWT	Tokenization	Secure, encoded payload delivery for AuthN and AuthZ.

Handling Cold Starts in Serverless AI: Why Your First Request Fails (And How to Fix It)

David Essien — Tue, 02 Dec 2025 10:00:00 +0000

First request to your AI model: timeout. Second request: instant success. If you've integrated AI APIs into serverless applications, you've probably hit this wall.

Here's what's happening, why it matters for user experience, and how I solved it without forcing users to manually retry.

The Problem: Cold Starts Kill First Impressions

I was testing LogicVisor (a code review platform using Gemini AI) when I noticed a pattern: after a few hours of inactivity, the first API call would consistently fail with "Model is temporarily unavailable. Please try again later". Trying again just a few seconds later always worked.

For a new user trying the platform for the first time, their experience would be:

Submit code for review
See an error message
Get told to "try again"

As you can expect, this isn't a great first experience. Even if the issue would be resolved on their second try, many would just leave.

Why This Happens: Resource Management in Serverless

On free/low-cost tiers of cloud AI services, providers deallocate resources during inactivity. When your request comes in after idle time, the model needs to "wake up":

Allocate compute resources
Load the model into memory
Initialize the runtime environment

This cold start adds latency—sometimes 2-10 seconds depending on model size. Your request times out before the model is ready.

This doesn't happen on premium tiers because you're paying for dedicated resources. But for no-cost/low-cost MVPs and proof-of-concept apps like mine, you'll deal with cold starts.

The Standard Solution: Exponential Backoff

The industry-standard approach is exponential backoff retry logic:

First retry: wait 2 seconds
Second retry: wait 4 seconds
Third retry: wait 8 seconds
Fourth retry: wait 16 seconds

This works well for distributed systems handling network congestion or database deadlocks where you don't know how long the issue will persist.

Why I Chose Linear Backoff Instead

For my specific use case, I knew:

The error was transient (always resolved on second attempt)
This was a user-facing application (waiting 16 seconds is unacceptable)
Maximum 3 retries was reasonable

Linear backoff fit better: 2s → 4s → 6s progression instead of exponential growth.

Here's the implementation:

// Helper function to call AI with linear backoff retry logic
async function callAIWithRetry(maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      // Call Gemini or Groq AI service (simplified for clarity)
      const response = await ai.models.generateContentStream({...});
      return response;
    } catch (error) {
      const errorMessage = error instanceof Error ? error.message : String(error);
      const is503Error = 
        errorMessage.includes("503") || 
        errorMessage.includes("overloaded") ||
        errorMessage.includes("temporarily unavailable");

      if (is503Error && attempt < maxRetries - 1) {
        // Linear Backoff: 2s → 4s → 6s (not exponential 2s → 4s → 8s → 16s)
        const waitTime = 2000 * (attempt + 1); 

        // Notify user via Server-Sent Events (the UX fix)
        if (!coldStartNotified) {
          controller.enqueue(
            encoder.encode(`data: ${JSON.stringify({
              type: "cold_start",
              message: "Waking up sleepy reviewer... ☕"
            })}\n\n`)
          );
          coldStartNotified = true;
        }

        console.log(`Retrying in ${waitTime}ms (Attempt ${attempt + 1}/${maxRetries})`);
        await new Promise((resolve) => setTimeout(resolve, waitTime));
        continue;
      }

      throw error; // Not a 503 or max retries exceeded
    }
  }
  throw new Error("Max retries exceeded");
}

The key differences from exponential backoff:

Fixed increment (2 seconds) instead of exponential growth
User-facing messaging during retries via Server-Sent Events
Early exit after 3 attempts to avoid hanging

Making Delays Transparent: Frontend Handling

Backend retry logic solves the technical problem, but users still experience a delay. I added cold start detection on the frontend:

const response = await submitCode(
  code,
  language,
  problemName || "Code Review",
  selectedModel,
  (content: string, eventType?: string) => {
    // Handle cold start event
    if (eventType === "cold_start") {
      setIsColdStart(true);
      setSubmitting(false);
      return;
    }

    // Handle streaming content
    setStreaming(true);
    setStreamedContent((prev) => prev + content);
  }
);

When a cold start is detected, the UI shows:

{isColdStart && (
  <div className="mb-4 p-3 bg-amber-50 dark:bg-amber-900/20 
                  border border-amber-200 dark:border-amber-800 rounded-lg">
    <p className="text-sm text-amber-800 dark:text-amber-200">
      ☕ Waking up sleepy reviewer... This may take a few extra seconds.
    </p>
  </div>
)}

This turns a confusing timeout into an understandable loading state. Users know something is happening, not that the app is broken.

Alternative Strategies (And Why I Didn't Use Them)

1. Keep-Alive Mechanisms

Set up a cron job to ping your endpoint every 5 minutes, preventing cold starts entirely.

Why I skipped it: Adds infrastructure complexity and still incurs API costs even when no real users are active.

2. Upgrade to Premium Tier

Pay for dedicated resources, eliminate cold starts.

Why I skipped it: Not viable for an MVP with zero revenue. This is the eventual solution once the platform proves itself.

Results

With linear backoff + transparent messaging:

First-time users no longer see raw error messages
Retries happen automatically and transparently
Average additional latency: ~2-4 seconds on cold starts only
Warm requests: no change in performance

Takeaway

Cold starts are an infrastructure constraint you can't eliminate on free tiers, but you can handle them gracefully:

Implement retry logic appropriate to your error pattern (linear for transient errors, exponential for unknown duration)
Make delays visible and understandable to users through status messaging
Design for the 80% case (warm starts) while handling the 20% (cold starts)

User experience isn't just about speed—it's about managing expectations during unavoidable delays.

Have you dealt with cold starts in your serverless applications? What strategy worked for you?

DEV Community: David Essien

Code Fingerprinting: Detecting Duplicate Submissions Without Losing Your Mind (or Your API Budget)

The Problem With "Identical"

Enter the Abstract Syntax Tree

Two Parsers for the Price of One

Babel Parser (for JavaScript and TypeScript)

Tree-sitter (for everything else)

The Implementation

The Simple Canonicalization (Pre-AST)

The Router

The Babel Path (JS/TS)

The Tree-sitter Path (Everything Else)

Hashing the Canonical Form

Putting It All Together in the Request Handler

Does It Actually Work?

The Tradeoffs Worth Knowing

What I Took Away From This

Why I Move AI Model Calls to the Server — Security, Performance, and Everything In Between

Table of Contents

First, Let's Establish What We're Even Choosing Between

The Case for Client-Side AI Calls

Why Client-Side AI Calls Break Down in Production

The API Key Problem

Your Prompt Engineering Is Public

You Have No Control Over Abuse

No Caching

You're Flying Blind in Production

The Case for Server-Side AI Calls

The API Key Never Touches the Client

You Control Rate Limiting

Response Caching Becomes Possible

You Can Inject Server-Side Context Into Prompts

Full Observability

The BFF Argument — One Round Trip Instead of Many

Architecture Diagrams

Client-Side AI Calls — The Problem

Server-Side AI Calls — The Solution

How This Played Out in Logicvisor

Performance — Collapsing the Waterfall

Security — API Obfuscation as a Feature

Authentication — Stateless and Seamless

Caching — Paying for Inference Once

Provider Abstraction — Switching Models Without Touching the Client

AI Response Processing — Cleaning Up the Model's Output

So Was It Ever Really a Debate?

How to Authenticate Users with Solana Wallets in NestJS

Backend

Redis Service

Auth Service

Wallet Auth Guard

Auth Controller

Backend Summary

Frontend

Wallet List

Sign-In Button

Frontend Summary

Conclusion

Building Secure JWT Auth in NestJS: Argon2, Redis Blacklisting, and Token Rotation

Authentication (AuthN) vs. Authorization (AuthZ)

The NestJS Toolkit: Passport and Guards

Secure Onboarding: Why Argon2?

Registration (Hashing)

Login (Verification)

The Dual-Token Strategy

1. The Access Token (Short-lived & Stateless)

2. The Refresh Token (Long-lived & Stateful)

Solving the "Stateless Revocation" Problem with Redis

Refresh Token Rotation & Absolute Limits

The Absolute Time Limit

Reuse Detection (The "Nuclear" Option)

Conclusion

Summary of our Security Workflow

Technical Stack Overview

Handling Cold Starts in Serverless AI: Why Your First Request Fails (And How to Fix It)

The Problem: Cold Starts Kill First Impressions

Why This Happens: Resource Management in Serverless

The Standard Solution: Exponential Backoff

Why I Chose Linear Backoff Instead

Making Delays Transparent: Frontend Handling

Alternative Strategies (And Why I Didn't Use Them)