wenbo

What's stopping you from coming over to Supabase?

You can find it under the "See Database add-on plans" section on https://supabase.com/pricing.

I contributed to Supabase Realtime [0] before being hired late January of 2021.

[0] https://github.com/supabase/realtime/commits?after=9990120c6...

Thanks, will take a look at your article!

Yes, developers will have to do this themselves for now.

I see that you worked on Firebase's Realtime database back in the day. How did your team handle such cases?

So you will lose messages.

This is true but you can store your messages inside your database and on reconnect you can fetch the messages you missed.

Thanks, the demo isn't mobile responsive quite yet.

Wen Bo from the Supabase Realtime team here!

Client will seek to continuously reconnect to the WebSocket when there's a connection issue and server must receive at least one heartbeat in a 60 second window; otherwise it will clean up the WebSocket connection.

We built Supabase Realtime on top of Phoenix Channel, and along with our clients, handles unreliable network connections gracefully, including on mobile.

Wen Bo from the Supabase Realtime team!

Just want to confirm that we did put in place a client-side character limit.

Wen Bo from the Supabase Realtime here!

Also, every single person on the Supabase team actively does support so if you would like world class support than look no further!

Wen Bo from the Realtime team here!

That back button glitch is specific to the demo. We had to do a few redirects based on Presence sync and load balancing each room. I'm sure there's a better way of doing it and will seek to improve it when I update it. Sorry about that!

We started developing Realtime: Multiplayer version many months ago in a private repo just to experiment with Phoenix's Broadcast and Presence and over time we just added to it.

We plan to move all the code over to https://github.com/supabase/realtime in the next couple of weeks and you'll be able to see the code in its entirety.

Wen Bo from the Supabase Realtime team here!

We actually use https://github.com/supabase/walrus to get the database changes and we're planning on moving to a Rust worker (https://github.com/supabase/walrus/tree/worker/worker) for better performance especially in the RLS-enabled use case.

I promised José that I would check out Postgrex.ReplicationConnection and we might add it in to our Supabase Realtime some time in the future.

Is server authroity and broadcast permissions handled or left as a task for the user? Can channels be locked down to a list of users?

Broadcast permissions is currently not handled by the server and left to the developer to implement. We have discussed this internally and will prioritize Broadcast authorization accordingly because we've gotten feedback about this from a number of developers.

Can users be kicked from a channel?

Not at the moment but again we've gotten feedback about this as well and will prioritize it.

Is message spam/flooding/DDOSing users in a channel protected?

We have built rate limiting and other protections so bad actors don't affect the good in the cluster. A colleague of mine posted these limitations of Supabase Realtime to prevent abuse: https://news.ycombinator.com/item?id=32511586.

Thanks for the feedback! Passed it on to our frontend team.

Member of the Supabase team!

Would love to hear your pain points with local development. Always looking for feedback so that we may improve your experience.

Supabase dev and the maintainer of Supabase Realtime here!

Meteor was before my time (I was doing product when Meteor was all the rage back in the day and never had a chance to explore it as a dev) so can't speak to that but Realtime scales pretty well since it's an Elixir/Phoenix server listening to a Postgres database.

We've recently added Realtime RLS, a more secure version of Realtime, so we need to continue to tune it to make it more performant. I think a couple hundred is doable for now. You should give it a try and give us feedback.

We have a Supabase user who is running the version prior to Realtime RLS, which is more performant at the expense of security, and they have thousands of users chatting concurrently. Just to clarify these chat messages are being saved to a database and then being broadcast to thousands of users.

We're also actively working on Realtime Broadcast which doesn't need to go through the database. Great for ephemeral chat messages and definitely more performant.

Supabase dev here!

I believe this is you: https://github.com/supabase/supabase/discussions/5911#discus.... I just want to let you know that I saw your comment!

Thank you so much for the kind words!

2) Recently added built-in database-driven GraphQL module is ingenious, but would benefit greatly from Realtime capability

A member of the team is currently investigating this so please stay tuned.

I'll pass on the rest of your feedback internally. Thanks again!

Supabase dev and one of the creators of multiplayer.dev here!

This led us to use Centrifugal, a oss go microservice, which has worked great

Thanks for sharing this! Will definitely take a look at their offering.

I didn't found any Elixir based rt-as-a-service product, and it looks like you guys are in a great position to tackle that space.

That's exactly right!

Thank you so much for the kind words!

Supabase dev and the maintainer of Supabase Realtime here!

The real time doesn't work until you enable the sync on the supabase dashboard which was not apparent to me.

Thanks for the feedback! I think you're right and we can do a better job of exposing this so it's more apparent for everyone.

There are bunch of oddities with how policies and realtime work.

Would love to hear more about the oddities! Realtime works with Postgres RLS policies so there should be nothing odd about it. Set up your policies and Realtime works accordingly.

That's a similar approach to supabase

I'm a Supabase dev and the maintainer of Supabase Realtime and just wanted to clarify that Realtime works by listening to Postgres' logical replication because we realized early on that it scales better and circumvents the limitations of pg_notify; for example notify has a payload limit of 8000 bytes.

every day my excitement for Supabase grows

Love to hear it!

What would be the best way to build a multi-region cluster in Supabase?

The easiest way we've found is to deploy the cluster on Fly.io. You can check out the docs here: https://fly.io/docs/getting-started/elixir.

Wanted to follow up on this. I spoke to the team and just wanted to re-iterate that we will be open sourcing the SQL very soon.

first elixir project

Simple Phoenix server that made requests to third party API endpoints.

Did you have any trouble skipping Erlang and going straight to elixir?

I don't think I referred to any Erlang code and just picked up Elixir. Ultimately, you will have to pick up some Erlang but you can get away with just Elixir for a long time.

This was actually my path. I started working on side projects and picked Elixir because I had my eyes on it for a few years and wanted to give it a shot.

I was just implementing some of those SQL commands.

Way to take the initiative! I think it was more of an oversight on our part than intentionally choosing to keep it closed.

And I will look more at the realtime libraries to see the new stuff.

Awesome! We have a lot of updates and better documentation coming in the next couple of weeks so stay tuned.

Thanks for all the open code!!

You're very welcome and it's the least we can do!

finding the building blocks of modern applications (database, auth, functions, presence, realtime subscriptions), making them easy to use, and then sharing the source code.

Great observation!

I’ve learned a ton just from cruising around supabase GitHub.

Glad to hear it!

Can you say which of these new components will be open sourced?

All of these components are open source and licensed under Apache License v2.0.

There are some other features (e.g. function hooks) that are also closed-source at the moment.

I actually worked on the initial implementation of function hooks. We've actually already open sourced both the client (see: https://github.com/supabase/supabase/tree/88bcef911669595428...) and the pg_net extension it requires (see: https://github.com/supabase/pg_net). I think we've yet to open source the SQL commands needed to create the schema, functions, etc. I'll talk to my team and we'll open source it.

Is Supabase heading for an “open core” model?

I don't think so. We want to continue to open source our projects under either MIT (client libs) and Apache License v2.0 (server libs).

Interesting, I haven't heard of Eve Online but will definitely do my research.

We want to provide developers with the tools that best fit their use cases. We're starting with WebSockets but have discussed offering additional protocols and technologies, like WebRTC. Plus, these tools can complement each other. For example, you can use Realtime Broadcast as the signalling layer for WebRTC. Then, you're free to use data channels to pass whatever ephemeral data you want between clients.