Case study / Cinova
Make API failures part of the browsing experience.
A movie browser is easy to judge when every request succeeds. Cinova also has to explain a failed setup request, a missing poster, or a search that can be retried. This project pairs the browsing interface with explicit recovery paths, using small JavaScript modules and controlled API fixtures for repeatable tests.
- Bounded rate-limit retries
- Section-specific recovery
- Public source and browser-test specifications
Evidence Snapshot
The public source separates API access, rendering, modal behavior, state, and watchlist controls. On November 4, 2026, static checks, JavaScript typecheck, and all four encoding-helper unit tests passed locally. The repository includes a GitHub Actions workflow for its full check and Playwright suite. The browser specifications use mocked TMDB responses; they are not proof of a live provider session.
Problem and Users
Cinova is for someone browsing movies and television, searching for a title, opening details, and keeping a watchlist. The interaction should remain understandable when the provider is slow or temporarily unavailable.
The goal was to give failures a place in the interface, so a person can retry the affected task without restarting the whole browsing session.
Key Product Decisions
Setup validates the token and loads genres before opening the browsing flow. A transient setup failure offers a retry. The featured title, individual sections, and search results also have their own retry controls, so one failed section does not require refreshing everything.
Watchlist buttons expose their saved state through aria-pressed and update their accessible labels when a title is added or removed. Browser history supports navigation between views. Empty search guidance and touch-target changes are visible in the source history.
Engineering Decisions
The API module applies a request timeout through AbortController. Rate-limit responses have a bounded retry loop and honor a usable Retry-After header. Successful responses can be cached using normalized endpoint and parameter keys, with an explicit refresh path.
Independent rendering and watchlist modules keep UI updates separate from the request boundary. Resilience specifications simulate failures in the hero, a section, and search, then assert recovery through the matching control. Another test passes an unsafe poster path and checks that the interface falls back instead of rendering the unsafe image.
The personal watchlist persists in browser storage. This is a local convenience, not an account-backed service or a promise of cross-device persistence.
Accessibility Considerations
The source includes labeled search, dialog semantics, setup-error announcements, trailer titles, and reduced-motion support. The axe specification checks serious and critical findings and disables color-contrast. That leaves contrast and other findings outside its gate; it is not a comprehensive accessibility audit or a WCAG compliance claim.
Performance Considerations
The API cache and parallel section loading reduce repeated work in the implementation. Their impact on real browsing speed has not been measured here. The static interface avoids a framework runtime, while poster and trailer loading still depend on external services.
Current Status and Limits
The implementation and test specifications are public. A real TMDB session needs a valid token, and mocked tests cannot verify provider availability or the full live-data experience. No usage or conversion results are reported. Development is AI-assisted; the source links below expose the behavior behind the case study.
What I Would Improve Next
- Review color contrast and remaining axe findings instead of relying on the current severity gate.
- Verify the full browsing and recovery flow against the live provider.
- Measure loading behavior on slower devices and connections.
- Review browser-stored token handling before treating this as a production service.
Inspect the Source
These links pin the evidence to the revision reviewed for this page.