movixcorp/movixopensource

1. Repository shape: a multi-client media platform

Movix is a monorepo where one product is split across several runtime boundaries: a web frontend, a primary Node backend, a real-time WatchParty service, Python proxy services, a mobile app, browser tooling, and a Rust/WASM sync engine. The architecture is not “frontend + API” only; some features intentionally span 3–4 components.

2. Main user-facing client: src/

The primary app is a React + TypeScript frontend built with Vite. It owns navigation, account/profile UI, media browsing, watch pages, VIP flows, watchparty screens, admin screens, and most presentation logic. It talks to the backend through src/services/api.ts and feature-specific service modules, and it relies heavily on local state plus browser storage for preferences and session-adjacent state.

3. Primary backend: API/Mainapi/

This is the authoritative backend for the product. It is a Node.js service with many Express route modules grouped by domain: auth, profiles, sync, search, downloads, VIP, comments, likes, shared lists, admin, OAuth apps, TMDB, live TV, and multiple provider-specific route files. It is the place where persistent application data, moderation/admin workflows, and cross-device synchronization are handled.

4. Persistence layer: MySQL + Redis

API/Mainapi/ uses MySQL as the durable system of record for user/account data, lists, comments, feedback, VIP-related tables, sessions, OAuth apps, bans, moderation, and tracking tables introduced via SQL scripts in exportscripts/ and wrapped_tables.sql. Redis is used for fast state: rate limiting, locks, cache, and coordination utilities. The frontend also keeps a meaningful amount of state in localStorage, so the system is a mix of server persistence and client-side preferences.

5. Auth, identity, and sync

Authentication and account linking are handled in the backend and consumed by the React app through AuthContext, profile pages, and auth-related services. The repo also contains sync-related utilities and route groups, which suggests the app keeps user settings, profiles, and watch-related metadata synchronized across devices rather than treating the browser as the sole source of truth.

6. Watch playback and source/extraction pipeline

Playback is split across frontend player components, backend provider routes, and supporting utilities. The frontend contains several player implementations and helper logic for source selection, extraction, DNS/proxy handling, and safe playback. Backend routes such as download, proxy, search, TMDB, live TV, and provider-specific modules help resolve media sources and enrich playback data before it reaches the player UI.

7. Proxy and embed infrastructure

API/proxiesembed/ is a separate Python service used for high-churn proxying, embeds, DRM-related interactions, and service-specific extraction logic. It contains a large catalog of site adapters, so it acts as a specialized media gateway rather than a general-purpose API. This is a distinct boundary from API/Mainapi/ because it likely has different performance, network, and scraping requirements.

8. WatchParty real-time subsystem

WatchParty is its own backend service at API/watchpartyAPI/, backed by Socket.IO-style real-time coordination on a dedicated port. The frontend watchparty pages, useWatchParty hook, sync utilities, worker, and WASM module all feed into this service. The key data flow is: UI event → sync logic / worker / WASM → WatchParty API → other participants’ clients.

9. Rust/WASM sync engine

wasm/watchparty-sync/ is the performance-sensitive synchronization core compiled to WebAssembly and published under public/wasm/watchparty-sync/. It is used by the frontend watchparty flow to keep timing/state reconciliation fast and deterministic in the browser, with a worker offloading the coordination work from the main UI thread.

10. Browser extension and userscript

extension/ and userscript/ are separate client-side surfaces that integrate with the same media ecosystem. They contain injection/content scripts, background logic, and extraction helpers, which means some playback or page-control behavior can happen inside the streaming site context rather than only inside the Movix web app.

11. Mobile app boundary

app/ is a React Native client with Android and iOS scaffolding. It reuses the same product concepts—browser, DNS handling, updates, casting, and bridge/injection logic—but as a native shell. It is architecturally separate from the web app, yet it still depends on the same backend URLs and app-level services for updates, address resolution, and media-related flows.

12. Edge/serverless and proxy deployment layers

The repo includes Cloudflare Workers (cloudflareproxy/, RivestreamCloudflareProxy/) and serverless functions under functions/. These are thin edge boundaries used for proxying, CORS/redirect behavior, previews, or route-specific hosting concerns. They sit in front of or alongside the main backend rather than replacing it.

13. Support services and integrations

The platform integrates with several external services that materially affect architecture: TMDB for metadata, Discord and Google auth flows, Turnstile for anti-abuse, and various media/provider endpoints. The frontend and backend each have dedicated helpers/config for these integrations, so the system is “integration-heavy” rather than self-contained.

14. Static/public artifact layer

public/ holds important runtime assets, not just images: avatars, tutorial content, WASM artifacts, service-worker assets, and route/public metadata. This makes deployment a mixed static + dynamic model: the frontend serves static bundles and media assets while backend services handle stateful and network-heavy operations.

15. Practical diagram boundary

If you draw the architecture, the clearest split is:

- Clients: React web app, mobile app, browser extension, userscript

- Core backend: Main API

- Specialized services: WatchParty API, proxy/embed Python service, bypass403 microservice, Cloudflare workers

- Storage: MySQL, Redis, browser local storage

- External services: TMDB, Discord, Google, Turnstile, provider/media sites

The main cross-cutting flow is: client UI requests media/account state from the main API, fetches or resolves playback sources through proxy/extraction layers, and uses the WatchParty stack only for synchronized group viewing.