feat: fast lane outgoing broadcast messages

[w3b6x9]

What kind of change does this PR introduce?

feat

What is the new behavior?

Fast lane outgoing broadcast messages, and count them, so they don't need to be relayed through channel processes.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated
realtime-demo	⬜️ Ignored (Inspect)			Mar 31, 2023 at 5:46AM (UTC)

[chasers]

Putting this here too for comms. It is handling outbound messages already:

https://user-images.githubusercontent.com/1019814/227007147-551b2279-426d-4c7f-8572-ec284ad29911.mp4

You did catch some something with having both Postgres extensions use the same dispatcher though. Need to do that.

And needs tests to make this obvious for the future if you want to help out with that?

[chasers]

Maybe it's better because you're manually fastlane-ing them now?

But doesn't Channels do that for us anyways with the default dispatcher? But maybe we're not getting that benefit because we're subscribing to tenant <> : <> sub_topic which is different than what the client is subscribing to.

That kind of always smelled odd to me actually. Why would clients not join realtime:tenant:topic? I think then we wouldn't have to subscribe to it and it would get fastlaned automatically. We'd still need a custom dispatcher to do the counting probably.

[abc3]

That kind of always smelled odd to me actually. Why would clients not join realtime:tenant:topic?

@chasers this was made for backward compatibility when we were transferring users to multiplayer

[w3b6x9]

Putting this here too for comms. It is handling outbound messages already

Ah, you're right. It was just non-obvious to me as it was hidden by the catchall of handle_info(%{event: type, payload: payload}, socket).

I think this PR makes it more intentional and spells out what we're counting.

But doesn't Channels do that for us anyways with the default dispatcher?

Yes, Channels automatically attaches :fastlane metadata when subscribing to the topic so if we were using that then the existing code on main wouldn't have worked b/c it bypasses the channel processes.

But maybe we're not getting that benefit because we're subscribing to tenant <> : <> sub_topic which is different than what the client is subscribing to.

Yes, we failed to attach the :fastlane metadata when manually subscribing to tenant <> : <> sub_topic so that's why the Broadcast and Presence messages are sent to the channel processes.

That's what tripped me up b/c I assumed we were fastlaning these messages so I was like how are we counting outgoing messages in that case.

Why would clients not join realtime:tenant:topic?

What @abc3 wrote: https://github.com/supabase/realtime/pull/560#issuecomment-1480327328