Beginner Paths
Use this page when your question is: "How do I actually start with MediaSFU without taking on too much at once?"
This is the practical beginner flow:
- Pick the SDK that matches your app.
- Prove the secure backend boundary.
- Keep the stock flow working before changing major UI.
- Choose the lightest customization style that fits your product.
- Start from a product-shaped tutorial once the basics work.
Step 1: Pick the right SDK
| If you are building... | Start here | Why |
|---|---|---|
| A React web app | ReactJS SDK | Fastest web path with direct component control. |
| An Angular web app | Angular SDK | Best if your app already uses Angular DI and templates. |
| A bare React Native app | React Native SDK | Best when you control the native mobile workflow directly. |
| An Expo-managed mobile app | React Native Expo SDK | Best when you want Expo-managed mobile setup. |
| A Vue web app | Vue SDK | Best for Vue composition-friendly integration. |
| A custom wrapper or advanced runtime shell | mediasfu-shared | Best when you need lower-level control than the UI SDKs expose. |
If you do not know which package to start with, do not begin at mediasfu-shared. Start with the SDK for your framework and move lower only when the higher-level package stops fitting.
Step 2: Secure the backend boundary first
For an ordinary production app, the frontend should not hold raw MediaSFU credentials.
Start here:
What this step should give you:
- a working create-room or join-room flow
- server-side storage of MediaSFU credentials
- frontend hooks or adapters that call your backend instead of MediaSFU directly
Do this before branding, starter-screen cloning, or deep UI replacement.
Step 3: Decide how much of the UI to keep
| If your product looks like... | Start here | Typical result |
|---|---|---|
| A meeting room with light branding | UI overrides | Keep MediaSFU workflow and replace a few surfaces. |
| A branded room with a stronger shell | Custom component replacement | Keep MediaSFU workflow and replace larger blocks. |
| A host workspace, operator console, or non-room shell | Headless mode | Keep MediaSFU runtime logic and own the full UI shell. |
| A framework wrapper or deep runtime integration | mediasfu-shared | Own transports, producers, consumers, and helpers more directly. |
The main rule is simple:
- If the product still feels like a room, stay close to the default UI first.
- If the product no longer feels like a room, move toward headless mode or shared-core.
Step 4: Learn the runtime concepts after connection works
Once the join flow is working, most teams hit the next set of questions:
- how do I capture and publish media?
- how do I consume remote media?
- how do I render media differently for my UI?
- how do I handle requests, permissions, moderation, or recording?
Start here:
This is where you move from "I connected successfully" to "I understand what MediaSFU is doing for me."
Step 5: Start from a product-shaped tutorial
If you do not want to think in generic room terms, start from the closest product shape instead.
| Product shape | Best first path | Why |
|---|---|---|
| WhatsApp-style call screen | Starter screens + UI overrides | Fastest way to keep room logic and simplify the surface. |
| Twitch-style host dashboard | Starter screens + Custom component replacement | Best for stage, moderation, recording, and dashboard-style host controls. |
| TikTok Live host and guest queue | Starter screens + Media lifecycle | Best for guest request, admit, spotlight, and layout control. |
| Support or AI agent console | Starter screens + Headless mode | Best when the shell is not a room anymore. |
Where Storybook fits
Use the docs portal for:
- choosing the right SDK
- secure backend setup
- deciding between overrides, replacement, and headless mode
- understanding runtime workflows
Use Storybook for:
- visual inspection of overrideable surfaces
- component-level exploration
- comparing room UI pieces before replacing them
Storybook is the visual companion, not the main beginner entry point.
Recommended beginner reading order
Where framework-specific details belong
Use the shared usage guides when you are choosing a path, learning the room lifecycle, or comparing UI ownership levels. Move into the SDK guide once you are ready to install a package, wire framework-specific components, or check platform caveats.
For example, the secure backend boundary is the same idea across frameworks, but React, Angular, Vue, Flutter, Kotlin, and React Native each have their own setup page for package installation and application wiring.