You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+114-4Lines changed: 114 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -21,10 +21,6 @@ def deps do
21
21
end
22
22
```
23
23
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
-
28
24
## How to use it
29
25
30
26
To use it, set your configuration file with the informations for your database:
@@ -65,6 +61,120 @@ defmodule MyApp do
65
61
end
66
62
end
67
63
```
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
+

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).
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
+
defhandle_continue(:connect, state) do
123
+
with {:ok, conn} <-Postgrex.start_link(state.meta.opts.()),
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.
0 commit comments