diff --git a/apps/docs/pages/guides/realtime/architecture.mdx b/apps/docs/pages/guides/realtime/architecture.mdx index 5a8830cd9eb..989814d9a0e 100644 --- a/apps/docs/pages/guides/realtime/architecture.mdx +++ b/apps/docs/pages/guides/realtime/architecture.mdx @@ -11,6 +11,8 @@ Realtime is a globally distributed Erlang cluster. Clients can connect to any no Realtime is written in [Elixir](https://elixir-lang.org/) (a flavor of Erlang) and utilizes many tools the [Phoenix Framework](https://www.phoenixframework.org/) provides out of the box. +![Global Architecture](/docs/img/guides/realtime/realtime-arch.png) + ## Elixir & Phoenix Phoenix is fast and able to handle millions of concurrent connections. @@ -19,14 +21,6 @@ Phoenix can handle many concurrent connections because Erlang provides lightweig Client-facing WebSocket servers need to handle many concurrent connections. Elixir & Phoenix let the Supbase Realtime cluster do this easily. -## Extensions - -Extensions are pluggable feature sets enabled by initializing a Realtime connection with certain message types. - -[Broadcast](/docs/guides/realtime/broadcast), [Presence](/docs/guides/realtime/presence) and [Posgres Changes](/docs/guides/realtime/postgres-changes) are all Realtime Extensions. Some Extensions, like Postgres Changes, require backend configuration to be saved on the cluster before use. - -For example, Realtime needs your database credentials to know how to connect to your database and you don't want to send those over a client connection. - ## Global Cluster Presence is an in-memory key-value store backed by a CRDT. When a user is connected to the cluster the state of that user is sent to all connected Realtime nodes. @@ -59,18 +53,6 @@ Connection IDs are Erlang processes representing underlying sockets on the clust After receiving results from the polling query, with connection IDs appended, Realtime delivers records to those connections. -## Channels - -Channels are a `topic` you define when you initialize your Supabase Realtime client. Everyone connected to the same Channel will receive the same messages. - -Clients can send and receive messages bi-directionally over a Channel. The Realtime backend can also push messages to all clients connected to the same Channel. - -A single client can receive change records from Postgres, Broadcast messages from other clients and Presence updates all over the same Channel. - -Channels are implemented over [Phoenix Channels](https://hexdocs.pm/phoenix/channels.html) which uses [Phoenix.PubSub](https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.html) with the default `Phoenix.PubSub.PG2` adapter. - -The PG2 adapter utilizes Erlang [process groups](https://www.erlang.org/docs/18/man/pg2.html) to implement the PubSub model where a publisher can send messages to many subscribers. - export const Page = ({ children }) => export default Page