DEV Community: Najmul Hasan

IndexNow in Next.js: Notify Bing and Yandex on Publish (Google Is Different)

Najmul Hasan — Sun, 08 Nov 2026 20:14:14 +0000

My blog commits each article to GitHub and Vercel redeploys. Bing and Yandex then find the new URL whenever they next crawl. IndexNow in Next.js shortens that wait: you send the URL to one endpoint the moment it changes. This article covers the key file, a protected route handler, the response codes, and why Google is not covered. Everything targets Next.js 16 (App Router) on Node.js 20.9 or newer.

The short answer

Host a key file at your site root, then POST the changed URLs with that key to https://api.indexnow.org/indexnow. According to the IndexNow documentation, participating engines share submitted URLs with each other, so one request is enough. As of mid-2026, Google is not one of them.

{
  "host": "najmulhasan.dev",
  "key": "<your key>",
  "keyLocation": "https://najmulhasan.dev/<your key>.txt",
  "urlList": ["https://najmulhasan.dev/blog/<slug>"]
}

Step 1: Create the IndexNow key and key file

The key must be 8 to 128 characters: letters, digits and dashes. The file is named after the key and contains only the key.

KEY=$(openssl rand -hex 16)   # 32 hex characters
printf '%s' "$KEY" > "public/$KEY.txt"
echo "$KEY"

Store the same value as INDEXNOW_KEY in Vercel and in .env.local. After the next deploy, https://najmulhasan.dev/<key>.txt must open in a browser and show only the key.

Put the file at the root. The docs allow a deeper location, but then the key only covers URLs under that path, and they strongly recommend the root.

Step 2: Send URLs from a Next.js route handler

Two files. A second variable, INDEXNOW_SECRET, protects your own endpoint so strangers cannot make your site send requests to IndexNow.

// lib/indexnow.ts (Next.js 16, App Router, Node.js 20.9+)
const HOST = "najmulhasan.dev";
const ENDPOINT = "https://api.indexnow.org/indexnow";

export function isOwnUrl(url: unknown): url is string {
  return typeof url === "string" && url.startsWith(`https://${HOST}/`);
}

export async function submitToIndexNow(urls: string[]) {
  const key = process.env.INDEXNOW_KEY;
  if (!key) throw new Error("INDEXNOW_KEY is not set");

  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "Content-Type": "application/json; charset=utf-8" },
    body: JSON.stringify({
      host: HOST,
      key,
      keyLocation: `https://${HOST}/${key}.txt`,
      urlList: [...new Set(urls)],
    }),
  });

  return { status: res.status, accepted: res.status === 200 || res.status === 202 };
}

// app/api/indexnow/route.ts
import { timingSafeEqual } from "node:crypto";
import { isOwnUrl, submitToIndexNow } from "@/lib/indexnow";

function authorized(request: Request): boolean {
  const secret = process.env.INDEXNOW_SECRET;
  if (!secret) return false;
  const sent = Buffer.from(request.headers.get("authorization") ?? "");
  const expected = Buffer.from(`Bearer ${secret}`);
  return sent.length === expected.length && timingSafeEqual(sent, expected);
}

export async function POST(request: Request) {
  if (!authorized(request)) {
    return Response.json({ error: "unauthorized" }, { status: 401 });
  }

  const body = await request.json().catch(() => null);
  const urls = body?.urls;
  if (!Array.isArray(urls) || urls.length === 0 || !urls.every(isOwnUrl)) {
    return Response.json(
      { error: "urls must be a non-empty array of URLs on this host" },
      { status: 400 },
    );
  }

  try {
    const result = await submitToIndexNow(urls);
    return Response.json(result, { status: result.accepted ? 200 : 502 });
  } catch {
    return Response.json({ error: "submission failed" }, { status: 500 });
  }
}

The host filter exists because IndexNow answers 422 for URLs that do not belong to the host. The Set removes duplicates. One POST can carry up to 10,000 URLs.

Submit URLs that were added, updated or deleted. That is what the protocol is for.

Step 3: Test it and read the response codes

# 1. the key file must be public and contain only the key
curl -i "https://najmulhasan.dev/$INDEXNOW_KEY.txt"

# 2. submit one URL through your route
curl -i -X POST https://najmulhasan.dev/api/indexnow \
  -H "Authorization: Bearer $INDEXNOW_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"urls":["https://najmulhasan.dev/blog/nextjs-rate-limiting-upstash-redis-serverless"]}'

The response codes, as the documentation lists them:

200: URL submitted successfully.
202: received, key validation pending.
400: invalid format.
403: key not valid (file not found, or the key is not in the file).
422: URLs do not belong to the host, or the key does not match the schema.
429: too many requests (potential spam).

Why IndexNow does not cover Google

As of mid-2026, Google does not support IndexNow, although a test was announced in October 2021. A third-party summary from June 2026 lists Bing, Yandex, Naver, Seznam and Yep as participants. That list can change, so verify it before relying on it.

For Google, keep your sitemap and use "Request indexing" in Search Console. That step is manual, because Google has no indexing API for normal pages. IndexNow only delivers the news that a URL changed. Ranking is a separate question, and I cannot tell you what any engine will rank.

Pitfalls

A 200 means received, not indexed. The documentation says the same.
Submit after the deploy is live. If you call the route when you push the commit, Vercel may still be building and the crawler gets a 404. Trigger it from a webhook or CI step that runs once the deployment has succeeded.
Only submit changes. Resubmitting unchanged URLs is how you earn a 429.
The key file is public. Treat the key as an identifier, not a secret, and protect your own endpoint with a separate value like INDEXNOW_SECRET.
What I have and have not tested. I added this to my blog's admin and tested it against a mock IndexNow server. I have not run it against the live service yet, so I make no claim about how fast any engine picks up a URL.

Summary

IndexNow needs one key file and one POST, and a single submission reaches the participating engines.
Protect your route handler with its own secret and filter URLs to your host.
Submit changed URLs only, and only after the deploy is live.
Google is not covered, so keep the sitemap and Search Console.

Next: protect routes like this one from abuse with per-IP limits in Next.js rate limiting on Vercel with Upstash Redis.

Originally published at najmulhasan.dev/blog/indexnow-nextjs-bing-yandex-indexing.

Expo React Native Pre-Launch Checklist: 6 Bugs Your Dev Client Won't Show You

Najmul Hasan — Sat, 31 Oct 2026 11:15:26 +0000

Before inviting beta testers I ran a structured audit of RailMate, my React Native/Expo app. The verdict was blunt: not ready for beta. None of the findings were architectural. They were small, ordinary bugs that stay hidden during day-to-day development because you always test the same paths in the same dev client. This Expo React Native pre-launch checklist covers the six categories, with the fix for each.

The short answer

Audit a release-like build, not the dev client. Walk every screen and every link, test every filter with real data, and look for the bugs that only appear when you stop knowing where things are.

eas build --platform android --profile preview

1. Fonts that never loaded

The app declared custom fonts, including a dedicated Bengali typeface, but nothing ever loaded them. React Native doesn't warn loudly: text just renders in the system font, and the design you think you're shipping isn't the one on screen.

// app/_layout.tsx
import { useEffect } from "react";
import { Stack } from "expo-router";
import { useFonts } from "expo-font";
import * as SplashScreen from "expo-splash-screen";

SplashScreen.preventAutoHideAsync();

export default function RootLayout() {
  const [loaded, error] = useFonts({
    "Inter-Regular": require("../assets/fonts/Inter-Regular.ttf"),
    "Inter-Bold": require("../assets/fonts/Inter-Bold.ttf"),
  });

  useEffect(() => {
    if (loaded || error) SplashScreen.hideAsync();
  }, [loaded, error]);

  if (!loaded && !error) return null;
  return <Stack />;
}

Check: every fontFamily string you use must appear in a useFonts map.

2. A menu item pointing to a screen that doesn't exist

A Profile menu entry linked to a settings route with no file behind it. In Expo Router, routes are files, so a typo or a deleted screen leaves a link that goes nowhere.

