DEV Community: Lolo

My rate limiter was doing exactly what I told it to do. That was the problem.

Lolo — Mon, 06 Jul 2026 16:29:38 +0000

I had a /image endpoint capped at 3 requests per minute. Simple express-rate-limit, keyed by IP, standard stuff. I was proud of it, honestly — felt like the responsible thing to do before shipping.

Then I actually looked at where those 3 requests per minute were going.

The assumption I didn't know I was making

Rate limiting by IP protects against one thing: a single user hammering your endpoint. It assumes the thing you're protecting has infinite capacity, and you're just being polite about how fast any one person can use it.

That assumption falls apart the second your endpoint calls a third-party API that has its own rate limit — because that limit isn't per-user. It's per-account. Per-project. Shared across every single person hitting your backend, whether they know each other exist or not.

My /image endpoint calls two different image generation providers depending on the model requested. Both of them enforce rate limits at the account level:

Provider A: 5 images per minute, account-wide
Provider B: 10 images per minute, account-wide

My limiter was capping each IP address at 3 requests per minute. Which sounds conservative, until you do the math: five different users on five different IPs can each stay comfortably under their personal cap of 3/min while collectively sending 15 requests per minute to a provider that only allows 5.

Every one of those users would see my API return success. Then, somewhere between my server and the provider, requests would start silently failing — not because of anything they did, but because of what everyone else was doing at the same time, completely invisibly to them and to me.

Why this is easy to miss

Rate limiting per IP feels correct. It's the default in every tutorial, every middleware library's example code, every "add rate limiting to your API" blog post. It solves a real problem — it's just the wrong problem when the actual constraint sits somewhere else entirely.

The bug doesn't show up in testing. It shows up exactly once you have enough concurrent users for their individual, well-behaved usage to add up to something that isn't well-behaved anymore. Which means the more successful you get, the more likely you are to hit it — right when you can least afford flaky behavior.

What actually fixes it

You need a limiter that reflects the real constraint: a shared counter across every user, not per-IP, checked against the actual provider ceiling before you ever make the call.

javascript
const providerRequestLog = {
  providerA: [],
  providerB: []
}

const PROVIDER_LIMITS = {
  providerA: 5,  // per minute, account-wide
  providerB: 10
}

function checkCapacity(provider) {
  const now = Date.now()
  const windowStart = now - 60_000
  const log = providerRequestLog[provider]

  // drop anything outside the rolling window
  while (log.length > 0 && log[0] < windowStart) {
    log.shift()
  }

  if (log.length >= PROVIDER_LIMITS[provider]) {
    return { allowed: false }
  }

  log.push(now)
  return { allowed: true }
}

Before calling the provider, you check capacity against the shared log — not against a per-IP bucket. If there's no room left, you reject before spending the call, with a clear Retry-After, instead of finding out from a 429 you didn't see coming from the provider itself.

One caveat worth flagging honestly: this is in-memory, so it only works cleanly on a single process. If you're running multiple instances behind a load balancer, this counter needs to live somewhere shared — Redis, or similar — or each instance ends up enforcing its own version of a limit that's supposed to be global.

The actual lesson

Rate limiting isn't one thing. "Protect against abuse from a single user" and "don't exceed a ceiling shared across all your users" are two different problems that happen to look identical in a middleware config file. Solving the first one doesn't solve the second, and most default setups only ever solve the first.

If your backend depends on any third-party API with account-wide quotas — payment providers, AI providers, anything with a per-project rate limit — it's worth checking whether your rate limiting actually reflects that shared ceiling, or if it's quietly protecting against something that was never the real risk.

I checked my OpenAI and Anthropic dashboards every morning for a month. Then I stopped.

Lolo — Tue, 30 Jun 2026 14:53:33 +0000

OpenAI usage page, check spend. Anthropic console, check spend. Add it up in my head. Close both tabs, annoyed before writing a single line of code.

