DEV Community: Andrea Roversi

Generating a Crossword in the Browser: Why Grid Backtracking Fails and What Works Instead

Andrea Roversi — Fri, 07 Aug 2026 08:47:02 +0000

I wanted to add a crossword to my site's games, generated differently every round instead of pulled from a pre-made template. Between the idea and the first playable round there was a backtracking fill algorithm that always failed, a dictionary that grew from 200 to 671 words without fixing anything, and the discovery that the vocabulary had never been the real problem.

Three ways to generate a crossword, and the right question to ask first

There are essentially three routes for a game like this.

Fixed template: prepare N grids with words and clues already crossed by hand, and the game draws one at random. Guaranteed quality, but finite content that repeats after a handful of rounds.
Dynamic generation: keep only a dictionary of words with clues, and a fill algorithm (backtracking over a grid with black squares) crosses random words together every round. Infinite variety, but a genuinely hard constraint-satisfaction problem, with client-side generation times that can spike badly.
Semi-dynamic: fixed grid shapes, but the words that go into them are drawn at random from a length-compatible pool every round. A reasonable compromise between variety and simplicity — and the route I started from.

The first engine: fixed templates and backtracking fill

I built the full game — grid, clues, timer, keyboard, local high-score saving — with an initial dictionary of about 200 words with clues (3-8 letters) and three fixed-shape grid templates, filled every round by a backtracking algorithm: try a length-compatible word in each open slot, and if a crossing doesn't work out, back up and try another.

An automated stress test in Node — 200 iterations for each of the three templates — gave a clear result: failure almost every single time, even after growing the dictionary to nearly 400 entries.

The real problem wasn't the dictionary, it was the rigidity of the grid

The cause wasn't the amount of available words, but the structure of the templates themselves. One of the three had a vertical word running through every row of the grid, crossing six horizontal words at once — and at each of those points, the last letter of a horizontal word needs to exactly match the letter the vertical word requires at that position.

Italian words almost always end in a vowel and often start with a consonant: a combination of simultaneous constraints structurally too rigid for any reasonable amount of extra words to fix. It would take thousands of entries, not hundreds, to cover every possible combination at that spot in the grid.

The lesson that changed the approach. A bigger dictionary doesn't fix a structurally over-dense crossing constraint. Past a certain point the problem stops being "how many words do I have" and becomes "how many simultaneous letter-by-letter combinations am I asking to satisfy at one single spot in the grid".

Generating the grid at runtime wasn't enough on its own

The next attempt was dropping the three fixed templates and generating the grid's shape procedurally every round, retrying with a different layout on failure — same already-validated backtracking algorithm, but with the ability to switch templates instead of always hitting the same wall.

Even here, though, stress tests showed the same limit: some crossing combinations remain mathematically too constrained for a hand-written dictionary, no matter how many different templates get generated.

The fix: a freeform interlocking engine

At that point I changed approach entirely: instead of solving an already-drawn empty grid (the classic constraint satisfaction problem, or CSP, that most crossword generators are built on), the engine builds the grid as it plays.

It starts from a word drawn at random from the dictionary, then adds others one at a time, anchoring each new word to a letter already present in a word already placed, and checking that no conflicts arise with neighboring cells. The final shape of the grid emerges from the words themselves: there's never a pre-existing template that has to work out, so there's no "impossible" state the fill can get stuck in — it only ever builds what actually fits together.

Validated offline in Python, where computation time isn't a constraint: 100 out of 100 attempts succeeded, on both difficulty levels, with compact, well-interconnected grids. Then ported to JavaScript to run in the browser.

A bug that looked structural, and was just an execution order issue

During the JavaScript port, a stress test extracted separately to check the exact browser code kept failing for an apparently serious reason: the list of all available words came out empty, even though the dictionary loaded correctly.

It wasn't a flaw in the algorithm, but a problem in my own extraction script for the test: the order in which the two script blocks were read outside the page's real context didn't match the actual execution order in the browser. Once the extraction was fixed, the final stress test gave 200 successes out of 200 on both difficulties, at roughly 26 milliseconds per generation.

Two interface bugs born straight out of the intersections

The first: typing horizontally onto a cell shared between two words would unexpectedly flip direction to vertical, as if that cell had been deliberately clicked twice. The cause was that the focus-moving function set a cell as "active" before actually giving it focus — so when the focus handler ran, the code saw "same cell already active" even during normal sequential typing, not only during a deliberate double click.

The fix was separating the two cases: focus, even automatic focus during typing, no longer touches direction; the direction toggle only fires on a genuine click on a cell that was already the active one before that click, tracked separately through direct pointer-press events.

The second: on a letter already written by a crossing word, typing the same letter again blocked automatic advancement. The text field had a one-character limit, and if you type the same character already present without the content being selected first, the browser doesn't count it as a change — so no event, no advancement.

The fix had two parts: selecting the cell's content on every focus, so typing always replaces it, plus a direct keypress handler as a safety net for some mobile keyboards that don't fire the standard event.

The game isn't just the algorithm: background, dictionary, PWA

With the engine stable, what remained were the details that separate "it works" from "it belongs on the site". The background animation shared with the other games (animated lines on canvas) was missing, and got added using the exact same pattern used elsewhere.

The dictionary grew from 399 to 671 words, concentrating the growth on the thinner length buckets rather than the ones already well covered, and every addition was checked against duplicates before merging into the existing pool. With the bigger dictionary, a new stress test gave 300 successes out of 300 on both difficulties, at roughly 35 milliseconds per generation.

Last step, the PWA side: icons generated with the same squircle convention used for every other app on the site, keeping the original artwork whole — it wasn't square to begin with — instead of cropping it, placing it on a square canvas with a thin border in the site's own color. On iPhone, three targeted fixes: removed the gray tap highlight on cells and buttons, enabled an immediate tap response instead of the browser's default delay, and disabled autocorrect on the text cells — otherwise iOS tries to "correct" crossword letters while you're playing.

Shipping the game: redirects, sitemap, and an SEO audit that caught stale copy

Integrating the game into the site's games page also required a small layout change: slightly shrinking the cards so three fit per row instead of two, leaving the mobile behavior untouched. Then the less visible but equally necessary work: the redirect from the extensionless URL to the .html one, and the matching sitemap entry.

The final SEO audit found something more interesting than a simple character-limit overrun in the meta description: in three spots on the page — the intro paragraph, the visible FAQ section, and the same FAQ's structured data — the copy still said "almost 200 words" and described the engine as "validated fixed templates with backtracking". True sentences when they were written, turned false the exact moment the algorithm changed — and left silently in place, because nobody had gone back to check them after that change. All three were corrected, so the copy now says exactly what the game does today.

What I take away from this

A bigger dictionary doesn't fix a structurally over-dense crossing constraint: past a certain threshold, the problem stops being "how many words do I have" and becomes "how many simultaneous combinations am I asking to satisfy at one single spot in the grid" — at that point the robust fix is no longer more data, it's a different algorithm.

Building the grid word by word instead of solving one already drawn removes every "impossible" state at the root — it's not a quality compromise, it's simply a different and easier problem.

And finally, the most annoying bugs in this work were never the algorithm decisions, but the small, silent details of real interaction — a focus state set a moment too early, an identical character the browser doesn't register as a change, descriptive copy nobody updates after the underlying logic changes.

FAQ

Why can a backtracking algorithm on a fixed grid fail to generate a crossword even with hundreds of words in the dictionary?
Because the constraint that matters isn't how many words exist in total, but how many simultaneous intersections are needed at one spot in the grid. A vertical word crossing six horizontal words at once needs a coverage of letter-by-letter combinations that only a dictionary of thousands of entries can reliably provide.

What is a "freeform interlocking" crossword generator?
Instead of filling an already-drawn empty template, the generator builds the grid: it starts from one word, then adds others one at a time, anchoring each to a letter already present in a previously placed word. The grid's final shape emerges from the words themselves, so the puzzle is solvable by construction.

Why is it better to generate the grid at runtime instead of using a handful of pre-drawn fixed templates?
Because every fixed template carries a rigid crossing pattern that the dictionary either always satisfies or never does — with only a few templates, the puzzle ends up failing at the same spot every time.

Why is it worth redoing an SEO and content audit after a radical change to a page's algorithm?
Because copy written to describe "how a page works" becomes false the exact moment the implementation changes, and it survives silently both in the visible text and in the structured data — worth explicitly rechecking after every substantial change, not just at first publish.

You can play the finished game for free at roversia.it/giochi/cruciverba.

Originally published on roversia.it

I launched Roversia on Product Hunt — 39+ free browser tools, zero frameworks

Andrea Roversi — Thu, 06 Aug 2026 09:10:22 +0000

Today I launched Roversia on Product Hunt — a free, ad-free platform of 39+ browser-based utility tools I've been building solo.

The stack is deliberately minimal: vanilla JavaScript, no frontend framework, no bundler. Backend is Firebase (Auth, Firestore, RTDB, Storage) with Netlify Functions for the few things that need server-side logic — PDF processing, API proxying, that kind of thing. Zero recurring server costs was a hard constraint from day one.

Some of the tools run entirely client-side, including AI-powered ones — background removal runs fully in-browser via ONNX/Transformers.js, no server round-trip.

If you're curious about the implementation details, I've been writing about specific pieces on this blog — Firebase auth patterns, PWA architecture, that ONNX integration, and more.

Would genuinely appreciate feedback on Product Hunt if you have a minute, especially on which tools are most/least useful: https://www.producthunt.com/products/roversia?utm_source=devto&utm_medium=social

Bringing an External CRM's Chats into Firestore for AI Search: Vector Search, Webhooks, and a Stubborn Bundling Error