Turn on typed routes and let the compiler find these:

// app.json
{ "expo": { "experiments": { "typedRoutes": true } } }

Then run npx tsc --noEmit in CI. A link to a missing route becomes a type error.

3. A filter tab that was always empty

A "verified" tab on the community screen filtered on a condition that no record ever satisfied. Everything looked fine with a few demo rows and nobody tapped that tab with real data.

Fix: for each filter, seed data that should match it and assert the result isn't empty. A test as small as this catches it:

it("verified filter returns verified reports", () => {
  const items = [{ id: 1, verifiedCount: 3 }, { id: 2, verifiedCount: 0 }];
  expect(filterVerified(items).map((i) => i.id)).toEqual([1]);
});

4. A score displayed against the wrong scale

The trust score was stored on one range and rendered as if it were on another, so the badge showed misleading progress. Anything a user reads as "good" or "bad" needs one owner of its range:

export const TRUST_SCORE_MAX = 100;

export const trustPercent = (score: number) =>
  Math.min(100, Math.max(0, (score / TRUST_SCORE_MAX) * 100));

Import the constant in both the code that writes the score and the component that draws it.

5. A setting that can't be reached after onboarding

Language selection existed only in the first-run flow, so a user who picked the wrong language had no way back. Rule: every choice made during onboarding needs a permanent entry point in Settings, and you should reach it from a fresh install in under three taps.

6. Dead code shipped in the bundle

An old mockup file was still in the repo. It's harmless until someone imports it or the file confuses a reviewer. Find unused files with a tool instead of memory:

npx knip

What happened next

A later checklist counted sixteen issues fixed, with two blockers still open: an email sign-in link opening the website instead of the app, and a phone-number OTP flow blocked by trial-tier SMS restrictions. The first is why I now prefer typed codes over magic links; see Supabase email OTP in Next.js.

Summary

Audit a preview build, not the dev client.
Fonts: every fontFamily must be loaded.
Routes: typed routes plus tsc in CI.
Filters: test with data that should match.
Scales: one constant owns each range.
Settings: every onboarding choice needs a permanent home.
Dead code: let a tool find it.

Next: how one Postgres function keeps a website and a React Native app in sync: One Supabase RPC function for web and mobile.

Originally published at najmulhasan.dev/blog/expo-react-native-pre-launch-checklist.

Next.js 16 Async Params: Fix Route Handlers, Pages and generateMetadata

Najmul Hasan — Thu, 29 Oct 2026 23:59:50 +0000

Next.js 16 async params is the breaking change to check first when you move from 15 to 16. Next.js 15 made params, searchParams, cookies() and headers() asynchronous but still allowed synchronous access during a compatibility period. Next.js 16 removes that. I hit this while porting the blog system on my portfolio to Next.js 16. Below is the fixed version of every common call site, the codemod, and what the codemod does not convert.

The short answer

Await them. In Next.js 16, params and searchParams are Promises, and cookies(), headers() and draftMode() return Promises.

const { slug } = await params;
const { page } = await searchParams;
const token = (await cookies()).get("token");

Then run npx @next/codemod@canary next-async-request-api . and search your code for @next-codemod-error. Everything below targets Next.js 16 (App Router). On 15, synchronous access still works with a warning. On 14 it is still synchronous.

What changed, exactly

According to the Next.js upgrade guide, version 15 introduced the Async Request APIs with temporary synchronous compatibility, and Next.js 16 fully removes synchronous access. The affected APIs are:

params and searchParams in page, layout, route and default files
params and searchParams in generateMetadata and generateViewport
cookies(), headers() and draftMode() from next/headers

Route handlers

The second argument of a dynamic route handler carries params as a Promise.

// app/api/posts/[slug]/route.ts (Next.js 16, App Router)
export async function GET(
  _req: Request,
  ctx: { params: Promise<{ slug: string }> },
) {
  const { slug } = await ctx.params;
  return Response.json({ slug });
}

Pages and generateMetadata

generateMetadata and the page component both receive the same Promise-typed params, so both must await it.

// app/blog/[slug]/page.tsx (Next.js 16)
import type { Metadata } from "next";

type Props = { params: Promise<{ slug: string }> };

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  return {
    title: slug, // look up the post by slug here
    alternates: { canonical: `https://najmulhasan.dev/blog/${slug}` },
  };
}

export default async function Page({ params }: Props) {
  const { slug } = await params;
  return <h1>{slug}</h1>;
}

searchParams, cookies() and headers()

The same rule applies to searchParams and to the functions from next/headers.

// app/search/page.tsx (Next.js 16)
import { cookies, headers } from "next/headers";

type Props = { searchParams: Promise<{ page?: string }> };

export default async function Page({ searchParams }: Props) {
  const { page = "1" } = await searchParams;
  const theme = (await cookies()).get("theme")?.value ?? "dark";
  const userAgent = (await headers()).get("user-agent");
  return <p>{`page ${page}, theme ${theme}, ${userAgent}`}</p>;
}

Client component pages

A client component cannot be async. The codemod docs show React.use() for this case.

// app/blog/[slug]/page.tsx, if the page itself is a client component
"use client";
import { use } from "react";

export default function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = use(params);
  return <h1>{slug}</h1>;
}

Run the codemod, then check what it missed

The Next.js docs list this codemod for the async request APIs:

npx @next/codemod@canary next-async-request-api .

It rewrites cookies(), headers() and draftMode() calls to be awaited or wrapped with React.use(). It also rewrites property access on params and searchParams in page, layout, route and default files and in generateMetadata and generateViewport. Where it cannot convert a call site, it leaves the marker @next-codemod-error. Search for that string and fix those spots by hand.

Pitfalls

Helpers are not made async for you. The Next.js error docs say the codemod will not turn a synchronous helper that calls cookies() into an async one. Make the helper async and await it at every caller.
Third-party code. A library that reads request data synchronously inside will break. The docs suggest checking whether it has a release compatible with Next.js 15 or later.
Image routes. In Next.js 16, the image-generating function (such as opengraph-image) receives params and id as Promises. generateImageMetadata still receives synchronous params.
I have not run this exact code. I tested the call sites while porting my own blog. The snippets here are written fresh for this article.

Summary

Next.js 15 warned about synchronous params, searchParams, cookies() and headers(). Next.js 16 removes the synchronous path.
await them in pages, layouts, route handlers and generateMetadata. Use use() in client components.
Run npx @next/codemod@canary next-async-request-api ., then search for @next-codemod-error.
Sync helpers and third-party libraries are the usual leftovers.

Next: send and verify email OTP codes with route handlers and SSR cookies: Supabase Email OTP in Next.js.

Originally published at najmulhasan.dev/blog/nextjs-16-async-params.

Building an LLM-Powered GitHub Profile Scorer: Deterministic Metrics First, Model Second

Najmul Hasan — Wed, 28 Oct 2026 17:16:37 +0000

A GitHub profile is a pile of unstructured signals: repositories, READMEs, commit rhythm, a bio. Reviewers skim it for a few minutes and form an opinion that varies by reviewer and by day. I built Devfolio Analyzer to turn that skim into a structured, weighted evaluation. This article walks through the design: what the code computes itself, what it hands to an LLM, how the output is validated, and where the approach stops being trustworthy.

The short answer

Compute everything that can be computed (language percentages, streaks, presence checks) in plain code. Use the model only for judgments that don't reduce to rules, such as "is this README useful?". Force the model's output through a schema, and keep a deterministic fallback for when it fails.

The pipeline

Validate the username (1–39 alphanumeric characters or hyphens).
Fetch in parallel: user profile, repository list, recent events, contribution data.
Normalise into a compact object: top repositories, language percentages, contribution metrics, presentation flags.
Score with the model against a fixed rubric.
Combine into a weighted total, cache it, store a shareable report.

The project's own docs estimate four to eight seconds end to end, dominated by GitHub calls and model latency. I cache results for six hours, which also keeps repeat requests from burning GitHub quota and model spend.

Reduce the data before the model sees it