Every new project meant repeating it: new account, new key, new billing page, new error format. By the third project, I had four tabs pinned just for billing.

The breaking point was small. An email saying I'd hit 80% of a budget I didn't remember setting. Not because I'd overspent, but because I'd lost track of my own guardrails across two dashboards I only half-watched.
The problem was never the money. It was running two mental models for what should've been one workflow.

So I replaced both dashboards with one number: credits. One key, one balance, that drops no matter which provider handles the request. Didn't set out to build a product, just wanted to stop doing math every morning. Apiarium came after, once I noticed other people doing the same two-tab dance.

Slack or Telegram for solo founder alerts? I was asking the wrong question.

Lolo — Sun, 28 Jun 2026 22:06:56 +0000

When I started thinking about real-time alerts for my SaaS, my first instinct was Slack. Familiar, used it in previous jobs, wanted everything centralized. Case closed.

Then someone reframed it: the right tool depends on the action the alert should trigger, not on familiarity.
Urgent events like payment failures, production errors, and API abuse need to reach you fast. Telegram wins here: instant, personal, no overhead.
Operating history like signups, plan changes, and usage summaries benefit from search and structure. Slack wins as a lightweight company log.

The rule I'm keeping: if you can't name the action you'll take after receiving the notification, it shouldn't be real-time.

Most things don't need to interrupt you. A daily digest teaches more than 20 individual pings throughout the day.
Still setting this up for my own SaaS, but the mental model is clear now.

I Got Tired of Rewriting AI API Wrappers, So I Built a Gateway

Lolo — Sat, 27 Jun 2026 19:35:50 +0000

Every side project starts the same way.

-Generate an OpenAI key.

-Add it to .env.

-Write a wrapper.

-Realize I also need Claude.

-Create another account.

-Another API key.

-Another billing dashboard.

Before the project even starts, I've already configured three different services.

At some point I thought why not just make this a proper API and host it publicly?

That's how Apiarium started.

Why Not LiteLLM or OpenRouter?

They're great projects. But I wanted something more opinionated:

Credit-based billing so users always know what they're spending
One normalized API across text, images, TTS, and transcription
A self-hosted backend I fully control
Simple pricing without per-model complexity

My target isn't teams running production AI infrastructure. It's developers building side projects who want one API key and a predictable bill.

How It Works

Client
   │
   ▼
Apiarium
   ├── /llm         → OpenAI, Anthropic (more coming)
   ├── /image       → gpt-image-1 (more coming)
   ├── /tts         → OpenAI TTS, ElevenLabs (soon)
   └── /transcribe  → Whisper (more coming)

*More providers coming.

Adding a new provider doesn't change the API contract.
Same endpoints, same auth, more options.

From the client's perspective, every provider looks exactly the same:

# GPT-4o-mini
curl -X POST https://api.apiarium.dev/llm \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"Hello"}]}'

# Switch to Claude — same endpoint, same auth
curl -X POST https://api.apiarium.dev/llm \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku","messages":[{"role":"user","content":"Hello"}]}'

The Technical Decisions

Credits instead of per-model pricing. Pricing by token across four providers is confusing. I landed on credits text generation costs 1–20 credits depending on the model, images cost 100, TTS costs 10 per 1,000 characters. One number, always visible.

Normalized error format. OpenAI and Anthropic return completely different error structures. Every error from Apiarium looks the same regardless of which provider caused it:

{
  "error": "Rate limit exceeded. Try again in 30 seconds.",
  "code": "rate_limit_exceeded",
  "retry_after": 30
}

Provider abstraction. Every provider adapter returns the same internal response format before it's sent back to the client. That means adding a new provider is mostly implementing one adapter instead of changing the whole API.

What I'd Do Differently

If I started again, I'd build the provider abstraction first instead of adding providers one by one. Every new model taught me another edge case around streaming, token accounting, or error handling. Designing for those differences upfront would've saved me time.

Where It Is Now