Andrea Roversi — Mon, 03 Aug 2026 12:00:22 +0000

A client wanted their management panel's AI assistant to answer questions like "what did this contact write me" or "who replied about a certain topic", pulling from thousands of conversations held on an external CRM. Between the idea and the first correct answer there was a bundling error that came back three times, a cursor that never advanced, and a phone number that pointed to the wrong contact.

What already existed, and what was really missing

The client's management panel already had a solid integration with the external CRM used to handle WhatsApp, SMS, and email conversations with contacts: reading sales pipelines, opening chat with bubbles and attachments, sending replies. All reusable infrastructure, already in production for a while. One specific piece was missing: no function queried the CRM's full contact directory — only opportunities inside a specific pipeline — and, more importantly, there was no way at all for the panel's AI assistant to read past conversations.

First rule, before writing a single new line of code: reuse what already worked. The function that read multiple pipeline stages in parallel, the modal that opened chat with full history, the function that sent messages — all proven and already in use. The one genuinely missing piece was a function able to search the entire contact directory, with text search and pagination, which the existing functions (built for single pipelines) didn't do.

A search that has to run across all contacts, not just the 30 loaded on screen

With tens of thousands of contacts in the directory, loading them all client-side to filter isn't an option. The correct approach is server-side search: on every keystroke (debounced by 400ms to avoid hammering the API), the backend function forwards the query to the CRM's own search engine, which runs it against the entire archive — name, phone, email — not just the results already shown on screen. What the user sees, 30 contacts at a time with a "load more" button, is only the current page, not the search scope.

A real limitation worth knowing: a third-party CRM's search is almost always a "contains" match, not fuzzy — it doesn't tolerate typos or a swapped first/last name. Worth keeping in mind both in the UI and, later in this story, in a piece of AI logic that broke for exactly this reason.

Two small but annoying interface bugs

Before tackling the hard part, two minor fixes noticeably improved the contact directory's usability. The first was a misalignment between column headers and table rows: caused by using two different layout systems, a flex container for the header and a real table for the rows, which could never match in width. The fix was putting the header inside a real <thead> in the same table, with a <colgroup> fixing the same widths for both.

The second was a cascading tag filter: a new function lists every tag that exists in the account (not just the ones seen among the contacts already loaded on screen), populates a dropdown, and selecting one reruns the same text search passing the tag name — zero new endpoints for the actual filtering, since the CRM's search engine already covered tags too.

The request that changes the scale of the project

At that point came the request that changed the nature of the work: the client wanted every contact and every conversation to also persist in their own database, kept up to date over time, queryable by the panel's AI assistant — no longer just fetched on the fly from the CRM when needed. With nearly 48,000 contacts and a chat history growing daily, this stopped being one more feature and became an architecture decision.

Why Firestore and not Realtime Database

The first decision, and the one worth getting right: Realtime Database retransmits the entire node on every write, to every connected client. With tens of thousands of contacts and conversations that keep growing, a node like contacts/{id}/messages would have become a bandwidth problem from the very first wave of writes. Firestore, by contrast, supports indexed queries, subcollections that grow without rewriting the parent document, and — the decisive reason here — native vector search, exactly what's needed for semantic search across all conversations at once, without adding a separate vector database to pay for and manage.

The data model is one document per contact (profile, tags, last sync) with a messages subcollection for history — not an array inside the document itself. A contact with hundreds of messages would soon hit the one-megabyte-per-document limit, and more importantly every new message writes a single new document instead of rewriting the entire history each time.

The batched backfill, and the first obstacle: "Cannot find package firebase-admin"

Writing and querying vector fields on Firestore reliably means using the official firebase-admin SDK, not the raw REST API. That runs against a project convention — zero npm dependencies in the existing Netlify Functions — and the exception made itself felt on the very first deploy: Cannot find package 'firebase-admin' imported from /var/task/..., despite the package being correctly declared in a dedicated package.json.

The cause is a function-bundling problem, not a code problem: the bundler simply wasn't packaging the dependency into the final zip. First attempt, explicitly setting the modern bundler via node_bundler = "esbuild" in the config — same error. Second attempt, explicitly marking the package as "external" so it wouldn't be bundled (external_node_modules), the documented standard fix for exactly this case — again the identical error, a sign the problem was no longer bundling but the install step itself during the build.

The definitive fix, when the "clean" routes aren't enough. No more half-measures: download the dependencies ahead of time and commit them already installed into the repository (so-called "vendoring" of node_modules), so the platform finds them already there instead of having to install them during the build.

The interesting practical detail: the client works entirely from a browser, with no local terminal. The solution was a browser-accessible cloud dev environment (a "codespace") with a real built-in terminal: npm install inside the functions folder, then commit and push the generated files straight from the interface — zero commands to install on the person's own computer. With node_modules physically present in the repository, the next deploy went through on the first try.

The cursor that never advanced (and the hidden cost of redoing the same work)

With bundling solved, actually importing nearly 48,000 contacts can't be a single call: it has to run in batches, repeated by a function scheduled every few minutes, with a progress cursor saved on Firestore to resume exactly where it left off. The first real run revealed a subtler problem: the cursor stayed null forever. The configured batch (25 contacts) simply couldn't finish within the function's time budget, so every execution restarted from the same initial contacts — not only failing to advance, but also re-paying for embedding every message that had already been embedded before, a silent and entirely avoidable cost.

The fix had two parts: shrink the batch size to something that genuinely completes within the available time budget, and — more importantly — check which messages already had an embedding saved from a previous run, skipping them instead of regenerating them. With that fix, the cursor finally started advancing, and a rough estimate based on the observed pace put the full historical import at about a day and a half.

Real-time messages: a "customer replied" trigger that isn't enough on its own

For new messages, the CRM's automation offered a "customer replied"-style trigger — but with a non-obvious limitation: the variables available in the webhook body exposed the contact's identity, not the message text or its real timestamp. And, more importantly, no equivalent trigger existed for "the operator replied": automation engines of this kind react to customer actions, not to internal team actions.

The sturdier fix wasn't chasing a trigger that probably doesn't exist, but changing how the available one gets used: the webhook no longer carries the message text, only the contact's identity, used as a signal meaning "this contact was just active, resync it now." The function it calls re-reads the entire fresh conversation from the same API the backfill already uses — which includes both inbound and outbound messages in the same fetch. One available trigger, full coverage on both directions. A second, lighter webhook, attached to contact-created/updated triggers, covers tag or profile changes that happen without a new message.

Dirty data in the pipeline: system events mistaken for messages

An unplanned side effect: imported messages started including system events like "opportunity deleted", generated by the CRM whenever an opportunity changes stage — not text written by either side of the conversation. The fix, minimal but needed in three separate places (the real-time webhook, the shared sync function, and the backfill job already live in production), was to explicitly filter these events by type before saving them or generating an embedding for them.

A practical reminder about this kind of change: an import job that's already live and running should be fixed with surgical patches, not rewritten for code cleanliness midway through — the risk of introducing a new bug while it's processing tens of thousands of records far outweighs the cosmetic benefit.

Searching by phone, searching by name — and a silent ambiguity

The first real test of AI search immediately exposed the limit of semantic search: searching for a phone number with the vector engine doesn't work, because the number doesn't appear in the meaning of the message text. What was needed was a direct identity lookup, not a content search — two different tools for two different questions.

The first attempt at a phone lookup produced a sneakier bug: a ten-digit local number that happened, by pure coincidence, to start with the same digits as the Italian country code was mistaken for an already-complete international number — and the search stopped at the first match found, returning the wrong contact with no warning at all. The correct fix wasn't "guess better" but checking every plausible variant in parallel (with and without the country code) and, if different contacts turn up, explicitly flagging the ambiguity instead of picking one at random. The same principle was then extended to a direct lookup by exact name and by tag, both with an automatic, silent fallback to semantic search whenever the direct match finds nothing.

The wrong time zone in the AI's answer

An easy detail to underestimate: timestamps were correctly stored in UTC, as they should be, but were passed to the language model as-is, leaving it to mentally convert them to local time in its final answer. The result was silently off by two hours, with no error to catch — a message from 1:22 PM local time was presented as 11:22 AM.

The reliable fix wasn't a more insistent prompt instruction, but removing that calculation from the model entirely: converting the timestamp server-side to the correct time zone (automatically handling daylight saving as well) before injecting it into the context, and explicitly stating that the time received is already local, so the model doesn't attempt the conversion again on its own.

How long an AI answer should be

One last problem, more mundane but frequent: some answers with long lists of messages were getting cut off halfway, with the last item — often the most recent and the most relevant one — missing. The cause was simply a response token budget too low for the language model. The fix has three layers, not just one: raise the maximum response token budget, order lists from most recent message to oldest (so any future truncation drops the least relevant data, not the freshest), and explicitly instruct the model to stay compact in its formatting, so it doesn't waste response headroom on unnecessary decoration.

What I take away from this

The broader lesson is that reusing existing infrastructure saves real time, but changing scale (from a few on-the-fly reads to tens of thousands of persistent, queryable records) is always an architecture decision, not just a code one — worth stopping to decide explicitly before writing the first line. Making an exception to an established convention like "zero npm dependencies" needs a plan B ready in advance: if standard bundling doesn't work on the first try, manually vendoring dependencies is a slow but reliable path, and it's better to know that before deploy day, not during it. Identity search and semantic search are two different tools, not one tool with two modes: using the wrong one produces a result that looks plausible but is silently incorrect, the hardest kind of bug to spot. And finally, the most annoying bugs in this work were never the "big" decisions — Firestore or RTDB, vector or text search — but the small, silent details: a time budget too tight, a time zone left unconverted, a token limit set too low. None of these throws a visible error: they just produce a wrong answer that looks right.