Sending raw API responses to a model is slow, expensive and noisy. I rank repositories by a weighted mix of stars (0.4), forks (0.3) and recency (0.3, decaying over 365 days) and keep the top six. Language breakdowns are fetched only for those six to limit API calls. Everything the model receives is a small, predictable JSON object.

Stars are a weak quality signal on their own, so this ranking can prefer a popular repo over a better one. I kept it because it's explainable, and I list it as a limitation rather than pretending otherwise.

Five dimensions, explicit weights

// lib/score.ts
import { z } from "zod";

export const WEIGHTS = {
  projectQuality: 0.3,
  consistency: 0.25,
  techStack: 0.2,
  presentation: 0.15,
  community: 0.1,
} as const;

export type Dimension = keyof typeof WEIGHTS;

const Dim = z.object({ score: z.number().min(0).max(100), feedback: z.string().min(1) });

export const LlmResult = z.object({
  projectQuality: Dim,
  consistency: Dim,
  techStack: Dim,
  presentation: Dim,
  community: Dim,
});

export function composite(r: Record<Dimension, { score: number }>): number {
  return Math.round(
    (Object.keys(WEIGHTS) as Dimension[]).reduce((sum, k) => sum + r[k].score * WEIGHTS[k], 0),
  );
}

export function label(total: number): "Excellent" | "Good" | "Fair" | "Weak" | "Poor" {
  if (total >= 85) return "Excellent";
  if (total >= 70) return "Good";
  if (total >= 50) return "Fair";
  if (total >= 30) return "Weak";
  return "Poor";
}

The weights sum to 1.0, so the composite stays on the same 0–100 scale as each dimension. Putting them in one constant means the UI, the prompt and the tests all read the same numbers.

Call the model like an API, not a chatbot

import OpenAI from "openai";

const client = new OpenAI();

async function callModel(profile: NormalizedProfile): Promise<unknown> {
  const res = await client.chat.completions.create({
    model: process.env.LLM_MODEL ?? "gpt-4o-mini",
    temperature: 0.2,
    response_format: { type: "json_object" },
    messages: [
      { role: "system", content: SYSTEM_PROMPT },
      { role: "user", content: JSON.stringify(profile) },
    ],
  });
  return JSON.parse(res.choices[0]?.message?.content ?? "{}");
}

The system prompt does three jobs: define each dimension, demand JSON only, and forbid generic advice by requiring the model to name specific repositories. It also says explicitly not to reward repository count, so a few maintained projects can outscore many abandoned ones.

Validate, then fall back

export async function scoreProfile(profile: NormalizedProfile) {
  try {
    const parsed = LlmResult.safeParse(await callModel(profile));
    if (parsed.success) return { source: "llm" as const, dimensions: parsed.data };
  } catch {
    // timeout or upstream error: fall through to the deterministic path
  }
  return { source: "fallback" as const, dimensions: deterministicScores(profile) };
}

deterministicScores uses only the computed metrics and returns no model-written feedback. A degraded answer with a clear source flag beats a 500 error, and it makes the failure visible in your logs.

Rate limit before you spend money

Anonymous callers get 5 requests per hour per IP; API-key holders get 60. The limiter runs before any GitHub or model call. The implementation is in this Upstash guide. Also verify the request body with a schema first, so malformed requests never consume quota.

What this does not do

It can't see private repositories, so developers who work mostly in private are under-represented.
Scores vary run to run. At temperature 0.2 the same profile can move by a few points after the cache expires. Lower temperature reduces variance but doesn't remove it.
Test detection is pattern matching. A file at the right path counts as tests whether or not it tests anything.
The contribution calendar isn't in GitHub's public API for arbitrary users, so I read it from the public profile page, which is fragile when the markup changes.
No validation study exists. I have not compared the scores against independent human reviewers, so treat the output as a structured prompt for a conversation, not a verdict.

Summary

Deterministic metrics first; the model only for qualitative judgment.
Weights in one constant, output validated by schema, fallback path for failures.
Cache and rate-limit to control GitHub quota and model cost.
Publish the limits; they're what make the score interpretable.

Next: the same GitHub API, used as a CMS backend: GitHub Contents API as a CMS in Next.js.

Originally published at najmulhasan.dev/blog/llm-github-profile-scorer-nextjs-serverless.

GitHub API Rate Limit in Next.js: Go From 60 to 5,000 Requests per Hour

Najmul Hasan — Mon, 26 Oct 2026 18:21:45 +0000

If your Next.js app calls the GitHub REST API without a token, GitHub counts those requests against your IP address and allows 60 per hour. That GitHub API rate limit is the first wall most apps hit, and a single page load that makes several calls reaches it fast. This is how Devfolio Analyzer, a tool that scores GitHub profiles (docs), stays under the limit: a server-side token, parallel fetches, a capped fan-out, and a clean 503 when GitHub says stop.

The short answer

Send every GitHub request from your server with a token in the Authorization header. As of October 2026, GitHub documents 60 requests per hour for unauthenticated requests and 5,000 per hour for authenticated users (GitHub docs). Read x-ratelimit-remaining and x-ratelimit-reset on every response. When remaining is 0, stop and tell your caller when to come back. The code below is written for Next.js 16 (App Router).

What one analysis costs

Devfolio validates the username, then fetches the user, the repo list, public events and the contribution calendar in parallel. It ranks the repos and keeps the top 6. Only those 6 get a per-repo language breakdown.

Counting only GitHub REST calls, that is about 9 requests per analysis. This is hypothetical arithmetic from the flow, not a measurement, and pagination adds more:

1 user
1 repo list
1 public events
6 language lookups

The contribution calendar is read from the public profile page, not the REST API, so it is not one of the 9.

Without a token, 60 / 9 is 6 analyses per hour per IP. With a token, 5,000 / 9 is about 555. That gap is the whole case for authenticating.

The top-6 cap matters too. The ranking is a weighted mix of stars 0.4, forks 0.3 and recency 0.3. Without a cap, language lookups would cost one request per repo, and a profile with 80 repos would cost 80.

Send the token from the server

Create a token with the least access that works for public data. Store it as GITHUB_TOKEN in your Vercel environment variables. Never put it in client code or in a NEXT_PUBLIC_ variable.

// lib/github.ts (Next.js 16, App Router, TypeScript)
import { z } from "zod";

export const usernameSchema = z.string().regex(/^[A-Za-z0-9-]{1,39}$/);

export class GitHubRateLimitError extends Error {
  constructor(public retryAfterSeconds: number) {
    super("GitHub rate limit reached");
  }
}
export class GitHubNotFoundError extends Error {}

async function gh<T>(path: string): Promise<T> {
  const res = await fetch(`https://api.github.com${path}`, {
    headers: {
      Accept: "application/vnd.github+json",
      "X-GitHub-Api-Version": "2022-11-28",
      Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
    },
    cache: "no-store",
  });

  if (res.status === 403 || res.status === 429) {
    const retryAfter = Number(res.headers.get("retry-after"));
    if (retryAfter > 0) throw new GitHubRateLimitError(retryAfter);
    if (res.headers.get("x-ratelimit-remaining") === "0") {
      const resetMs = Number(res.headers.get("x-ratelimit-reset")) * 1000;
      throw new GitHubRateLimitError(
        Math.max(Math.ceil((resetMs - Date.now()) / 1000), 1),
      );
    }
  }
  if (res.status === 404) throw new GitHubNotFoundError();
  if (!res.ok) throw new Error(`GitHub ${res.status} for ${path}`);
  return res.json() as Promise<T>;
}

GitHub says that when you exceed the primary limit you get a 403 or 429 with x-ratelimit-remaining at 0. It also says not to retry before the time in x-ratelimit-reset, or before retry-after seconds if that header is present. The helper follows that order.

Fetch in parallel, cap the fan-out

The three independent calls run together. The language lookups wait for the ranking, so they run second and only for the top 6.

// same file: lib/github.ts
type Repo = {
  name: string;
  full_name: string;
  stargazers_count: number;
  forks_count: number;
  pushed_at: string;
};

