Open PeerShare ↗   ·   Quickstart   ·   Architecture   ·   Benchmarks   ·   Learning guides

A video-on-demand platform built with Go, Next.js and WebRTC. Upload an MP4, make your channel your own and publish adaptive video. Discover creators, build playlists and watch through a custom player. When viewers choose to share, their browsers exchange verified video segments directly while HTTP remains available.

See it in action

_{Recorded from the running local application. The hosted showcase has 18 original visual explainers across six editorial channels, alongside the owner's original video. Showcase accounts are identified as editorial; the benchmark dataset stays separate.}

Built for creators and viewers

Publish your work Resumable MP4 uploads, private previews and adaptive 480p/720p HLS. Add a thumbnail, edit metadata and manage your full library in Studio.	Watch your way A custom player with quality selection, keyboard controls, seeking and fullscreen. Opt into peer delivery and see actual received and uploaded payload.
Find your next watch Search titles, creators and tags. Explore real topics, visit channels and follow creators for a personal feed.	Make it yours Custom channel banners, private or public playlists, ordered playback queues and light/dark appearance. Google and email sign-in share the same account ownership.
Understand your channel Creator analytics report qualified plays, watch time and delivery signals. PostgreSQL owns the data; Redis caches aggregates and enforces rate limits.	Run the platform A role-restricted operator workspace shows actual processing jobs and storage. Private dashboards connect API traffic, traces and media work.

Look around — Studio, player, dark mode and mobile

Creator Studio	Custom video player
Dark appearance	Made for smaller screens

Architecture

The product has three Go executables with distinct responsibilities: the catalogue API owns the user-facing platform, the media coordinator schedules processing and accepts outputs, and the worker runs FFmpeg. Kafka carries notifications; video bytes live in private object storage.

Open full-size SVG   ·   Service boundaries   ·   Data model

1. Publish. The API receives source uploads and submits a media job over authenticated gRPC. Kafka notifies a worker, which creates HLS renditions, thumbnails and integrity metadata. The coordinator verifies the output; the catalogue projects the accepted result. The creator chooses when to publish.
2. Watch. CloudFront serves the static frontend. API and media traffic stay uncached at the edge; Go checks current publication or ownership before reading private S3 media.
3. Share. The tracker introduces opted-in viewers. Browsers discover connection candidates with STUN and exchange segments over WebRTC data channels. The player verifies hashes before using received media.

A closer look at peer delivery

The tracker carries signalling, not video. Sharing requires consent and uses the viewer's upload bandwidth. Connection details expose actual HTTP, peer and upload bytes. The playback guide explains discovery, integrity and fallback.

Quickstart

Requirements: Node 22.23.3 (.nvmrc), Go 1.27.2, Docker with Compose, and FFmpeg for fixture generation.

git clone https://github.com/darshpatel1052/PeerShare.git
cd PeerShare
npm ci
npm run fixture
npm run compose:demo

Open localhost:3000. Create an account and channel, open Studio, then upload your own MP4. The Compose setup starts the frontend, API, media coordinator, worker, PostgreSQL, Redis and Kafka. Re-running it retains normal application data. A fresh checkout does not impersonate the hosted showcase accounts.

For native development or Google credentials, follow the development walkthrough and Google sign-in setup.

Measured performance

Workload	Measured result	Conditions
Catalogue API	200 offered operations/sec, p95 ≤55 ms, p99 ≤99 ms; zero failures or drops	Three 120-second trials; 100k metadata video records and 10k synthetic accounts; external k6 generator over a private tunnel
Media processing	A 120-second 1080p source became ready 94.1 seconds after upload completion	Includes queueing, encoding, S3 output and projection; fourteen renditions verified across seven real jobs
Peer delivery	34.7–48.7% less origin media response-body traffic, including sharing setup	Three eight-browser comparisons of a 30-second clip on one workstation; 23.6–29.2% aggregate dropped frames limit rendering/capacity conclusions

The measurements describe earlier direct-HTTPS application revisions, rather than the later CloudFront route. Synthetic records are not customer adoption; origin body bytes are not billed AWS savings. The failed load levels and generator limitations are published alongside the successful results.

Read the report · Protocol · Raw evidence + SHA-256 manifest · Learn how the measurements work

Explore the code

Where	What lives there
apps/web	Next.js/React application, Studio, account, library, analytics and operator pages
packages/player	HLS loading, verified segment cache, peer delivery and transport measurements
services/api	Go HTTP API, PostgreSQL stores, coordinator, encoder and worker executables
services/tracker	WebSocket peer introduction and signalling
contracts · proto	OpenAPI, events and typed gRPC service definitions
deploy	Compose, Envoy, Terraform and the separate Helm/kind exercise
docs	Feature guides, architecture decisions, deployment and measured evidence

The stack, and why each piece is here

Component	Role
Go	HTTP services, bounded concurrent work, gRPC coordination and media processing orchestration
Next.js + React + TypeScript	Static frontend, reusable components and interactive creator/viewer workflows
PostgreSQL	User/session ownership, relational catalogue, publication, playlists and processing state
Redis	Separate analytics caching and rate-limit workloads
Kafka + protobuf/gRPC	Event notifications and typed service commands/snapshots
FFmpeg + HLS	Adaptive video renditions, thumbnails and segmented playback
WebRTC + WebSocket + STUN	Peer connections, discovery and direct verified segment exchange
S3 + CloudFront + Envoy	Private media, frontend edge delivery and authorized application routing
Terraform + GitHub OIDC + ECR	Repeatable infrastructure, short-lived build credentials and immutable images
Prometheus + Grafana + Jaeger	Private metrics, dashboards and traces

Learn by following a feature

The guides connect what the user does to the React component, API, Go implementation and data model.

Start here	Follow it into the implementation
Create an account and channel	SQL relationships, sessions, ownership and Go foundations
Upload and publish	Chunks, checksums, processing and HLS
Run media services	Service ownership, Kafka, protobuf and gRPC
Follow creators and save videos	Search, subscriptions, playlists and analytics
Connect Google or add artwork	OIDC, revision-checked images and player components
Deploy and observe	AWS, Redis, STUN and observability
Understand the interface	Design system and component map
Operate and measure	Operator tools, Kubernetes and benchmarks

Deployment and project scope

The hosted application uses CloudFront, private S3 and one Mumbai EC2 host, with two API replicas sharing that machine. The database and Kafka broker are single instances. AWS runs within the selected Free plan and credits with a bounded demo lifetime; the demo can be offline outside that window. Deployment runbook · Cost and retention plan · Verified CloudFront cutover.

Public registration is closed. Every signed-in account can create a channel and publish within existing upload, rate and storage limits; platform operations remain restricted to operators. Invitation-only creator access is an explicit opt-in (CREATOR_APPROVAL_REQUIRED=true) and is disabled on the hosted application. Password recovery, email verification, a TURN relay and multi-host availability remain future work. Native HLS has different measurement capabilities from the verified Chromium path. Existing database, cookie, environment and protocol identifiers retain some peerscreen prefixes for compatibility; historical records keep their original names and release hashes.

Development checks and private operator tools

npm run check
npm run contracts:check
npm run proto:check
npm run api:vet
npm run test:integration
npm run test:browser

Dependency-based suites share a disposable test project and run sequentially. The normal app's data is retained. The review resolution records the latest product fixes.

• npm run dev:observed (also npm run operations) starts the development app with private Grafana, Prometheus and Jaeger collecting real application metrics and traces. The hosted EC2 deployment also runs its own monitoring stack. Use npm run operations:cloud to access its dashboards through a private SSH tunnel; those localhost links show AWS data, not the development app. Observability guide.
• npm run kube -- up starts the separate local Helm/kind exercise. It does not provision EKS. Kubernetes guide.
• The media, gateway and recovery runbooks explain the supporting checks.

Read the documentation   ·   Report an issue   ·   Back to top ↑