DEV Community: Jeason Li

How I Built an AI Image Editor with Next.js 16 + OpenRouter (Gemini) + Supabase Auth

Jeason Li — Sat, 24 Jan 2026 09:47:55 +0000

I’ve been building Image Banana — a web-based AI image editor where you can upload a photo and describe edits in plain English (for example: “replace the background with a snowy mountain”, “keep the same character, change the outfit”, “make it golden hour”).

site：https://www.my-nano-banana.com/

This post walks through the architecture and a few implementation details that made the product feel “real” quickly:

Image-to-image editing and text-to-image generation
One-shot editing (one prompt -> final output)
Batch processing (multiple inputs) as a premium feature
A guest trial: 1 generation without signing up, then prompt Google sign-in
A simple credits + subscription model

If you want to try it live, replace the placeholders below with your domain and deploy it.

Product Decisions That Shaped the Code

Before writing code, I forced myself to answer:

1) What does the “happy path” look like in under 30 seconds?
2) What’s the minimum gating needed to prevent abuse, without killing the first-run experience?
3) Which features should be paid (and why)?

That led to:

Guest trial: let people generate once without login.
Batch mode: premium because it’s costlier and easier to abuse.
Clear error UX: show “why” (credits, subscription required, missing inputs) rather than “something went wrong”.

High-Level Architecture

The app is a standard Next.js App Router stack:

