DEV Community: Najmul Hasan

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.