DEV Community: chao xue

I built a "should I block you?" friend quiz on Cloudflare Workers — here's what I learned

chao xue — Wed, 14 Oct 2026 15:41:55 +0000

A few weeks ago I kept seeing the same post on Threads and Instagram: "I'm blocking my fake friends 🚫 should I block you?" followed by a quiz link. Someone answers ten questions about themselves, shares the link, and friends try to guess the answers. Score low and you're "blocked".

It's a simple idea, and it spreads well because every player is one tap away from making their own quiz. I wanted to see how far I could take it as a side project, so I built my own version: Block You Test Me.

This post covers the parts that turned out to be more interesting than I expected.

The stack

Next.js 16 with OpenNext on Cloudflare Workers
D1 (SQLite) for quizzes and scores, KV for rate limiting
next-intl for 8 languages
No accounts, no login. The quiz maker gets a private scoreboard link instead.

Everything runs in one Worker. There's no separate API server and no image service.

1. Instant feedback without handing out the answers

Players see whether each answer is right as soon as they tap it. That makes the game much more fun, but it means the browser has to know the right answer before the quiz is submitted.

I didn't want the answers sitting in the JSON as plain values, so each question ships two choices plus a short hash for each one:

// server
h[k] = isCorrect(choice)
  ? sha256(`${quizId}:${questionId}:${choice.index}`).slice(0, 8)
  : sha256(`${quizId}:${questionId}:x:${k}`).slice(0, 8); // decoy

The client hashes quizId:questionId:index with Web Crypto and compares. Someone with DevTools open can still work it out, and that's fine for a party game. The score on the scoreboard is always calculated again on the server, so nobody can post a fake 10/10.

The wrong choice is picked from the creator's other options using the quiz ID as a seed. Every player gets the same pair of options, so scores are comparable.

2. Dynamic OG images (and when not to use them)

The share preview is what people see in WhatsApp before they tap, so each quiz gets its own image: "Will Mia block you?". It's rendered with next/og inside the Worker.

Two things I didn't expect:

Non-Latin names. The default font only covers Latin characters. An Arabic or emoji name made next/og fetch glyphs at runtime, which added 1–2 seconds, and Arabic came out reversed. Now names outside Latin and Latin-1 get a redirect to a static image. That covers most of my users, and the edge cases fail gracefully.
Bundle size. Adding OG generation took the Worker from about 1.2 MB to about 2.0 MB gzipped. That still fit, but it became the theme of the whole project. More on that below.

3. Story cards with a QR code

Most of the similar quiz sites I looked at had no Story image to save, and none of them had a QR code, so I added two:

an invite card for the quiz maker ("Will Mia block you?" + QR code)
a result card for players ("Mia will NEVER block me 💖 9/10")

They're drawn on a 1080×1920 <canvas> in the browser, with qrcode-generator (MIT, no dependencies) for the QR code. On mobile I try navigator.share({ files }) first. Instagram and WhatsApp's in-app browsers often can't download files, so the fallback is a full-screen preview with a "long-press to save" hint.

4. Sound effects without audio files

Every tap makes a small sound. There are no audio files: everything is synthesized with the Web Audio API, a few oscillators and gain envelopes. The whole sound module is about 120 lines.

The one rule that matters: only create the AudioContext inside a user gesture. My first version replayed the result fanfare when someone revisited a finished quiz, which counts as autoplay. Now results that are loaded from localStorage render quietly.

5. Eight languages, chosen by the data

I launched in English, then added Malay, Indonesian, Filipino, Spanish and Portuguese based on where the original trend came from.

Then I looked at Google Analytics. In the first three days the site had about 600 visitors, and more than half of them had Turkish browsers, mostly arriving from Google search. I hadn't planned for Turkish at all, so I added Turkish and Vietnamese the next day.

A few i18n details that helped:

English URLs have no prefix, and the other languages do (/tr/create). Existing links never changed.
Every page has hreflang links to every other language plus x-default.
No automatic redirects based on Accept-Language. Visitors get a small "View this page in Türkçe" bar instead. Azerbaijani browsers are also offered Turkish, since the two languages are close.
Quiz IDs and answers don't depend on language. A quiz made in Turkish can be played in English with the same options and the same scoring.

6. Staying under the 3 MB Worker limit

The Workers free plan allows 3 MB (gzipped). Each language added about 70 KB, and the last feature, about 60 pop-culture questions split by region, pushed the bundle to 2.96 MB.

The fix turned out to be one line of code. I had merged two translation tables with object spread:

// before: the bundler can't drop the unused parts
QUESTIONS_I18N.tr = { ...trQuestions, ...trPopQuestions };

That made every translation reachable from the Worker entry, so nothing could be tree-shaken. Keeping the tables separate and picking one at lookup time saved 60 KB:

const table = id.startsWith("p") ? POP_I18N : QUESTIONS_I18N;

My takeaway: read the dry-run output before every deploy (wrangler deploy --dry-run prints the gzipped size).

7. Things I'd do the same way again

Make the share flow the main feature. Players finish 85% of the quizzes they start, and the "now it's your turn" button is where new quiz makers come from.
Keep data small. I only store a nickname, answers and scores. Quizzes with no plays for 90 days are deleted by a cron trigger.
Write the questions yourself. Original, gender-neutral questions with emoji options read better than copied ones, and you can translate them cleanly.

Try it

Make a quiz, send it to a friend, and see who gets blocked: blockyoutestme.app. There are also a Best Friend Test, a Couple Test and a Crush Test.

If you've built something viral on Workers, I'd like to hear how you handled bundle size and OG images. Questions are welcome in the comments.

I hope you like this tiny game.

I built an AI face rating app that shows its work: MediaPipe in the browser, an LLM on the server

chao xue — Wed, 14 Oct 2026 15:17:29 +0000

A lot of young people want to know how attractive they are, so they ask Gemini or ChatGPT to "rate my face from 1 to 10". Ask twice and you often get two different numbers, and neither answer shows how the number was reached. So I built a more methodical rating tool, where the score comes with evidence you can check yourself.

The result is PSL Rating, a small face analysis app. You upload one selfie and get a tier on the PSL scale, a 1–10 score, and measurement lines drawn on your photo.

Measure first, then judge

Measurements run in the browser. I use MediaPipe's Face Landmarker (@mediapipe/tasks-vision), which returns 478 landmarks per face, including iris centers. From those points the client computes facial thirds, eye spacing, canthal tilt, jaw width and symmetry, then draws the lines on a canvas over the photo. None of this needs a server, and it's deterministic: the same photo always gives the same lines.

The rating comes from an LLM with a carefully tuned prompt. The photo, a text summary of the measurements and a fixed rubric go to a vision model (Gemini, through a third-party API). The model returns structured JSON, which I validate with Zod before anything reaches the UI. If a field is missing or out of range, that section is dropped instead of invalidating the whole report.

The prompt matters a lot. When the model sees "eye spacing ratio 1.04, canthal tilt +4.1°" next to the image, its comments stay much closer to what the overlay actually shows.

The canthal tilt bug I almost shipped

Canthal tilt comes up constantly in face rating discussions. It's the angle of the line from the inner corner of the eye to the outer corner. The most direct way to compute it is:

Straighten the face so the eyes are level.
Measure the angle of each eye.

But that's wrong. If you level the face using the eye line, you rotate away the exact tilt you're trying to measure, and everyone comes out near 0°.

The fix is to correct head roll with a line that doesn't go through the eyes. I use the facial midline, from the top of the forehead (landmark 10) to the chin (landmark 152):

// Roll of the face itself: how far the midline (forehead -> chin) leans from vertical.
// Don't use the eye line here, or you cancel out the real canthal tilt.
export function rollRad(px: Pt[]): number {
  const t = px[LM.FOREHEAD_TOP]; // 10
  const c = px[LM.CHIN];         // 152
  return Math.atan2(c.x - t.x, c.y - t.y);
}

export function canthalTilt(P: Pt[]) {
  // P = pixel landmarks already rotated so the midline is vertical
  const tilt = (inner: number, outer: number) => {
    const dx = Math.abs(P[outer].x - P[inner].x);
    // y grows downward, so inner.y - outer.y > 0 means the outer corner is higher
    return Math.atan2(P[inner].y - P[outer].y, dx) * (180 / Math.PI);
  };
  const right = tilt(133, 33);
  const left = tilt(362, 263);
  return { left, right, avg: (left + right) / 2 };
}

Two more things to watch out for:

Convert normalized coordinates to pixels before measuring angles. MediaPipe returns x and y in 0–1, scaled by width and height separately. On a non-square image, angles computed on normalized coordinates are skewed.
Corner landmarks are noisy. They wobble by a pixel or two between frames. On a small image that's about ±1°, so the UI rounds and labels small values as "neutral" instead of pretending 0.6° means something.

If you just want to try this part, there's a standalone canthal tilt calculator that runs entirely in the browser.

Photo quality moves the score more than the face does

Early testing showed the same person getting very different results from different selfies. The cause was the photo angle: the camera below eye level, a wide-angle lens too close to the face, overhead lighting, a tilted head.

So before rating, the client runs a quick quality check (face size in the frame, head turn and tilt estimated from landmarks, brightness), and the AI also returns a short "photo check" with up to three issues and three retake steps. If the verdict is "retake", the result page says so at the top. That one card probably did more for fairness than any prompt change.