UI: components/image-editor.tsx (client component)
Generation API: app/api/generate/route.ts (Node runtime)
Auth:
- Start OAuth: app/auth/login/route.ts
- Callback: app/auth/callback/route.ts
Billing primitives: lib/billing/* (supports Supabase-backed billing, with a local JSON fallback for dev)

The core request flow:

1) Browser collects prompt + optional uploaded image(s)
2) POST to /api/generate
3) Server calls OpenRouter (Gemini image models) and extracts returned image URLs
4) UI renders returned image(s) and offers download / “edit again”

Image Generation via OpenRouter (Gemini)

At a high level, the server makes a chat/completions request with modalities ["image","text"].

Implementation notes:

Timeouts matter (don’t let requests hang forever).
Be strict with payload validation: missing prompt, missing reference image in image-to-image mode, etc.
When the model returns images, you typically get hosted URLs (not base64). Your UI needs to treat them as remote URLs.

Minimal (simplified) request shape:

const res = await fetch("https://openrouter.ai/api/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
    "Content-Type": "application/json",
    "HTTP-Referer": process.env.OPENROUTER_HTTP_REFERER ?? "http://localhost:3000",
    "X-Title": process.env.OPENROUTER_X_TITLE ?? "image-banana",
  },
  body: JSON.stringify({
    model: "google/gemini-2.5-flash-image",
    modalities: ["image", "text"],
    messages: [
      {
        role: "user",
        content: [
          { type: "text", text: prompt },
          ...(imageUrl ? [{ type: "image_url", image_url: { url: imageUrl } }] : []),
        ],
      },
    ],
  }),
})

Guest Trial: “One Free Generation” Without Login

The UX goal: let users try the product immediately.

The abuse-prevention goal: don’t give unlimited free generations.

I implemented guest trial as:

Client-side: a localStorage flag for fast UI gating (image-banana-guest-trial-used)
Server-side: an HTTP cookie (ib_guest_trial_generate_v1) so the API is the source of truth

This way, even if someone clears localStorage, the API still enforces the “one free generation” rule.

On the server (/api/generate), the logic looks like:

If not logged in:
- if batch image-to-image -> 401 (auth required)
- if trial cookie already set -> 401 (trial exhausted)
- else allow exactly one request, then set the trial cookie

And the client reacts to 401 by opening a sign-in dialog or redirecting to /auth/login.

Batch Processing as a Premium Feature

Batch mode is great UX, but it’s also a cost multiplier.

I made it premium by checking entitlements:

Batch requires an active subscription
Single requests consume credits
In a batch, if some items fail, refund the credits for failed items (so you only pay for successes)

This “refund failed items” detail is small, but it prevents a lot of frustration.

Google Sign-In with Supabase Auth (Avoiding Open Redirects)

OAuth flows love to break in subtle ways. One place I’m careful: the next parameter.

If you accept an arbitrary next URL, attackers can create “open redirect” links.

So the auth routes sanitize next:

must start with /
must not start with //
if invalid -> fall back to /

Then the login route starts the Supabase Google flow and redirects back to:

/auth/callback?next=<safe_next>

Billing: Credits + Subscriptions (with a Local Dev Fallback)

I wanted billing logic I could run locally without setting up every external dependency immediately.

So the project supports:

Supabase-backed billing when SUPABASE_SERVICE_ROLE_KEY is present
Local billing otherwise (.local/billing.json)

That gives you a nice dev experience:

run the UI
test credits/subscriptions
only wire webhooks/payments when you’re ready

SEO Cold Start Checklist (So You Don’t Launch Invisible)

If you’re shipping a product site, SEO isn’t “later” — it’s launch-critical. I added:

robots.txt with sensible disallows and a sitemap pointer
a single sitemap source (/sitemap.xml)
page-specific title/description on key pages
hreflang alternates for locales
default noindex for mirrored locales (until translations are real)

Even a basic setup helps you avoid the most common cold-start traps.

What I’d Improve Next

Real translations for /zh and /ko (or remove them until ready)
Better prompt presets per use case (product shots, portraits, UGC, etc.)
A job queue for long-running generations + webhooks
Real background removal (current clone has a mocked tool page)

If You Want to Build Your Own Version

If you want to replicate the core stack, you’ll need:

Node.js >= 20.9
OpenRouter API key
Supabase project + Google OAuth enabled
A payment provider (this project uses Creem)

And then start from:

/generator (the main product surface)
/api/generate (the core API)

If you’re building something similar, I’d love to hear:

How you gate free usage without ruining first-run UX
Whether you prefer “credits” vs “subscription-only” for image tools
What you consider “must-have” editing features beyond background replacement

Building a Minimal Flip Clock in the Browser (Astro + React)

Jeason Li — Sat, 24 Jan 2026 09:43:39 +0000

I wanted a big, clean clock I could keep on a second screen during meetings (and occasionally full-screen on a TV). Most clock sites are either too busy or not quite the style I wanted, so I built my own:

Live site: https://www.uni-datetime.site/

This post is a quick walkthrough of the technical approach and a few lessons learned while getting the flip animation to feel "right".

What I built

Uni Datetime is a minimal flip clock web page:

Large flip digits (HH:MM:SS)
Date above time
Light/Dark mode
12/24-hour toggle
Fullscreen toggle (ESC exits fullscreen)

Time and timezone are derived from the browser/system timezone, so if you change your browser timezone (or simulate one in DevTools), the displayed time changes accordingly.

Stack

I kept it simple and static:

Astro for a fast, static build
React for the interactive clock "island"
Luxon for date/time formatting

Astro gives me a tiny HTML shell and bundles a React component for the clock UI and controls.

The flip digit: two halves + two animated layers

The flip effect comes from rendering four layers:

upper (static top half)
lower (static bottom half)
flip-upper (animated top half that flips down)
flip-lower (animated bottom half that flips in)

Visually, the key is: the flip uses the old value until the midpoint, then reveals the new value.

In React, each digit keeps current and next values, plus a play flag for the CSS animation:

const FLIP_MS = 600;

function FlipDigit({ value }: { value: string }) {
  const [play, setPlay] = useState(false);
  const [current, setCurrent] = useState(value);
  const [next, setNext] = useState(value);

  useLayoutEffect(() => {
    if (value === current) {
      setNext(value);
      setPlay(false);
      return;
    }

    // Start flip from current -> value
    setNext(value);
    setPlay(true);

    const t = window.setTimeout(() => {
      setCurrent(value);
      setPlay(false);
    }, FLIP_MS);

    return () => window.clearTimeout(t);
  }, [value, current]);

  return (
    <div className={`flip-digit${play ? " play" : ""}`}>
      <div className="upper"><span>{play ? next : current}</span></div>
      <div className="lower"><span>{current}</span></div>
      <div className="flip-upper"><span>{current}</span></div>
      <div className="flip-lower"><span>{next}</span></div>
    </div>
  );
}

And the CSS animation is split into two phases (top flips first, then bottom):

.flip-digit { perspective: 1000px; }

.flip-upper { transform-origin: bottom; }
.flip-lower { transform-origin: top; transform: rotateX(90deg); }

.flip-digit.play .flip-upper { animation: flipUpper 0.3s ease-in forwards; }
.flip-digit.play .flip-lower { animation: flipLower 0.3s ease-out 0.3s forwards; }

@keyframes flipUpper { to { transform: rotateX(-90deg); } }
@keyframes flipLower { to { transform: rotateX(0deg); } }

Keeping it smooth (and avoiding "new value flips first")

The most common bug I hit: the digit briefly shows the new number on the top half before the flip starts, which ruins the illusion.

The fix was to:

Treat the currently-rendered value (current) as authoritative for the static lower half
Only update current after the flip finishes
Use a layout effect (useLayoutEffect) so DOM updates and animation class toggles happen without visible flicker

Preferences: theme + 12/24 format

Preferences are simple:

Store theme and format in localStorage
Apply theme via document.documentElement.dataset.theme
Format time via Luxon:
- HHmmss for 24-hour
- hhmmss + a for 12-hour + AM/PM

I also used tabular numbers (font-variant-numeric: tabular-nums) to prevent digit width jitter.

Fullscreen toggle

Fullscreen is handled with the standard Fullscreen API (requestFullscreen / exitFullscreen). ESC exits fullscreen by browser default; the app just listens for fullscreenchange to keep the button label in sync.

Accessibility and motion

Flip animations look great, but not everyone wants them:

If prefers-reduced-motion: reduce is set, the animated layers are hidden and the clock becomes a static digit update.

Small SEO baseline (for a single-page tool)

Even for a simple tool, it's worth adding:

A good <title> and meta description
A canonical URL
A sitemap.xml

Next on my list: OpenGraph/Twitter cards and JSON-LD (structured data) so links look better when shared.

Try it / feedback

If you have thoughts on the animation timing, typography, or anything you'd like to see added, I'd love feedback:

https://www.uni-datetime.site/