DEV Community: Chaminade Dondah ADJOLOU

Give Your AI Feature a Kill Switch, a Budget, and a Paper Trail

Chaminade Dondah ADJOLOU — Fri, 23 Oct 2026 10:04:57 +0000

The second-most dangerous demo is "watch the agent do everything." The most dangerous is shipping that demo to real users on Monday.

I build web and mobile products with Node, React, and Flutter, and I speak about AI in community spaces. The pattern I keep seeing: teams add a chat box or an "AI assistant" tab, wire an API key, and hope prompt vibes will behave in production. Hope is not an architecture.

This post is a practical starter kit for fullstack builders: three controls every AI feature should have before you invite non-technical users — a kill switch, a budget, and a paper trail. No cloud-vendor lock-in assumed. You can implement these with boring Node middleware and a small React admin panel.

Why demos lie

Figure: gate every model call — kill switch, budget, paper trail.

In a Meetup demo:

You are the only user
You type polite, on-distribution prompts
You ignore the bill
You can Ctrl+C when it loops
Nobody pastes a 40-page PDF of junk to "summarize"

In production:

Users paste secrets by accident
Prompts go adversarial or just confused
A retry storm turns into a surprise invoice
An agent tool call hits the wrong environment
You need to explain what happened three days later

Governance sounds enterprise. The core is simpler: assume the model will be wrong, expensive, or both — and design the blast radius.

Control 1: Kill switch (feature flags that actually stop spend)

A kill switch is not a blog toggle in Notion. It is a runtime gate checked before every model call and every tool invocation.

Minimal shape:

// lib/aiFlags.js
export async function assertAiEnabled(featureKey) {
  const row = await db.flags.get(featureKey);
  if (!row?.enabled) {
    const err = new Error("AI_FEATURE_DISABLED");
    err.code = "AI_FEATURE_DISABLED";
    throw err;
  }
}

Call it at the edge of your AI service:

export async function runAssistant({ userId, featureKey, input }) {
  await assertAiEnabled(featureKey);
  // ... budget check, then model call
}

Wire a React admin (or even a secured POST /admin/flags) so you can disable meetup-copilot without redeploying. When something smells wrong at 1 a.m., you want a button — not a pipeline.

Mobile note: Flutter clients should treat AI_FEATURE_DISABLED as a first-class UI state ("Assistant temporarily off"), not a generic 500. Users forgive maintenance; they do not forgive spinning forever.

Bonus: scoped kills

Prefer per-feature flags over a global "AI off":

chat.summarize
chat.reply-suggest
agent.tools.github (keep this off until you are truly ready)

That way a broken experimental agent does not take down a simple title-rewriter that still helps organizers.

Control 2: Budget (tokens, calls, and blast radius)

If you cannot answer "what is the max this feature can cost today?", you do not have a product — you have an open tab.

Soft limits per user / per org

export async function assertWithinBudget({ tenantId, featureKey }) {
  const usage = await db.usage.today(tenantId, featureKey);
  const limit = await db.limits.get(tenantId, featureKey);

  if (usage.calls >= limit.maxCalls || usage.tokens >= limit.maxTokens) {
    const err = new Error("AI_BUDGET_EXCEEDED");
    err.code = "AI_BUDGET_EXCEEDED";
    throw err;
  }
}

Practical defaults for an early community product:

Cap calls per user per day
Cap max input characters (reject the 2MB paste early)
Cap max tool iterations for agents (e.g. 5 steps, then stop with a clear message)
Separate "playground" keys from "production" keys

Hard limits at the provider

Also set provider-side spending caps where they exist. Application budgets fail closed when Redis hiccups; provider caps fail closed when your app has a bug. Use both.

Agents need step budgets, not vibes

If you are building anything agent-like (tool calling, multi-step plans):

Maximum steps
Maximum wall-clock time
Allowlist of tools (read calendar ✗ delete calendar until proven)
Human confirmation for irreversible actions

Pausing / resuming agents is a hot topic for a reason: long-running autonomy without checkpoints is how you get surprise side effects. Even a simple job table with status: running | paused | done | failed beats an unbounded while-loop in memory.

Control 3: Paper trail (logs you can defend)

When someone asks "why did the assistant tell my users X?", screenshots are not enough.

Log structured events:

await db.aiEvents.insert({
  id: crypto.randomUUID(),
  tenantId,
  userId,
  featureKey,
  model,
  promptVersion,      // e.g. "rsvp-helper@3"
  inputHash,          // hash raw input; store raw only if policy allows
  toolCalls: [...],   // names + args summaries
  outputHash,
  tokensIn,
  tokensOut,
  latencyMs,
  createdAt: new Date().toISOString(),
});

Privacy-aware defaults

Prefer hashes + short redacted previews over full prompts for sensitive products
Never log API keys, auth headers, or payment fields
Define retention (30/90 days) and stick to it
Make "export my AI history / delete my AI history" a real endpoint if you serve EU users or simply respect people

Prompt versioning is underrated

Store prompts in git (prompts/rsvp-helper.v3.md) and send promptVersion with every call. When behavior changes, you can diff. "The model got dumber" is often "we edited the prompt on Tuesday and forgot."

A thin React admin that earns its keep

You do not need a full observability suite on day one. A single authenticated page with:

Feature flags table + toggle
Today's spend / call counts per feature
Last 50 AI events (status, latency, error code)
Big red "disable all AI features" button

…will save you more pain than another model provider abstraction.

How this maps to a real feature

Suppose you add "Suggest event description" for organizers:

Flag: events.ai.suggest-description (default off in prod until soak test)
Budget: 20 suggestions / organizer / day, 1k max input chars
Paper trail: prompt version + hashes + tokens
UX: show the suggestion as a diff the human must accept — never auto-publish
Kill: if suggestions degrade, flip the flag; the rest of the app keeps working

That is product engineering. The model is a dependency, not the product.

Takeaways

Kill switches belong in the request path, not in a document.
Budgets need daily caps, input caps, and agent step caps — plus provider hard limits.
Paper trails need structured events, prompt versions, and privacy rules.
Human confirmation for irreversible actions is not optional.
Ship AI as a flaggable slice of a working app, not as the app's only spine.

If you are adding your first assistant to a Node/React or Flutter app, start with these three controls before you polish the avatar animation. Cool UI with no blast-radius design is how demos become incidents.

What control do you wish you had added earlier — flag, budget, or audit log? I am curious what broke first for other builders.

Retries Without Regret: Idempotency Keys in Spring Boot and Node

Chaminade Dondah ADJOLOU — Wed, 21 Oct 2026 10:06:19 +0000

A popular DEV discussion recently asked to retry or not to retry. The honest answer is: retry, but only once you've made it safe. On mobile networks, where requests time out after the server has already done the work, the dangerous case isn't "the request failed". It's "the client doesn't know whether it succeeded."

This post covers three things:

Which requests are safe to retry by definition.
How to make the unsafe ones (usually POST) safe with an idempotency key stored in Postgres, in both Spring Boot and Node.
How to retry politely: exponential backoff with jitter.

1. What HTTP already guarantees

RFC 9110 defines a method as idempotent if the intended effect of several identical requests is the same as one. GET, HEAD, OPTIONS, PUT and DELETE are idempotent; POST and PATCH are not.

That's a contract about intended effect, so your implementation has to honour it (a PUT that appends a row isn't idempotent, whatever the RFC says). But it gives a clear starting point:

Idempotent methods: retry with backoff.
POST with an idempotency key: retry with the same key.
POST without a key: don't auto-retry. Query the status first.
4xx like 400/401/403/422: don't retry; the request itself is wrong.
429 / 503: retry, honour Retry-After if present, add jitter.

2. Idempotency keys

The pattern, popularised by payment APIs like Stripe and being standardised by the IETF HTTPAPI working group as the Idempotency-Key header (an Internet-Draft, not yet an RFC), is simple:

The client generates a unique key (a UUID) once per logical operation and sends it on every attempt.
The server records the key before doing the work. If it sees the same key again, it returns the stored result instead of redoing the work.

The table

CREATE TABLE idempotency_keys (
  key           text        NOT NULL,
  user_id       bigint      NOT NULL,
  request_hash  text        NOT NULL,
  status        text        NOT NULL DEFAULT 'in_progress', -- in_progress | done
  response_code int,
  response_body jsonb,
  created_at    timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (user_id, key)
);

Two details matter:

Scope keys per user/client. Two users must never collide on the same key.
Store a hash of the request body. If the same key arrives with a different payload, that's a client bug: reject it (Stripe and the IETF draft both treat key reuse with a different payload as an error; the draft suggests 422).

Claiming a key atomically

Postgres' INSERT ... ON CONFLICT DO NOTHING gives you an atomic "claim": exactly one concurrent request inserts the row, the others get zero rows back.

INSERT INTO idempotency_keys (key, user_id, request_hash)
VALUES ($1, $2, $3)
ON CONFLICT (user_id, key) DO NOTHING
RETURNING key;

One row returned: you own the key, do the work, then update status='done' with the response.
No row returned: load the existing row.
- done and same hash → replay the stored response.
- in_progress → return 409 Conflict so the client retries later.
- different hash → 422.

Ideally, do the business write and the "done" update in the same transaction, so you never end up with work done and no stored result.

Spring Boot

