Skip to content

Commit 314fa3c

Browse files
authored
fix: Update Readme with more technical details (#10)
1 parent 27cc793 commit 314fa3c

File tree

2 files changed

+114
-4
lines changed

2 files changed

+114
-4
lines changed

README.md

Lines changed: 114 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -21,10 +21,6 @@ def deps do
2121
end
2222
```
2323

24-
## How it works
25-
26-
We connect to a Postgres instance using Postgrex. With the [Postgrex.Notifications](https://hexdocs.pm/postgrex/Postgrex.Notifications.html) module we will track for `LISTEN` events on the configured channel. We'll also use `NOTIFY` queries to send the node's information.
27-
2824
## How to use it
2925

3026
To use it, set your configuration file with the informations for your database:
@@ -65,6 +61,120 @@ defmodule MyApp do
6561
end
6662
end
6763
```
64+
### Why do we need a distributed Erlang Cluster?
65+
66+
At Supabase, we use clustering in all of our Elixir projects which include [Logflare](https://github.com/Logflare/logflare), [Supavisor](https://github.com/supabase/supavisor) and [Realtime](https://github.com/supabase/realtime). With multiple servers connected we can load shed, create globally distributed services and provide the best service to our customers so we’re closer to them geographically and to their instances, reducing overall latency.
67+
68+
![Example of Realtime architecture where a customer from CA will connect to the server closest to them and their Supabase instance](realtime_example.png)
69+
70+
Example of Realtime architecture where a customer from CA will connect to the server closest to them and their Supabase instance
71+
To achieve a connected cluster, we wanted to be as cloud-agnostic as possible. This makes our self-hosting options more accessible. We don’t want to introduce extra services to solve this single issue - Postgres is the logical way to achieve it.
72+
73+
The other piece of the puzzle was already built by the Erlang community being the defacto library to facilitate the creation of connected Elixir servers: [libcluster](https://github.com/bitwalker/libcluster).
74+
75+
### What is libcluster?
76+
77+
[libcluster](https://github.com/bitwalker/libcluster) is the go-to package for connecting multiple BEAM instances and setting up healing strategies. libcluster provides out-of-the-box strategies and it allows users to define their own strategies by implementing a simple behavior that defines cluster formation and healing according to the supporting service you want to use.
78+
79+
### How did we use Postgres?
80+
81+
Postgres provides an event system using two commands: [NOTIFY](https://www.postgresql.org/docs/current/sql-notify.html) and [LISTEN](https://www.postgresql.org/docs/current/sql-listen.html) so we can use them to propagate events within our Postgres instance.
82+
83+
To use this features, you can use psql itself or any other Postgres client. Start by listening on a specific channel, and then notify to receive a payload.
84+
85+
```markdown
86+
postgres=# LISTEN channel;
87+
LISTEN
88+
postgres=# NOTIFY channel, 'payload';
89+
NOTIFY
90+
Asynchronous notification "channel" with payload "payload" received from server process with PID 326.
91+
```
92+
93+
Now we can replicate the same behavior in Elixir and [Postgrex](https://hex.pm/packages/postgrex) within IEx (Elixir's interactive shell).
94+
95+
```elixir
96+
Mix.install([{:postgrex, "~> 0.17.3"}])
97+
config = [
98+
hostname: "localhost",
99+
username: "postgres",
100+
password: "postgres",
101+
database: "postgres",
102+
port: 5432
103+
]
104+
{:ok, db_notification_pid} = Postgrex.Notifications.start_link(config)
105+
Postgrex.Notifications.listen!(db_notification_pid, "channel")
106+
{:ok, db_conn_pid} = Postgrex.start_link(config)
107+
Postgrex.query!(db_conn_pid, "NOTIFY channel, 'payload'", [])
108+
109+
receive do msg -> IO.inspect(msg) end
110+
# Mailbox will have a message with the following content:
111+
# {:notification, #PID<0.223.0>, #Reference<0.57446457.3896770561.212335>, "channel", "test"}
112+
```
113+
114+
### Building the strategy
115+
116+
Using the libcluster `Strategy` behavior, inspired by [this GitHub repository](https://github.com/kevbuchanan/libcluster_postgres) and knowing how `NOTIFY/LISTEN` works, implementing a strategy becomes straightforward:
117+
118+
1. We send a `NOTIFY` to a channel with our `node()` address to a configured channel
119+
120+
```elixir
121+
# lib/cluster/strategy/postgres.ex:52
122+
def handle_continue(:connect, state) do
123+
with {:ok, conn} <- Postgrex.start_link(state.meta.opts.()),
124+
{:ok, conn_notif} <- Postgrex.Notifications.start_link(state.meta.opts.()),
125+
{_, _} <- Postgrex.Notifications.listen(conn_notif, state.config[:channel_name]) do
126+
Logger.info(state.topology, "Connected to Postgres database")
127+
128+
meta = %{
129+
state.meta
130+
| conn: conn,
131+
conn_notif: conn_notif,
132+
heartbeat_ref: heartbeat(0)
133+
}
134+
135+
{:noreply, put_in(state.meta, meta)}
136+
else
137+
reason ->
138+
Logger.error(state.topology, "Failed to connect to Postgres: #{inspect(reason)}")
139+
{:noreply, state}
140+
end
141+
end
142+
```
143+
144+
2. We actively listen for new `{:notification, pid, reference, channel, payload}` messages and connect to the node received in the payload
145+
146+
```elixir
147+
# lib/cluster/strategy/postgres.ex:80
148+
def handle_info({:notification, _, _, _, node}, state) do
149+
node = String.to_atom(node)
150+
151+
if node != node() do
152+
topology = state.topology
153+
Logger.debug(topology, "Trying to connect to node: #{node}")
154+
155+
case Strategy.connect_nodes(topology, state.connect, state.list_nodes, [node]) do
156+
:ok -> Logger.debug(topology, "Connected to node: #{node}")
157+
{:error, _} -> Logger.error(topology, "Failed to connect to node: #{node}")
158+
end
159+
end
160+
161+
{:noreply, state}
162+
end
163+
```
164+
165+
3. Finally, we configure a heartbeat that is similar to the first message sent for cluster formation so libcluster is capable of heal if need be
166+
167+
```elixir
168+
# lib/cluster/strategy/postgres.ex:73
169+
def handle_info(:heartbeat, state) do
170+
Process.cancel_timer(state.meta.heartbeat_ref)
171+
Postgrex.query(state.meta.conn, "NOTIFY #{state.config[:channel_name]}, '#{node()}'", [])
172+
ref = heartbeat(state.config[:heartbeat_interval])
173+
{:noreply, put_in(state.meta.heartbeat_ref, ref)}
174+
end
175+
```
176+
177+
These three simple steps allow us to connect as many nodes as needed, regardless of the cloud provider, by utilising something that most projects already have: a Postgres connection.
68178

69179
## Acknowledgements
70180

realtime_example.png

203 KB
Loading

0 commit comments

Comments
 (0)