That's a similar approach to supabase. Why reinvent the wheel? (I'm asking out of curiosity here).
Why websockets? Do you allow bidirectional communication? If not, wouldn't it be better to use http push for easier scaling?
Why websockets? Do you allow bidirectional communication? If not, wouldn't it be better to use http push for easier scaling?
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.
We've initially built the technology already for IHP DataSync (https://ihp.digitallyinduced.com/Guide/realtime-spas.html). So we used what we already had here :)
> Why websockets?
We also use the WebSockets to do write operations. This allows for lower latency than doing a HTTP call for any API call. Additionally we run all operations in parallel. With HTTP push we wouldn't be able to easily run all these operations in parallel.
Supabase is a copy of Firebase. Same question?
You cannot provide firebase as part of your services because you cannot self host it.
I asked why to understand the reason for another open source implementation.