Launched a few days ago. Still early, but the infrastructure is solid and every endpoint works.

I'm mostly interested in whether this solves a real problem for other developers. If you've hit the same setup tax or think I'm solving the wrong problem entirely, I'd genuinely like to hear it.

If even one developer stops copy-pasting another ai-utils.js file because of this, I'll call it a success.

apiarium.dev · Docs

The Security Bug Every Node.js Developer Ships to Production

Lolo — Thu, 25 Jun 2026 09:51:15 +0000

Last year I was doing a code review for a startup. Everything looked fine on the surface, clean code, good structure, tests passing.

Then I noticed this:

const query = `SELECT * FROM users WHERE email = '${req.body.email}'`

That's it. That's the bug. SQL injection, sitting right there in a startup that had been in production for 8 months.

Nobody caught it. Not the developer, not the reviewer, not the CTO.

Here's the thing, it's not that developers are careless. It's that this kind of bug is invisible until it isn't. The code works perfectly. Tests pass. Users are happy. Until someone types ' OR '1'='1 in the email field and walks straight into your database.

The bugs I see most often

1. Raw SQL with user input

// 🚨 This is everywhere
const query = `SELECT * FROM users WHERE email = '${email}'`

// ✅ Use parameterized queries
const query = 'SELECT * FROM users WHERE email = $1'
db.query(query, [email])

2. Secrets in environment variables... committed to git

# .env
DATABASE_URL=postgres://user:actualpassword@prod-db.company.com/mydb
STRIPE_SECRET=sk_live_...

Then .env ends up in the repo because someone forgot to add it to .gitignore. I've seen this more times than I want to admit. GitHub's secret scanning catches some of these, but not always before someone has already cloned the repo.

3. JWT tokens that are never actually verified

// 🚨 Decoding is not the same as verifying
const user = jwt.decode(token)

// ✅ Always verify
const user = jwt.verify(token, process.env.JWT_SECRET)

jwt.decode just reads the token. Anyone can forge it. jwt.verify actually checks the signature. The names are confusingly similar and the wrong one silently works in development.

4. No rate limiting on auth endpoints

// 🚨 Anyone can try a million passwords
app.post('/login', async (req, res) => {
  const user = await db.findUser(req.body.email)
  // ...
})

// ✅ Add rate limiting
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10
})
app.post('/login', authLimiter, async (req, res) => {
  // ...
})

Without rate limiting, a brute force attack costs nothing. With it, 10 failed attempts and you're blocked for 15 minutes.

5. Error messages that reveal too much

// 🚨 Tells attackers exactly what's wrong
catch (error) {
  res.status(500).json({ error: error.message })
  // "relation 'users' does not exist"
  // "invalid input syntax for type uuid"
}

// ✅ Log internally, send generic message
catch (error) {
  console.error(error)
  res.status(500).json({ error: 'Something went wrong' })
}

Stack traces and database error messages are gold for anyone trying to map your system.

The one question that catches most of these

Before shipping any endpoint that touches user input, ask:

"What happens if someone sends me something I'm not expecting?"

Empty string. Null. A 10,000 character string. SQL characters. A valid email that belongs to a different user.

Most security bugs aren't sophisticated. They're just cases nobody thought about.

What's the most embarrassing security bug you've found in production, yours or someone else's?

The Node.js Mistake That Cost My Client $3,000 in AWS Bills

Lolo — Tue, 23 Jun 2026 09:37:15 +0000

Last year I was asked to investigate a startup's AWS bill.

It had jumped from roughly $200/month to over $3,000 in a few weeks.

Nobody knew why.

After digging through logs, metrics, and database traffic, I found the culprit: a polling loop with no backoff strategy.

The code looked harmless:

async function processQueue() {
  const jobs = await getJobs()

  for (const job of jobs) {
    await processFile(job)
  }

  processQueue()
}

processQueue()

At first glance, this seems reasonable. Process all available jobs, then check again.