@PostMapping("/payments")
public ResponseEntity<?> create(@RequestHeader("Idempotency-Key") String key,
                                @RequestBody PaymentRequest req,
                                @AuthenticationPrincipal User user) {
    String hash = DigestUtils.sha256Hex(json.writeValueAsString(req));
    int claimed = jdbc.update("""
        INSERT INTO idempotency_keys (key, user_id, request_hash)
        VALUES (?, ?, ?) ON CONFLICT (user_id, key) DO NOTHING""",
        key, user.getId(), hash);

    if (claimed == 0) {
        return idempotency.replayOrConflict(user.getId(), key, hash);
    }
    PaymentResult result = payments.execute(req, user, key); // stores result + status='done'
    return ResponseEntity.status(201).body(result);
}

(DigestUtils here is Apache Commons Codec; replayOrConflict implements the three branches above. Exception handling trimmed for readability.)

Node (Express + node-postgres)

app.post("/payments", async (req, res) => {
  const key = req.get("Idempotency-Key");
  if (!key) return res.status(400).json({ error: "Idempotency-Key required" });
  const hash = sha256(JSON.stringify(req.body));

  const claim = await pool.query(
    `INSERT INTO idempotency_keys (key, user_id, request_hash)
     VALUES ($1, $2, $3) ON CONFLICT (user_id, key) DO NOTHING RETURNING key`,
    [key, req.user.id, hash]
  );

  if (claim.rowCount === 0) return replayOrConflict(req.user.id, key, hash, res);

  const result = await executePayment(req.body, req.user, key); // stores result, status='done'
  res.status(201).json(result);
});

Expiry

Keys don't need to live forever. Stripe documents (for its API v1) that keys can be removed after they're at least 24 hours old. Pick a window longer than your longest client retry, and clean up with a scheduled job:

DELETE FROM idempotency_keys WHERE created_at < now() - interval '24 hours';

3. Retrying politely: backoff with jitter

If every client retries at exactly 1s, 2s, 4s, they all hit your recovering server at the same moments. AWS's architecture blog post on exponential backoff and jitter compares strategies and shows that adding randomness spreads retries out. "Full jitter" is the simplest:

async function withRetry<T>(fn: () => Promise<T>, max = 5, base = 300, cap = 10_000) {
  for (let attempt = 0; ; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (attempt >= max - 1 || !isRetryable(err)) throw err;
      const delay = Math.random() * Math.min(cap, base * 2 ** attempt);
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

Crucially, the idempotency key is created outside this function, once, so every attempt reuses it:

const key = crypto.randomUUID();
await withRetry(() => api.post("/payments", body, { headers: { "Idempotency-Key": key } }));

When not to retry

Validation and auth errors. Retrying a 422 just produces another 422.
Non-idempotent calls without a key. Show the user a "checking status" state and query the server instead.
When the user is waiting. Cap total retry time. A spinner that lasts a minute is worse than a clear error with a "try again" button.
Retries at every layer. If the mobile client, the API gateway and the backend's HTTP client all retry 3 times, one failure can become 27 calls. Retry at one layer.

Checklist

[ ] Every non-idempotent endpoint that clients may retry accepts an Idempotency-Key.
[ ] Keys are scoped per user and stored with a request hash.
[ ] The claim uses INSERT ... ON CONFLICT DO NOTHING.
[ ] In-progress duplicates get 409, mismatched payloads get 422.
[ ] Clients generate the key once, outside the retry loop.
[ ] Backoff uses jitter and a cap; only one layer retries.
[ ] Keys expire after a documented window.

What's the worst duplicate-request bug you've shipped (or caught just in time)?

Supabase Stops Auto-Exposing New Tables on Oct 30: The Checklist to Run This Week

Chaminade Dondah ADJOLOU — Tue, 20 Oct 2026 10:04:21 +0000

Supabase is a popular backend for hackathons, side projects and production apps alike, and for good reason. You create a table, call it from supabase-js, and you have a working app before lunch. That convenience came from a default: every new table in the public schema was automatically reachable through the Data API.

That default is going away. Supabase announced it in its changelog in April, it's already the default for new projects, and on October 30, 2026 it will be applied to all existing projects. That's about ten days from now.

Whether you have a weekend hackathon build you want to keep alive, a side project you touch once a month, or an app with real users, there are two ways this can hurt you:

It breaks: a tutorial, starter repo or AI-generated migration written for the old behavior creates a table and your client gets 42501 permission denied.
It leaks: you "fix" that error the fast way, or you keep adding tables to an older project where new tables are still auto-granted, and you end up with a table that anyone holding your public key can read, update and delete.

This post explains exactly what's changing (from Supabase's own changelog), the mental model you need, and a checklist with SQL you can paste into your migrations this week, before the change reaches your project.

What exactly is changing

From the official changelog entry, "Breaking Change: Tables not exposed to Data and GraphQL API automatically":

Date	What happens
April 28, 2026	Opt-in setting available at project creation
May 30, 2026	New behavior becomes the default for new projects (gradual rollout over a few weeks)
October 30, 2026	New behavior applied to all existing projects

Before: when you created a project with default settings, select, insert, update and delete were granted on every table in public to the anon, authenticated and service_role roles. Every table was reachable via the Data API on creation.

After: new tables in public "require an explicit opt-in (via a Postgres grant) before the Data API can see them."

Four clarifications from the same page that matter a lot:

Existing tables are not affected. They "keep their current grants and stay reachable." Your running app doesn't go dark on October 30.
It only concerns the Data API (the auto-generated REST and GraphQL layer that supabase-js and the other client libraries call). If your app talks to Postgres over a direct connection — psql, an ORM, an app server with a connection string — "this change will not affect you."
RLS behavior is unchanged. Grants and Row Level Security are separate layers.
Only the public schema is concerned. Per the changelog FAQ, tables in storage, auth, realtime and custom schemas keep their current grants and defaults.

When a grant is missing, PostgREST returns an explicit error instead of failing silently:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

The rollout dates come from Supabase's changelog. If your project was created before the new default, October 30 is your date.

Supabase also says it is emailing owners and admins of active projects (a five-week notice went out on September 23, and a final notice is scheduled for October 23), and that the Security Advisor flags affected tables with remediation SQL. If you got one of those emails and filed it away, this is the week to open it.

Who gets caught by this

Code written fast, by several people at once, frequently with an AI assistant, and without a review step is exactly the kind of code this change targets. Supabase's changelog names that context as the reason for the change: today, "agents, CLI scripts, and AI platforms create tables too, and many of those operations do not have a human reviewing the diff."

Hackathon projects fit that description perfectly, but so do side projects and plenty of production apps. Here are the three scenarios I'd expect to see around October 30:

Scenario A — You start a brand-new project. New projects have had the new behavior by default since the May 30 rollout. Any tutorial, video or starter template written before that assumes your tables are reachable right after create table. They won't be. You'll hit 42501 and lose time.

Scenario B — You keep building on an older project. Until October 30, new tables on that project still receive the old default grants. Create a table from a migration or a script without enabling RLS, and it is immediately readable and writable by the anon role. Then, after October 30, the next table you add to the same project will behave differently from the ones you created last week, which is a confusing way to discover the change. This is the most common case for hackathon builds that turned into side projects, and for production apps that have been running for a while.

Scenario C — You rebuild from migrations later. You spin up a fresh project, a preview branch, or reset your local database. Tables created by migrations without explicit grants will not be reachable through the Data API anymore. The app that worked in the demo or in production "suddenly" breaks in the new environment.

The fix for all three is the same: make access an explicit, written decision in your migrations.

The mental model: GRANT and RLS are two different doors

This is the part I'd want every teammate to understand before touching the database.

GRANT decides whether a role can touch a table at all.
RLS decides which rows that role sees once it can.

And you need to know who the roles are:

anon is what requests run as when nobody is signed in. Your anon (or publishable) key ships in your frontend bundle. Anyone can extract it with the browser's dev tools. Whatever anon can do, the whole internet can do.
authenticated is what signed-in users run as. If anyone can sign up for your app, this is almost as public as anon.
service_role is for server-side code only. It bypasses RLS. It must never reach a browser or a mobile app bundle.

Put grants and RLS together and you get four situations:

Red is the leak. Blue is what new tables look like after the change.

Only the red row is dangerous, and it's an easy one to land in. A table created through plain SQL starts with RLS off (that's the Postgres default). Under the old default grants, that meant: readable and writable by anon from the moment it existed.

The October 30 change moves new tables to the blue row. That's safer. The danger is in how people get out of the blue row.

Trap 1: "fixing" 42501 with GRANT ALL

You create a table, the app throws 42501, you search the error (or ask your AI assistant), and you find something like this:

-- Don't do this on its own
grant all on table public.notes to anon, authenticated, service_role;

The error disappears. If RLS isn't enabled on that table, you have just moved it straight to the red row. The DEV author x3blank made this point well in a recent DEV post, and it's worth repeating: the most common quick fix for this error re-opens exactly the hole the change closes.

Even the hint in the official error message suggests granting SELECT to anon. That's correct for a public catalog. It's wrong for a table of user submissions. The hint tells you what is missing, not whether that role should have it.

The same caution applies to the changelog's own rollback FAQ, which shows how to bulk-grant select, insert, update, delete on all tables in schema public if an early opt-in breaks your app. That's a legitimate emergency rollback, but it puts every table back in reach of anon, so check RLS on each of them afterwards.

Trap 2: before Oct 30, adding a GRANT doesn't remove the default ones

