DEV Community: MrLong

Vercel /api works in production but returns 404 in Vite? Here's my local fix

MrLong — Fri, 30 Oct 2026 08:59:18 +0000

I was testing a Vue 3 + Supabase + Stripe flow locally. The frontend loaded and signup worked, but clicking Upgrade returned a 404 for /api/create-checkout-session.

The endpoint worked on Vercel. The mismatch was the local runtime: vite dev serves the frontend and HMR, but it does not execute files in Vercel's /api directory.

There are two reasonable fixes:

Run vercel dev and use Vercel's local runtime.
Run a small Node server for the API handlers, then proxy /api from Vite to that server.

I chose the second option so local testing uses the same handler files as deployment. The request path is:

Browser → Vite :5173 → /api proxy → local Node shim :5175 → same handler

The Vite proxy is small:

server: {
  proxy: {
    '/api': {
      target: 'http://localhost:5175',
      changeOrigin: true,
    },
  },
},

The shim routes known paths to the actual handler modules. It adapts Node request/response objects to the shape those handlers expect, rather than maintaining a second copy of checkout or webhook logic.

Two details took longer to catch than the proxy itself:

Load .env before importing handlers. The handlers read Stripe and Supabase variables at module load time, so loading .env afterward is too late.
Preserve the webhook's raw request body. Stripe signature verification uses the original bytes; parsing and re-serializing the body can invalidate an otherwise correct signature.

I run the frontend and API shim separately:

npm run dev
npm run dev:api

Then I test checkout with Stripe test mode and confirm the webhook updates the Supabase subscription row. The live demo is also a sandbox and does not charge a real card.

I wrote up the implementation and tradeoffs in this step-by-step guide.

The Vue 3 + Supabase + Stripe source kit includes the local API shim and notes. It is a separate one-time $29 purchase; the live demo is only a test-mode sandbox.

Disclosure: AI assistance was used to prepare this wording; the project and implementation are mine.

Supabase RLS for SaaS Billing: Keep Stripe Subscription Status Server-Side

MrLong — Fri, 30 Oct 2026 07:30:38 +0000

When adding subscriptions to a Supabase app, the browser should never decide that a user is paid. Keep billing state on the server and use Row Level Security (RLS) to limit what each signed-in user can read.

A common source of confusion is assuming that an “update your own profile” policy makes every field on that row safe to edit. RLS policies control which rows a query can affect; PostgreSQL grants control which actions a role can perform. Billing fields such as subscription_status should be written only by trusted server-side code.

The risky pattern

Imagine a profiles table with an owner-scoped update policy and a broad table grant:

create policy "users update own profile"
  on public.profiles for update
  using (auth.uid() = id)
  with check (auth.uid() = id);

grant select, insert, update, delete
  on public.profiles to anon, authenticated;

That policy answers “which row?” It does not make subscription_status an approved column. A signed-in user who can update their own row could try to change that field from the client.

Keep billing writes server-side

If the browser only needs to read a user’s profile, a narrower permission setup is easier to reason about. Keep an owner-scoped SELECT policy in place, remove direct table writes from normal client roles, and let trusted server code process billing updates:

revoke all on public.profiles from anon, authenticated;
grant select on public.profiles to authenticated;
grant all on public.profiles to service_role;

This SQL changes table privileges; it does not create the SELECT policy. Keep a policy such as auth.uid() = id for profile reads. If users need editable fields, grant only those specific columns and keep subscription fields outside that allowlist. Adapt the grants to your schema and any signup flow that inserts profiles.

The Supabase service role key must stay on the server and must never be included in a frontend bundle. In a Stripe integration, update billing state after verifying the webhook signature against the untouched request body. A checkout success redirect is not proof of payment and should not unlock the paid UI by itself.

Try the demo

I built a small Vue 3 + Supabase + Stripe SaaS starter to practice this end-to-end flow. The hosted demo uses Stripe test mode; its sample $19/month price is a test price. The source kit is a separate, one-time Gumroad purchase.

I used AI assistance to edit the wording. The project and implementation are mine.

Designing Spatial Synergies for a 4x4 Auto-Battler

MrLong — Fri, 30 Oct 2026 05:44:30 +0000

I built a small browser auto-battler prototype in about ten days to answer one question: can arranging items in a backpack make the next fight more interesting?

Pack Tactics uses a 4×4 inventory grid. Between waves, you drag items into the backpack, rotate them to make them fit, and merge copies up to level 5. Where an item sits can also matter because neighboring items can activate synergies. Then the next wave puts that layout to the test.

The prototype is written in TypeScript and rendered with Canvas 2D. I kept the scope small so I could test the interaction loop before adding more content.

The loop I wanted to test

Inspect the items available between waves.
Decide what to keep, combine, rotate, or move.
Arrange the grid around space and adjacency.
Start the next fight and see what the setup does.

The important part is that the backpack should change the player's decision, not just store rewards. A strong item can be useful by itself, while moving it next to another item may create a different payoff. Merging copies gives another choice: improve one item, or keep more pieces available for a different arrangement.

Design questions I used to evaluate it

Does placement matter after the shop?

If moving an item only makes the backpack look tidier, the grid is busywork. Adjacency effects give placement a reason to matter in the next fight. Rotation adds a spatial constraint, so fitting an item and keeping a useful neighbor relationship can pull in different directions.

Can players understand why a layout worked?

The next wave is the feedback for the previous arrangement. If players cannot connect an outcome to the items they placed, the synergy rules need clearer previews or combat feedback. That is one of the first things I would watch in a playtest.

Is merging a meaningful trade-off?

Combining copies can make an item stronger, but it also changes how many pieces occupy the grid and which adjacency options remain. I want that to feel like a build decision rather than an automatic upgrade.

What I would test next

Can a new player predict which neighboring items will interact before starting a wave?
Does rotating an item create an interesting choice, or only extra clicks?
After a fight, can the player name one layout decision that helped or hurt?
Does the 4×4 space feel constrained in a useful way across several waves?

I made the prototype in the browser so the interaction can be tried without installing anything. The current interface is in Chinese:

Play the prototype: https://floral-queen-7f68.huanglongjian7515.workers.dev/

If you build strategy games, I would value feedback on one thing: what is the clearest way you have found to show adjacency rules before a player commits to a layout?

Disclosure: This article was prepared with AI writing assistance. The project details and design questions are based on my own prototype.