DEV Community: Devil

I Built a Developer Trading Card Generator with Google AI Studio — Meet CodeCard Forge

Devil — Sat, 25 Apr 2026 05:04:55 +0000

I Used Google AI Studio to Mint My Developer Identity as a Collectible Card — Here's What Happened

This is a submission for the Google Cloud NEXT Writing Challenge

I want to be honest with you: I did not expect this to work.

Not "work" in the sense of running without errors. I mean work in the sense of — within a single afternoon, going from a random idea in my head to a real, deployed web application that I'm actually proud to show people. That's not how software has ever felt before. Until Google Cloud NEXT '26.

The Idea

Google AI Studio dropped a feature at NEXT '26 that lets you describe an app in plain English and watch it get built in front of you — full TypeScript, React components, API integrations, the whole thing. I'd seen the Magic: The Gathering card demo floating around. Cool, but everyone was going to write about that.

I wanted to build something that felt mine.

So I landed on this: CodeCard Forge — an app where developers mint their own identity as a collectible trading card. You enter your name, your top 3 skills, years of experience, and a one-liner bio. Gemini writes you a "Special Ability" description based on your stack. Imagen generates your avatar. And the card assigns you a rarity tier — Rare, Epic, or Legendary.

The tagline wrote itself: Mint your developer identity as a collectible.

For my own card I entered: AI Engineer, MI Engineer, DL Engineer — 1 year of experience — and a bio that says "like making machines alive."

The Prompt That Started Everything

Here's the exact prompt I typed into Google AI Studio's Build interface:

"Create an app called CodeCard Forge that generates a developer trading card. The user enters their name, top 3 skills, years of experience, and a one-line bio. Use Imagen to generate a stylized avatar/portrait for the card, and Gemini to write a fun 'special ability' description based on their skills. Style the card like a collectible trading card with stats and a rare/epic/legendary rarity tier."

I hit Run. And then I just... watched.

What Actually Surprised Me

I've used AI coding tools before. I expected something half-baked that I'd need to spend an hour fixing.

What I did not expect was how fast a complete, structured application appeared — not a snippet, not a prototype shell, but a full file tree: components/, services/, types.ts, App.tsx, deployment config and all. I was reading through the files while they were still being written.

The moment that genuinely caught me off guard was the "Thinking..." section in the Code Assistant panel. Gemini 2.5 doesn't just generate — it plans out loud. It decided on its own how to split responsibilities between Imagen (visuals) and Gemini (text/lore), how to structure the React components, and how to handle the rarity logic. I didn't tell it any of that.

The other thing: when it hit errors during generation (and it did — type mismatches, an import conflict), it caught and fixed them itself before I even saw the problem. No red screen, no Stack Overflow tab, no asking me what to do. Just: "Analyzing 10 errors... resolved."

That's new behavior. That's not autocomplete.

The Result: CodeCard Forge

The final app has:

A clean forge form on the left (name, skills, XP, bio)
A live card preview that generates on the right
Gemini-written "Special Ability" lore based on your actual stack
An Imagen-generated portrait styled to the card's rarity
Rarity tiers: Rare → Epic → Legendary (based on years of experience + skill depth)
Footer: "Art and Ability descriptions powered by Gemini AI. Stylized after Vintage CCG Rarity Standards."

I generated my own card. I got Common.

I'm choosing to take that as a challenge.

But here's the thing — look at the Special Ability Gemini wrote for me:

*Algorithmic Awakening — Converts any 'Hardware' or 'Tool' card on your field into a 'Sentient Machine' unit with Power and...

Common rarity. Legendary ability. An AI accidentally wrote the most accurate description of a self-taught developer I've ever seen. You start underestimated. You adapt. You stack.

I did not expect a card generator to say something real.

What This Means for Developers Like Me

I write code with AI. I'm not ashamed of that — I review it, I understand it, I make sure it's correct. What changed with this NEXT '26 feature isn't the code quality. It's the starting point.

Before, "I have an app idea" meant: set up the repo, configure the bundler, wire up the API client, figure out the deployment pipeline, write the boilerplate... and somewhere in there, lose the energy that sparked the idea in the first place.

Now the starting point is a deployed URL with a working app behind it. The creative work — the idea, the angle, the why — that's still yours. The scaffolding just doesn't get in the way anymore.

CodeCard Forge isn't production software. But it's a real thing that exists, that I built in an afternoon, that I can show in a portfolio and talk about in an interview. That's the shift.

Try It + Build Your Own Card

🔗 CodeCard Forge — Live Demo

Type in your stack and see what rarity you pull. If you're Legendary, you've earned it.