If you're working on an older project (Scenario B), create table still gives anon full CRUD until the change reaches your project. Adding grant select ... to authenticated doesn't take anything away from anon, because GRANT only adds privileges.

So the order that's safe both before and after October 30 is: revoke first, then enable RLS, then write policies, then grant only what's needed. The revoke is a harmless no-op once the new default applies.

The same order in every migration. Step 6 is the one that tells you the truth.

The migration template to paste into your repo

Let's say you're building a small app where signed-in users file reports, and there's a public list of categories anyone can read. Two tables, two very different access needs.

A public, read-only table

create table public.categories (
  id bigint generated always as identity primary key,
  name text not null unique,
  created_at timestamptz not null default now()
);

-- 1. Remove anything that was auto-granted (no-op on projects with the new default)
revoke all on table public.categories from public, anon, authenticated;

-- 2. RLS on, always
alter table public.categories enable row level security;

-- 3. Policy: anyone may read
create policy "categories are public"
  on public.categories for select
  to anon, authenticated
  using (true);

-- 4. Minimal grants: read for clients, full access for server code
grant select on table public.categories to anon, authenticated;
grant select, insert, update, delete on table public.categories to service_role;

A private, owner-only table

create table public.reports (
  id bigint generated always as identity primary key,
  user_id uuid not null default auth.uid() references auth.users (id),
  body text not null check (char_length(body) <= 2000),
  created_at timestamptz not null default now()
);

revoke all on table public.reports from public, anon, authenticated;

alter table public.reports enable row level security;

create policy "users read their own reports"
  on public.reports for select
  to authenticated
  using (user_id = (select auth.uid()));

create policy "users create their own reports"
  on public.reports for insert
  to authenticated
  with check (user_id = (select auth.uid()));

-- No grant to anon at all. Signed-in users can read and insert, nothing else.
grant select, insert on table public.reports to authenticated;
grant select, insert, update, delete on table public.reports to service_role;

A few things to notice:

anon gets nothing on reports. Not "nothing because of RLS", but nothing because there is no grant. Two independent layers both say no.
authenticated doesn't get update or delete. If your feature doesn't need it, don't grant it. You can add it with a policy later.
Grants, RLS and policies live in the same file. Supabase's changelog recommends exactly this: treat the three steps "as a unit" and bundle the GRANT statements alongside ENABLE ROW LEVEL SECURITY and the policies in the same migration.

If an insert fails with a permission error on a sequence (for example if you used serial instead of an identity column), grant usage, select on that specific sequence to the role that inserts. Don't reach for a schema-wide grant.

Trap 3: October 30 doesn't fix tables that are already open

"Existing tables keep their grants" means nothing breaks. It also means any table that is in the red row today stays in the red row. Whether it's last month's hackathon project or an app with real users, audit it before you add anything new.

Check 1: ask Postgres which tables `anon` can read with RLS off

select c.relname as table_name
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'r'
  and not c.relrowsecurity
  and has_table_privilege('anon', c.oid, 'SELECT');

Any row this returns is a table readable with your public key. Views don't have RLS, so check relkind = 'v' separately.

A subtle point from the x3blank post: if you audit with information_schema.role_table_grants from a restricted role, you can get zero rows and wrongly conclude there are no grants. That view only shows privileges where the current role is involved as grantor or grantee. has_table_privilege() doesn't have that problem.

The dashboard can help too: the changelog points to the Data API exposure badge in the Table Editor and to the Security Advisor as the places that list the tables worth reviewing.

If a table should not be reachable through the Data API at all, the changelog gives the per-table revoke:

revoke all on table public.your_table from anon, authenticated, service_role;

Check 2: use the anon key like an attacker would

This is the check I trust most, because it tests the real path:

curl -s -o /dev/null -w '%{http_code}\n' \
  -H "apikey: $ANON_KEY" \
  -H "Authorization: Bearer $ANON_KEY" \
  "https://<project-ref>.supabase.co/rest/v1/reports?select=*&limit=1"

For a private table, a 200 that returns rows is a red flag. An error or an empty result is what you want. Run it for every table before you call the audit done, and again after every migration that adds a table.

Check 3: opt in early so there are no surprises

You don't have to wait for October 30. The changelog gives the SQL to adopt the new behavior on an existing project today:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

These change the defaults for future tables and sequences created by the postgres role in public. Existing tables keep their current grants. Keep the for role postgres part. You can confirm what defaults remain with:

select pg_get_userbyid(defaclrole) as grantor,
       defaclnamespace::regnamespace as schema,
       defaclobjtype,
       defaclacl
from pg_default_acl;

Doing this this week means you experience the new behavior on your own schedule, on a day you're watching for it, instead of discovering it the first time someone adds a table after October 30.

If an AI assistant writes your migrations

Supabase's changelog explicitly suggests updating your AI tool's system prompt, or adopting the Supabase agent skill, so that grants are part of table creation. Whatever tool you use, I'd add three lines to its instructions:

- Every CREATE TABLE in public must be followed, in the same migration, by:
  revoke defaults, enable RLS, explicit policies, and minimal GRANTs per role.
- Never grant anything to anon unless the data is meant to be public.
- Never use GRANT ALL to fix a 42501 error. Explain which role needs which privilege and why.

Then review what it produces. The error-message hint is designed so agents can self-correct, but an agent that self-corrects by granting SELECT to anon on a private table has fixed the error and created a leak.

The same principle, outside Supabase

None of this is Supabase-specific thinking. It's least privilege, made explicit. Two examples from my own projects, with different stacks:

TwinFlow (a Go sidecar in front of PostgreSQL) says it plainly in its README: "It is a proxy, not a permission system: the Postgres role you give it is the access it has." The tool doesn't pretend to add security on top of a role that's too powerful. The role is the boundary, so you choose the role carefully. Its contributing guide also forbids logging SQL arguments, row payloads, tokens or connection strings.
Ezoato (a past-exam-papers platform with a PHP/MySQL backend) documents that its AI session endpoint only returns sessions belonging to the current JWT, responding with a 404 otherwise, and ships a security test script that covers this kind of ownership check (IDOR) alongside input validation.

Different databases, same rule: decide who can touch what, write it down in code, and test it from the outside.

The checklist to run before October 30

This week, on every existing project

[ ] List the projects that use the Data API (supabase-js, any client library, /rest/v1/ or /graphql/v1). Projects that only use a direct Postgres connection can skip the rest.
[ ] Run the has_table_privilege audit and fix any red-row tables (enable RLS with policies, or revoke per table).
[ ] Check the Security Advisor and the Data API exposure badge for flagged tables.
[ ] Decide whether to run the official opt-in SQL now, so the project behaves like a new one on your schedule.
[ ] Make sure the service_role key is only in server-side environment variables, never in a NEXT_PUBLIC_/VITE_/Flutter asset file.

In your repo

[ ] Put the two migration templates above in your repo (supabase/migrations/ or a sql/ folder).
[ ] Find every migration, seed script or provisioning step that creates a table in public and add explicit grants next to it.
[ ] Add the three instructions above to your AI assistant's system prompt or project rules.

Every time you add a table

[ ] Create → revoke → RLS → policies → minimal grants, in one file.
[ ] When you see 42501: ask which role needs which privilege, never GRANT ALL.
[ ] Review AI-generated SQL for grants to anon.
[ ] Run the anon-key curl against the new table.

Before October 30

[ ] Rebuild from migrations once (new project, branch or local reset) to prove the migrations are complete on their own.
[ ] Delete abandoned tables and the SQL files that create them, so they can't come back on the next rebuild.
[ ] Run the has_table_privilege query one last time.

The October 30 change makes new tables safe by default. Your job is to not undo that with a rushed GRANT ALL the first time something breaks.

Sources

Supabase changelog, "Breaking Change: Tables not exposed to Data and GraphQL API automatically": https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically
Supabase CLI PR #5524 (local default for auto_expose_new_tables): https://github.com/supabase/cli/pull/5524
x3blank on DEV, "Supabase stops auto-granting new tables on Oct 30. Don't fix the 42501 with GRANT ALL": https://dev.to/x3blank/supabase-stops-auto-granting-new-tables-on-oct-30-dont-fix-the-42501-with-grant-all-3lom
TwinFlow README and CONTRIBUTING: https://github.com/Donchaminade/twinflow
Ezoato backend docs: https://github.com/Donchaminade/ezoato

All diagrams in this post are mine, made for this article.

Threads, Pools, Promise.all: Why Your Postgres Falls Over First (Spring Boot vs Node)

Chaminade Dondah ADJOLOU — Mon, 19 Oct 2026 09:59:47 +0000

Two recent DEV posts describe the same incident from opposite sides of the stack. In one, a Spring Boot service learned that threads are not connections. In the other, a Node service found out why await Promise.all() can crash your database. There's also a write-up of a connection pool that collapsed twice in a day, where restarting made it worse.

The pattern is the same everywhere. Concurrency in your app has become almost free: virtual threads in Java 21+, Promise.all in Node. Concurrency in your database has not. Postgres has a hard max_connections, and each connection is a real backend process on the server. The app scales, the pool saturates, and the database (or the pool in front of it) is the first thing to fall over.

Instead of arguing about it, I measured it.

The setup