If you're interested in the broader reasoning behind database choices in this same management panel, I also wrote about migrating RTDB rules after an authentication issue. And if you want to see how the AI assistant that learned to read these chats is structured in the first place, the starting article is the one on the Gemini API chatbot inside the management panel.

FAQ

Why use Firestore instead of Realtime Database to store a CRM's conversations?
Because Realtime Database retransmits the entire node on every write, to every connected client: with tens of thousands of contacts and growing conversations that becomes a bandwidth problem. Firestore instead supports indexed queries, subcollections that grow without rewriting the parent document, and the native vector search needed for semantic search.

What is vector search and what is it useful for in a case like this?
It's a search by meaning rather than by exact words: each message is turned into a numeric vector (embedding) by an AI model, and a query of the same kind finds the semantically closest messages. It's useful for questions like "who asked for a refund this month", where the exact wording of the question never appears in the original messages.

Why can a Netlify Function with a dependency like firebase-admin fail in production even if it works locally?
Because the function bundler sometimes fails to correctly package heavy dependencies with native bindings or dynamic require() calls, even when explicitly setting the modern bundler or excluding the package from the bundle. In the most stubborn cases the only reliable fix is vendoring node_modules — committing it already installed into the repository instead of letting it install during the build.

Why can a phone number without its country code lead to the wrong contact?
Because a search that stops at the first match found, without checking every plausible variant of the number (with and without the country code), can return a different contact than the one being searched for by pure numeric coincidence. The correct fix is checking every variant in parallel and explicitly flagging an ambiguity instead of picking one at random.

Is it possible to capture both inbound and outbound CRM messages in real time?
It depends on the CRM: many automation engines offer a "customer replied" trigger but no native trigger for "the operator replied". In that case, it's better to use the available trigger only as a "this contact is active, resync it" signal, and re-read the whole conversation from an API that returns both directions in a single pass.

Why can timestamps stored in UTC appear wrong in an AI-generated answer?
Because if the model is left to mentally convert a UTC timestamp to local time, the calculation can be silently wrong. The reliable fix is converting the time server-side before passing it into the prompt, and explicitly stating to the model that the time is already local, so it doesn't attempt the conversion again on its own.

Bringing an External CRM's Chats into Firestore for AI Search: Vector Search, Webhooks, and a Stubborn Bundling Error

Andrea Roversi — Thu, 30 Jul 2026 10:55:59 +0000

A client wanted their management panel's AI assistant to answer questions like "what did this contact write me" or "who replied about a certain topic", pulling from thousands of conversations held on an external CRM. Between the idea and the first correct answer there was a bundling error that came back three times, a cursor that never advanced, and a phone number that pointed to the wrong contact.

Here's the full path, bugs included.

What already existed, and what was really missing

A search that has to run across all contacts, not just the 30 loaded on screen

The request that changes the scale of the project

Why Firestore and not Realtime Database

The first decision, and the one worth getting right: Realtime Database retransmits the entire node on every write, to every connected client. With tens of thousands of contacts and conversations that keep growing, a node like contacts/{id}/messages would have become a bandwidth problem from the very first wave of writes. Firestore, by contrast, supports indexed queries, subcollections that grow without rewriting the parent document, and — the decisive reason here — native vector search, exactly what's needed for semantic search across all conversations at once, without adding a separate vector database to pay for and manage.

The batched backfill, and the first obstacle: "Cannot find package firebase-admin"

Cannot find package 'firebase-admin' imported from /var/task/...

despite the package being correctly declared in a dedicated package.json.

The cause is a function-bundling problem, not a code problem: the bundler simply wasn't packaging the dependency into the final zip.

First attempt — explicitly setting the modern bundler via node_bundler = "esbuild" in the config. Same error.
Second attempt — explicitly marking the package as "external" so it wouldn't be bundled (external_node_modules), the documented standard fix for exactly this case. Again the identical error, a sign the problem was no longer bundling but the install step itself during the build.

The definitive fix, when the "clean" routes aren't enough. No more half-measures: download the dependencies ahead of time and commit them already installed into the repository (so-called "vendoring" of node_modules), so the platform finds them already there instead of having to install them during the build.

The cursor that never advanced (and the hidden cost of redoing the same work)

Real-time messages: a "customer replied" trigger that isn't enough on its own

Dirty data in the pipeline: system events mistaken for messages

Searching by phone, searching by name — and a silent ambiguity

The first real test of AI search immediately exposed the limit of semantic search: searching for a phone number with the vector engine doesn't work, because the number doesn't appear in the meaning of the message text. What was needed was a direct identity lookup, not a content search — two different tools for two different questions.

The first attempt at a phone lookup produced a sneakier bug: a ten-digit local number that happened, by pure coincidence, to start with the same digits as the country code was mistaken for an already-complete international number — and the search stopped at the first match found, returning the wrong contact with no warning at all. The correct fix wasn't "guess better" but checking every plausible variant in parallel (with and without the country code) and, if different contacts turn up, explicitly flagging the ambiguity instead of picking one at random. The same principle was then extended to a direct lookup by exact name and by tag, both with an automatic, silent fallback to semantic search whenever the direct match finds nothing.

The wrong time zone in the AI's answer

How long an AI answer should be

What I take away from this

Reusing existing infrastructure saves real time, but changing scale (from a few on-the-fly reads to tens of thousands of persistent, queryable records) is always an architecture decision, not just a code one — worth stopping to decide explicitly before writing the first line.
A dependency exception needs a plan B ready in advance. If standard bundling doesn't work on the first try, manually vendoring dependencies is a slow but reliable path, and it's better to know that before deploy day, not during it.
Identity search and semantic search are two different tools, not one tool with two modes. Using the wrong one produces a result that looks plausible but is silently incorrect — the hardest kind of bug to spot.
The most annoying bugs were never the "big" decisions — Firestore or RTDB, vector or text search — but the small, silent details: a time budget too tight, a time zone left unconverted, a token limit set too low. None of these throws a visible error: they just produce a wrong answer that looks right.

I write about Firebase, Netlify, PWAs, and AI applied to real production projects on roversia.it/blog. This post was originally published there.

When a Public API Stops Working: CORS, an Abandoned NASA Dataset, and a Netlify Function Proxy

Andrea Roversi — Tue, 28 Jul 2026 03:44:15 +0000

I wanted to build a page aggregating real-time space data from three free public sources: astronomy photos, the Space Station’s position, upcoming launches. In theory, three fetch() calls and done. In practice each of the three sources broke in a different way, and none of the three ways was what I expected.

Three sources, three different categories of risk

The idea was simple: zero server costs, zero keys to manage where possible, data read straight from the browser. The page needed to show the astronomy picture of the day and Mars rover images, the International Space Station’s real-time position, and upcoming launches with rocket and reusable-booster data — three categories, three different providers, all documented as “free public API, no complicated signup”.

I assumed “public and free” also meant “callable directly from a web page.” That’s not true by definition, and it was the first thing that surfaced once the page went live.

CORS blocked: when the problem isn’t in your code

The launches section returned a console error that was as clear as it was unhelpful at first glance:

No 'Access-Control-Allow-Origin' header is present on the requested resource

The key detail is that this check isn’t done by the API’s server — it’s done by the browser of whoever is visiting the site. If the server doesn’t include that header in the response, the browser discards the response before it ever reaches the JavaScript code, even though the requested data arrived just fine. An identical request made from a terminal works without a hitch, because CORS is a rule that only exists in a browser’s context.

The standard fix is to move the call server-side: a small Netlify Function that queries the third-party API and returns the response with the correct CORS headers pointed at your own domain. The user’s browser only talks to your own function, not to the remote API, so the browser-side CORS check simply no longer applies to that part of the path.

Almost never enough to stop there. I wrote the proxy, deployed it, and the section kept returning errors — just with a different code.

The proxy works, but the response is still a 502

With the proxy in place the CORS block was gone, but requests came back with a 502 Bad Gateway: the function was reaching the remote API correctly, but it wasn’t responding usefully. Before digging further into my own code, I checked the status of the open source project powering that API. The GitHub repository had been archived about a month earlier — read-only, no new commits possible. In the meantime some endpoints had silently migrated to a new version while others stayed on the old one, and the infrastructure behind the API showed signs of broken connectivity, not just slowness.

An archived repository is as strong a signal as a changelog entry: nobody is triaging issues anymore, nobody is shipping fixes. Continuing to debug against a service in that state is time spent chasing a target that might stop existing entirely in the meantime.

Replacing the source, not just the code

The sturdier choice at that point wasn’t another round of patches but switching providers. I found a launch-tracking API that’s professionally and actively maintained, with a different but comparable data shape: the same ability to list future and past launches, the same access to rocket configurations, and — a detail I hadn’t taken for granted — tracking of individual reusable boosters too, with serial number and status, the exact equivalent of what the discontinued API offered.

Before writing a single line of code I verified the data schema with a real live call, instead of trusting the documentation alone: a ten-minute check that avoided another round of “ship it, someone reports the bug, fix it.”

A 404 that actually means “closed for good”

In parallel, the Mars rover photos section had stopped returning results: the main endpoint responded 404, and even the fallback endpoint I’d written for exactly this situation responded 404 too. At that point the suspicion shifted from “malformed request” to “the service no longer exists,” and the confirmation came from a place I hadn’t checked first: the official data catalog linked to that API stated in plain text that the dataset contained no data, maintained by a single external developer, untouched for over a year.

The practical difference between an isolated 404 and a structural one sits right here: a single error on one endpoint, maybe intermittent, is often a temporary hiccup. Multiple related endpoints returning the same error consistently, confirmed by an independent source like an official data catalog, tell a different story — an abandoned service, not a service outage.

