Watchario

When a user finishes an episode, that one event has to land on every account they have linked. The providers do not share a vocabulary: one calls a list state CURRENT, another watching; scores are 0–10 on one service, 0–100 on another, and five smiley faces on a third.

The write goes to the primary provider first, because that is the one the user sees in their catalogue and the one whose failure must surface immediately. Only then do the secondaries fan out concurrently, each through a normalisation layer that maps the canonical status and score into that provider's model. A secondary failing is logged and retried, not surfaced as an error — the user's own list already updated.

The same path is reused by every entry point: the web UI, the Stremio addon, the browser extension, and Plex/Jellyfin/Emby webhooks. There is exactly one place in the codebase where a progress update is written, which is the only reason four surfaces stay consistent.

Everything above depends on a question none of the providers can answer: is the thing the user just watched on service A the same thing as this entry on service B? Each maintains its own identifier namespace, and the film and television databases the metadata comes from maintain three more.

So a title has to resolve across seven namespaces — AniList, Kitsu, MyAnimeList, IMDb, TMDb, TheTVDB and AniDB — and the mapping is not static: new titles appear weekly and existing entries get corrected. An automated pipeline refreshes it daily from the open mapping datasets, enriches the gaps, and publishes the result through the public API so other projects can use it too.

The hard cases are structural rather than missing rows. A franchise that one service models as seasons 1..N is often a single flat season elsewhere, so a split-cour show has to be sliced back into per-cour numbering using the preceding cours' episode counts — otherwise opening the second cour of a series shows all forty episodes instead of its own twelve. Reconstructing that requires walking the relation graph, not a lookup table.

Each provider gets its own native flow, so no password ever passes through infrastructure I control unless the provider gives me no alternative: AniList uses authorization code, Trakt likewise, MyAnimeList uses PKCE, and Kitsu offers only a resource-owner password grant.

MyAnimeList advertises PKCE but accepts only code_challenge_method=plain — the variant every guide tells you not to use. There is no way to make it S256; the choice is to implement it as specified or not support MyAnimeList. I implemented it, and documented why in the repository so the next person to read that code does not "fix" it.

Refresh failures do not cascade. A provider whose refresh token has expired is flagged for lazy re-authentication and its pill in the UI shows a needs reauth badge; the other three keep working. Losing one linked account should never mean re-linking all of them.

Users can point Watchario at their own third-party addon endpoints, which means the server makes outbound HTTP requests to hosts a user chose. That is a server-side request forgery primitive unless it is handled deliberately.

Checking the hostname before the request is not enough: the default handler follows redirects, so a URL on a legitimate public host can answer 302 pointing at [::1] or a private cloud address, and a naive client will follow it and hand back the body. The real boundary has to be at the socket.

So user-supplied traffic goes through a dedicated named HttpClient whose ConnectCallback vets the resolved address of every hop, with a connect timeout and a response-size cap. The pre-flight hostname check stays, but only to produce a decent error message when someone pastes something wrong.

A related trap cost me a real leak: those addon URLs embed per-user API keys, and HttpClient's own framework logging writes the full request URI at Information. The keys were going into production logs without a single log statement of mine being involved. The fix pins that client's log category to Warning, and an automated check now fails the build if anyone lowers it.

The same instinct governs crash reporting: diagnostics are opt-out, and the payload is redacted on the device before it is uploaded, so keys and tokens never leave the user's phone in the first place. Redacting at the receiving end would have been less code and the wrong boundary.

When an episode a user is watching airs, they should get a notification at the moment it airs — not up to an hour later. The obvious implementation is a minute-resolution polling job, which is both wasteful and still imprecise.

Instead an in-process BackgroundService pulls the airing schedule once a day and arms one timer per upcoming episode. Notifications fire exactly on time, the database is not polled, and there is no external scheduler to operate.

That design has one honest weakness: the machine auto-stops when idle to keep hosting costs near zero, and a stopped machine has no timers. A small Cloudflare Worker therefore pings the app at the airing moment to wake it — free-tier cron triggers and KV, no Durable Objects. The in-process scheduler remains the mechanism; the Worker only guarantees the process is alive to run it.

One SQLite file holds every account: tokens, linked providers, notifications, cached state. For a single-region service with this read pattern it is faster than a network database and dramatically cheaper. The objection is not performance, it is durability — a single file on a single volume is a single point of failure.

Litestream answers it by streaming the write-ahead log continuously to object storage, so the recovery point is seconds rather than the last nightly dump. The container entrypoint restores from the newest replica automatically when it starts on an empty volume, which means the restore path runs on every fresh deploy rather than being a document nobody has tested.

I have also rehearsed the restore deliberately, and my local development environment works by pulling a real replica down and scrubbing the credentials out of it. The backup is exercised weekly whether or not anything has gone wrong.

Pushing to the working branch merges to master and Fly deploys it. There is no review step, because there is no second engineer. That is a fine arrangement right up until a commit that compiles but throws during startup ships, and the machine crash-loops.

The CI pipeline that used to guard this took over three minutes and ran after the push — by which point production was already broken. I replaced it with a pre-flight script that runs the same assertions locally in about a minute, and a git hook that refuses to push unless it has passed for the exact commit being pushed, with a clean tree.

It checks the failure modes that have actually happened, not the ones that sound plausible: the app boots and answers its health endpoint twice, ten seconds apart, because answering once does not prove the process survives; the published Blazor boot script returns 200, because a build reordering once shipped a site where every page rendered a static skeleton while the server logs stayed perfectly clean; and the payment webhook returns its handler's status code rather than one rewritten by middleware, because that bug burned all sixty of the payment provider's retries on an unfulfilled purchase.

Every check in that script is a scar. When something new breaks, the fix is not finished until there is a check that would have caught it.

The UI ships in English and Greek. Localisation projects fail in a predictable way: someone adds a string in a hurry, forgets the translation table, and that language silently falls back to English for the next six months.

So it is not a convention here, it is a gate. A guardrail in the pre-flight script scans the markup for translated literals and fails the push if any key is missing from any language table, or if a translation's format placeholders do not match the original — a mismatch that would otherwise be a runtime exception in front of a user.

The Android app is a .NET MAUI Blazor Hybrid head over the same component library. The deployment pipeline compiles only the web head, so a MAUI-specific mistake — a native binding that does not match the Java API — would not surface until it was on a device. Every change touching that project therefore gets built for Android locally, in both Debug and Release, before it goes anywhere.

The instructive bug was the video player failing to draw under the display cutout. It needed three separate fixes: window flags on the modal's own window, because modern MAUI hosts modal pages in a dialog fragment whose window is not the activity's; opting the page out of safe-area insets; and opting the layouts inside it out as well, since insets are applied per-layout and a root grid will happily pad its children away from the notch on its own.

I found the third piece by rendering the window flags and view positions as an overlay on the player itself, after several blind attempts had failed. Making the invisible state visible solved in one build what guessing had not solved in five.