And if you want to build something like this yourself, the Google AI Studio Build feature is free to try at aistudio.google.com. The only cost is the idea.

Tags: #devchallenge #cloudnextchallenge #googlecloud #gemini #ai #webdev

The JWT Refresh Race Condition Nobody Talks About (v0.3.0 — Now Production Ready)

Devil — Tue, 07 Apr 2026 06:23:58 +0000

The Bug That Kept Logging Me Out

I was building a PWA with a custom Node.js backend and Supabase auth.
Everything worked fine — until users (me) kept getting randomly logged out
for no obvious reason.

No errors. No warnings. Just suddenly back at the login screen.

What Was Actually Happening

Most JWT auth setups use two refresh strategies:

Proactive — a timer fires ~1 minute before the access token expires and
refreshes it silently in the background.

Reactive — an Axios interceptor catches 401 errors and refreshes the token
when a request fails.

The problem: both fired at the same time.

Here's the exact sequence:

Proactive timer fires → sends refresh token to backend
An API call returns 401 simultaneously → interceptor also sends the same refresh token
Backend receives two requests with the same refresh token
First one succeeds → Supabase rotates the token, old one is now dead
Second one fails with 401 → interceptor hits the failure path → clears localStorage → redirects to /login

User is logged out. No error. No warning. Just gone.

Why Existing Libraries Don't Fix This

I checked axios-auth-refresh and axios-auth-refresh-queue. Both solve
concurrent 401s — multiple requests failing at the same time.

But neither coordinates with a proactive timer. They only know about
requests going through Axios. Your timer fires outside of that.

The Fix

Both the proactive timer and the reactive interceptor need to share a
single lock. If one is already refreshing, the other should join a queue
and wait for the result — not fire a second request.

I extracted this pattern into a small package:

axios-refresh-sync

npm install axios-refresh-sync@latest

import { createRefreshManager } from 'axios-refresh-sync'

const manager = createRefreshManager({
  axiosInstance: api,
  refreshEndpoint: '/api/auth/refresh',
  getAccessToken: () => localStorage.getItem('access_token'),
  getRefreshToken: () => localStorage.getItem('refresh_token'),
  setTokens: (accessToken, refreshToken) => {
    localStorage.setItem('access_token', accessToken)
    localStorage.setItem('refresh_token', refreshToken)
  },
  onRefreshFailed: () => window.location.href = '/login'
})

// Call after login or app init
manager.scheduleRefresh()

That's it. Both the timer and the interceptor now coordinate under one lock.
If one is mid-refresh, the other waits. Supabase only gets called once.

How It Works Internally

Each manager gets its own isolated lock instance containing:

acquireLock() — check if a refresh is already running
setLock(true/false) — claim or release the lock
enqueue() — join the waiting queue if locked
flushQueue() — resolve or reject everyone waiting

Both proactive and interceptor modules read from the same lock instance.
Neither can race the other. Multiple managers don't share state.

Works With Any Backend

Despite being built with Supabase in mind, the package is completely
backend agnostic. As long as your refresh endpoint accepts a refresh token
and returns new tokens, it works.

Storage is also configurable — you bring your own get/set functions,
so localStorage, cookies, or anything else works.

Update: v0.2.0 — Multi-tab sync

One gap I noticed after publishing: if a token is refreshed in Tab A,
Tab B still had the stale token in memory and would try to refresh again.

v0.2.0 fixes this using the localStorage storage event — when one tab
refreshes the token, all other tabs detect it and flush their queues
automatically with the new token. No duplicate refresh requests across tabs.

Update: v0.3.0 — Production Ready

After some sharp feedback from the community, v0.3.0 fixes several real bugs:

🔴 Critical: Interceptor Recursion Bug (Fixed)

The refresh call was using the same axios instance that had the 401 interceptor
attached. If your refresh token expired, the interceptor would catch the 401 from
the refresh endpoint and try to refresh again — infinite loop.

Fix: The library now creates a bare axios instance internally for refresh calls
with no interceptors attached.

Instance Isolation (Fixed)

Two createRefreshManager() calls previously shared the same lock and timer
state. They would corrupt each other. Each manager now gets fully isolated state.

New: `destroy()` Method

const manager = createRefreshManager({ ... })

// On logout or component teardown:
manager.destroy() // clears timer, removes interceptor, removes storage listener

New: Custom Response Parser

createRefreshManager({
  // If your backend returns different field names:
  parseTokens: (data) => ({
    accessToken: data.token,
    refreshToken: data.refresh,
  })
})

19 Tests Added

Full test suite covering concurrent 401s, timer vs interceptor race,
refresh failure, multi-instance isolation, and destroy cleanup.