PostgreSQL 18.4, local, with max_connections = 25 (deliberately small, so the limits show up fast). As usual, 3 slots are reserved for superusers, which leaves 22 for the app role.
Java 21 with HikariCP 7.0.2 (the version Spring Boot 4.1.1 manages) and the PostgreSQL JDBC driver.
Node 20 with node-postgres (pg) and p-limit.
The workload is a burst of 1,000 concurrent queries, each select pg_sleep(0.05): a 50 ms query, roughly a real indexed lookup plus some network.
The pool max is 10 on both stacks, which is the default for both HikariCP and node-postgres.

These are runs on one machine, not a benchmark suite. The shape of the results is the point, not the exact milliseconds.

The math nobody does first

A pool of 10 connections running 50 ms queries can serve at most:

10 connections / 0.05 s per query = 200 queries per second

So 1,000 queries need at least 5 seconds, however many threads or promises you throw at them. Everything below is about what happens to the requests that are waiting during those 5 seconds.

Result 1: instances × pool size must fit `max_connections`

The first failure doesn't even involve a burst. You scale your Node API to three instances, each with the default max: 10:

const pools = [1, 2, 3].map(() => new pg.Pool({ ...cfg, max: 10 }));
await Promise.allSettled(Array.from({ length: 300 }, (_, i) => pools[i % 3].query(QUERY)));

3 instances x max=10: ok=57/300
  'remaining connection slots are reserved for roles with the SUPERUSER attribute': 108
  'sorry, too many clients already': 135

That's 30 wanted connections against 22 available. Most queries didn't just wait: they failed, because Postgres refuses connections beyond its limit and pg passes the error to your query.

The budget has to cover everything that connects:

instances × pool max  +  migrations  +  cron/workers  +  admin/monitoring  ≤  max_connections − reserved

This is exactly what bites during autoscaling and rolling deploys, when old and new instances are briefly up at the same time. It's also why hosted Postgres providers put a pooler in front of the database. Supabase, for example, offers Supavisor in session mode (port 5432) and transaction mode (port 6543). Transaction mode lets many short-lived clients share few connections, but per the Supabase docs it doesn't support prepared statements or session state (SET, advisory locks, LISTEN/NOTIFY). With JDBC, for instance, they list prepareThreshold=0. Know which mode your connection string uses.

Result 2: the same burst, both stacks

Spring Boot / HikariCP (connection timeout = how long a caller waits for a free connection):

scenario                              ok   poolTimeout  rejected  p50     p99     wall
platform threads (200), timeout 1s   576   424          0         1742ms  3013ms  3089ms
virtual threads, timeout 1s          175   825          0         1003ms  1009ms  1063ms
virtual + bulkhead(20, 100ms)         28     0        972          195ms   266ms   319ms
virtual threads, timeout 30s (dflt) 1000     0          0         2695ms  5173ms  5220ms

Node / node-postgres:

Promise.all x1000, max=10, acquire timeout 1s:  ok=200/1000  ('timeout exceeded when trying to connect': 800)
Promise.all x1000, max=10, no timeout:          ok=1000/1000 in 5089 ms   peak waitingCount = 990
p-limit(10) x1000, max=10, acquire timeout 1s:  ok=1000/1000 in 5100 ms   peak waitingCount = 0
p-limit(10) + shed when queue > 100:            ok=110, busy(503)=890 in 583 ms

What this tells us:

Virtual threads removed the queue you didn't know you had. With a fixed pool of 200 platform threads (Tomcat's default server.tomcat.threads.max is 200), at most 200 requests were waiting on Hikari at once. The rest waited in the executor's queue, where Hikari's timeout doesn't apply. With virtual threads, all 1,000 requests hit the pool at the same moment (998 threads waiting at peak), and with a 1 s timeout, 82% failed. Turning on spring.threads.virtual.enabled=true is great for I/O-bound apps, but it moves the bottleneck straight to the pool.
Long timeouts "fix" errors by hiding latency. With Hikari's default 30 s connection timeout, or with node-postgres's default connectionTimeoutMillis: 0 (wait forever), everything succeeded, with p99 above 5 s. That's fine for a batch job, but for a mobile client with a 10 s HTTP timeout and a user tapping "retry", it's a slow outage.
A limiter doesn't make anything faster. p-limit(10) took the same ~5.1 s as the unbounded Promise.all; the pool's waiting count just dropped from 990 to 0. What it gives you is control: the queue now lives in your code, where you can measure it and cap it.
Load shedding is the only option that keeps latency bounded. The bulkhead (Java) and the queue cap (Node) rejected most of the burst within ~0.3–0.6 s, with a clean "busy" error the client can retry with backoff. Whether that's right depends on the endpoint. For a user-facing read, failing fast is usually better than a 5-second spinner.

The Node pattern

import pg from 'pg';
import pLimit from 'p-limit';

export const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  max: Number(process.env.PG_POOL_MAX ?? 10),   // per process!
  connectionTimeoutMillis: 2_000,               // default is 0 = wait forever
  idleTimeoutMillis: 10_000,
});

const limit = pLimit(Number(process.env.PG_POOL_MAX ?? 10));
const MAX_QUEUE = 100;                          // beyond this, shed load

export class BusyError extends Error { status = 503; }

export function withDb(fn) {
  if (limit.pendingCount >= MAX_QUEUE) {
    return Promise.reject(new BusyError('database busy, retry later'));
  }
  return limit(() => fn(pool));
}

// usage
await Promise.all(ids.map(id => withDb(db => db.query('select ... where id = $1', [id]))));

Map BusyError to 503 with a Retry-After header in your error middleware. And when you see Promise.all(items.map(query)) over a list of user-controlled size, that's a code-review comment.

The Spring Boot pattern

# application.properties
spring.threads.virtual.enabled=true
spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.connection-timeout=2000

@Component
class DbBulkhead {
    private final Semaphore permits = new Semaphore(20);   // ~2x pool size

    <T> T call(Callable<T> work) throws Exception {
        if (!permits.tryAcquire(100, TimeUnit.MILLISECONDS)) {
            throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "busy, retry later");
        }
        try { return work.call(); } finally { permits.release(); }
    }
}

The Semaphore logic is exactly what I measured above (in a plain Java harness against HikariCP). The Spring wiring is shown as a sketch. If you already use Resilience4j, its Bulkhead does the same job with metrics built in.

Two Spring-specific traps make pool exhaustion worse:

Holding a connection while doing something slow. A @Transactional method that calls an external HTTP API (or an LLM) keeps its connection for the whole call. Do the slow call outside the transaction, then open a short transaction to write the result.
Open Session in View. With Spring Data JPA, spring.jpa.open-in-view is enabled by default (Boot logs a warning about it), which can keep a connection tied to the request while the view renders. For APIs, set it to false.

How big should the pool be?

Usually smaller than you think. HikariCP's own pool sizing guide starts from connections ≈ (core_count × 2) + effective_spindle_count on the database server, and argues that a small pool with a queue in front of it beats a big pool. Practical steps:

Start from the database's capacity and the budget formula above, not from your thread count.
Divide by the maximum number of app instances you can run at once (including during deploys).
Load-test, and increase only if the database has CPU headroom while the pool is saturated.

The metrics to watch before it breaks

Hikari (via Micrometer/Actuator): hikaricp.connections.pending (threads waiting), hikaricp.connections.active, hikaricp.connections.acquire (time to get a connection) and hikaricp.connections.timeout (a counter you want to stay at zero).
node-postgres: pool.totalCount, pool.idleCount, pool.waitingCount, plus your limiter's pendingCount.
Postgres: select state, count(*) from pg_stat_activity group by state;. Lots of idle in transaction means connections are held by code that isn't talking to the database.

Alert on waiting and acquire time, not just on errors. In every run above, the waiting count spiked long before the first error.

Takeaways

Threads and promises are cheap; connections are a budget. Write the budget down.
Virtual threads and Promise.all push all of your concurrency onto the pool. Put a limit in front of it.
Pick a timeout on purpose: short for user-facing paths, longer for batch jobs.
Shed load with a clear 503 rather than letting latency grow without limit.
Measure pending/waiting, and look at pg_stat_activity before you resize anything.

Which default bit you first: Hikari's 30 seconds, or node-postgres's "wait forever"? Tell me in the comments.

You Don't Need Python to Ship AI: Adding an LLM Feature to a Spring Boot API

Chaminade Dondah ADJOLOU — Mon, 19 Oct 2026 09:57:10 +0000

AI owns DEV's front page this week: AI features running in the browser on one side, AI fatigue on the other. The Java corner of that conversation is still quiet. A few posts cover agent memory with Spring AI or RAG with LangChain4j, but most teams with a Spring Boot backend still assume that "adding AI" means standing up a Python service.

For a lot of features, it doesn't. If what you need is "call a model, get structured data back, use it in my existing API", you can do that in the service you already deploy, monitor and secure.

This post builds one such feature end to end: support ticket triage. A ticket comes in and the API returns a category, a priority, a short summary and tags. The goal isn't a demo. It's the boring parts that make it safe to ship: typed output, a deadline, a budget and a fallback.

What I actually ran: Spring Boot 4.1.1, Spring AI 2.0.1 (spring-ai-starter-model-openai), Java 21, against a local mock OpenAI-compatible server. The mock let me force each failure mode on demand: valid JSON, prose instead of JSON, a hang, a 500. I didn't call a real paid model for this post. The numbers below measure the code's behavior, not model quality.

1. Spring AI or LangChain4j?

Both are mature options for the JVM. A quick way to choose:

Spring AI if you're already on Spring Boot and want auto-configuration, application.properties settings, Micrometer observations and a fluent ChatClient. It feels like RestClient for models.
LangChain4j if you're not on Spring (Quarkus, Micronaut, plain Java), or if you want its higher-level "AI services" (interface-based agents) and its integrations catalogue.

Both support OpenAI-compatible APIs, which covers many hosted and local models (including servers like Ollama or vLLM that expose that API). This post uses Spring AI, but sections 3 to 5 apply to either.

2. Setup

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>4.1.1</version>
</parent>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.ai</groupId>
      <artifactId>spring-ai-bom</artifactId>
      <version>2.0.1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-openai</artifactId>
  </dependency>
</dependencies>

spring.ai.openai.api-key=${OPENAI_API_KEY}
spring.ai.openai.base-url=${OPENAI_BASE_URL}
spring.ai.openai.chat.options.model=${LLM_MODEL}
spring.ai.openai.chat.options.temperature=0.0
spring.ai.openai.chat.options.max-tokens=300
spring.ai.openai.chat.max-retries=1

triage.timeout=6s
triage.max-concurrent=8

The API key comes from the environment, never from the repo. max-tokens is your first cost control: a triage answer is small, so cap it. I'll come back to max-retries, because the default surprised me.

3. Ask for a record, not for text

Define exactly what you want back, and keep it small. Every field is a promise the model has to keep.

/** What we ask the model for. */
record LlmTriage(Category category, Priority priority, String summary, List<String> tags) {
    enum Category { BILLING, BUG, ACCOUNT, FEATURE_REQUEST, OTHER }
    enum Priority { LOW, MEDIUM, HIGH }
}

/** What our API returns. "source" is ours, not the model's. */
public record TicketTriage(LlmTriage.Category category, LlmTriage.Priority priority,
                           String summary, List<String> tags, String source) {
    static TicketTriage fromLlm(LlmTriage t) {
        return new TicketTriage(t.category(), t.priority(), t.summary(),
                t.tags() == null ? List.of() : t.tags().stream().limit(5).toList(), "llm");
    }
    static TicketTriage fallback() {
        return new TicketTriage(LlmTriage.Category.OTHER, LlmTriage.Priority.MEDIUM,
                null, List.of(), "fallback");
    }
}

Why two records? In my first version I passed the API record (with source) straight to .entity(...). When I logged the outgoing request, Spring AI had generated a JSON Schema from it and listed source as a required field for the model to fill. The model doesn't know whether it's a fallback; your code does. Keep the model-facing type separate from your API type.

Using enums is the cheapest guardrail available. The generated schema includes "enum": ["BILLING", "BUG", ...], and if the model invents "PAYMENTS", parsing fails instead of letting an unknown category leak into your database.

4. The service: deadline, budget, fallback

@Service
class TriageService {
    private static final Logger log = LoggerFactory.getLogger(TriageService.class);
    private static final String SYSTEM = """
        You triage customer support tickets for a web and mobile app.
        Classify the ticket. Keep the summary under 25 words.
        Never include personal data (names, phone numbers, emails) in the summary or tags.
        """;

    private final ChatClient chat;
    private final Duration timeout;
    private final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
    private final Semaphore inFlight;

    TriageService(ChatClient.Builder builder,
                  @Value("${triage.timeout:5s}") Duration timeout,
                  @Value("${triage.max-concurrent:8}") int maxConcurrent) {
        this.chat = builder.defaultSystem(SYSTEM).build();
        this.timeout = timeout;
        this.inFlight = new Semaphore(maxConcurrent);
    }

    TicketTriage triage(String ticketText) {
        if (ticketText == null || ticketText.isBlank() || ticketText.length() > 4_000) {
            throw new IllegalArgumentException("ticket text must be 1..4000 characters");
        }
        if (!inFlight.tryAcquire()) {        // budget: never queue unbounded LLM calls
            log.warn("triage: too many in-flight calls, using fallback");
            return TicketTriage.fallback();
        }
        Future<LlmTriage> call = executor.submit(() -> chat.prompt()
            .user(u -> u.text("Ticket:\n<ticket>\n{ticket}\n</ticket>").param("ticket", ticketText))
            .call()
            .entity(LlmTriage.class));
        try {
            LlmTriage t = call.get(timeout.toMillis(), TimeUnit.MILLISECONDS);
            if (t == null || t.category() == null || t.priority() == null) return TicketTriage.fallback();
            return TicketTriage.fromLlm(t);
        } catch (TimeoutException e) {
            call.cancel(true);
            log.warn("triage: LLM call exceeded {}", timeout);
            return TicketTriage.fallback();
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return TicketTriage.fallback();
        } catch (ExecutionException e) {
            log.warn("triage: LLM call failed: {}", e.getCause().toString());
            return TicketTriage.fallback();
        } finally {
            inFlight.release();
        }
    }
}

And a plain controller:

@RestController
@RequestMapping("/api/tickets")
class TriageController {
    private final TriageService service;
    TriageController(TriageService service) { this.service = service; }
    record TriageRequest(String text) {}

    @PostMapping("/triage")
    TicketTriage triage(@RequestBody TriageRequest req) { return service.triage(req.text()); }
}

The design choices:

Input limits first. A 4,000-character cap protects both your token bill and your latency.
The ticket is data, not instructions. It goes inside <ticket> tags via a template parameter, and the system prompt states the rules. That doesn't make prompt injection impossible, but combined with enum-only output it limits what an injected instruction can achieve: the worst case is a wrong category, not arbitrary text in your UI.
A deadline the caller can rely on. The endpoint answers within triage.timeout, whatever the provider does. Virtual threads make it cheap to wrap a blocking call in a Future.
A concurrency budget. The Semaphore caps simultaneous model calls. When it's full, you degrade instead of queueing, which protects both your rate limit and your threads.
A fallback that keeps the product working. source: "fallback" tells the UI (and your metrics) that a human should triage this one. The feature degrades gracefully; it doesn't cause an outage.

5. What happened when things went wrong

I pointed the app at the mock server and forced each failure. These are the actual results:

valid JSON         → {"category":"BILLING","priority":"HIGH","summary":"Customer charged twice ...","source":"llm"}   ~0.7 s
prose, not JSON    → source=fallback   ~0.01 s   (StreamReadException: Unrecognized token 'Sure')
model hangs 8 s    → source=fallback   6.0 s     (our deadline fired)
HTTP 500           → source=fallback   ~0.5 s    (2 upstream calls with max-retries=1)

Two findings are worth calling out.

Retries stack. With the defaults, a single failing user request produced four upstream calls to the model endpoint. In Spring AI 2.0, the OpenAI integration is built on the official openai-java SDK, which has its own retry setting (spring.ai.openai.chat.max-retries, default 3 in the configuration metadata). For a user-facing endpoint with a fallback, that's three extra billed attempts the user is waiting for. Setting spring.ai.openai.chat.max-retries=1 brought it down to two. Also note that spring.ai.openai.chat.options.max-retries also exists in the metadata, but it had no effect in my test. The non-options property did. Count upstream calls in your provider's logs before you trust any retry setting.

Keep your own deadline. The metadata also lists spring.ai.openai.chat.timeout (default 60s). In my test, setting it to 4s didn't cut the hanging call before my 6-second application deadline did. I didn't dig further, so treat this as "verify in your setup". Either way, an application-level deadline is something you control and can unit-test.

6. When to stay in Java, and when to add a Python service

Stay in your Spring Boot API when:

the feature is "call a model, parse structured output, store or return it" (classification, extraction, summarization, drafting replies);
the model is hosted (a provider API or an OpenAI-compatible server you run separately);
you want it behind the same auth, rate limits, logging and deployment you already have.

Reach for a separate Python service when:

you train or fine-tune models, or run data science pipelines (that ecosystem is still Python-first);
you need in-process model inference with libraries that only exist in Python;
a team that owns the ML work wants its own deploy cycle.

Even then, the Spring Boot side looks the same as above: a typed call with a deadline and a fallback. Only the URL changes.

Before you ship: a checklist

