DEV Community: Jonas Hämmerle

Caching exchange rates correctly: per-day TTL, not per-request memoization

Jonas Hämmerle — Sat, 19 Sep 2026 13:16:30 +0000

If you're converting to several currencies at once — a pricing page showing a product in 8 currencies, say — the naive approach is one /convert call per currency pair. That works, but it's leaving an easy optimization on the table: ECB-sourced rates update once per business day, so there's no reason to be making fresh network calls more often than that.

The right cache key isn't "this specific conversion," it's "the rate table for this base currency, as of today's date":

const rateCache = new Map(); // key: `${base}:${isoDate}`

async function getRatesForDay(base) {
  const today = new Date().toISOString().slice(0, 10);
  const key = `${base}:${today}`;
  if (rateCache.has(key)) return rateCache.get(key);

  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/rates?base=${base}`, {
    headers: { "X-RapidAPI-Key": key_env, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  const data = await res.json();
  rateCache.set(key, data);
  return data;
}

One call per base currency per day gets you every target currency's rate in that response — /v1/rates returns the full table, not just one pair — so converting to 8 currencies from a cached table is 8 in-memory lookups, not 8 network round-trips.

Two things worth being careful about: cache the date the rate was published, not the date you fetched it (a request right after midnight UTC might still be serving yesterday's ECB publish if today's hasn't landed yet), and don't cache across a process restart without also persisting the date key — a stale in-memory cache that outlives its day is exactly the silent-wrong-number problem you're trying to avoid.

Currency API's /v1/rates endpoint is built for this pattern — pull the whole table once, cache it client-side for the day, and reserve /v1/convert for one-off single conversions where pulling the whole table would be overkill. Sibling APIs on the same account: Validate and QR API.

The QR code capacity cliff: why a shortened URL scans more reliably than a long one

Jonas Hämmerle — Thu, 17 Sep 2026 14:19:51 +0000

QR codes don't degrade gracefully as you stuff more data into them — they hit a capacity ceiling per version/error-correction combination, and the module grid gets denser and denser as you approach it. Past a certain point you're not looking at a QR code you can scan from arm's length anymore, you're looking at one that needs to nearly touch the camera lens to resolve.

The numbers, roughly: at the lowest error correction level (L), a QR code tops out around 2,900 alphanumeric characters or ~4,300 numeric-only characters. That sounds like a lot until you remember two things:

Every character costs more space than you'd think, because the encoding also has to carry the error-correction payload alongside your data — that's not overhead you can opt out of, it's the whole point of the format being scannable at all.
Real-world scanning distance matters more than theoretical capacity. A QR code sized for a business card that's encoding near the character ceiling will produce a module grid so fine-grained that a phone camera needs to be uncomfortably close to resolve individual modules.

The fix is almost always: don't encode raw data, encode a short pointer to it. A URL-shortened link, a UUID that looks up a record server-side, a short numeric ID — anything that keeps the encoded payload well under a hundred characters keeps the module grid coarse enough to scan reliably from a normal distance, at a normal print size.

# fine — short, scans easily even printed small
curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://short.link/x7f2" ...

# avoid — encoding a full JSON payload directly makes the grid dense
# and print-size-sensitive for no real benefit over a lookup pointer

If you're building this into a product, cap the accepted input length and fail with a clear error before hitting the encoder's own hard limit — silently truncating someone's data is worse than telling them up front. QR API caps data at 2000 characters for exactly this reason: comfortably under the spec's own ~2900-character ceiling at the lowest ECC level, with a clear 4xx instead of an encoder crash past it. Same account also runs Validate and Currency API.

MX record checks: the cheap email validation step everyone skips

Jonas Hämmerle — Tue, 15 Sep 2026 14:19:14 +0000

Regex-validating an email address only tells you the syntax is plausible. It says nothing about whether user@totallyfakedomain12345.com can receive mail. An MX record lookup closes that gap for basically zero extra latency.

import { resolveMx } from "node:dns/promises";

async function domainCanReceiveMail(domain) {
  try {
    const records = await resolveMx(domain);
    return records.length > 0;
  } catch {
    return false;
  }
}

This won't catch every typo (an MX record existing doesn't mean the specific mailbox exists — that needs an actual SMTP handshake, which is slow, unreliable, and often blocked by mail servers as spam-probing behavior). But it's a strong, cheap signal that catches a meaningful chunk of junk signups before you send a verification email into the void.

I run this as an optional flag on the email endpoint of Validate — syntax check always runs, MX check is opt-in since it adds a DNS round-trip. Sibling APIs on the same account: QR API and Currency API.

Why a currency API should return 502, not a stale rate, when the upstream is down

Jonas Hämmerle — Sat, 12 Sep 2026 12:59:36 +0000

A tempting shortcut when your rate source is unreachable: serve the last cached rate and let the request succeed. For most APIs that's a reasonable degradation strategy. For anything touching money, it's the wrong default.

The problem isn't that a stale rate is wrong — it's that a stale rate looks identical to a correct one from the caller's side. A 200 response with a slightly-off number is far more dangerous than an honest failure, because nothing downstream knows to treat the value with suspicion. A checkout flow that silently converts at yesterday's rate doesn't fail loudly; it just quietly overcharges or undercharges, and nobody notices until a reconciliation problem shows up much later.

async function getRateOrFail(base, target) {
  try {
    const res = await fetch(upstreamUrl(base, target));
    if (!res.ok) throw new Error(`upstream returned ${res.status}`);
    return await res.json();
  } catch (err) {
    // Explicit failure, not a stale fallback — the caller needs to know
    // "we don't have a trustworthy number right now," not get a wrong one.
    throw new UpstreamError(err);
  }
}

The tradeoff this makes explicit: you're accepting worse availability (a 502 during an upstream outage) in exchange for a hard guarantee that every successful response is a real, current-as-of-its-timestamp rate — never a guess dressed up as data.

This is the one place Currency API's "no fabricated data" principle gets tested in practice: if Frankfurter (the ECB rate proxy it uses) is unreachable, the API returns a clean 502 upstream_error instead of quietly serving whatever it last had cached. Same principle sibling API Validate applies to its VIES/MX lookups — fail honestly rather than silently degrade on anything where the caller can't tell the difference between fresh and stale. Third sibling API on the same account: QR API.

SVG output for QR codes: why vector beats raster once anyone screenshots or resizes it

Jonas Hämmerle — Thu, 10 Sep 2026 13:40:11 +0000

Raster QR codes (PNG/JPEG) look fine at the size they were generated for and fall apart the moment someone resizes, screenshots, or prints them larger — the module edges blur, and blurred module edges are exactly what breaks a decoder's ability to read the grid.

SVG sidesteps this completely because a QR code is fundamentally vector data already — it's a grid of black/white squares, not a photograph. Rendering it as <rect> elements instead of a pixel bitmap means it stays crisp at any zoom level, print size, or screen density:

<img src="qr.svg" alt="Scan to open" width="600" />

That's a 600px display of a code that could've been generated at any size — no upscaling artifacts, because there was never a fixed pixel grid to begin with.

A couple of practical notes if you're embedding these in a product:

Inline the SVG (rather than referencing it as an <img src>) if you need to style fill colors with CSS at render time instead of baking colors in server-side.
Strict hex validation on any color params matters more than it looks — if a QR generation endpoint lets you pass custom foreground/background colors and embeds them directly into SVG attributes, that's an injection surface if the values aren't validated as actual hex colors first.
Raw matrix output is still useful — for canvas rendering, terminal output, or anything that isn't "embed an image," getting the boolean module grid directly beats parsing an SVG back into pixels.

QR API returns image/svg+xml by default from GET /v1/qr, with a /v1/qr/matrix variant returning the raw grid for exactly that second use case. Sibling APIs on the same account: Validate and Currency API.

Why I put input validation behind an API instead of a shared npm package

Jonas Hämmerle — Tue, 08 Sep 2026 13:36:28 +0000

Most validation logic (IBAN, VAT, phone, email, credit card format) is language-agnostic — it's just string parsing and checksums. So why did I build it as an HTTP API instead of a JS library?

A few reasons that mattered to me:

Polyglot by default. An HTTP API works from Python, Go, Ruby, whatever — a JS package only works in JS projects.
No dependency upgrades to babysit. libphonenumber's metadata changes as countries update numbering plans; that's my problem to keep current, not every consumer's.
The VIES/MX-record/breach-check lookups need a server anyway. Those aren't pure functions — they're network calls. Once you need a server for those, you may as well put the offline checks behind the same API for consistency.

The tradeoff is obviously latency — a network round-trip beats a local function call every time. For anything on a hot path doing thousands of validations per second, a local library is the right call. For "validate this form submission once," the API overhead is noise.

If you want to see the actual shape of it: Validate on RapidAPI — free tier, no card required. Source structure is public too: https://github.com/Jay-Ecommerce/validate-api. Same account also runs QR API and Currency API.

ECB reference rates vs live FX feeds: what 'updated once a day' actually costs you

Jonas Hämmerle — Sat, 05 Sep 2026 12:54:28 +0000

Most currency-conversion needs in a typical web app — pricing pages, invoicing, displaying a rough converted total — don't need a tick-by-tick FX feed, but it's worth being explicit about what you're trading away when you use ECB reference rates (published once per business day) instead.

What ECB rates are good for: pricing display, invoicing, order totals shown to a customer, anything where "the rate as of this morning" is an acceptable, disclosed approximation. They're free, stable, and don't require an account.

What they're not good for: FX execution, arbitrage, anything where being a few hours stale has real financial consequences. If you're actually trading currency, not just displaying a converted number, you need a feed that updates far more often than once a day — and probably isn't free.

The practical pattern that works for the first category:

async function getRate(base, target) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/convert?from=${base}&to=${target}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { rate, result, date } — "date" tells you exactly how fresh this is
}

The date field matters more than people give it credit for — surfacing "rate as of {date}" next to a converted price, rather than presenting it as live, sets the right expectation and avoids a support ticket when someone notices the number doesn't match what their bank showed them an hour later.

Currency API is built on exactly this tradeoff: ECB reference rates via Frankfurter, free and keyless, explicit about being once-a-day data rather than pretending to be a live feed. Same account also runs Validate (IBAN/email/phone/etc. format checks) and QR API (QR code generation) if useful for the rest of a checkout/invoicing flow.

QR code error correction levels: L vs M vs Q vs H, and when the tradeoff is actually worth it

Jonas Hämmerle — Thu, 03 Sep 2026 13:39:01 +0000

Every QR code has a Reed-Solomon error-correction level baked in — L (~7% recovery), M (~15%), Q (~25%), H (~30%) — and picking the wrong one either wastes visual density or leaves you with a code that stops scanning the moment it gets a little damaged.

Here's the actual decision, not just the percentages:

L — clean digital display only (a code shown on a screen, never printed, never overlaid with anything). Smallest, least dense module grid for a given payload.
M — the safe default for most printed material. Handles minor print smudging or a slightly low-quality printer.
Q — printed material that gets handled a lot (product packaging, shipping labels) or is at moderate risk of scuffing.
H — anything with a logo or graphic overlaid on top of the code, since that overlay is itself "damage" the decoder has to recover from. Also the right call for outdoor/weather-exposed prints.

The mistake I see most often: defaulting to H everywhere "to be safe." Higher error correction means more modules for the same data, which means a denser, harder-to-scan-from-a-distance code with zero benefit if nothing's ever going to obscure it. Match the level to the actual damage risk, not to the theoretical maximum.

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&ecc=Q" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

QR API exposes ecc as a plain query param (defaults to M) so you can set it per use case instead of hardcoding one level everywhere. Same account also runs Validate (IBAN/email/phone/etc. format checks) and Currency API (exchange rates).

Luhn's algorithm: the 70-year-old checksum still validating every card you own

Jonas Hämmerle — Tue, 01 Sep 2026 14:07:54 +0000

Every credit card number has a built-in checksum digit, and the algorithm that checks it (Luhn's algorithm) predates modern computing — it was patented in 1954, before credit cards as we know them existed.

function luhnValid(number) {
  const digits = number.replace(/\D/g, "").split("").reverse().map(Number);
  const sum = digits.reduce((acc, digit, i) => {
    if (i % 2 === 1) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    return acc + digit;
  }, 0);
  return sum % 10 === 0;
}

This only checks that the number is structurally valid — it says nothing about whether the card exists, is active, or has funds. That's a completely separate (and much more sensitive) concern that needs a real payment processor, not a format checker.

Brand detection (Visa vs Mastercard vs Amex) is a second, separate step based on the IIN/BIN prefix ranges. I bundled both into one endpoint on Validate since they're almost always needed together. Same account also runs QR API and Currency API.

Looking up a historical exchange rate correctly (and why 'the rate on that date' is fuzzier than it sounds)

Jonas Hämmerle — Sat, 29 Aug 2026 14:37:05 +0000

A common ask in invoicing/reconciliation code: "what was the USD/EUR rate on 2024-01-15?" The naive approach — pick a rate source, hit it with a date, trust the number — glosses over one detail that matters: ECB reference rates only publish on business days, so "the rate on" a weekend or bank-holiday date doesn't exist as a distinct value.

The honest way to handle this is to resolve the requested date to the nearest actual trading date and say so in the response, rather than silently picking one:

async function getHistoricalRate(date, from, to) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/historical?date=${date}&from=${from}&to=${to}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { from, to, rate, date } — "date" is the resolved trading date, not necessarily the one you asked for
}

Two failure modes worth guarding against explicitly, not just the happy path: a future date (there's no "historical" rate for a date that hasn't happened) and a date before your data source's coverage starts (ECB/Frankfurter data begins 1999-01-04 — pre-Euro-era rates aren't there). Both should be a clean 400, not a confusing 502 or a silently wrong 200.

Currency API's new /v1/historical endpoint does exactly this: validates the date up front (rejects future/out-of-range/malformed dates with a 400), resolves weekend/holiday dates to the prior business day, and returns which date it actually used — same "fail honestly, don't fabricate" principle as the rest of the API. Sibling APIs on the same account: Validate and QR API.

Branded QR codes without a design tool: setting foreground/background color via query params

Jonas Hämmerle — Thu, 27 Aug 2026 19:52:52 +0000

The default black-on-white QR code works fine functionally, but it clashes with pretty much every brand style guide the moment you drop it into a poster, product package, or app screen. Most "just generate a QR code" APIs don't expose color at all, which pushes color-matching into a separate image-editing step after the fact — recoloring an SVG's fill by hand, or worse, round-tripping through a design tool for something that should be a one-line request.

QR API takes color (module/foreground) and bgColor (background) as plain hex query params on GET /v1/qr, no leading #:

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&color=1a2b3c&bgColor=f4f1ea" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

Both default to black-on-white (000000/ffffff) if omitted, so existing integrations don't need to change anything to keep their current output.

Two things worth knowing if you're picking colors instead of just accepting the defaults:

Contrast still has to survive a camera, not just a screen. A QR decoder needs a clear light/dark distinction between modules and background — a pastel-on-pastel combination that looks fine in a design mockup can fail to scan reliably once printed or viewed under bad lighting. Keep real contrast between the two hex values, not just a stylistic difference.
Validate hex input server-side if you ever accept it from a user. These values get embedded directly into SVG fill attributes, so strict 3/6-digit hex validation isn't optional — it's the difference between a color param and a markup-injection vector.

Same /v1/qr/matrix raw-grid endpoint is unaffected by color params since it returns boolean modules, not rendered output — colors only apply to the SVG path. Sibling APIs on the same account: Validate and Currency API.

EU VAT number validation: format check vs VIES lookup, and when you need which

Jonas Hämmerle — Tue, 25 Aug 2026 09:49:58 +0000

If you sell B2B in the EU, you'll eventually need to validate a customer's VAT number. There are two very different levels of "validation" here and it's worth knowing which one you actually need:

Format validation — does the string match the country's VAT number pattern (length, structure)? This catches typos instantly, works offline, and is free forever.

VIES lookup — is this VAT number actually registered with that EU country's tax authority right now? This requires a live call to the European Commission's VIES service, can be slow (VIES has outages more often than you'd like), and is the only way to know if the number is real vs just correctly-formatted.

For most signup flows, format validation is enough to catch mistakes, with an optional VIES check before you actually apply a reverse-charge VAT exemption (since that's the part with tax liability implications).

POST /v1/validate/vat
{ "countryCode": "IE", "vatNumber": "6388047V", "checkExistence": true }

That's the shape I settled on for Validate — format check always runs, VIES lookup is opt-in per request so you're not waiting on a flaky government API when you don't need to. Sibling APIs on the same account: QR API and Currency API.