For the live camera, I first built an auto-capture countdown. It didn't work well: the damn countdown kept restarting. Now it's a large oval guide plus a shutter button the user presses themselves.

Privacy as an architecture decision

Face photos are sensitive, so the design principle is to not keep them:

The photo is sent for the rating request and never written to storage. The database keeps the report's text and numbers only.
The full report's AI style previews (for example the same face with a different haircut, one change per image) are kept in the user's own browser via IndexedDB for 30 days and cleared on logout.
It's 18+ only. Every photo gets an AI age check, and generated previews go through a moderation pass before they're shown. Of course the model gets it wrong sometimes. When I tested with a photo of my cousin, it decided she was under 18. She didn't seem too upset about it.

The trade-off is that a user who clears their browser loses the preview images. For this kind of data, I think that's the right call.

Stack

Next.js 16 deployed to Cloudflare Workers with OpenNext
D1 (SQLite) for users, credits and reports; KV for small cached values
Google sign-in, one free rating per account, then paid reports
Vitest for tests, with an in-memory store and a node:sqlite store so the D1 SQL runs in CI

What I'd do differently

I'd write the measurement code with pixel coordinates and roll correction from the start, with unit tests on synthetic landmark sets. Most of my early bugs were coordinate-system bugs.
I'd build the photo check before tuning prompts. Bad input made the prompt work look worse than it was.
I'd be more careful with wording. A face score can easily read as a judgment of someone's worth. The app calls ratings AI estimates for fun and self-improvement, and every suggestion is tagged by effort (today, weeks, months, structural) so people can see what's realistic to change.

If you've built something with MediaPipe or vision LLMs, I'd love to hear how you handled noisy landmarks or inconsistent model output. Feedback on the app is welcome too: pslrating.me.

I built a free bedroom feng shui checker that doesn’t give generic advice

chao xue — Sat, 05 Sep 2026 08:57:50 +0000

When I first tried to arrange my bedroom according to feng shui, I quickly discovered how vague the rules can be. “Put your bed in the commanding position,” every article said. But what counts as commanding when the door is beside a sloping ceiling and the only wall wide enough for a bed also contains a window?

I wanted a tool that could look at an actual room—not an ideal square diagram—and tell me whether the bed, mirror, desk, and windows conflicted with each other. After reading too many conflicting guides, I built a small JavaScript app that lets you draw your floor plan and checks it against the most common feng shui bedroom principles right in the browser. It is now live as a free feng shui bedroom layout checker with illustrated guides, and this post explains the geometry and product thinking behind it.

Why generic answers are useless for real rooms

Feng shui bedroom advice usually takes the form of “the bed should not face the door” or “do not put a mirror where it reflects the bed.” Those rules assume a rectangular room with clear layouts. Actual bedrooms have angled walls, two doors, sliding doors, radiators, or shared-wall windows. A rule like “the bed should not be in line with the door” depends entirely on where the door and bed are, so an abstract rule cannot describe a room.

That signaled a great software problem. Instead of writing a list of static tips, I could create a simple geometric model of the room and let the model answer questions. If the user draws the walls and places a bed, the code can calculate relative positions. The tool checks what actually applies to that floor plan. This approach also avoids superstition-heavy claims: the interface only highlights traditional concerns and lets the user decide whether it matters to them.

Sketching a room with canvas

To make the tool mobile-friendly and reduce friction, I used the browser's canvas with pointer events. Users draw their room by clicking or tapping corners to create walls. Unlike a general room-planner, it intentionally keeps the tool simple: walls, door, window, and furniture are the only object types needed for a feng shui assessment.

Each object is stored as a set of coordinates. Walls are polygons; doors and windows become line segments placed on walls; the bed, mirror, desk, and screen are rectangles with a front edge so the code can tell which way the user would sleep or look. The drawing layer may feel like a rudimentary CAD, but it produces enough information to run a useful rule engine:

a door is a segment with an opening direction
a window is a segment with a normal side pointing outside
a bed stores its orientation and the side where the headboard sits
a mirror is represented by the wall or object it is mounted on

I deliberately skipped straight lines and perfect right angles because real rooms are rarely perfect. For every placement, the code compares vector angles and distances instead of assuming a grid. The result is a lightweight sketch tool where the visual output is not a polished render but a meaningful map for the checks that follow.

Commanding position as a vector calculation

The central feng shui concept in the bedroom is the commanding position: the bed should have a clear view of the door, but not be straight in line with it. In a normal room, the most commanding bed position is diagonal from the door, often with an angle between 30 and 60 degrees from the line between the door and the bed.

Implementing that rule requires three pieces of information:

the center of the bed
the center of the door opening
the bed's headboard direction