[ ] Output is a small record with enums wherever possible; the model-facing type is separate from the API type.
[ ] Input is length-capped and passed as a template parameter, not concatenated into the instructions.
[ ] max-tokens is set; temperature is low for classification.
[ ] An application deadline is shorter than your HTTP client's and your users' patience.
[ ] Retries are counted end to end (SDK + yours + the client's).
[ ] Concurrency is capped; overflow degrades to a fallback.
[ ] The response says whether it came from the model or the fallback, and you graph that ratio.
[ ] You know what personal data leaves your system in the prompt, and your provider's data-retention terms allow it.

Notes

Spring AI 2.0 targets Spring Boot 4.x. If you're still on Boot 3.x, use Spring AI 1.x; the ChatClient and .entity(...) API shown here exists there too, but property names may differ.
.entity(...) also accepts reliability switches (spec -> spec.validateSchema() to retry with error feedback, useProviderStructuredOutput() to send the schema as a provider-level constraint). I didn't test them against the mock, so they aren't in the code above. Read the Structured Output reference before enabling them, and remember that each validation retry is another billed call.
If you add springdoc to the same project, check for a swagger-annotations version conflict (I had to pin 2.2.55).

Are you adding LLM features in Java, or did your team go the Python-microservice route? I'd like to hear why in the comments.

Your Java long IDs Are Lying to Your React Native App: Contract Rules Between Spring Boot and TypeScript

Chaminade Dondah ADJOLOU — Mon, 19 Oct 2026 09:50:03 +0000

This bug doesn't throw. Your Spring Boot API returns an order with id 1849203948123456789. Your React Native app shows the order and lets the user tap "Cancel". Then it sends DELETE /api/orders/1849203948123456800. The server answers 404, or worse, it cancels a different order.

Nothing crashed and every type checked. The API and the client simply disagree about what a number is.

A popular DEV post this week asked how to validate unknown in TypeScript without a schema library, and another reminded us that Twitter added id_str in 2010 because JavaScript can't hold a Java long. This post puts the two together, from the point of view of a full-stack developer who owns both ends: a Spring Boot backend and a TypeScript client (React, React Native or both).

Everything below was run on Spring Boot 4.1.1 (Jackson 3.1.5), springdoc-openapi 3.1.1, openapi-typescript 7.13, Zod 4.6 and Node 20. Version notes are in the last section.

1. The precision cliff: 2^53

Java's long is a 64-bit integer. A JavaScript number is a 64-bit IEEE 754 float, so it can represent every integer exactly only up to Number.MAX_SAFE_INTEGER, which is 2^53 − 1 = 9,007,199,254,740,991. Past that, integers get rounded to the nearest representable value.

JSON.parse doesn't warn you. It produces the nearest double:

// Node 20, run as-is
const o = JSON.parse('{"id":1849203948123456789,"customerId":9007199254740993}');
console.log(o.id);                      // 1849203948123456800
console.log(o.customerId);              // 9007199254740992  (off by one)
console.log(Number.isSafeInteger(o.id)); // false
console.log(1849203948123456789 === 1849203948123456800); // true (!)

"My IDs come from a Postgres bigserial, they'll never reach 2^53," you might say. That's often true for auto-increment keys. But many modern ID schemes deliberately use the high bits:

Snowflake-style IDs (timestamp + worker + sequence), used by many social and messaging APIs;
TSID / time-sorted IDs, which are popular in Java backends because they index well;
external IDs from payment providers, telcos or partners that you store as long.

All of these sit far above 2^53. The day you switch ID generators, or integrate a partner, your client starts rounding.

2. Rule 1: 64-bit integers travel as strings

Treat an ID as an opaque token. You never do arithmetic on it, so it doesn't need to be a number on the wire.

On the Spring Boot side you have two options.

Per field, with an annotation:

import com.fasterxml.jackson.annotation.JsonFormat;

record OrderDto(
    @JsonFormat(shape = JsonFormat.Shape.STRING) Long id,
    ...
) {}

Globally, so nobody can forget. With Spring Boot 4 (Jackson 3), register a module through a JsonMapperBuilderCustomizer:

import org.springframework.boot.jackson.autoconfigure.JsonMapperBuilderCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import tools.jackson.databind.module.SimpleModule;
import tools.jackson.databind.ser.std.ToStringSerializer;

@Configuration
class JsonConfig {
    // Every Long / long in every response body is written as a JSON string.
    @Bean
    JsonMapperBuilderCustomizer longsAsStrings() {
        SimpleModule module = new SimpleModule("longs-as-strings");
        module.addSerializer(Long.class, ToStringSerializer.instance);
        module.addSerializer(Long.TYPE, ToStringSerializer.instance);
        return builder -> builder.addModule(module);
    }
}

The response now looks like this (actual output from the test app):

{"id":"1849203948123456789","customerId":"9007199254740993","createdAt":"2026-10-19T09:30:00Z",
 "status":"PAID","total":"15000.50","note":null,"itemCount":3}

Note that itemCount is an int, so it stays a number. That's what you want: small integers are safe.

Inbound, Jackson is lenient. By default, it accepted both "customerId":"9007199254740993" and "customerId":9007199254740993 for a Long field in a request body, and it returned 400 for "abc". So the client can send strings without any change on the server. Clients that still send numbers won't break during a migration either.

The global option has a trade-off: it's a breaking change for existing clients that expect numbers. Roll it out behind a new API version, or start with the per-field annotation on IDs only.

3. Rule 2: money is a decimal string, not a float

BigDecimal has the same problem in a different form. Jackson writes new BigDecimal("15000.50") as the JSON number 15000.50, and JSON.parse turns it into 15000.5. The scale is gone. For amounts above 2^53 minor units (rare, but possible in currencies with large nominal values), precision goes too. And then someone writes 0.1 + 0.2 in the client and gets 0.30000000000000004.

Send money as a decimal string ("15000.50"), or as an integer count of minor units plus a currency code. On the client, format it for display and do any arithmetic with a decimal library, or on the server.

I hit a subtle trap while testing this. I annotated total with @Schema(type = "string") for the docs, but Jackson still serialized it as a number. The OpenAPI annotation documents the contract; it doesn't enforce it. You need @JsonFormat(shape = STRING) (or a global BigDecimal serializer) and the schema annotation. Section 6 shows how to catch that mismatch automatically.

4. Rule 3: dates, enums and nulls

Dates. Use Instant (or OffsetDateTime) on the server and ISO-8601 with an offset on the wire: "2026-10-19T09:30:00Z". With Spring Boot 4 / Jackson 3, the test app produced that by default, with no WRITE_DATES_AS_TIMESTAMPS tweak needed. On Spring Boot 3 / Jackson 2, check your config: older setups often emit epoch numbers. Avoid LocalDateTime in APIs. It has no zone, so "09:30" means something different in Lomé, Paris and São Paulo.

Enums. Java enums serialize as their names. That's fine, as long as the client is ready for a value it has never seen. When you add REFUNDED next quarter, an old app build on someone's phone will receive it. On mobile you can't force everyone to update, so the client must have a fallback branch ("unknown status") instead of crashing in a switch.

Nulls vs missing. "note": null and a missing note are different things in TypeScript (string | null vs note?: string). Pick one convention per API and write it down. The setup below makes required-but-nullable explicit.

5. Rule 4: generate the TypeScript types, don't hand-copy them

Hand-written interface Order { id: number } files are where these bugs live. Generate the client types from the server's OpenAPI document instead.

Server: describe the DTO precisely. springdoc reads your records. Without hints it describes Long as integer/int64 (true for Java, wrong for your JSON) and marks every field optional. Annotate:

import static io.swagger.v3.oas.annotations.media.Schema.RequiredMode.REQUIRED;

record OrderDto(
    @Schema(type = "string", requiredMode = REQUIRED, example = "1849203948123456789") Long id,
    @Schema(type = "string", requiredMode = REQUIRED) Long customerId,
    @Schema(requiredMode = REQUIRED) Instant createdAt,
    @Schema(requiredMode = REQUIRED) OrderStatus status,
    @JsonFormat(shape = JsonFormat.Shape.STRING)
    @Schema(type = "string", requiredMode = REQUIRED, example = "15000.50") BigDecimal total,
    @Schema(requiredMode = REQUIRED, types = {"string", "null"}) String note,
    @Schema(requiredMode = REQUIRED) int itemCount
) {}

Client: generate types.

curl -s http://localhost:8080/v3/api-docs > api-docs.json
npx openapi-typescript api-docs.json -o src/api/schema.d.ts

The generated type, unedited:

OrderDto: {
    /** @example 1849203948123456789 */
    id: string;
    customerId: string;
    /** Format: date-time */
    createdAt: string;
    /** @enum {string} */
    status: "PENDING" | "PAID" | "SHIPPED" | "CANCELLED";
    /** @example 15000.50 */
    total: string;
    note: string | null;
    /** Format: int32 */
    itemCount: number;
};

Before I added requiredMode, every field came out as id?: string, and the client had to null-check everything. Run this generation in CI and commit the output, so a backend change shows up as a diff in the client.

6. Rule 5: check at the boundary, at runtime

Generated types are a compile-time promise. The bytes that reach a phone over a flaky mobile network are not. A proxy can return HTML, an old server version can still be deployed, or someone can forget @JsonFormat. Validate once, where unknown enters the app:

import { z } from 'zod';
import type { components } from './api/schema';
type OrderDto = components['schemas']['OrderDto'];

const Id = z.string().regex(/^\d{1,19}$/, 'expected a numeric string id');

export const OrderSchema = z.object({
  id: Id,
  customerId: Id,
  createdAt: z.iso.datetime({ offset: true }),
  status: z.enum(['PENDING', 'PAID', 'SHIPPED', 'CANCELLED']),
  total: z.string().regex(/^-?\d+(\.\d+)?$/),
  note: z.string().nullable(),
  itemCount: z.number().int(),
});

// Compile-time check: runtime schema and generated type must agree both ways.
type Parsed = z.infer<typeof OrderSchema>;
const _a: OrderDto = {} as Parsed;
const _b: Parsed = {} as OrderDto;

If the server regresses and sends a numeric id, parsing fails loudly instead of rounding silently:

OrderSchema.safeParse({ ...order, id: 1849203948123456789 })
→ success: false, "Invalid input: expected string, received number"

The two _a / _b lines are a cheap trick: if someone edits the Zod schema or regenerates the types and they drift, tsc fails. For enums on mobile, swap z.enum([...]) for z.string() plus a mapping with an "unknown" fallback, so a new server value doesn't take down old app builds (see rule 3).

Don't count on clever JSON.parse tricks either. Newer JavaScript engines expose the raw source text to revivers, but you can't rely on that across every runtime your app ships on (Hermes, older WebViews). Fix the wire format instead.

A checklist for your next API review

[ ] Every 64-bit ID is a JSON string (globally or per field).
[ ] Money is a decimal string or integer minor units + currency, never a float.
[ ] Timestamps are Instant/OffsetDateTime, ISO-8601 with offset.
[ ] The client handles unknown enum values without crashing.
[ ] null vs missing is a documented convention; required fields are marked.
[ ] TS types are generated from /v3/api-docs in CI, not hand-written.
[ ] A runtime schema (Zod or hand-written guards) validates responses at the boundary.
[ ] A test asserts that the serialized JSON matches the OpenAPI types (catches the @Schema ≠ @JsonFormat trap).

Version notes

Spring Boot 4 uses Jackson 3. Packages moved from com.fasterxml.jackson to tools.jackson, except com.fasterxml.jackson.annotation (so @JsonFormat keeps its import). Jackson2ObjectMapperBuilderCustomizer became JsonMapperBuilderCustomizer. On Spring Boot 3.x, use the com.fasterxml imports and the old customizer name; the idea is identical.
springdoc 3.x targets Spring Boot 4. In a project that also pulled in Spring AI, I had to pin swagger-annotations to the version springdoc expects (2.2.55), otherwise /v3/api-docs threw NoSuchMethodError. Check mvn dependency:tree -Dincludes=io.swagger.core.v3 if you see that.
The code samples are from a small test app I ran locally. Adapt package names and versions to your project.

What's your team's convention: IDs as strings everywhere, or only above 2^53? Tell me in the comments.

I vibe-coded a cassette deck for family memory — K7 Mémoire (Sanity Challenge Path 2)

Chaminade Dondah ADJOLOU — Fri, 02 Oct 2026 15:36:05 +0000

I vibe-coded a cassette deck for family memory — K7 Mémoire (Sanity Challenge Path 2)

Author: Chaminade (Dondah Chamiande Adjolou) · Lomé, Togo

Challenge: Sanity Challenge Path 2 — Vibe-code something strange (Sep 18–Oct 4, 2026 PDT)

Tag: #sanitychallenge

Live deck: https://k7-memoire.vercel.app

Embedded Studio: https://k7-memoire.vercel.app/studio

Sanity project ID: nh4vx26w · Dataset: production

Why something strange

In Lomé, family history often travels by voice before it travels by page. I did not want another blog layout for that. Path 2 of the Sanity Challenge asks for something strange — so I vibe-coded K7 Mémoire: a Next.js cassette / radio UI that treats Sanity documents as tapes you can tune, filter by mood, and “play.”

The copy is French, Lomé-flavored. The chrome is a deck: FM dial, mood filters, spinning reels, counter, VU meters, rolling transcript, and a kente stripe. No article list. No card grid. Stories are bandes; narrators are voix.

This sits next to earlier work I care about — like a family-tree project for Hacktoberfest — but K7 Mémoire is its own object: oral memory as an instrument, not a CMS demo with a pretty skin.

The product prompt (and why process matters)

Judges for this challenge weigh process as much as the result. I kept a journal in the repo: PROMPT_LOG.md. The brief I gave the agent was essentially one product prompt:

An oral archive for Lomé, stored in Sanity, played by a cassette-deck UI, with Studio, seed stories, README, and this log.

From there, the log records what landed and what broke. Scaffolding with create-next-app (Next.js App Router, TypeScript, Tailwind) into a subdirectory, then moving to the repo root, was more reliable than aiming the CLI at the root. Studio landed at /studio with next-sanity, Sanity v6, Vision, and a custom desk (Bandes / Voix). One GROQ string is shared by the live client and by groq-js over the seed documents — tests assert eight tapes and resolved narrator names.

Failures were part of the craft: no Sanity credentials in the first environment (so the deck shipped a labeled demo mode using the same query, not a second content model); Vitest peer friction (switched to tsx --test); a Turbopack production build that choked on swr’s react-server export until swr was aliased in next.config.ts; Studio pulled into the RSC graph until the config lived behind a client boundary.

Left undone on purpose in that early pass: no audio files on demo tapes (audioUrl optional — Play falls back to the transcript), and no Cursor branding in the public brief.

That honesty is the submission as much as the UI.

Two schemas: tape and voice

Content is not files on the host. Stories stay in Sanity. The model is small on purpose:

Document	Studio title	Role
`story`	Bande	A tape: title, slug, narrator ref, place, era, transcript (portable text), optional `audioUrl`, tags, mood
`narrator`	Narrateur	A voice: name, short bio (≤280), optional photo with hotspot

The narrator’s name lives on the narrator document. The story only holds a reference. That keeps voices reusable across bandes and keeps the deck’s display join honest: narrator->name in GROQ, not a duplicated string on every tape.

Mood is a required string from a shared list (the filters on the dial). Era is approximate text (e.g. « vers 1987 ») and is what we sort on. Transcript is required portable text so the machine always has something to roll when there is no audio file.

One GROQ string, two sources

Whether the deck reads the Content Lake or the local seed drawer, the projection is the same:

*[_type == "story"] | order(era asc) {
  _id,
  title,
  "slug": slug.current,
  place,
  era,
  mood,
  tags,
  audioUrl,
  transcript,
  "narratorName": narrator->name,
  "narratorBio": narrator->bio,
  "narratorPhoto": narrator->photo.asset->url
}

That single string is the contract between Studio editors and the strange front end. An empty lake shows an open tray, not a crash. A failed query shows the error and no tapes. Demo mode is labeled — same query shape, seed documents in src/sanity/seed/documents.ts.

Studio at `/studio`, then the Lake

Studio is embedded in the Next app at /studio (Bandes / Voix desk + Vision). The path from vibe-coded demo to a real Content Lake was deliberate:

Create project + public production dataset in Sanity Manage.
Set NEXT_PUBLIC_SANITY_PROJECT_ID / NEXT_PUBLIC_SANITY_DATASET (defaults already point at nh4vx26w / production).
Editor write token only for seed — never committed.
npm run seed → createOrReplace 4 narrators and 8 stories.
Add CORS origins (local + https://k7-memoire.vercel.app), deploy, open Studio.

Public project ID and dataset are intentional: the deck can read without a token (watch Sanity’s public ACL: path("*") only matches IDs without dots — our seed uses hyphen IDs like story-radio-agoe). Write stays server-side for seed only.

What “strange” looks like on screen

(Screenshots: seeded deck on live — open the app for the full FM dial + kente chrome.)

You do not scroll a feed. You tune. Mood filters narrow the drawer. Play spins the reels and advances a counter while the transcript rolls — or audio plays when audioUrl is set. The on-screen service manual even prints the GROQ, so the “machine” explains how it listens to the Lake.

Stack in short: Next.js (App Router) + TypeScript + Tailwind + Sanity Studio (next-sanity, Sanity v6) on Vercel.

Links for judges and readers

What	Where
Live app	k7-memoire.vercel.app
Studio	k7-memoire.vercel.app/studio
Sanity project ID	`nh4vx26w`
Dataset	`production`
Seeded content	4 narrators · 8 stories
Origin source of truth	cursor.com/codebase/donchaminade/k7-memoire (private)
Process log	`PROMPT_LOG.md` in that repo
GitHub	Donchaminade
LinkedIn	chaminadeadjolou

What I’d vibe next

Real family recordings behind optional audioUrl (consent and quiet UX first).
More Lomé places and eras as the Lake grows — still one GROQ contract.
A small “donate a tape” flow that creates a draft story in Studio without breaking the deck metaphor.
Vision-assisted queries from the service manual for editors learning GROQ beside the reels.

Strange does not mean unserious. A cassette deck is a joke until it is how your aunt’s voice finds the next generation. Sanity’s schemas, Studio, and Content Lake made that joke into something I can seed, ship, and keep editing from Lomé.

Thanks to the Sanity Challenge for Path 2 — and to everyone who still presses Play on memory.

#sanitychallenge · nextjs · sanity · africa

Lignée — A Family Tree Built for Someone I Love (and Generations I'll Never Meet)

Chaminade Dondah ADJOLOU — Fri, 02 Oct 2026 09:27:11 +0000

Lignée — A Family Tree Built for Someone I Love (and Generations I'll Never Meet)

I did not build this for a portfolio. I built it for my family.

For the Adjolou and Chamiande lineage — for the people who raised me in Lomé, Togo, and for the children who will one day ask who came before us? This is my Hacktoberfest Weekend Challenge submission under Build for a Friend. The "friend" is not a stranger on the internet. It is someone I love: my family, including future generations I may never meet.

Lignée (French for lineage) is an open-source family tree that turns oral family stories into durable digital memory — with open-source AI at the core, a mind-map you can edit on your phone, and a promise that our kinship will not vanish when the last elder who remembers stops speaking.

Who it's for

Someone I love is not a single person. In West African extended kinship, "family" is wider than a nuclear unit: grandparents, aunts, uncles, cousins, marriages that braid two names together, in-laws who become our people.

I am Dondah Chamiande Adjolou, from Lomé, Togo. Like many families in the diaspora — and many still at home — we carry our history in conversations: around a table, on a phone call, in a funeral speech, in a name whispered to a newborn. That memory is rich. It is also fragile.

Lignée is for:

Elders whose stories deserve more than a fading recollection
Parents who want their children to know the tree they grew from
Cousins scattered across cities and continents who still share one lineage
Future generations who will open a phone and see faces and names instead of silence

This is not a generic genealogy product. It is a gift I intend to hand over — to my family first, and then to anyone who needs the same thing for theirs.

The problem: oral memory is fading

In many African families, lineage is oral. That is beautiful — and it is at risk.

Elders pass away, and with them go the precise links: who married whom, which child belonged to which house, how two surnames became one story.
The diaspora stretches kinship across borders. A cousin in Europe and a cousin in Lomé may share blood and still not share a shared map of the family.
Young people grow up knowing that they come from somewhere, without knowing how the branches connect.
Paper notebooks get lost. WhatsApp threads scroll away. A Facebook album is not a tree.

If we do nothing, the next generation inherits love without structure — affection without ancestry they can navigate. I did not want my family's story to depend on whoever happens to remember next Sunday.

I wanted something durable, editable, installable on a phone, and honest about privacy — because family data is not the kind of data you casually hand to a closed cloud.

What Lignée does

Lignée is a web app (and a PWA you can install on your phone) that lets a family build and explore its tree as a living mind-map.

A mind-map of kinship, not a stiff chart

Using React Flow, the tree is a visual graph you can pan, zoom, and rearrange. People are nodes. Marriages, parent–child links, cousins, and in-laws are edges. It feels like thinking on a whiteboard — not like filling a bureaucratic form.

Click-to-edit, rich people cards

Tap a person. Open their card. Add or correct a name, dates, notes, relationships. No ceremony — if Auntie remembers a detail at dinner, you fix it in thirty seconds.

Relationships that match how we actually live

Nuclear-only trees fail African (and many diaspora) families. Lignée models:

Marriages and unions that connect two branches
Cousins and extended kinship, not only parents and children
In-laws — the people who become family by bond, not only by blood

Install it on your phone (PWA)

Family conversations happen on phones. Lignée is a Progressive Web App: install it to the home screen, open it like a native app, and keep the tree close when someone starts telling a story.

Story import — from récit familial to nodes

This is the heart of the project. You paste (or type) a family story — a récit familial — and open-source AI helps turn narrative into structured people and relationships. Then you review, correct, and own the result.

Home view, shown before opening the tree:

Demo walkthrough (screenshots above):

Open the tree — see the Adjolou/Chamiande mind-map.
Tap a person — edit their card.
Paste a short family story — run story import.
Review suggested nodes and links — accept what is right, fix what is not.
Install the PWA on your phone — take the tree with you.

Live demo: https://story-lineage.vercel.app

Source (primary public link): https://github.com/Donchaminade/story-lineage
Origin mirror (optional): https://cursor.com/codebase/donchaminade/story-lineage

Demo note: The Vercel serverless deployment uses ephemeral storage, so demo seed data may reload on cold instances; edits made on a prior instance may not persist.

Open-source AI at the core

I refuse to build a family memory tool that only works if a closed vendor stays friendly, cheap, and online.

How story import works

You provide a natural-language family story (French or English — the language of the telling).
An open AI pipeline (designed for Ollama and local inference, with a local fallback) extracts candidate people, generations, and relationships.
The app proposes nodes and edges on the tree.
A human always reviews. AI suggests; the family decides.

No magic black box that silently rewrites your lineage. Suggestion, then consent.

Why open matters for family data

Concern	Why open-source AI helps
Privacy	Family names, dates, and stories are intimate. Local inference (e.g. Ollama) keeps data on machines you control.
No vendor lock-in	Models and providers can be swapped. Your tree is not hostage to one API's pricing or terms.
Local option	When the network is weak — or trust is low — local fallback still lets story import run.
Inspectability	Open models and open code mean the community can audit how narrative becomes structure.

Closed AI might be convenient. For family lineage, convenience is not enough. Sovereignty over memory is the feature.

How I built it (honest technical notes)

Stack

Next.js — app framework, routing, and a clean path to a PWA
SQLite — simple, portable persistence; easy to back up; no heavy ops tax for a family project
React Flow — interactive mind-map UX (pan, zoom, nodes, edges)
PWA — installable on Android/iOS home screens for real family use
Open AI / Ollama + local fallback — story import without requiring a single proprietary cloud

What went well

React Flow made "kinship as a graph" feel natural quickly — marriages and cousins are just edges with meaning.
SQLite kept the data model honest and movable: a family's tree should be something you can copy, backup, and keep.
Designing for phone-first editing forced clarity: click-to-edit beats multi-step wizards when an elder is mid-story.

What was hard (and still is)

Modeling extended kinship without drowning the UI — African families are dense graphs; the UX has to stay readable.
Story import is only as good as the review loop. Hallucinated cousins are worse than missing ones — so the product bias is: suggest carefully, confirm always.
Bilingual reality (French oral culture, English for this challenge write-up and global open source) — the product must respect the language of the récit, not only the language of the README.

What I would improve next

Richer media on person cards (photos, voice notes of elders telling the story)
Stronger conflict resolution when two relatives disagree on a link
Export/import formats for long-term archival beyond one app

This was a weekend challenge build with a long-horizon intention. The code is a starting lineage of its own: it will grow.

Handing it over — what it means for future generations

When I imagine a child in twenty years opening Lignée, I do not imagine a product demo. I imagine them tapping a great-grandparent's card and reading a note that someone bothered to write down — a marriage that joined Chamiande and Adjolou, a cousin who left and came back, a name that explains their own.

Oral memory gave us warmth. Digital lineage can give us continuity.

I am handing this to my family as a living gift: editable, installable, private by design, open in its AI so we are not tenants on someone else's memory server. If other families fork it for their own surnames and stories, that is the point of open source — lineage that multiplies without being owned.

For Hacktoberfest, this is my weekend challenge. For my family, this is unfinished on purpose: trees grow.

Prize Categories

Overall only.

(This submission does not claim partner tool categories such as Copilot, Cloudflare, Docker, etc., unless those tools were genuinely central to the build. The core stack here is Next.js, SQLite, React Flow, PWA, and open-source AI / Ollama with local fallback.)

DEV Community: Chaminade Dondah ADJOLOU

Give Your AI Feature a Kill Switch, a Budget, and a Paper Trail

Why demos lie

Control 1: Kill switch (feature flags that actually stop spend)

Bonus: scoped kills

Control 2: Budget (tokens, calls, and blast radius)

Soft limits per user / per org

Hard limits at the provider

Agents need step budgets, not vibes

Control 3: Paper trail (logs you can defend)

Privacy-aware defaults

Prompt versioning is underrated

A thin React admin that earns its keep

How this maps to a real feature

Takeaways

Retries Without Regret: Idempotency Keys in Spring Boot and Node

1. What HTTP already guarantees

2. Idempotency keys

The table

Claiming a key atomically

Spring Boot

Node (Express + node-postgres)

Expiry

3. Retrying politely: backoff with jitter

When not to retry

Checklist

Supabase Stops Auto-Exposing New Tables on Oct 30: The Checklist to Run This Week

What exactly is changing

Who gets caught by this

The mental model: GRANT and RLS are two different doors

Trap 1: "fixing" 42501 with GRANT ALL

Trap 2: before Oct 30, adding a GRANT doesn't remove the default ones

The migration template to paste into your repo

Trap 3: October 30 doesn't fix tables that are already open

Check 1: ask Postgres which tables anon can read with RLS off

Check 2: use the anon key like an attacker would

Check 3: opt in early so there are no surprises

If an AI assistant writes your migrations

The same principle, outside Supabase

The checklist to run before October 30

Threads, Pools, Promise.all: Why Your Postgres Falls Over First (Spring Boot vs Node)

The setup

The math nobody does first

Result 1: instances × pool size must fit max_connections

Result 2: the same burst, both stacks

The Node pattern

The Spring Boot pattern

How big should the pool be?

The metrics to watch before it breaks

Takeaways

You Don't Need Python to Ship AI: Adding an LLM Feature to a Spring Boot API

1. Spring AI or LangChain4j?

2. Setup

3. Ask for a record, not for text

4. The service: deadline, budget, fallback

5. What happened when things went wrong

6. When to stay in Java, and when to add a Python service

Before you ship: a checklist

Notes

Your Java long IDs Are Lying to Your React Native App: Contract Rules Between Spring Boot and TypeScript

1. The precision cliff: 2^53

2. Rule 1: 64-bit integers travel as strings

3. Rule 2: money is a decimal string, not a float

4. Rule 3: dates, enums and nulls

5. Rule 4: generate the TypeScript types, don't hand-copy them

6. Rule 5: check at the boundary, at runtime

A checklist for your next API review

Version notes

I vibe-coded a cassette deck for family memory — K7 Mémoire (Sanity Challenge Path 2)

I vibe-coded a cassette deck for family memory — K7 Mémoire (Sanity Challenge Path 2)

Why something strange

The product prompt (and why process matters)

Two schemas: tape and voice

One GROQ string, two sources

Studio at /studio, then the Lake

What “strange” looks like on screen

Links for judges and readers

What I’d vibe next

Lignée — A Family Tree Built for Someone I Love (and Generations I'll Never Meet)

Lignée — A Family Tree Built for Someone I Love (and Generations I'll Never Meet)

Check 1: ask Postgres which tables `anon` can read with RLS off

Result 1: instances × pool size must fit `max_connections`

Studio at `/studio`, then the Lake