A replacement that slightly changes what the page promises

In place of the discontinued service I connected the same agency’s official image library, a different, actively maintained piece of infrastructure — but with a slightly different content nature: from “the latest photo the rover took in the last few hours” to “relevant images from the official archive, filtered by rover and sorted by date.” Same real photos, same institutional source, but no longer a snapshot of the exact moment.

The temptation in these cases is to pretend nothing changed and keep presenting the section as “latest photos.” I chose to state it explicitly next to the selector instead, with a line explaining why these aren’t strictly the most recent photos anymore: an honestly disclosed limitation is far less of a problem than an unexplained result the user has to figure out on their own.

A quieter bug: when structured data doesn’t tell the truth

In the final review pass I found two problems that had nothing to do with the external APIs. The first was simple: the meta description comfortably exceeded the roughly 155-160 characters Google shows before truncating awkwardly in search results. The second was sneakier: three of the six FAQPage structured-data question/answer pairs had slightly different wording than the text actually visible on the page — differences born from writing the two blocks in separate passes, invisible on a quick re-read.

Search engines expect FAQPage structured data to faithfully mirror what a visitor actually sees, not a summary or a paraphrase: even a small mismatch can make the content ineligible for the rich result. I found it with a small script that programmatically compares the two versions word for word, not by eyeballing it.

(While writing this very recap, I made the exact same mistake once — a nice reminder that this class of bug doesn’t announce itself.)

What I take away from this

The most useful lesson isn’t about a single error, but about an order in which to verify things:

A real call always beats documentation, especially for a community-maintained project.
A proxy fixes CORS but doesn’t guarantee the uptime of the service downstream — two separate problems even when they show up at the same point in the code.
An archived repository is already an answer, no need to wait for the API to formally stop responding too.
Structured data needs to be checked against visible content automatically, because small wording differences almost always slip past a manual read.

If you’re interested in the same server-side proxy pattern applied to a different case, I also wrote about summarizing PDFs with Gemini Flash-Lite via a Netlify Function. And if the topic is more generally about integrating an external API into a vanilla JS project, there’s also the article on the Gemini API chatbot inside a management dashboard.

I originally published this on my site, where you can also try the live Space page this post is about.

Removing a Photo's Background in the Browser, With No Upload: AI Licenses, ONNX Models, and a Frozen Tab

Andrea Roversi — Fri, 24 Jul 2026 12:36:06 +0000

I wanted to add a background-removal tool to my site's image cluster that stayed true to the 100% client-side processing principle I already use for PDFs and image conversions. The path there was anything but linear: a library dropped over a licensing problem, a carefully chosen model that turned out more limited than expected, and a bug that froze the entire page — not just the tool — during computation.

Here's the full build, including the parts that didn't work the first time.

The starting problem: what's actually feasible for free?

The initial idea was broad: remove backgrounds, and maybe unwanted objects too. The two tasks have very different difficulty levels.

Removing objects requires inpainting — plausibly reconstructing the erased area — which in practice still means heavy generative models, impractical to run client-side with good quality on an average device.

Removing a background, on the other hand, is a segmentation problem: separating a subject from its surroundings. That has much lighter models available, runnable entirely via WebAssembly with no server involved at all.

So: background removal only, object removal shelved for later.

The AGPL trap

The first library that looked like a perfect fit turned out to be distributed under AGPL, a strong copyleft license. Free to use — but with a real catch for anyone embedding it in a public, closed-source web service: AGPL can require releasing the full source of the project that embeds it, under the same license.

"Free for the end user" and "safe to drop into a closed-source commercial product" are two different questions, and it's worth answering the second one before writing integration code, not after deploying it.

Before wiring any "free" AI library into a commercial project, check the exact license, not just the price tag. AGPL, GPL, and other strong copyleft licenses are fine for personal or internal tools, risky for a public closed-source product.

The fix: switch to Transformers.js — Hugging Face's library for running ML models in the browser on top of ONNX Runtime Web — with a permissively licensed model (Apache-2.0) instead of the AGPL wrapper. Same principle (an ONNX model pulled once from a CDN, then cached by the browser), clean license.

A light CNN, not a heavy transformer

Picking the model taught me a lesson that generalizes to any browser-ML project: architecture matters more than file size.

A transformer-based model, even a qualitatively great one with a permissive license, can crash from memory exhaustion during WASM inference on a lot of machines. Transformer attention scales memory with the number of image "patches," and at normal photo resolution the intermediate tensors get huge. A smaller CNN with an architecture built for segmentation runs far more reliably in WASM.

Layer	Choice
Runtime	Transformers.js on top of ONNX Runtime Web (WASM)
Default model	Light CNN, Apache-2.0, optimized for people
Optional model	Heavier transformer, MIT, more general-purpose
Processing	100% local, no image upload
Cache	Browser + service worker, one-time download

The "raw matte" problem

The model often left a residual color halo around the cutout, because the output is a soft alpha matte rather than a clean binary mask — background pixels could carry residual alpha values of 5–15% instead of a clean 0.

No second model needed. Just post-process the alpha curve: force low values to full transparency, force high values to full opacity, use a smoothstep transition in between so soft edges (hair, fine detail) survive. On a test image this pushed over 60% of pixels to fully transparent and over 35% to fully opaque, leaving only a small sliver in the mid-range — a clean result.

// Simplified alpha cleanup
function cleanAlpha(a, lowT = 0.08, highT = 0.85) {
  if (a <= lowT) return 0;
  if (a >= highT) return 1;
  const t = (a - lowT) / (highT - lowT);
  return t * t * (3 - 2 * t); // smoothstep
}

The real limit: a specialized model isn't a general one

First real-world tests were disappointing on two fronts: a flat illustration (the model only trimmed the margin around the shape, leaving the whole drawing opaque) and a dim, cluttered indoor photo (the model nearly erased the main subject too).

To isolate the cause, I temporarily added a debug panel showing the model's raw mask, before any alpha cleanup, next to the final result. They were nearly identical — so the bug wasn't in my post-processing, it was upstream, in the model itself.

Checking the model card confirmed it: the default model was trained specifically on a human segmentation dataset, not a general-purpose one. On a well-lit, close-up portrait, the cutout is genuinely clean, hair included. On anything far from that training domain — illustrations, dark scenes, cluttered framing — quality drops in a predictable, not-a-bug way.

A model that's "light and WASM-reliable" is often exactly that because it's trained on a narrow domain. Before calling a model "bad," check what it was actually trained on — the mismatch is usually domain, not quality.

An optional "better model" button, not a default swap

Instead of replacing the light model with a heavier, more general one for everyone — making every user pay the load-time cost for a case they may never hit — I added a second model (an MIT-licensed transformer, better suited to generic scenes) available only on request. A "Try the better model" button appears after the first result and reprocesses the same image, without overwriting the existing output until the heavier model succeeds. If it fails from insufficient memory, the first result stays intact and the user gets a clear error instead of a broken tool.

Light by default, heavy on explicit request — nobody pays for a download they'll never use.

The real bug: the main thread freezes during inference

Testing the heavier model surfaced something much worse than mediocre output: during processing, the entire page stopped responding — not just the tool, the top nav links too.

The cause: by default, ONNX Runtime Web runs WASM computation on the browser's main thread, the same one handling clicks, scroll, and rendering. During heavy inference that thread stays busy and the whole UI freezes.

First attempt at a fix — flipping an internal library option meant to delegate computation to a separate thread — didn't work, likely due to delicate initialization timing. The reliable fix was writing and controlling a real dedicated Web Worker myself: a separate thread that loads the library, downloads the model, and runs the whole inference, talking to the main page only through postMessage (input image in, progress and result out).

// worker.js (simplified)
self.onmessage = async (e) => {
  const { imageBuffer } = e.data;
  const { pipeline } = await import('https://cdn.jsdelivr.net/npm/@huggingface/transformers');
  const remover = await pipeline('background-removal', MODEL_ID, { device: 'wasm' });
  const result = await remover(imageBuffer);
  self.postMessage({ type: 'done', result }, [result.buffer]);
};

This way the main thread never does heavy computation by construction, not by a configuration flag I was hoping would hold.

If client-side AI processing freezes the whole interface, not just the component using it, the top suspect is main-thread computation. A config flag might not be enough — a dedicated, explicitly written Web Worker is the more reliable fix.

Handling a real two-minute wait

Even with the freeze fixed, there was a perception problem left: the heavier model takes roughly two minutes on common hardware, and the library doesn't expose real percentage progress during inference — only during the model download.

A progress bar sitting "full and still" for two minutes reads as broken, not slow.

Final approach: a bar that advances on an estimated curve over ~2.5 minutes, with elapsed seconds shown below, and — if processing runs past that estimate — an automatic switch to an indeterminate animation (a continuously scrolling stripe), the universal "still working" signal without faking a percentage the model can't provide. A wider safety timeout unlocks the UI if something really goes wrong, so the user can retry.

What I took away from this

The most useful lesson isn't about one bug — it's about ordering priorities:

Check the license before you check the quality.
Check a model's training domain before you judge its output.
Don't trust a library flag for something as critical as "doesn't block the main thread" — verify it with a real test, don't assume it holds.
A clearly communicated limitation ("works best on well-lit close-up photos") is far less frustrating for users than an unexplained bad result.

If you've hit the AGPL-vs-permissive-license question before, or fought with onnxruntime-web blocking a UI thread, I'd be curious to hear how you solved it.

I write about building and maintaining roversia.it — a personal site with 35+ browser tools, PWA games, and small web apps, all vanilla JS, zero monthly cost, and (as much as possible) zero server-side processing.