export async function fetchProfile(
  username: string,
  rank: (repos: Repo[]) => Repo[],
) {
  const [user, repos, events] = await Promise.all([
    gh<Record<string, unknown>>(`/users/${username}`),
    gh<Repo[]>(`/users/${username}/repos?per_page=100&sort=pushed`),
    gh<unknown[]>(`/users/${username}/events/public?per_page=100`),
  ]);

  const top = rank(repos).slice(0, 6);
  const settled = await Promise.allSettled(
    top.map((r) => gh<Record<string, number>>(`/repos/${r.full_name}/languages`)),
  );

  for (const s of settled) {
    if (s.status === "rejected" && s.reason instanceof GitHubRateLimitError) {
      throw s.reason;
    }
  }
  const languages = settled.map((s) => (s.status === "fulfilled" ? s.value : {}));
  return { user, repos, events, top, languages };
}

Promise.allSettled means one failed language lookup does not sink the whole analysis. A rate-limit error is the exception, because every later call would fail the same way, so it is rethrown.

Return a clean error when GitHub says stop

An upstream limit is not the caller's fault. My own per-IP limiter answers with 429, so I answer GitHub's limit with 503 and a Retry-After header.

// app/api/analyze/[username]/route.ts (Next.js 16: params is a Promise)
import { NextResponse } from "next/server";
import {
  fetchProfile,
  GitHubNotFoundError,
  GitHubRateLimitError,
  usernameSchema,
} from "@/lib/github";
import { rankRepos } from "@/lib/rank"; // your ranking function

export async function GET(
  _req: Request,
  ctx: { params: Promise<{ username: string }> },
) {
  const { username } = await ctx.params;
  const parsed = usernameSchema.safeParse(username);
  if (!parsed.success) {
    return NextResponse.json({ error: "invalid_username" }, { status: 400 });
  }

  try {
    return NextResponse.json(await fetchProfile(parsed.data, rankRepos));
  } catch (err) {
    if (err instanceof GitHubRateLimitError) {
      return NextResponse.json(
        { error: "github_busy" },
        { status: 503, headers: { "Retry-After": String(err.retryAfterSeconds) } },
      );
    }
    if (err instanceof GitHubNotFoundError) {
      return NextResponse.json({ error: "user_not_found" }, { status: 404 });
    }
    return NextResponse.json({ error: "upstream_error" }, { status: 502 });
  }
}

Devfolio also caches each result for 6 hours. Every cache hit is about 9 requests you do not spend.

Pitfalls

One token is one shared budget. All your visitors draw from the same 5,000 per hour. Put your own limit in front of it. Devfolio allows 5 anonymous requests per hour per IP and 60 per hour with an API key. The serverless trap is covered in my rate limiting article.
Do not build logic on an exact remaining count. Use the x-ratelimit-* headers as the source of truth, because GitHub can change limits.
Secondary limits exist. GitHub also limits bursts, so keep the fan-out bounded and never retry in a tight loop.
Private repos are invisible to this setup. The repo list above reads only the first page of 100, and more pages cost more requests.
The contribution calendar is the fragile part. Reading it from the public profile HTML adds about 800 ms, and it fails silently when the user hides private contributions.
I have not run the code above in this exact form. Test it against your own token before you ship it.

Summary

Unauthenticated GitHub API calls get 60 per hour; with a token you get 5,000 (GitHub docs, October 2026).
Keep the token on the server and read the x-ratelimit-* headers on every response.
Cap the fan-out (top 6 repos) and cache results so one analysis costs about 9 requests, not hundreds.
Return 503 with Retry-After when GitHub says stop, and put your own rate limit in front.

Next: why in-memory counters do nothing on serverless and how to fix it: Next.js rate limiting with Upstash Redis.

Originally published at najmulhasan.dev/blog/github-api-rate-limit-nextjs.

IndexNow in Next.js: Submit New Pages to Bing and Yandex (Google Is Different)

Najmul Hasan — Fri, 23 Oct 2026 14:30:49 +0000

When you publish a page, Bing and Yandex normally find it whenever their crawler gets around to it. IndexNow lets your site tell them immediately: one POST request lists the URLs that were added, changed or deleted. This guide sets up IndexNow in Next.js 16 (App Router): the key file, a submit function, a protected route handler and the response codes. It also covers the part many guides blur: Google does not take part in IndexNow.

The short answer

Host a text file named <key>.txt at the root of your site, containing the key. Then POST JSON to https://api.indexnow.org/indexnow once the page is live. According to indexnow.org, a notification sent to one participating engine is shared with the others. Those engines are Bing, Yandex, Naver, Seznam and Yep. Google is not one of them, so for Google you still rely on your sitemap and Search Console.

publish → page is live (200) → POST changed URLs to IndexNow → Bing, Yandex and partners are notified

1. Create a key and host the key file

The key must be 8 to 128 characters. I use a 32-character hex string:

KEY=$(node -p "require('node:crypto').randomUUID().replaceAll('-', '')")
printf '%s' "$KEY" > "public/$KEY.txt"
echo "INDEXNOW_KEY=$KEY"

Next.js serves everything in public/ from the site root, so the file appears at https://www.example.com/<key>.txt. Add INDEXNOW_KEY and SITE_URL (your canonical origin, for example https://www.example.com) to your environment variables. Check the file is reachable before you submit anything:

curl -i https://www.example.com/<key>.txt

The body must be exactly the key. The key is not a secret in practice, because anyone can fetch the file. It only proves you control the host.

2. A small submit function

Next.js 16, TypeScript, plain fetch, server only:

// lib/indexnow.ts
const ORIGIN = process.env.SITE_URL!; // e.g. "https://www.example.com"
const KEY = process.env.INDEXNOW_KEY!;

export async function submitIndexNow(paths: string[]) {
  const host = new URL(ORIGIN).host;
  const urlList = paths.map((p) => new URL(p, ORIGIN).toString());

  const res = await fetch("https://api.indexnow.org/indexnow", {
    method: "POST",
    headers: { "Content-Type": "application/json; charset=utf-8" },
    body: JSON.stringify({ host, key: KEY, keyLocation: `${ORIGIN}/${KEY}.txt`, urlList }),
    cache: "no-store",
    signal: AbortSignal.timeout(8000),
  });

  return { ok: res.status === 200 || res.status === 202, status: res.status, submitted: urlList.length };
}

Every URL must belong to host. One POST can carry up to 10,000 URLs, far more than a blog needs.

3. A route handler you can call after publishing

This route triggers outbound requests under your identity, so it needs the same auth as the rest of your admin:

// app/api/admin/indexnow/route.ts
import { isAdmin, sameOrigin } from "@/lib/admin-auth"; // your existing admin auth helpers
import { submitIndexNow } from "@/lib/indexnow";

export async function POST(req: Request) {
  if (!isAdmin(req) || !sameOrigin(req)) return new Response("Forbidden", { status: 403 });

  const { slugs } = (await req.json()) as { slugs?: string[] };
  const valid =
    Array.isArray(slugs) &&
    slugs.length >= 1 &&
    slugs.length <= 20 &&
    slugs.every((s) => /^[a-z0-9]+(?:-[a-z0-9]+)*$/.test(s));
  if (!valid) return Response.json({ error: "Send 1 to 20 valid slugs" }, { status: 400 });

  const result = await submitIndexNow(slugs.map((s) => `/blog/${s}`));
  return Response.json(result, { status: result.ok ? 200 : 502 });
}

The slug check means the caller can only submit URLs under /blog/. Throttle this route too; the pattern is in my Upstash rate limiting guide

4. Submit after the page is live

Order matters. Search engines fetch your key file and the URL after they receive the ping. If the deploy is still running, they may see a 404. My admin commits the article, waits until the article URL returns 200, then calls the route above. Submit new, changed and deleted URLs only, not your whole site on every deploy.

5. Read the response

From the IndexNow documentation:

200: submitted successfully.
202: received, key validation still pending.
400: invalid format.
403: key not valid (file missing, or the key is not in the file).
422: URLs don't belong to the host, or the key doesn't match the protocol schema.
429: too many requests.