With those coordinates, the app calculates whether the door is visible from a seated or lying position, and whether the headboard points toward the door. It flags the bed if the door is behind the headboard line, or if opening the door would hit the bed frame. It also checks whether the body position aligns directly with the door; if that happens, the layout gets a warning.

This is where the tool becomes more than a checklist. A bed that points toward the door on one side of a room is problematic under the traditional rule, but the same bed angle in a bigger room may be perfectly acceptable because an extra wall adds protection. A rules engine that understands room shape can see that distinction automatically.

What about mirrors and windows?

Mirrors have boggled many readers. Some traditions say they should never reflect the bed; others focus on not having a mirror directly behind a headboard. In the app, a mirror object stores its surface normal. The checker can then determine whether the mirror's reflected view can reach the bed.

The implementation is not a naïve “rectangle intersection.” It finds the closest reflecting rectangle that covers the mirror, computes the line from the bed's front edge to the mirror center, reflects it across the mirror plane, and checks whether the reflected ray intersects another object. This gives a believable answer for an oddly-sized mirror placed on a closet door or side wall. If the result is false, the tool suggests simpler fixes: move the mirror, cover it at night, or place a screen between the mirror and the bed.

Windows go through a separate check. A window above the headboard creates a draft and adds outside light in many homes. The tool flags this not as a taboo, but as a practical concern, using the bed's headboard side, the window segment, and the wall width. It will also warn if a desk faces a window and the user is working at night because screen glare is a more direct problem than any mystical principle.

Rules, not magic

One of the design decisions I am happiest about is keeping the language grounded. The long descriptions deliberately say “traditional preference” or “practical safety” instead of promising wealth or luck. That matters because a developer-made tool should earn trust through clarity. The illustrated guides also show floor-plan diagrams rather than abstract quotes, so a user can see why a change is recommended.

The feng shui labels are just culturally learned heuristics for comfort, light, direction, and room flow. Behind them are useful questions I can phrase to a browser: Is this spot visible from the door? Does a mirror reflect a sleeping person? Is there enough clearance on both sides of the bed? Developers can rarely agree on what “comfortable” means, but we can agree on vector distances. Framing features that way helped me build a tool that feels actionable instead of mystical.

What I learned from shipping it

Building the checker taught me that a niche browser tool can be valuable if it gives people a feeling of control. Users do not need a room design service; they need a quick answer with a visual explanation. The free tool at the start of this post includes all of this logic and more, works on mobile, and requires no signup. You can draw your actual room in under a minute and experiment with moving the bed around.

If you have ever struggled with a bedroom that never feels right—and if you know enough JavaScript to be curious how “feng shui” can be represented as coordinates—I hope this gives you an idea for your next weekend project: the best tools are not the ones with endless options, but the ones that tell you what is wrong with the layout you already have.

The Power of Simple Tools: Why Sometimes All You Need is a Counter

chao xue — Thu, 26 Mar 2026 17:00:54 +0000

As developers and tech enthusiasts, we often get caught up in the "feature race." We build complex systems, integrate AI into everything, and obsess over syncing data across every possible cloud. But over time, I’ve realized that the tools people actually stick with are often the ones that do exactly one thing—and do it perfectly.

Think about the small, repetitive tasks that pop up throughout the day: counting inventory in a warehouse, tracking sets at the gym, or even just tallying attendance at a local meetup. These aren't massive engineering problems, but they are frequent ones. When you’re in the middle of a task, the last thing you want is to wait for a bloated app to load, sit through a 5-second ad, or—worst of all—be forced to "Create an Account" just to start counting.

This is why lightweight, browser-based utilities still feel like magic in 2026. They are "zero-friction." You open a tab, you do the work, and you close it. No strings attached.

Lately, I’ve been focusing on this philosophy of "minimalist utility." I wanted to see how much I could strip away while still making a tool incredibly useful. The result is onlinecounter.org.

In building it, I focused on two specific pain points I noticed in other tools:

Mobile-First Interaction: Most web counters feel clunky on a phone. I wanted something that felt like a native app—responsive, snappy, and easy to tap with one hand while you're on the move.

The "Copy" Workflow: Usually, after you finish counting, you need that number somewhere else—a spreadsheet, a text message, or a note. Instead of making users manually type it out, I added a "one-click copy" feature. It’s a small detail, but it saves a massive amount of hassle.

I also made a conscious choice to skip "cloud sync." By keeping the data strictly in your local browser, the site stays lightning-fast and respects your privacy. No data leaves your device; it’s just you and your tally.

At the end of the day, not every problem needs a "platform." Sometimes, the most effective tools are the ones that quietly do their job, stay out of your way, and let you get back to what really matters.

If you’re looking for a straightforward, ad-free way to keep track of... well, anything... feel free to give it a try:
https://onlinecounter.org/

Because sometimes, less really is more.