Summarizing a PDF with AI for less than a cent: PDF.js, Gemini Flash-Lite, and a Netlify Function

Andrea Roversi — Wed, 22 Jul 2026 07:56:33 +0000

I wanted to add a tool to my site's PDF cluster that summarizes uploaded documents and contracts, without blowing up costs or breaking the zero-heavy-server-processing principle I follow for every other tool. Here's the architecture I picked, the real economics behind an AI-generated summary, and an authentication snag I didn't expect: Google's newer API keys use a different format than the one I'd always worked with, and they silently break the most common authentication method used in tutorials and existing code.

The problem: what does it actually cost to have an AI read a PDF?

The starting idea was simple: a tool where the user uploads a PDF — a contract, a report, a long document — and gets back a structured summary in a few seconds. The rest of the site's PDF cluster (merge, split, compress, OCR) already processes everything client-side, at zero cost. An AI summary is different by nature: it necessarily needs a call to a language model, and that has a real per-token cost. Before writing a single line of code, the real question was: what does this cost me at scale, if the tool actually gets used?

With a cheap model like Gemini Flash-Lite, the numbers were more reassuring than I expected. For a twenty-page-ish contract (roughly 13,000 input tokens plus the instruction prompt, and a 500-token summary in output), a single call costs on the order of a few thousandths of a dollar — most of the cost comes from input volume, priced far lower than output tokens. Even much longer documents stay under one or two cents. On a monthly basis, even with sustained traffic for a personal site, the worst-case spend stays in the tens of euros.

The real cost risk isn't normal use, it's abuse: someone looping the call or repeatedly uploading huge documents. That's why I built in a rate limit from day one, not as a later optimization.

Architecture: browser-side extraction, server-side AI processing

The decision that shaped everything else was to keep text extraction client-side, reusing the same PDF parsing library already used elsewhere in the site's PDF tools, and to send the serverless function only clean text, never the binary file.

Layer	Choice
Text extraction	PDF.js, entirely in the browser
Backend	Netlify Function, receives text only
AI model	Gemini Flash-Lite via REST API
Rate limiting	Per-IP/day counter on Firestore, via Admin SDK
Document storage	None — processed on the fly, nothing is saved

The main reason isn't only cost: serverless functions have tight limits on payload size and execution time. A heavy scanned PDF could easily blow past them. By extracting text in the browser, the function receives a small, predictable payload, the token cost is lower since there's no binary markup to process, and timeout risk drops close to zero. For scanned PDFs (image, not real text), OCR remains available as an optional preliminary step.

Rate limiting without forcing a login

I didn't want to put a login wall in front of a tool meant for quick, occasional use. The solution is a per-IP daily counter, saved server-side with the same service credentials already used by the site's other functions, checked before every model call and incremented right after. Once a daily threshold is hit, the function returns an explicit error instead of calling the AI.

One detail that made me stop and think: the database security rules stay at allow read, write: if false for all direct client traffic, with no need to add an exception for the new counter collection. Serverless functions use the Admin SDK with service credentials, which always bypasses the rules — so the global "deny all" automatically covers a collection created later too, with no changes needed.

The unexpected snag: an API key in a format I'd never seen

When it came time to actually wire up the API key, I got one starting with a different prefix than what I'd always worked with in previous projects. My first instinct was to assume a mistake — maybe an OAuth token copied by accident instead of a real API key.

It wasn't a mistake: it's a newer "Auth Key" format that the latest key-creation interfaces generate by default. The real problem, though, was technical: keys in the new format don't work when passed as a ?key= URL parameter — the most common method in tutorials and in already-written code — and return an authentication error. They expect a dedicated HTTP header instead.

// Before: breaks with the newer key format
const resp = await fetch(
  `https://generativelanguage.googleapis.com/v1beta/models/${MODEL}:generateContent?key=${apiKey}`,
  { method: 'POST', headers: { 'Content-Type': 'application/json' }, body }
);

// After: works with both the new and the previous key format
const resp = await fetch(
  `https://generativelanguage.googleapis.com/v1beta/models/${MODEL}:generateContent`,
  {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'x-goog-api-key': apiKey },
    body
  }
);

If a project suddenly stops authenticating with Google after regenerating a key, this is the first thing worth checking.

A side note on operational security: during debugging, the key was accidentally pasted in plain text into a chat. Even in a private channel, a key seen by anyone else (or by another system) should be treated as potentially compromised: the correct move is to rotate it immediately, not to keep using it because "no one really saw it."

Verifying the key before deploy, not after

Instead of wiring the regenerated key straight into the production function, I prepared an isolated Node.js script that makes a single test call to the model and prints only the outcome and the model name — never the key itself. On Windows, the only snag was remembering that the syntax for setting an environment variable in PowerShell differs from bash: two separate commands instead of one line.

Once I confirmed the key worked and that the model name was actually available for the account, wiring it into Netlify as a function-scoped environment variable was the last, uneventful step.

From a "form-only" page to an indexable tool

The first version of the tool page was, in practice, almost just a file upload form: functional for someone who already knows what to do, but a problem for organic search. A page with little indexable text around the form gets classified as "thin content" — search engines don't have enough signal to understand what it's about or which queries to show it for.

I added: hreflang tags, structured data for BreadcrumbList and FAQPage (on top of the existing WebApplication schema), a three-step "How it works" section, a visible FAQ matching the structured data content, and internal links to related tools. All validated before shipping: balanced markup, all JSON-LD blocks parsing correctly, no credentials in the code.

One almost comic detail: after wiring up the tool, I noticed it was missing the animated canvas background present on every other page of the site. The cause was trivial — I'd used a plain <div id="canvas-container"> in the page instead of the <canvas id="canvas"> element the shared animation script explicitly looks up by id. A reminder of how a small detail, copied wrong from a template, can go unnoticed until someone spots it by eye.

What I take away from this project

The most useful lesson isn't strictly technical: a "free for the user" tool is never truly zero-cost for whoever maintains it, and it's worth doing the math before writing code, not after. In my case the numbers confirmed the project was sustainable — but rate limiting is still the first piece I wrote, not the last. The same goes for operational security: a key seen by an extra pair of eyes gets rotated, full stop, without calculating how "likely" it is that it was actually used.

Originally published on roversia.it, where I write about the vanilla JS/Firebase/Netlify stack behind my personal projects.

PanelControl: a 65-file business app, in vanilla JavaScript with no framework

Andrea Roversi — Mon, 20 Jul 2026 08:44:50 +0000

PanelControl is an internal business app I designed and maintain solo for an official myPOS reseller: sales, onboarding, shipping, staff shifts, HR, and administration, all in one multi-role Progressive Web App. It started as a single HTML file. It's now 65+ source files and about thirty serverless functions — and it's still framework-free, with no build step.

Here's what kept it standing as it grew.

The problem

Before PanelControl, the business ran on spreadsheets, WhatsApp, email, and phone calls. Dozens of orders a day, hundreds of sales leads, contract activations, shipments, shifts, time off, payroll, plus a steady stream of leads from an external CRM — no single view, no reliable history, no way to know in real time what a colleague was doing.

I built a single PWA that centralizes all of it, installable on desktop and mobile, used daily on tablets and phones by the team.

A hand-written rendering engine

No React, no Vue. A global state object holds every piece of application data. Every state change triggers a debounced render() (80ms, to avoid cascading re-renders during closely spaced writes), plus a renderNow() for cases that need an immediate synchronous update.

The part I'm proudest of: a user-interaction guard. Before every re-render, the engine checks whether focus is on an input field, and if so, postpones the render by a few seconds so a realtime update from Firebase never wipes out a form someone is filling in — with explicit exceptions for controls that must stay reactive (month selectors, checkboxes).

Not every module loads on first launch either. Heavy modules load on-demand when the user navigates to that section, with a retry loop if the module hasn't arrived over the network yet — important since the app also runs on tablets over spotty mobile connections.

From `on('value')` to granular listeners

The single most impactful optimization in the project: migrating Firebase Realtime Database listeners from on('value') to granular child_added / child_changed / child_removed.

Before: every single write to a growing node caused every connected client to re-download the entire history.
After: only the changed delta gets transmitted.
Measured result: an estimated 40–60 MB/day saved in Firebase bandwidth, with a direct impact on pay-as-you-go costs.

The same pattern applied to the activity log cut the initial page load from 200 to 50 records via once('value'), followed by a child_added listener for new events only — about 75% bandwidth saved on that section alone.

Authentication without shared credentials

The login system was rebuilt to eliminate shared Firebase credentials on the client. A Netlify Function verifies username and password with PBKDF2-SHA256 hashing, applies server-side rate limiting against brute force, and returns a server-minted Firebase Custom Token. The client exchanges it for an authenticated session, with permissions mapped via custom claims and checked in the database's security rules.

For granular, per-operator permissions on top of the base role, I settled on one non-negotiable pattern for every access check:

access = legacy_hardcoded_list.includes(operator)
      OR hasPermission(operator, feature)

Never the dynamic check alone. This avoids breaking access for operators not yet explicitly migrated to the new permission system — a rule I've applied across every permission change in the project since: new rules OR with the old ones, they never replace them outright.

A few modules that raised real problems

Internal chat. A floating bubble UI hit the classic position:fixed bug: it stops working correctly once an ancestor has a CSS transform applied, which is common when nesting modals. Fixed by making the chat a direct sibling of the main container instead of a descendant.

Mail. Polls the Gmail API instead of using push, with a denormalized schema split across two nodes to balance list speed against detail speed. Listeners here are always granular — the nodes hold potentially heavy email bodies, and on('value') would redownload the whole mailbox on any tiny change.

Call history. A two-speed architecture: the current month stays on the Realtime Database with a capped listener, past months move to Firestore with block pagination. Searches always route to Firestore to avoid saturating the realtime database.