You can test by hand before wiring any code:

curl -i -X POST https://api.indexnow.org/indexnow \
  -H 'Content-Type: application/json; charset=utf-8' \
  -d '{"host":"www.example.com","key":"<key>","urlList":["https://www.example.com/blog/my-post"]}'

6. What about Google?

Google does not support IndexNow (as of October 2026, verify). For Google, submit your sitemap in Search Console, link new posts from pages Google already crawls, and use "Request indexing" in the URL Inspection tool for important pages. That button is manual; there is no indexing API for normal pages. Treat the result as weeks to months, not minutes.

Pitfalls

A ping is a request, not a promise. Engines still decide whether a page deserves to be indexed.
Host must match exactly. www.example.com and example.com are different hosts. Submit the canonical one, or you get a 422.
The key file must stay reachable. A redirect, rewrite or auth gate in front of /<key>.txt causes 403s.
Don't ping on draft saves. Submit when the page is public.
Don't resubmit unchanged URLs on a loop. It adds noise and gains nothing.
Protect the route. Without auth it is an open relay to a third-party API.

What I tested

The IndexNow call in my admin passed checks against a mock IndexNow server, along with the rest of the admin's 41 API checks. I haven't run it against the live endpoint, so I'm not claiming any indexing speed. Run a single URL by hand with the curl command above first.

Summary

Host <key>.txt in public/ and POST changed URLs to api.indexnow.org/indexnow.
Submit only after the page returns 200, and only URLs on your canonical host.
Bing, Yandex, Naver, Seznam and Yep are covered. Google is not.
For Google, use a sitemap, Search Console and internal links.

Need this built or fixed in your project? I do it as a fixed-price job. Email hire@najmulhasan.dev.

Next: Supabase email OTP in Next.js with 6-digit codes.

Originally published at najmulhasan.dev/blog/indexnow-nextjs-bing-yandex.

RailMate Bangladesh: A Train Search and Live Updates App for Passengers

Najmul Hasan — Wed, 21 Oct 2026 09:50:43 +0000

RailMate Bangladesh is a railway companion app for Android, with a matching website, made for people who travel by train in Bangladesh. You can search trains between stations, see schedules, and read or share live updates such as delays and crowding. This page explains what RailMate Bangladesh does, who it suits, how to use it, and what it does not do.

The short answer

RailMate Bangladesh helps you plan a train trip and follow it. Search trains between two stations at railmatebd.com or in the Android app, then check live updates from other riders. The app is in beta (closed testing on Google Play), and the Play Store listing is coming soon.

RailMate is free to use and has no ads. It does not sell tickets. It sends you to the official Bangladesh Railway e-ticket portal, where you buy them. Always confirm times with official sources.

What RailMate Bangladesh is

RailMate Bangladesh has two parts: an Android app and a website at railmatebd.com. Both work in English and Bangla.

It does three things:

Train search. Pick two stations and see the trains between them.
Schedules. See schedule information for each train.
Live updates. See updates that riders share, such as delays and crowding, and add your own when you travel.

RailMate is an independent project. It is not affiliated with Bangladesh Railway.

Who it is for

RailMate is for anyone who takes the train in Bangladesh and wants to check their options before heading to the station. That includes regular commuters, people travelling between cities, and visitors who prefer to read in English.

Because the app and website work in Bangla too, you can use whichever language you are comfortable with. If you like to know what other riders are seeing on the way, the live updates are the part to try.

How to use RailMate Bangladesh in 3 steps

Search. Open the website or the app, choose where you are leaving from and where you are going, and look through the trains between those stations and their schedules.
Check live updates. Before you leave and while you travel, look at what riders are reporting, such as delays or crowding. If you see something useful, share it for the next passenger.
Buy your ticket on the official portal. When you have picked a train, RailMate sends you to the official Bangladesh Railway e-ticket portal. You complete the purchase there. RailMate takes no payment.

Limits

RailMate Bangladesh is a companion, not an official source. Keep these limits in mind:

It does not sell tickets. There are no tickets and no payments inside RailMate.
Schedules can change. Always confirm times with official sources before you travel.
Live updates are rider reports. Passengers share them; they are not railway announcements. Treat them as a useful signal, not a guarantee.
It is independent. RailMate is not the railway's own app and cannot speak for Bangladesh Railway.
It is in beta. The app is in closed testing, so you may meet rough edges. Your feedback helps.
The app is for Android. The website works in a browser.

FAQ

Is RailMate Bangladesh free to use?

Yes. RailMate is free to use, and it has no ads.

Is RailMate an official Bangladesh Railway app?

No. RailMate is an independent project and is not affiliated with Bangladesh Railway. Official ticketing happens on the Bangladesh Railway e-ticket portal.

Can I buy train tickets in RailMate?

No. RailMate does not sell tickets or take payments. When you are ready to buy, it sends you to the official Bangladesh Railway e-ticket portal.

Which languages does RailMate Bangladesh support?

English and Bangla, in both the app and the website.

How do I send feedback?

Email contact@najmulhasan.dev. Tell us which screen you were on and what you expected.

Summary

RailMate Bangladesh is an Android app and website for train passengers, in English and Bangla. It is free and has no ads.
Search trains between stations, see schedules, and read or share live updates such as delays and crowding.
Tickets are bought on the official Bangladesh Railway e-ticket portal; RailMate only sends you there.
It is an independent beta project, so always confirm times with official sources.

Next: more field notes and articles on the blog. All articles

Originally published at najmulhasan.dev/blog/railmate-bangladesh-train-app.

One Supabase RPC Function for Web and Mobile: Sharing Search Logic Between Next.js and React Native

Najmul Hasan — Mon, 19 Oct 2026 13:24:33 +0000

Two clients, one database, and eventually two different ideas of what a "train" is. That is what happened in RailMate: the website queried one schema shape, the mobile app queried another, and the website's version was still tied to an external API the project had decided not to depend on. The fix was to put search logic in a single Postgres function and make both clients call it. This guide shows the pattern with Supabase RPC, React Native and Next.js.

The short answer

Write the query once as a Postgres function, expose it with supabase.rpc(), generate TypeScript types from the database, and import the same types in both apps. Anything the clients disagree on becomes a compile error instead of a production bug.

Why drift happens

Each client grows its own query code: a .from("trains").select(...) chain in the app, a different one on the web. Then a column is renamed or a business rule changes (which days a train runs, which stops count), and one client is updated. Nothing fails loudly; results just differ.

Design the schema for the query, not the UI

A simplified version:

create table stations (
  id uuid primary key default gen_random_uuid(),
  name text not null
);

create table trains (
  id uuid primary key default gen_random_uuid(),
  name text not null,
  days_of_week smallint[] not null  -- days the train RUNS, ISO numbering: 1 = Mon ... 7 = Sun
);

create table train_stops (
  train_id uuid references trains(id) on delete cascade,
  station_id uuid references stations(id),
  stop_order int not null,
  arrival_time time,
  departure_time time,
  primary key (train_id, stop_order)
);

create index on train_stops (station_id, train_id);

Two decisions worth copying. First, UUID primary keys everywhere, so ids from one environment can't collide with another's. Second, days_of_week stores the days a train runs (an inclusion list) rather than the days it doesn't. Off-day lists invert silently when someone misreads them; an inclusion list reads the way the query uses it.

The function

create or replace function public.search_trains(
  p_from uuid,
  p_to   uuid,
  p_date date
)
returns table (
  train_id   uuid,
  train_name text,
  departs    time,
  arrives    time
)
language sql
stable
security invoker
set search_path = public
as $$
  select t.id, t.name, a.departure_time, b.arrival_time
  from trains t
  join train_stops a on a.train_id = t.id and a.station_id = p_from
  join train_stops b on b.train_id = t.id and b.station_id = p_to
  where a.stop_order < b.stop_order
    and extract(isodow from p_date)::smallint = any (t.days_of_week)
  order by a.departure_time;
$$;

