docs(realtimekit): Added getting started page #24511
Closed
+762
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
roerohan
reviewed
Aug 19, 2025
Contributor
roerohan
left a comment
roerohan
left a comment
There was a problem hiding this comment.
Changes in internal URLs
|
|
||
| Before we get started with RealtimeKit, let's understand the SDK model. | ||
|
|
||
| In RealtimeKit, the concepts of [**meeting**](/realtime/realtimekit/concepts#meeting) and [**participant**](/realtime/realtimekit/concepts#participant) serve as blueprints—these are database entries that define the structure and roles for real-time interactions. A meeting blueprint outlines the configuration for a collaborative space (such as a classroom, telehealth appointment, or webinar), while a participant blueprint defines the roles and permissions available within that space. |
Contributor
There was a problem hiding this comment.
The URLs should have trailing /s
This makes sure that when the URL is opened, the corresponding tab is highlighted on the left sidebar.
Suggested change
| In RealtimeKit, the concepts of [**meeting**](/realtime/realtimekit/concepts#meeting) and [**participant**](/realtime/realtimekit/concepts#participant) serve as blueprints—these are database entries that define the structure and roles for real-time interactions. A meeting blueprint outlines the configuration for a collaborative space (such as a classroom, telehealth appointment, or webinar), while a participant blueprint defines the roles and permissions available within that space. | |
| In RealtimeKit, the concepts of [**meeting**](/realtime/realtimekit/concepts/#meeting) and [**participant**](/realtime/realtimekit/concepts/#participant) serve as blueprints—these are database entries that define the structure and roles for real-time interactions. A meeting blueprint outlines the configuration for a collaborative space (such as a classroom, telehealth appointment, or webinar), while a participant blueprint defines the roles and permissions available within that space. |
| In RealtimeKit, the concepts of [**meeting**](/realtime/realtimekit/concepts#meeting) and [**participant**](/realtime/realtimekit/concepts#participant) serve as blueprints—these are database entries that define the structure and roles for real-time interactions. A meeting blueprint outlines the configuration for a collaborative space (such as a classroom, telehealth appointment, or webinar), while a participant blueprint defines the roles and permissions available within that space. | ||
|
|
||
| When it comes to real-time usage, these blueprints are instantiated as sessions and peers: | ||
| - A [**session**](/realtime/realtimekit/concepts#session) is a live instance of a meeting, representing an active, real-time interaction. |
Contributor
There was a problem hiding this comment.
Suggested change
| - A [**session**](/realtime/realtimekit/concepts#session) is a live instance of a meeting, representing an active, real-time interaction. | |
| - A [**session**](/realtime/realtimekit/concepts/#session) is a live instance of a meeting, representing an active, real-time interaction. |
|
|
||
| When it comes to real-time usage, these blueprints are instantiated as sessions and peers: | ||
| - A [**session**](/realtime/realtimekit/concepts#session) is a live instance of a meeting, representing an active, real-time interaction. | ||
| - A [**peer**](/realtime/realtimekit/concepts#peer) is a live instance of a participant—an actual user (such as a teacher, student, doctor, or patient) joining the session. |
Contributor
There was a problem hiding this comment.
Suggested change
| - A [**peer**](/realtime/realtimekit/concepts#peer) is a live instance of a participant—an actual user (such as a teacher, student, doctor, or patient) joining the session. | |
| - A [**peer**](/realtime/realtimekit/concepts/#peer) is a live instance of a participant—an actual user (such as a teacher, student, doctor, or patient) joining the session. |
| }' | ||
| ``` | ||
|
|
||
| For more about apps and their role, see the [RealtimeKit Concepts guide](/realtime/realtimekit/concepts#app). |
Contributor
There was a problem hiding this comment.
Suggested change
| For more about apps and their role, see the [RealtimeKit Concepts guide](/realtime/realtimekit/concepts#app). | |
| For more about apps and their role, see the [RealtimeKit Concepts guide](/realtime/realtimekit/concepts/#app). |
|
|
||
| Before adding participants, you need to decide what permissions they should have. | ||
| Presets define these permissions, and RealtimeKit provides some default presets to get you started. | ||
| Learn more about presets in the [Concepts guide](/realtime/realtimekit/concepts#preset). |
Contributor
There was a problem hiding this comment.
Suggested change
| Learn more about presets in the [Concepts guide](/realtime/realtimekit/concepts#preset). | |
| Learn more about presets in the [Concepts guide](/realtime/realtimekit/concepts/#preset). |
| - A [**session**](/realtime/realtimekit/concepts/#session) is a live instance of a meeting, representing an active, real-time interaction. | ||
| - A [**peer**](/realtime/realtimekit/concepts/#peer) is a live instance of a participant—an actual user (such as a teacher, student, doctor, or patient) joining the session. | ||
|
|
||
| > **Note:** In some contexts, the terms **session** and **meeting**, as well as **peer** and **participant**, are used interchangeably. This is because most people are more familiar with the terms "meeting" and "participant." However, in RealtimeKit, using "session" and "peer" helps differentiate between live instances (sessions and peers) and their blueprints (meetings and participants), making it easier to track and manage them individually in the RealtimeKit dashboard. |
Contributor
There was a problem hiding this comment.
Suggested change
| > **Note:** In some contexts, the terms **session** and **meeting**, as well as **peer** and **participant**, are used interchangeably. This is because most people are more familiar with the terms "meeting" and "participant." However, in RealtimeKit, using "session" and "peer" helps differentiate between live instances (sessions and peers) and their blueprints (meetings and participants), making it easier to track and manage them individually in the RealtimeKit dashboard. | |
| > **Note:** In some contexts, the terms **session** and **meeting**, as well as **peer** and **participant**, are used interchangeably. This is because most people are more familiar with the terms "meeting" and "participant". However, in RealtimeKit, using "session" and "peer" helps differentiate between live instances (sessions and peers) and their blueprints (meetings and participants), making it easier to track and manage them individually in the RealtimeKit dashboard. |
Contributor
|
PR: #26407 has all these changes. Closing this PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Added Getting Started Page for RealtimeKit Product. A separate PR will be raised to explain to clients about how to create custom UI.
Thinks to be Noted.
Documentation checklist