CRM reconciliation. A scheduled function checks each lead against the external CRM one call at a time (not a bulk dump) to stay within rate limits, rechecking recent leads every 24 hours and permanently skipping older ones once they've settled.

Fail-soft serverless functions

Backend functions are pure ESM, deliberately dependency-free. A few shared patterns across every webhook integration:

Deduplication via a business key (order number), not a CRM-generated ID
Every webhook logs to both RTDB and Firestore, for realtime visibility and historical queries
Critical alerts go out via Telegram with per-category throttling
Webhooks always respond HTTP 200, even on an internally handled error — so the external CRM doesn't retry the same request forever

One operational constraint worth knowing: Netlify environment variables cap out at 4KB per function. Large credentials like private keys end up hardcoded in the function file instead, with a note for manual rotation, rather than blowing the limit and breaking the deploy.

Takeaway

"No framework" doesn't mean "no discipline." It means writing by hand the rules a framework would otherwise give you for free — a sensible debounce, a user-interaction guard, a non-destructive permission pattern — and sticking to them as the codebase grows from one file to sixty-five.

I wrote a longer, more detailed version of this case study, plus related deep-dives on the Custom Token migration and a cross-app HMAC token, on my site: roversia.it/blog-21.

Free Online Burraco, From Scratch: Rules, Wildcards, and a Three-Tier AI in Vanilla JavaScript

Andrea Roversi — Fri, 17 Jul 2026 06:27:46 +0000

I wanted a real burraco game, playable right away against the computer, with no sign-up and none of the intrusive ads that clutter most free alternatives online. Here's how I wrote the validation for sets and runs with wildcards, pot and hand-closing logic, and a three-tier AI opponent — all with no framework, no game library, and no build step.

Why burraco, and why from scratch

Burraco is among the most searched card games online in Italy, yet good free options are scarce: many sites require an account just to start, others push straight toward paid multiplayer, others are so full of banners the match becomes unreadable on mobile. I wanted the opposite — open the page, the computer shuffles, you play. Like the other games on my site, it's all vanilla JavaScript: no card library, no engine, just DOM, CSS, and game logic.

The interesting part isn't the interface — cards, animations, layout are mechanical work — but the rules themselves. Burraco has a set of constraints that look simple until you have to turn them into code that must always work, including the edge cases: how many runs can form with two wildcards at the ends, when the pot can be opened, what happens if nobody closes and the deck runs out.

Validating sets and runs, wildcards included

The two valid melds are sets (3+ cards of the same rank) and runs (3+ cards in sequence, same suit). 2s and jokers are wild and can replace any card in either. For a set the rule is straightforward: separate real cards from wilds, check that all real cards share the same rank, and require wilds not to outnumber real cards — otherwise the set would become "mostly wild," which classic rules don't allow.

The run is trickier. I take the real cards of the same suit, compute the span between the lowest and highest rank, and the internal "gaps" left to fill are the difference between the span and the number of real cards. If the available wilds can't cover those gaps, the run is invalid. If wilds are left over after filling internal gaps, they can extend the run past either end — but only if there's "room" toward the ace or the king, since the deck doesn't wrap around.

The case that cost me the most time: a run starting at 9 and ending at king, with one leftover wild. That wild can only extend downward (9→8) because there's no room above the king. If you don't explicitly handle the asymmetry between "room below" and "room above" the span, the validator accepts impossible runs.

The actual "burraco" — the meld that gives the game its name — is a run of at least 7 cards: clean if made of real cards only, dirty if it contains one or more wilds. It's also the condition required to close a hand: without at least one burraco on the table, melding your entire hand isn't enough to win.

The pot: a rule that depends on history, not the present

The pot is a stack of 11 cards that can be taken whole instead of drawing a single card from the deck. To open it, though, a player must have melded at least one set or one clean run — no wilds. This is the rule that forced me to rethink the game state: you can't just look at what's on the table right now, because once the pot is open it stays open even if only dirty melds follow. You need a persistent flag per player — "has already opened" — set once, on the first clean meld, and never recalculated from scratch.

Whoever takes the pot adds all 11 cards to their hand in one move: a huge advantage in terms of possible combinations, but also eleven extra cards to get rid of before closing. Deciding when it's worth taking is one of the most important calls even for a human opponent, which makes it a good lever for tuning how "aggressive" the AI plays.

A three-tier AI, no neural networks

No machine learning: the opponent runs on different heuristics per difficulty, applied at three points in the turn — whether to take the pot, searching for possible melds, and choosing which card to discard.

Easy. Takes the pot only 12% of the times it could, looks exclusively for sets already sitting in hand (no run search at all), attempts a single meld per turn and then stops, and discards a random card — even a wild if it comes up, which is objectively a weak move but realistic for a beginner tier.

Medium. Takes the pot 30% of the time and switches to a greedy loop: looks for sets, then runs, then tries adding cards to melds already on the table, repeating until it finds something to play or hits a safety iteration cap. For the discard, it picks the highest-value non-wild card, to shed the risk of being stuck with heavy cards at the end of the hand.

Hard. Takes the pot 65% of the useful times, runs the same greedy loop as medium but also reuses leftover wilds to extend its own runs toward a burraco (7 cards), and crucially chooses its discard by reading the table: it computes which suits and ranks the human opponent is actually using in their melds, and avoids discarding cards they'd need, keeping wilds as a last resort.

The result is an opponent that, on the same codebase, behaves noticeably differently just by changing a handful of numeric thresholds and adding a couple of targeted heuristics — without the complexity of a real search engine.

Closing a hand, scoring, and what gets saved

A hand ends when a player melds their last card with no discard left, having already made at least one burraco — or in a stalemate if the deck runs out before anyone closes. Scoring sums the value of each player's melded cards and subtracts whatever's left in hand, with dedicated bonuses for clean and dirty burracos. Match history and total score are saved in localStorage: no account, but also no syncing across devices — a choice consistent with the "open and play" goal, worth revisiting only if real multiplayer with a backend becomes necessary.

I'd already used the same installable, zero-dependency PWA approach for Neon Breakout: the nature of the problem changes — real-time physics and collisions on canvas there, discrete rule validation and heuristic AI here — but the underlying philosophy stays the same: a self-contained HTML file, installable as an app, with no build step.

FAQ

How do you validate a run of cards with wildcards in JavaScript?
Separate real cards from wilds, compute the span between the lowest and highest rank of the same suit, and check that internal gaps are covered by the available wilds. Leftover wilds can then extend the run past either end, as long as it stays within the ace-to-king range.

How do you code an AI opponent for a card game like burraco?
No neural networks or exhaustive search needed: different heuristics per difficulty tier, applied to pot-taking probability, a greedy search for possible melds, and discard choice based on what the opponent is using.

Can you play free online burraco without signing up?
Yes: open the page and play right away against the computer, no account needed. Match history and score are saved locally in the browser via localStorage.

How does the pot work in burraco, and why is it the trickiest rule to code?
It opens when a player melds their first set or first clean run, with no wilds. It's tricky because it depends on that player's meld history, not the current table state: you need a persistent flag set only once.

Should you write a card game in vanilla JavaScript or use a framework?
For a card game with a classic HTML/CSS interface and validation logic, a framework adds complexity with no real benefit. It only starts paying off with real-time multiplayer or complex shared state.

You can play the finished game at roversia.it/giochi/burraco.

A Black Box Drawn Over a PDF Isn't Redaction — Here's How I Fixed It Client-Side

Andrea Roversi — Wed, 15 Jul 2026 13:11:10 +0000

I wanted a complete PDF editor running entirely in the browser — page reordering, annotations, highlights, a drawn signature, watermark — on the same zero-upload principle as the rest of my site's tools. The interesting technical problem wasn't the interface. It was redaction.

A black box drawn over text in a PDF covers it visually, but the text stays in the document underneath, selectable and copyable. I wanted to fix that properly.