The a.stop_order < b.stop_order condition makes sure the train visits the origin before the destination. security invoker means row-level security policies apply to the caller, which is what you want for a function exposed to clients.

Test it in the SQL editor before touching either app:

select * from search_trains('<from-uuid>', '<to-uuid>', '2026-10-20');

Generate types once, share them

npx supabase gen types typescript --project-id "$SUPABASE_PROJECT_REF" > packages/db/database.types.ts

Put the file in a shared package (or copy it into both repos in your CI step). Both clients then create a typed client:

import { createClient } from "@supabase/supabase-js";
import type { Database } from "@/db/database.types";

export const supabase = createClient<Database>(url, anonKey);

Call it from both clients

The call is identical in React Native and Next.js:

export async function searchTrains(from: string, to: string, date: string) {
  const { data, error } = await supabase.rpc("search_trains", {
    p_from: from,
    p_to: to,
    p_date: date, // "YYYY-MM-DD"
  });
  if (error) throw error;
  return data; // typed: { train_id, train_name, departs, arrives }[]
}

In the mobile app wrap it in TanStack Query for caching and retries; on the web call it from a Server Component or route handler. The function is the single source of truth; the wrappers are thin.

Pitfalls

ISO day numbering. extract(isodow ...) returns 1–7 with Monday = 1. extract(dow ...) returns 0–6 with Sunday = 0. Pick one and document it next to the column.
Changing return columns. Postgres can't create or replace a function if the return type changes. Drop and recreate in a migration, and ship a client update together.
Don't expose raw crowd data. If part of your result comes from user-submitted reports, join against an aggregated view rather than the raw reports table, so neither client can read individual submissions.
Missing data is not zero. If a train has no verified stop times, return nothing for those fields instead of guessing; let the UI say "not yet verified".

Summary

One RPC function owns the business rule; both clients call it.
Generated types turn drift into compile errors.
Store inclusion lists, use UUIDs, and index the join columns.

Originally published at najmulhasan.navicore.co/blog/supabase-rpc-web-mobile.

GitHub Contents API CMS in Next.js: Publish Markdown Without a Database

Najmul Hasan — Fri, 16 Oct 2026 16:45:50 +0000

You can publish from a browser without running a database: an admin form commits a Markdown file to your GitHub repo, and the host redeploys. This post shows that GitHub Contents API CMS pattern in Next.js 16 (App Router), the one rule that trips people up (sha), and how to handle a 409.

Status first: I built this admin and ran 41 API checks against mock GitHub, dev.to and IndexNow servers. I have not run it against the live services yet. Treat the code below as a pattern tested against mocks, not a battle-tested one.

The short answer

Commit with one request:

PUT /repos/{owner}/{repo}/contents/{path}

Send message, content (the file, base64-encoded) and branch. For an update, also send the file's current sha. A new file needs no sha. A stale sha returns 409. Show that to the editor instead of retrying blindly. After the commit, Vercel redeploys the site.

You also get git history, diffs and rollback for every edit, because the content is just files in the repo.

Set up the GitHub Contents API as a CMS

Articles are Markdown files in content/articles/<slug>.md. The admin runs on the server side of the same Next.js app, so the GitHub token never reaches the browser.

Environment variables (names only):

GITHUB_TOKEN
GITHUB_OWNER
GITHUB_REPO
GITHUB_BRANCH
SITE_ORIGIN

Use a fine-grained personal access token limited to this one repository, with Contents set to read and write (as of October 2026, verify the permission name in GitHub's settings). Never prefix it with NEXT_PUBLIC_.

Read and write a file

This is a minimal version written for Next.js 16. It is server-only code.

// lib/github-content.ts
const OWNER = process.env.GITHUB_OWNER;
const REPO = process.env.GITHUB_REPO;
const BRANCH = process.env.GITHUB_BRANCH || "main";
const base = `https://api.github.com/repos/${OWNER}/${REPO}/contents`;

function ghHeaders() {
  return {
    Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
    Accept: "application/vnd.github+json",
    "X-GitHub-Api-Version": "2022-11-28",
    "Content-Type": "application/json",
  };
}

export function isValidSlug(slug: unknown) {
  return typeof slug === "string" && /^[a-z0-9-]{1,80}$/.test(slug);
}

export async function readArticle(slug: string) {
  const res = await fetch(
    `${base}/content/articles/${slug}.md?ref=${BRANCH}`,
    { headers: ghHeaders(), cache: "no-store" }
  );
  if (res.status === 404) return null;
  if (!res.ok) throw new Error(`GitHub read failed: ${res.status}`);
  const data = await res.json();
  const markdown = Buffer.from(data.content, "base64").toString("utf8");
  return { markdown, sha: data.sha };
}

export async function writeArticle(slug: string, markdown: string, sha?: string) {
  const res = await fetch(`${base}/content/articles/${slug}.md`, {
    method: "PUT",
    headers: ghHeaders(),
    body: JSON.stringify({
      message: sha ? `Update article: ${slug}` : `Add article: ${slug}`,
      content: Buffer.from(markdown, "utf8").toString("base64"),
      branch: BRANCH,
      sha,
    }),
  });
  if (res.status === 409) return { conflict: true, sha: null };
  if (!res.ok) throw new Error(`GitHub write failed: ${res.status}`);
  const data = await res.json();
  return { conflict: false, sha: data.content.sha };
}

JSON.stringify drops sha when it is undefined, so one function handles both create and update. Validate the slug before it becomes part of a path. That regex is what stops ../ tricks.

The route handler

// app/api/admin/articles/route.ts
import { NextResponse } from "next/server";
import { cookies } from "next/headers";
import { verifySession } from "@/lib/session"; // your own signed-cookie check, not shown
import { isValidSlug, writeArticle } from "@/lib/github-content";

export async function PUT(req: Request) {
  if (req.headers.get("origin") !== process.env.SITE_ORIGIN) {
    return NextResponse.json({ error: "Bad origin" }, { status: 403 });
  }
  const store = await cookies();
  if (!verifySession(store.get("admin_session")?.value)) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const { slug, markdown, sha } = await req.json();
  if (!isValidSlug(slug) || typeof markdown !== "string" || markdown === "") {
    return NextResponse.json({ error: "Invalid input" }, { status: 400 });
  }

  try {
    const result = await writeArticle(slug, markdown, sha);
    if (result.conflict) {
      return NextResponse.json(
        { error: "File changed on GitHub. Reload before saving." },
        { status: 409 }
      );
    }
    return NextResponse.json({ sha: result.sha });
  } catch {
    return NextResponse.json({ error: "Publish failed" }, { status: 502 });
  }
}

In Next.js 15 and later, cookies() is async, hence the await. This route has no dynamic segment. If you add one, params is a Promise too. Next.js 14 is sync for both.

The sha rule and the 409

Updating a file needs the blob sha of the version you are replacing. Get it from a read (GET .../contents/{path}) and send it back with the edit.

Two details cause most bugs:

Keep the new sha. A successful PUT returns the new file sha in content.sha. Store it in the editor's state. If you keep sending the old one, the second save fails.
Do not auto-retry a 409. It means the file (or the branch) changed since you read it, for example from a second tab or a direct commit. Fetching a fresh sha and resending would silently overwrite that change. Return the 409 and let the editor reload.

Browser side:

const res = await fetch("/api/admin/articles", {
  method: "PUT",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ slug, markdown, sha }),
});
if (res.status === 409) {
  // tell the editor to reload
} else if (res.ok) {
  const data = await res.json();
  sha = data.sha; // use this on the next save
}

Pitfalls

Every save is a commit, and every commit can trigger a deploy. Keep draft: true in the front matter until the article is ready, and save less often.
UTF-8 and base64. Encode on the server with Buffer. In the browser, btoa throws on characters outside Latin-1, which includes Bangla text.
Write one file at a time. Parallel writes to the same branch can conflict. GitHub advises serial requests (as of October 2026, verify in the REST docs).
Branch protection. If the target branch requires pull requests, the direct commit is rejected. Commit to a branch that allows it.
Large files. The Contents API has size limits. Keep articles as text and store images elsewhere (as of October 2026, verify the current limits).
A missing sha on an existing file is rejected with a validation error, not a 409 (as of October 2026, verify the exact status code).
Protect the login route. Anyone who gets past the admin password can commit to your repo. Put a rate limit in front of it, as in Next.js rate limiting with Upstash Redis.
Not tested live. Everything above passed against mock servers only. Run one real commit to a scratch branch before you rely on it.