The problem appears when the queue is empty.

When getJobs() returned no work, the loop immediately queried the database again. And again. And again.

There was no delay, no backoff, and no event-driven trigger.

As a result, the service continuously hammered the database looking for work that didn't exist.

Each iteration generated:

A database query
Network traffic
CPU usage
Logging overhead
Additional infrastructure load

Individually, each operation was cheap.

Executed hundreds of thousands of times per day, they became expensive.

The fix was simple:

async function processQueue() {
  while (true) {
    const jobs = await getJobs()

    for (const job of jobs) {
      await processFile(job)
    }

    await new Promise(resolve => setTimeout(resolve, 5000))
  }
}

Even better would have been replacing polling entirely with an event-driven design using a message queue.

What this incident taught me:

1. Empty queues are production workloads.

Many engineers optimize for peak traffic and forget about idle traffic. Systems often spend more time idle than busy.

2. Polling needs backoff.

If you're polling, always define what happens when no work is found.

3. Cost bugs rarely look like bugs.

Nothing crashed. No exceptions were thrown. The system was technically working exactly as written.

It was just doing useless work 24/7.

4. Always monitor cost alongside performance.

CPU, latency, and error rates looked normal.

The AWS bill was the first real alert.

One question I ask during reviews now:

"What does this code do when there's nothing to do?"

That single question has caught more production issues than many architecture discussions ever did.

What's the most expensive bug you've ever seen in production?

Your SaaS is probably leaking money right now — and you don't know it

Lolo — Mon, 22 Jun 2026 11:49:32 +0000

Most indie developers ship their SaaS, celebrate, and move on. Security feels like something for "later" — for when you have real users, real money, real problems.

Here's the thing: the vulnerabilities that cost you money aren't the Hollywood ones. No masked hackers, no zero-days. They're embarrassingly simple, and they're sitting in codebases right now generating real financial losses for real founders.

Let me show you the ones I see most often.

1. The race condition that lets users pay once and use twice

Imagine your credit system works like this:

const user = await db.from('usage').select('credits').eq('user_id', id)

if (user.credits < cost) {
  return res.status(402).json({ error: 'Insufficient credits' })
}

await db.from('usage').update({ credits: user.credits - cost })

Looks fine. It's not.

Fire two API requests simultaneously from the same account. Both read the same credit balance before either one writes. Both pass the check. You just served two requests for the price of one — and your database has no idea it happened.

This isn't theoretical. It takes about 10 lines of JavaScript to exploit:

// This costs you money. Every time.
await Promise.all([
  fetch('/api/expensive-endpoint', { method: 'POST' }),
  fetch('/api/expensive-endpoint', { method: 'POST' }),
  fetch('/api/expensive-endpoint', { method: 'POST' }),
])

The fix: never do read-then-write for anything financial. Use a database-level atomic operation:

UPDATE usage
SET credits = credits - $1
WHERE user_id = $2
AND credits >= $1
RETURNING credits;

If that returns no rows, the user didn't have enough credits. One round trip. Atomically safe. No race condition possible.

2. Trusting the client for billing identity

This one is subtle and extremely common:

router.post('/checkout', async (req, res) => {
  const { email, plan } = req.body  // ← here's your problem

  const session = await stripe.checkout.sessions.create({
    customer_email: email,
    // ...
  })
})

You're letting the client tell you who they are. An authenticated user can simply change the email in the request body and create a checkout session for someone else's account.

In a naive implementation, this can mean:

Creating billing entries for arbitrary email addresses
Probing whether specific emails have accounts
In worst cases, confusing your billing system about who owns what subscription

The fix: never trust identity from the request body. Verify the session token server-side and extract the email from there:

router.post('/checkout', async (req, res) => {
  const token = req.headers.authorization?.replace('Bearer ', '')
  const { data: { user } } = await supabase.auth.getUser(token)

  if (!user) return res.status(401).json({ error: 'Unauthorized' })

  // Now you know exactly who you're billing
  const email = user.email  // from the verified token, not the body
})

