5 ms·

Forgive me, I'm still recovering from the flu and am having some trouble thinking, but I didn't find your "Why not build this into Realtime?" section very compe

Forgive me, I'm still recovering from the flu and am having some trouble thinking, but I didn't find your "Why not build this into Realtime?" section very compelling. If you've already got a central source of truth (so you don't currently need the peer-to-peer nature of CRDTs), isn't it faster to iterate on your solution if you implement the merge semantics within the central source of truth that you have full control over? I'm not convinced from your post that turning the database into a component of a peer-to-peer distributed system is predictably worthwhile; it's certainly predictably going to be very complex. It smacks to me of spending a great deal of engineering effort to keep your options much further open than I've seen you justify.

kiwicopple 4y ago
Thanks, perhaps I can try explaining it from another angle. At the moment, every tool in supabase is decoupled from the other tools. The only thing that each tool depends on is Postgres. This is beneficial, because now we don't need to build interfaces - Postgres is the interface. Putting this implementation into Realtime would introduce a second dependency for some tools or create a burden for the developer. For example, this query goes directly to PostgREST: supabase.from('posts').update({ title: 'Hello', content: 'World' }); If the "content" part of this is a CRDT, then suddenly the developer needs to know that that particular field needs to be sent through realtime (psuedo-code): supabase.from('posts').update({ title: 'Hello' }); supabase.from('posts').merge({ content: 'World' }); Or we'd need to build some automatic-routing logic into the libraries (or PostgREST), which is also complex. In my view, CRDTs are a data problem, and therefore probably a database problem. If we can make Postgres act like "just another peer", then it simplifies the architecture. > isn't it faster to iterate on your solution if you implement the merge semantics within the central source of truth that you have full control over? We have full control over both Realtime and Postgres (at least the extension), so this is less of a concern. We're also less worried about fastest iteration than finding the correct solution long-term

kiwicopple 4y ago

Thanks, perhaps I can try explaining it from another angle. At the moment, every tool in supabase is decoupled from the other tools. The only thing that each tool depends on is Postgres. This is beneficial, because now we don't need to build interfaces - Postgres is the interface. Putting this implementation into Realtime would introduce a second dependency for some tools or create a burden for the developer. For example, this query goes directly to PostgREST: supabase.from('posts').update({ title: 'Hello', content: 'World' }); If the "content" part of this is a CRDT, then suddenly the developer needs to know that that particular field needs to be sent through realtime (psuedo-code): supabase.from('posts').update({ title: 'Hello' }); supabase.from('posts').merge({ content: 'World' }); Or we'd need to build some automatic-routing logic into the libraries (or PostgREST), which is also complex. In my view, CRDTs are a data problem, and therefore probably a database problem. If we can make Postgres act like "just another peer", then it simplifies the architecture. > isn't it faster to iterate on your solution if you implement the merge semantics within the central source of truth that you have full control over? We have full control over both Realtime and Postgres (at least the extension), so this is less of a concern. We're also less worried about fastest iteration than finding the correct solution long-term