Summary

One PUT /repos/{owner}/{repo}/contents/{path} call turns a browser form into a commit, and the host redeploys.
New files need no sha. Updates need the current sha, and you must store the new one after each save.
Treat 409 as "someone changed this". Show it, do not retry blindly.
Keep the token server-side and scoped to one repo. Validate the slug before building the path.

Next: if you want a 6-digit code login for an admin or app instead of a password, here is the Supabase version. Supabase Email OTP in Next.js.

Originally published at najmulhasan.navicore.co/blog/github-contents-api-cms-in-next-js-publish-markdown-without-a-database.

Rate Limiting Next.js API Routes with Upstash Redis (and Why In-Memory Fails on Serverless)

Najmul Hasan — Fri, 16 Oct 2026 09:10:13 +0000

Every public endpoint you ship — a contact form, a newsletter signup, an OTP sender — will be hit by bots within days. Next.js rate limiting is the cheapest defence, but the version most tutorials show does nothing once you deploy to serverless. This article covers the pattern I use in production on Vercel with Upstash Redis, the numbers behind my limits, and the failure mode to avoid.

The short answer

Store counters in Redis, not in your function's memory. Use @upstash/ratelimit with a sliding window, key it by whatever the attacker cannot rotate (IP for anonymous forms, email for code verification), and return 429 with Retry-After.

Why an in-memory Map fails on serverless

This looks correct and works on your laptop:

// Does nothing useful in production.
const hits = new Map<string, number[]>();

export function allow(ip: string, max = 5, windowMs = 600_000) {
  const now = Date.now();
  const recent = (hits.get(ip) ?? []).filter((t) => now - t < windowMs);
  recent.push(now);
  hits.set(ip, recent);
  return recent.length <= max;
}

On serverless platforms such as Vercel, requests can be served by different function instances, instances are created and destroyed on demand, and none of them share memory. Your counter lives in one instance; the attacker's next request will often land on another with an empty counter. The limiter never trips.

You need state that outlives and spans instances. Redis is the standard answer, and Upstash's HTTP-based client works in serverless and edge runtimes without connection pooling headaches.

Setup

npm i @upstash/ratelimit @upstash/redis

Create a database in the Upstash console and add the REST credentials to your environment:

UPSTASH_REDIS_REST_URL=...
UPSTASH_REDIS_REST_TOKEN=...

One helper, several limiters

// lib/rate-limit.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

if (process.env.NODE_ENV === "production" && !process.env.UPSTASH_REDIS_REST_URL) {
  throw new Error("UPSTASH_REDIS_REST_URL is required in production");
}

const redis = Redis.fromEnv();

export const limiters = {
  contact:   new Ratelimit({ redis, prefix: "rl:contact",    limiter: Ratelimit.slidingWindow(5, "10 m") }),
  otpSend:   new Ratelimit({ redis, prefix: "rl:otp-send",   limiter: Ratelimit.slidingWindow(3, "10 m") }),
  otpVerify: new Ratelimit({ redis, prefix: "rl:otp-verify", limiter: Ratelimit.slidingWindow(5, "10 m") }),
};

export function clientIp(req: Request): string {
  return req.headers.get("x-forwarded-for")?.split(",")[0]?.trim() || "unknown";
}

The prefix keeps each limiter's keys separate, so a noisy contact form can't burn an OTP user's budget. On Vercel the platform sets x-forwarded-for; if you sit behind other proxies, make sure only your trusted proxy can set that header or the key is spoofable.

Use it in a route handler

// app/api/contact/route.ts
import { NextResponse } from "next/server";
import { clientIp, limiters } from "@/lib/rate-limit";

export async function POST(req: Request) {
  const { success, limit, remaining, reset } = await limiters.contact.limit(clientIp(req));

  const headers: Record<string, string> = {
    "X-RateLimit-Limit": String(limit),
    "X-RateLimit-Remaining": String(remaining),
    "X-RateLimit-Reset": String(Math.ceil(reset / 1000)),
  };

  if (!success) {
    const retryAfter = Math.max(1, Math.ceil((reset - Date.now()) / 1000));
    return NextResponse.json(
      { error: { code: "RATE_LIMIT_EXCEEDED", message: "Too many requests. Try again later." } },
      { status: 429, headers: { ...headers, "Retry-After": String(retryAfter) } },
    );
  }

  // validate body, send the email...
  return NextResponse.json({ ok: true }, { headers });
}

Run the limiter before validation and any paid call (email, LLM, database write). Rejected requests should cost you almost nothing.

Pick the key the attacker can't rotate

Endpoint	Key	Reason
Contact form	IP	No identity exists yet
OTP send	IP, plus email	IP stops one attacker; email stops mailbox flooding from many IPs
OTP verify	Email	An attacker can rotate IPs but cannot change the victim's email

The arithmetic behind "5 attempts per 10 minutes"

A 6-digit code has 1,000,000 possibilities. With no limit, an attacker making a hypothetical 100 guesses per second tries 360,000 codes in an hour — 36% of the space. With five verify attempts per 10 minutes, the same attacker gets 30 guesses an hour: 30 in 1,000,000, or 0.003%. Check your auth provider's code lifetime and size the window against it.

Fail open or fail closed?

If Redis is unreachable, limit() throws. Decide per endpoint:

try {
  const res = await limiters.otpVerify.limit(email.toLowerCase());
  if (!res.success) return tooMany(res);
} catch (err) {
  console.error("rate limiter unavailable", err);
  return NextResponse.json({ error: { code: "UPSTREAM_ERROR" } }, { status: 503 }); // auth: fail closed
}

For a contact form I fail open and log, because losing a lead is worse than letting a few extra messages through. For authentication endpoints I fail closed.

Test it

for i in $(seq 1 7); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST https://your-site.com/api/contact \
    -H "content-type: application/json" -d '{}'
done

The first five return whatever your validation returns for an empty body (for example 400). The sixth and seventh return 429.

The in-memory fallback trap

Many projects keep an in-memory fallback "so it still works without Redis." That is fine for local development and harmful in production, because it silently provides no protection. My own website backend ships such a fallback; the guard at the top of rate-limit.ts above is how I make a missing credential a deploy error instead of a quiet hole.

Summary

In-memory counters don't work across serverless instances; use Redis.
Use sliding windows, a prefix per limiter, and keys the attacker can't rotate.
Return 429 with Retry-After, and run the limiter before expensive work.
Decide fail-open vs fail-closed deliberately for each endpoint.

Next up: the same limiter protecting a 6-digit email OTP flow with Supabase.

Originally published at najmulhasan.navicore.co/blog/nextjs-rate-limiting-upstash-redis-serverless.

Supabase Email OTP in Next.js: 6-Digit Codes Instead of Magic Links

Najmul Hasan — Fri, 16 Oct 2026 00:11:43 +0000

Magic links are the default in Supabase email sign-in, and they break in exactly the places you don't test: in-app browsers, email clients that pre-fetch links, and mobile apps where the link opens your website instead of your app. In RailMate, an email sign-in link opening the website instead of the mobile app was one of the open issues in a pre-beta checklist. A 6-digit code avoids deep links entirely: the user reads it in their mail app and types it where they started. Here is how to implement Supabase email OTP in Next.js.

The short answer

Change the email template to print {{ .Token }}, call signInWithOtp to send the code, then call verifyOtp with type: "email" to create the session. Rate-limit verification per email address.

1. Change the email template

In the Supabase dashboard go to Authentication → Email Templates → Magic Link and replace the link with the token:

<h2>Your sign-in code</h2>
<p>Enter this code to continue:</p>
<p style="font-size:28px;letter-spacing:6px"><strong>{{ .Token }}</strong></p>
<p>It expires soon. If you didn't request it, ignore this email.</p>