3. The annual plan billing gap

This one is pure logic, not a vulnerability — but it bleeds money just as surely.

Most subscription SaaS reset usage credits monthly by listening to Stripe's invoice.paid event. Makes sense: Stripe bills monthly, Stripe fires the event, you reset.

Except for annual plans.

When a customer pays annually, Stripe fires invoice.paid once. Then silence for 364 days. If your credit reset logic lives entirely in that webhook handler, your annual subscribers get their credits on day 1 and nothing for the remaining 11 months of their paid subscription.

You just sold someone 12 months of service and delivered 1.

The fix: decouple credit resets from Stripe events entirely. Run a daily cron job that checks which users have a reset_date in the past and resets them regardless of billing cycle:

// Runs daily at 3 AM UTC
const dueUsers = await db
  .from('usage')
  .select('user_id, users!inner(plan)')
  .lte('reset_date', new Date().toISOString())

for (const user of dueUsers) {
  await db.from('usage').update({
    credits: PLAN_CREDITS[user.users.plan],
    credits_used: 0,
    reset_date: new Date(Date.now() + 30 * 24 * 60 * 60 * 1000).toISOString()
  }).eq('user_id', user.user_id)
}

Stripe events become a nice-to-have, not a single point of failure.

4. Storing recovery tokens in localStorage

Password reset flows are tricky. When a user clicks a reset link, you get a token in the URL hash. The tempting implementation:

// Looks harmless. It isn't.
const token = new URLSearchParams(window.location.hash).get('access_token')
localStorage.setItem('recovery_token', token)

You just stored a credential that can reset someone's password in a storage system accessible to every script running on your page — including browser extensions, third-party analytics, and any future XSS vulnerability.

Recovery tokens are short-lived, so the real-world risk is limited. But the principle is wrong: tokens that grant account control shouldn't touch localStorage.

The fix: let your auth SDK handle it. If you're using Supabase, detectSessionInUrl: true processes the recovery token automatically without you ever seeing it:

const supabase = createClient(url, key, {
  auth: { detectSessionInUrl: true }
})

// The SDK handled the token. Just call getSession().
const { data: { session } } = await supabase.auth.getSession()

The pattern behind all of these

None of these are sophisticated attacks. They don't require reverse engineering or insider knowledge. They require:

Reading your API response in the browser dev tools
Sending two requests at the same time
Knowing that annual billing exists
Opening localStorage in the browser console

The common thread: trusting the client. Trusting that requests arrive one at a time. Trusting that Stripe events cover every edge case. Trusting that tokens are safe in the browser.

They're not.

The good news: fixing all four of these takes less than a day. The bad news: most SaaS founders never audit for them until something goes wrong.

Audit yours before something does.

5 Things I Learned Building APIs with Node.js:

Lolo — Sat, 20 Jun 2026 13:18:48 +0000

Why Your CORS Setup Breaks in Production

You build the API. Test it locally. Everything works perfectly.

Then you deploy, and suddenly the browser console is full of red text about CORS policy violations.

If you've been there, here's why it happens and how to actually fix it instead of just slapping origin: '*' on everything and hoping for the best.

1. Localhost is forgiving. Production is not.

When you're developing locally, your frontend and backend often run on the same machine, sometimes even the same port through a proxy. The browser barely notices there's a cross-origin request happening.

In production, your frontend lives on one domain and your API on a completely different one. That's when the browser actually starts enforcing the same-origin policy seriously.

// Works fine locally because origins basically match
app.use(cors())

The moment you deploy to two separate domains, this default config either blocks everything or silently allows everything — neither of which you want.

2. origin: '*' is not a real fix

It's tempting. It makes the error go away. It's also a mistake waiting to bite you.

// Looks like it works. Is actually a liability.
app.use(cors({ origin: '*' }))