The naive approach (and why it's wrong)

Most "redact PDF" tools out there just draw a shape over the text:

// ❌ Just draws a black rectangle over existing content
const page = pdfDoc.getPage(pageIndex);
page.drawRectangle({
  x, y, width, height,
  color: rgb(0, 0, 0)
});
// The original text is still in the page's content stream:
// selectable, copyable, extractable with any PDF parser

Open the resulting PDF in any reader, select "all text on the page" (or just copy the black area itself), and the "hidden" content reappears in the clipboard. At the data level, nothing was removed — the PDF just gained a colored rectangle on top.

The fix: rasterize, but only where it matters

The only way to truly remove content while staying fully client-side, with no server-side content-stream rewriting engine, is to convert the page into an image after applying the blackout. A bitmap has no "text underneath" to extract — there's no text left, just pixels.

The obvious trade-off: rasterizing bloats file size and kills text selectability. So the rule is to rasterize only pages that actually contain a redaction, and leave every other page exactly as it is in the original.

// Simplified export logic
for (let i = 0; i < totalPages; i++) {
  const hasRedaction = redactionsByPage[i]?.length > 0;

  if (!hasRedaction) {
    // ✅ No redaction: page copied intact, stays vector
    const [copied] = await outputDoc.copyPages(sourceDoc, [i]);
    outputDoc.addPage(copied);
    continue;
  }

  // 🔥 Page with redactions: rasterized at high resolution
  const bitmap = await renderPageToCanvas(pdfjsDoc, i, { scale: 3 });
  burnRedactionsIntoCanvas(bitmap, redactionsByPage[i]);
  burnAnnotationsIntoCanvas(bitmap, annotationsByPage[i]);

  const jpg = await outputDoc.embedJpg(bitmap.toJPEG(0.92));
  const newPage = outputDoc.addPage([bitmap.width, bitmap.height]);
  newPage.drawImage(jpg, { x: 0, y: 0, width: bitmap.width, height: bitmap.height });
}

Two details matter here. First, rasterization happens at a higher scale (3x) than on-screen display, otherwise the "burned" pages look noticeably blurrier than the vector pages that stayed in the document. Second, on rasterized pages, non-redaction annotations (text, highlights, shapes, signature, watermark) get burned into the same bitmap too — mixing rendering types on the same page causes inconsistencies across different PDF readers.

The result: a 20-page document with one redaction on page 12 produces a PDF where 19 pages stay light, vector, and text-selectable, and only page 12 is an image — with nothing extractable under the blackout.

Architecture: canvas + coordinated overlay

The rendering pattern reuses something I'd already built for a PDF form-filler tool: each page is a PDF.js rendering <canvas> plus an HTML overlay of the same size, where annotations live as elements positioned as a percentage of the current viewport, not absolute pixels. That keeps them aligned with the underlying text at any zoom level — pixel-anchored annotations would drift on every resize.

Rendering is also guarded by a per-page render token: whenever scale or content changes, a new token is generated, and an in-flight render that's no longer the latest one self-cancels instead of painting a stale frame over a fresh one. Without this, rapidly resizing the window during a heavy render produces visually broken overlapping frames — a classic async-canvas race condition.

What I learned

"Redaction" carries an implicit irreversibility requirement that a graphic overlay alone doesn't satisfy.
Rasterize selectively, not the whole document — treating an entire PDF as "less trustworthy" because of one sensitive page is a bad trade-off.
Anchor annotations to the viewport, not to screen pixels.
A per-page render token avoids race conditions on async canvases during rapid resize/zoom.
Rasterize at a higher scale than the on-screen display scale, or burned pages look noticeably worse than the vector ones next to them.
Code written for one tool pays off on the next one — the rendering/overlay engine and drawn-signature logic came from an earlier PDF form-filler tool and saved a lot of time here.

Everything runs client-side: no upload, no server processing, the file never leaves the browser.

A plaintext Firebase password authenticated anyone who visited the site — here's how I fixed it without disconnecting anyone

Andrea Roversi — Fri, 10 Jul 2026 03:15:08 +0000

While doing a routine hardening pass on an internal Firebase panel — codename PanelControl, a management tool used daily by multiple operators with different roles — what was supposed to be "let's add a few Telegram alerts for suspicious activity" turned into discovering that the app's entire login system was just a UI filter.

Anyone who opened the site already had, automatically, a Firebase identity with full read/write access to the database. Here's what happened, and how it got fixed in 5 phases without ever locking the team out mid-shift.

The setup

PanelControl is a vanilla-JS internal panel backed by Firebase Realtime Database + Firestore. Operators log in with email/password, checked client-side against a database node, with a lockout after failed attempts. Nothing unusual so far.

The original ask was narrow: add Telegram notifications for a handful of suspicious events — brute-force attempts, a never-before-seen device for an operator, an unauthorized attempt to reach the Admin section, DevTools opened during use. Pure alerting work.

Bug #1: the login button that always unlocks

Before writing any alerting logic, a review of the existing Admin-area password check turned up this:

// ❌ The "|| true" makes the whole condition always truthy
function checkAdminPwd() {
  if (el.value || true) {
    unlockAdmin(); // runs regardless of what's typed, or nothing at all
  }
}

A debug leftover that made it to production. Anyone who landed on the Admin password overlay got in by clicking "Log in" — password or not. Fixed by actually wiring the real permission check, plus a server-side-verified fallback in case the function were ever called directly from the console.

The real discovery: a shared, hardcoded Firebase credential

Looking at the Realtime Database Rules ahead of the alerting work surfaced something much bigger. The Rules restricted read/write to a single fixed auth.uid — reasonable, until you check who actually gets that uid. This ran unconditionally, for every visitor, before the login screen even appeared:

// ❌ Plaintext Firebase credentials, executed for EVERY visitor
var _fbEmail = ['[shared-account]', '[domain]'].join('@');
var _fbPass  = '[REDACTED]';
firebase.auth().signInWithEmailAndPassword(_fbEmail, _fbPass);

The app's real login form — personal email, personal password, permission checks — protected nothing at the database level. It was a UI filter sitting on top of a database that was already wide open to anyone who simply loaded the page. No need to even read the source to get the credentials; the app authenticated itself with them automatically.

This isn't a one-line patch. Credentials shipped in a public JS bundle can never be truly secret, and with one Firebase identity shared by every operator, the Rules have no way to tell an authorized operator apart from anyone who just copied those two lines into an HTTP client.

The real security perimeter of a Firebase app is its Rules, not the login form the browser shows.

The fix: a serverless login function + Custom Tokens with role claims

The architecture moves identity verification server-side, where the Firebase service account is never exposed to the client:

The operator submits email + password to a Netlify Function
The function verifies credentials against the operators node (PBKDF2 via Web Crypto API) using the service account — never in the client bundle
If valid, it computes the role and signs a Custom Token with the operator's real identity as a claim
The client calls signInWithCustomToken() instead of the old hardcoded login
Database Rules check auth.token.operatore / auth.token.admin instead of a single fixed uid

// Netlify Function — server-side only, never shipped to the client
export default async function handler(req) {
  const { email, password } = await req.json();

  // 1. Server-side rate limit: 5 attempts, then 60s lockout per email
  const attempts = await getAttempts(email);
  if (attempts.locked) return json({ ok: false, error: 'locked' }, 423);

  // 2. Verify against the operators node (service account, never client-side)
  const op = await findOperatorByEmail(email);
  const valid = op && await verifyPassword(password, op.passwordHash);
  if (!valid) { await registerFailedAttempt(email); return json({ ok: false }, 401); }

  // 3. Role claims computed server-side, unforgeable by the client
  const claims = { operatore: op.chiave, admin: isAdmin(op) };
  const token = await mintCustomToken(`op_${op.chiave}`, claims);

  return json({ ok: true, token, operatore: op.chiave, admin: claims.admin });
}

The key point: admin and operatore are decided exclusively server-side and signed into a JWT with the service account's private key. The client can't "become admin" by flipping an in-memory variable — the claim is checked by the database Rules on every single read/write, not just when the session opens.

Rolling it out in 5 phases

Swapping the Firebase identity of an app used daily by a whole team isn't a one-shot change:

Isolated function — deployed but not called from the client yet. Zero risk, testable directly.
Client with fallback — login tries the new function first, falls back to the old method if it doesn't respond.
Verification on real accounts — admin and non-admin operators from different departments, console open hunting for permission errors.
Removing the hardcoded credentials — auto-login gone, the app waits for onAuthStateChanged() instead, with session persistence synced to the "Remember me" checkbox.
Deny-by-default Rules — only once the Service Worker has propagated the new client to the whole team.

Snag #1: Rules need touching mid-migration, not at the end

The original plan left the Rules untouched until the last phase. As soon as the client started authenticating with the Custom Token in phase 2, permission_denied errors appeared on realtime chat listeners still open from before login.

Reason: changing Firebase identity at runtime immediately invalidates the permissions of anything already open under the old identity. The old Rules only authorized the shared uid — the new, perfectly valid Custom Token meant nothing to them.

Fix: an additive OR, safe to publish mid-workday because Firebase Rules aren't sessions — every read/write is re-evaluated in real time.

{
  ".read":  "auth != null && (auth.uid === '[SHARED_UID]' || auth.token.operatore != null)",
  ".write": "auth != null && (auth.uid === '[SHARED_UID]' || auth.token.operatore != null)"
}

Snag #2: deny-by-default broke the whole app for non-admins

Once the team was fully on the new client, the Rules moved to a genuinely restrictive model: root false by default, granular per-role permissions per node.

First test with a non-admin account: the app opened completely empty. No visible console errors. The cause: one node had been classified "admin read-only," but it was also one of the nodes the app reads in full before showing any screen at all, regardless of role. Restricting it left every non-admin operator hanging on a read that would never resolve — no visible error, because that specific listener had no explicit error callback.

A second node, holding operator profile data, exposed a structural limit of Firebase Rules: they don't partially filter a node. If the client reads it all at once, permission is granted or denied for the entire content — you can't say "department and email yes, password hash no" within the same node without first splitting the data. Not something to improvise mid-debug, so that node was temporarily left open to all operators (no regression — it was already fully exposed under the old shared identity), with the split planned as follow-up work.

Before restricting a node to a specific role, always check whether it's part of the app's bootstrap path for every user — not just the role that's "supposed" to see it.

Cleaning up: delete the account, don't just rotate the password

One loose end: the original shared Firebase account. Rotating its password isn't enough — nothing uses it anymore, and Firestore's rules (separate from Realtime Database) only checked request.auth != null, without checking which user. Anyone who still had the old credential could still authenticate and touch Firestore data. Cleanest fix: delete the account from Firebase Authentication entirely. An account nothing depends on doesn't need a stronger password — it needs to not exist.

What I'd tell past me

A UI-level login isn't security if the database Rules don't mirror it — worth verifying explicitly even when the login "looks" correct.
Changing Firebase identity at runtime invalidates permissions on everything already open — update Rules additively as you go, not at the end.
Firebase Rules can't partially filter a node — split sensitive data out before writing granular permissions.
Before restricting a node, check if it's on the app's bootstrap path for everyone.
A real rate limit lives server-side — a client-only counter resets on page reload.
An unused account should be deleted, not renewed — if a second system doesn't check the same claim, an old credential is still an open door.

Full bilingual write-up (with the RTDB Rules diffs, the security-alert Telegram integration, and the complete phase-by-phase checklist) on my blog.

Building a Breakout PWA from scratch: canvas, synthesized audio, and power-ups in one HTML file

Andrea Roversi — Tue, 07 Jul 2026 07:37:38 +0000

I wanted a small arcade game, installable as an app, with no dependencies and no build step. Here's how a complete Breakout came together — from a minimal skeleton to 15 hand-drawn levels, sound effects generated with the Web Audio API without downloading a single audio file, particles, screen shake, and power-ups balanced so the playfield doesn't get overcrowded.

Stack first, game second

The first question wasn't "which game" but "with what". For a simple or medium 2D game the practical options are few:

Native canvas + vanilla JavaScript — maximum control, zero dependencies
Phaser.js — a full framework with physics included, useful if you want to save time on collisions and sprites
Plain HTML/CSS — for games with complex UI (cards, puzzles, quizzes), often with no game engine needed at all

Since the rest of the site is already built as single-file HTML pages with no build step, the natural choice was to stay consistent: native canvas, one self-contained file, easy to understand and deploy.

The minimum requirements to make it actually work as an installable PWA are three:

A manifest.json with a name, icons at least 192px and 512px, and display: "standalone"
A service worker for offline caching and installability
HTTPS, mandatory but already provided free by many hosting providers

Progress saving, at this stage, is deliberately simple: localStorage, no backend.

Why Breakout

Among the options considered — a grid puzzle, a themed memory game, a timed quiz, a Wordle-like, a light idle-management game — Breakout won on the ratio between development time and immediate payoff: simple collision logic, native canvas with no complex sprites, and a genre that lends itself well to becoming an installable arcade app.

The initial choices were deliberately minimal to get started quickly:

Iteration	What it adds
1 — Skeleton	Canvas, paddle, ball, random bricks, installable PWA
2 — Levels	10 then 15 fixed levels, multi-hit and indestructible bricks, level selector
3 — Visuals and audio	Trail, particles, synthwave background, sounds via Web Audio API
4 — Game feel	Screen shake, 4 power-ups, drop-probability balancing

From random levels to 15 hand-drawn ones

The first version generated bricks with a semi-random grid: functional, but with no personality. The next step was replacing it with hand-drawn patterns — pyramids, checkerboards, diamonds, corridors, a "fortress" — each with a deliberate difficulty curve.

At that point two kinds of special brick came in:

multi-hit: need two hits, change color after the first and award more points
indestructible: bounce the ball but never break and don't count toward level completion

💡 An easy detail to forget: once you add indestructible bricks, every place in the code that checks "how many bricks are left to finish the level" needs to explicitly exclude them, or the level becomes impossible to complete.

With 10 fixed levels came the rest of the progression too: high score and highest level reached saved together in localStorage, and a level selector that unlocks only levels already seen at least once. Later the progression was extended to 15 levels, with denser patterns toward the end, up to a final level that's almost entirely indestructible except for one opening row.

Neon visuals and sound without a single audio file

The base version worked but looked visually bare. Next came a glowing trail behind the ball, colored particles when a brick explodes, a synthwave-style grid-and-scanline background, a pulsing glow on the paddle, and a flash on contact with the ball.

For audio, the goal was zero files to download: the Web Audio API lets you generate oscillators directly in JavaScript, modulating frequency and volume over time:

function beep(freq, duration, type = 'square', volume = 0.15) {
  if (!audioCtx || muted) return;
  const osc = audioCtx.createOscillator();
  const gain = audioCtx.createGain();
  osc.type = type;
  osc.frequency.value = freq;
  gain.gain.value = volume;
  gain.gain.exponentialRampToValueAtTime(0.001, audioCtx.currentTime + duration);
  osc.connect(gain).connect(audioCtx.destination);
  osc.start();
  osc.stop(audioCtx.currentTime + duration);
}

A different sound for a wall bounce, a paddle bounce, a normal brick, a multi-hit brick, and an indestructible one, plus short melodies for losing a life, game over, and level complete.

One non-negotiable technical detail: browsers require a user interaction to start the audio context, so the first sound only plays on the first tap or click — it should be handled as expected behavior, not a bug.

Screen shake and power-ups: from "it works" to "it feels alive"

Screen shake, when you lose a life, is simpler than it sounds: apply a random, decreasing translate() to the canvas context for a few frames before drawing the scene, without touching the real position of the ball, paddle, or bricks.

For power-ups (wide paddle, slow ball, 3-ball multi-ball, extra life), the tricky part wasn't the idea but restructuring the update logic: the main ball and any extra multi-ball balls had to share the same behavior instead of duplicating code. The more robust fix was extracting a reusable updateSingleBall() function, called in a loop over every ball on screen.

⚠️ The first attempt at "slow ball" scaled dx/dy every frame with a multiplicative factor, risking divide-by-zero when restoring speed. The more robust version applies the scaling once, on activation and deactivation of the effect, not every frame.

Balancing drop probabilities

The first power-up version used a 28% total drop chance per normal brick destroyed — with hundreds of bricks per playthrough, the field got crowded far too fast.

Power-up	Before	After
🟢 Wide paddle	9%	5%
🔵 Slow ball	9%	4%
🟡 Multi-ball	7%	3.5%
🔴 Extra life	3%	1.5%

The general principle: minor helpers can stay relatively frequent because their impact is limited and temporary, while strong ones need to stay rare — otherwise the game loses the tension that makes it interesting. Power-ups only drop from normal bricks, never from multi-hit or indestructible ones.

Where it landed

The game is now a fully installable PWA: 15 fixed levels with multi-hit and indestructible bricks, a level selector, visual and audio effects generated without external assets, screen shake, and 4 balanced power-ups. The service worker caches all assets for offline use, and the cache version gets bumped on every deploy to avoid mismatches between the served and cached versions.

Openly postponed for now: more advanced power-ups and syncing scores across devices via a backend, instead of the current localStorage-only approach.

Original article with the bilingual IT/EN version, FAQ, and a live demo of the game: roversia.it

DEV Community: Andrea Roversi

Generating a Crossword in the Browser: Why Grid Backtracking Fails and What Works Instead

Three ways to generate a crossword, and the right question to ask first

The first engine: fixed templates and backtracking fill

The real problem wasn't the dictionary, it was the rigidity of the grid

Generating the grid at runtime wasn't enough on its own

The fix: a freeform interlocking engine

A bug that looked structural, and was just an execution order issue

Two interface bugs born straight out of the intersections

The game isn't just the algorithm: background, dictionary, PWA

Shipping the game: redirects, sitemap, and an SEO audit that caught stale copy

What I take away from this

FAQ

I launched Roversia on Product Hunt — 39+ free browser tools, zero frameworks

Bringing an External CRM's Chats into Firestore for AI Search: Vector Search, Webhooks, and a Stubborn Bundling Error

What already existed, and what was really missing

A search that has to run across all contacts, not just the 30 loaded on screen

Two small but annoying interface bugs

The request that changes the scale of the project

Why Firestore and not Realtime Database

The batched backfill, and the first obstacle: "Cannot find package firebase-admin"

The cursor that never advanced (and the hidden cost of redoing the same work)

Real-time messages: a "customer replied" trigger that isn't enough on its own

Dirty data in the pipeline: system events mistaken for messages

Searching by phone, searching by name — and a silent ambiguity

The wrong time zone in the AI's answer

How long an AI answer should be

What I take away from this

FAQ

Bringing an External CRM's Chats into Firestore for AI Search: Vector Search, Webhooks, and a Stubborn Bundling Error

What already existed, and what was really missing

A search that has to run across all contacts, not just the 30 loaded on screen

The request that changes the scale of the project

Why Firestore and not Realtime Database

The batched backfill, and the first obstacle: "Cannot find package firebase-admin"

The cursor that never advanced (and the hidden cost of redoing the same work)

Real-time messages: a "customer replied" trigger that isn't enough on its own

Dirty data in the pipeline: system events mistaken for messages

Searching by phone, searching by name — and a silent ambiguity

The wrong time zone in the AI's answer

How long an AI answer should be

What I take away from this

When a Public API Stops Working: CORS, an Abandoned NASA Dataset, and a Netlify Function Proxy

Three sources, three different categories of risk

CORS blocked: when the problem isn’t in your code

The proxy works, but the response is still a 502

Replacing the source, not just the code

A 404 that actually means “closed for good”

A replacement that slightly changes what the page promises

A quieter bug: when structured data doesn’t tell the truth

What I take away from this

Removing a Photo's Background in the Browser, With No Upload: AI Licenses, ONNX Models, and a Frozen Tab

The starting problem: what's actually feasible for free?

The AGPL trap

A light CNN, not a heavy transformer

The "raw matte" problem

The real limit: a specialized model isn't a general one

An optional "better model" button, not a default swap

The real bug: the main thread freezes during inference

Handling a real two-minute wait

What I took away from this

Summarizing a PDF with AI for less than a cent: PDF.js, Gemini Flash-Lite, and a Netlify Function

The problem: what does it actually cost to have an AI read a PDF?

Architecture: browser-side extraction, server-side AI processing

Rate limiting without forcing a login

The unexpected snag: an API key in a format I'd never seen

Verifying the key before deploy, not after

From a "form-only" page to an indexable tool

What I take away from this project

PanelControl: a 65-file business app, in vanilla JavaScript with no framework

The problem

A hand-written rendering engine

From on('value') to granular listeners

Authentication without shared credentials

A few modules that raised real problems

Fail-soft serverless functions

Takeaway

Free Online Burraco, From Scratch: Rules, Wildcards, and a Three-Tier AI in Vanilla JavaScript

Why burraco, and why from scratch

Validating sets and runs, wildcards included

From `on('value')` to granular listeners