If the template still contains {{ .ConfirmationURL }}, users receive a link and the code flow looks broken. Also configure custom SMTP (Resend, Postmark, SES). The default sender is intended for testing and is heavily rate-limited.

2. A server client that handles cookies

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export function createClient() {
  const cookieStore = cookies();
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll: () => cookieStore.getAll(),
        setAll(list) {
          try {
            list.forEach(({ name, value, options }) => cookieStore.set(name, value, options));
          } catch {
            // Called from a Server Component; middleware refreshes the session instead.
          }
        },
      },
    },
  );
}

3. Send the code

// app/api/auth/send-otp/route.ts
import { NextResponse } from "next/server";
import { z } from "zod";
import { createClient } from "@/lib/supabase/server";
import { clientIp, limiters } from "@/lib/rate-limit";

const Body = z.object({ email: z.string().email().max(254) });

export async function POST(req: Request) {
  const ip = await limiters.otpSend.limit(clientIp(req));
  if (!ip.success) return NextResponse.json({ error: { code: "RATE_LIMIT_EXCEEDED" } }, { status: 429 });

  const parsed = Body.safeParse(await req.json().catch(() => null));
  if (!parsed.success) return NextResponse.json({ error: { code: "INVALID_EMAIL" } }, { status: 400 });

  const supabase = createClient();
  const { error } = await supabase.auth.signInWithOtp({
    email: parsed.data.email.toLowerCase(),
    options: { shouldCreateUser: true },
  });
  if (error) console.error("send-otp", error.message);

  // Same response whether or not the email exists or sending failed: no account enumeration.
  return NextResponse.json({ ok: true });
}

4. Verify the code

// app/api/auth/verify-otp/route.ts
import { NextResponse } from "next/server";
import { z } from "zod";
import { createClient } from "@/lib/supabase/server";
import { limiters } from "@/lib/rate-limit";

const Body = z.object({
  email: z.string().email().max(254),
  token: z.string().regex(/^\d{6}$/),
});

export async function POST(req: Request) {
  const parsed = Body.safeParse(await req.json().catch(() => null));
  if (!parsed.success) return NextResponse.json({ error: { code: "INVALID_CODE" } }, { status: 400 });

  const email = parsed.data.email.toLowerCase();
  const rl = await limiters.otpVerify.limit(email); // keyed by email, not IP
  if (!rl.success) return NextResponse.json({ error: { code: "RATE_LIMIT_EXCEEDED" } }, { status: 429 });

  const supabase = createClient();
  const { error } = await supabase.auth.verifyOtp({ email, token: parsed.data.token, type: "email" });
  if (error) return NextResponse.json({ error: { code: "INVALID_CODE" } }, { status: 401 });

  return NextResponse.json({ ok: true }); // session cookies were set by the server client
}

Key the verify limiter on the email. An attacker can rotate IPs for free but can't change the account they're targeting. The limiter implementation and the numbers are in the Upstash rate limiting guide.

5. Keep the session fresh with middleware

// middleware.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function middleware(request: NextRequest) {
  let response = NextResponse.next({ request });
  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        getAll: () => request.cookies.getAll(),
        setAll(list) {
          list.forEach(({ name, value }) => request.cookies.set(name, value));
          response = NextResponse.next({ request });
          list.forEach(({ name, value, options }) => response.cookies.set(name, value, options));
        },
      },
    },
  );
  await supabase.auth.getUser(); // refreshes the token if needed
  return response;
}

export const config = { matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"] };

Pitfalls

Users get a link, not a code. The template still contains {{ .ConfirmationURL }}.
Account enumeration. Returning "no such user" from the send endpoint lets anyone test which emails are registered. Always return { ok: true }.
Unlimited guesses. A 6-digit code has 1,000,000 values; without a verify limit a fast script covers a large share of them within the code's lifetime. Five attempts per 10 minutes per email caps it at 30 guesses an hour.
Trusting the client. Use getUser() on the server for authorization decisions, not the session object read from cookies.
Phone OTP is a separate problem. SMS providers have their own restrictions; for instance, trial tiers can limit delivery to verified numbers, which blocks real users in testing and launch.

Summary

Template {{ .Token }} → signInWithOtp → verifyOtp({ type: "email" }).
Same response for every send request; rate-limit by IP on send and by email on verify.
Run middleware so sessions refresh, and authorize with getUser().

Originally published at najmulhasan.navicore.co/blog/supabase-email-otp-nextjs-6-digit-code.

I Built an AI Tool That Analyzes GitHub Profiles & Developer Portfolios

Najmul Hasan — Thu, 09 Apr 2026 23:32:29 +0000

I built an AI tool that analyzes your GitHub & portfolio like a recruiter.

Most developers think their GitHub profile is “fine”.

It has repos.

It has commits.

Maybe even some stars.

But when someone actually reviews it — especially a recruiter — the experience is very different.

They’re not counting commits.
They’re scanning for signal.

And most profiles don’t communicate it clearly.

The problem

A GitHub profile is supposed to represent your work.

But in reality:

Important projects are buried
READMEs are incomplete or unclear
Contribution activity looks inconsistent
Tech stack is hard to understand at a glance
Portfolio sites look good but say very little

From the outside, it’s hard to quickly answer:

“Is this developer actually strong?”

And from the developer side, it’s even harder to see your own blind spots.

So I built something to solve this

I built Devfolio Analyzer — a tool that evaluates GitHub profiles and developer portfolios and turns them into a structured, readable signal.

👉 Live: https://devfolioanalyzer.vercel.app
👉 Docs: https://devfoliodocs.vercel.app

The goal is simple:

Show how your profile actually reads to someone else.

What it does

You enter a GitHub username.

The system:

Fetches public GitHub data
Extracts meaningful signals
Normalizes them into structured data
Runs an AI-based evaluation
Returns a scored report with feedback

What it evaluates

Instead of vanity metrics, it focuses on five core areas:

1. Project quality

README clarity
Repo structure
Presence of tests
CI/CD setup
Commit quality

2. Tech stack signal

Languages used
Framework detection
Recency of technologies

3. Contribution consistency

Activity patterns
Streaks and gaps
Recent momentum

4. Portfolio presentation

Profile README
Pinned repos
Bio and links
Overall clarity

5. Community engagement

PRs to external repos
Issue activity
Open-source participation

Example output

Instead of vague feedback, you get something like:

Score: 78 / 100
Label: Good

Issues:

Inconsistent recent activity
Weak README structure in top repos
Profile presentation not aligned with project quality

Suggestions:

Improve top repo documentation
Add clearer profile messaging
Reorganize pinned repositories

Why this matters

Most developers optimize the wrong things:

stars
repo count
follower numbers

But those don’t tell the full story.

What actually matters:

clarity
consistency
presentation
real project quality

Because that’s what people look for when they evaluate you.

How it’s built (quick overview)

Frontend: Next.js + Tailwind
Backend: API routes
Data: GitHub REST API
AI: LLM-based scoring pipeline
Cache: Redis (Upstash)
Deployment: Vercel

Everything runs serverless — no separate backend needed.

Some limitations (important)

This isn’t magic.

Only public GitHub data is analyzed
Private work is invisible
LLM scoring has small variations
Code quality is inferred, not executed

The goal is not perfection — it’s clarity.

What I learned building this

Two things stood out:

1. Most profiles are harder to read than people think

Even strong developers often have weak presentation.

2. Signal is different from activity

You can be active and still look unclear.
You can have fewer repos and look stronger.

If you want to try it

👉 LINK

Run your profile through it and see what shows up.

You’ll probably notice things you didn’t expect.

I’d really like feedback

If you try it, I’d love to know:

Does the score feel fair?
Is the feedback actually useful?
What feels missing or inaccurate?

This is still evolving, and real feedback matters more than assumptions.

Final thought

Your GitHub profile is more than a code dump.

It’s how your work is interpreted.

And small improvements there can make a big difference.