This disables credentialed requests (cookies, auth headers in some setups) and opens your API to literally any website on the internet. Fine for a public read-only API. Bad for anything involving user accounts or payments.

3. The real fix is an explicit allowlist

const allowedOrigins = [
  'https://yourapp.com',
  'https://www.yourapp.com'
]

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true)
    } else {
      callback(new Error('Not allowed by CORS'))
    }
  },
  credentials: true
}))

The !origin check matters — server-to-server requests, curl, and some mobile clients don't send an Origin header at all. Without that check, you'd be blocking legitimate traffic that simply isn't a browser.

4. Changing your domain breaks everything silently

This one cost me an embarrassing amount of debugging time. I migrated from a default subdomain to a custom domain, updated the frontend, redeployed — and authentication started failing with cryptic 400 errors that had nothing to do with CORS in the error message itself.

The actual problem: my backend's CORS allowlist still only had the old domain. The browser was blocking the preflight request before it even reached my auth logic, and the error that bubbled up looked like an authentication failure, not a CORS one.

Lesson: whenever you change a frontend domain, your CORS allowlist is not optional to update. It's step one, not an afterthought.

5. Preflight requests fail before your routes even run

Browsers send an OPTIONS request before the real one whenever the request isn't "simple" (custom headers, JSON content-type, etc). If your CORS middleware isn't registered early enough, or runs after other middleware that rejects the request, the preflight fails and you never even see a log line from your actual route handler.

// CORS needs to run early, before anything that might short-circuit the request
app.use(cors({ origin: allowedOrigins, credentials: true }))
app.use(express.json())
app.use(authMiddleware)
app.use('/api', routes)

If you're staring at a 400 or 500 error with zero logs from inside your route, check whether the request even made it past the preflight. Half the time, it didn't.

CORS errors feel like browser nonsense until you understand they're doing exactly what they're designed to do — refusing to trust a cross-origin request you never explicitly allowed. The fix is rarely "disable security." It's almost always "tell the browser exactly who you trust."

What's the most confusing CORS bug you've run into? Always curious how creative the failure modes get.

5 Production Mistakes That Changed How I Build Express APIs

Lolo — Wed, 17 Jun 2026 19:50:18 +0000

I stopped thinking APIs break because of “complex code”.

They break because of boring things you didn’t take seriously.

Here are 5 lessons from production:

1. Validate early or suffer later

I used to validate inside the logic.

Then weird bugs started appearing far from the source.

Now I just kill bad requests immediately:

if (!req.body.email || typeof req.body.email !== "string") {
  return res.status(400).json({ error: "Valid email is required" });
}

No validation inside business logic. Ever.

2. Your errors are part of your API contract

A generic 500 is useless in production.

Be explicit:

return res.status(401).json({ error: "Invalid API key" });

return res.status(402).json({ error: "Insufficient credits" });

If your error needs explanation in Slack, your API message failed.

3. Middleware order can break everything silently

I once debugged “broken auth” for hours.

It was just middleware order.

app.use(cors());           // must go first
app.use(express.json());
app.use(authMiddleware);
app.use("/api", routes);

Move one line and everything changes.

4. Logging should be boring, not noisy

I’ve tried both extremes.

Both were wrong.

What actually helps in production:

console.log(`${req.method} ${req.path} -> ${res.statusCode}`);

And for real debugging:

console.error({
  requestId,
  error: err.message,
  stack: err.stack
});

Everything else becomes noise at 3AM.

5. Rate limiting is not “later”

I learned this after watching an endpoint get hammered and cost real money.

import rateLimit from "express-rate-limit";

const limiter = rateLimit({
  windowMs: 60 * 1000,
  max: 60,
  message: { error: "Too many requests" }
});

app.use(limiter);

If your API has no limits, it doesn’t have protection. It has hope.

Final thought

Most API failures don’t come from complex engineering.

They come from ignoring the basics because “it’ll be fine”.

It won’t.

Production doesn’t care.