3 ms·
Hasura discusses why they chose polling here (https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#when-do-we-refetch https://githu
by vaughan 5y ago
Hasura discusses why they chose polling here (https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#when-do-we-refetch https://github.com/hasura/graphql-engine/blob/master/archite...).
> WAL: Reliable stream, but LR slots are expensive which makes horizontal scaling hard, and are often not available on managed database vendors. Heavy write loads can pollute the WAL and will need throttling at the application layer.
Would like to hear Supabase's response to this.
- kiwicopple 5y agoHasura's approach is great and there are just tradeoffs between approaches. Sure, slots (can be) expensive; GCP doesn't offer slots but all the others do as far as I know (and I see that as a GCP issue, not a Supabase issue); a lot of writes can definitely fill the WAL. Stepping back, the main comment I can give is that we each approach problems with a slightly different philosophy. Hasura tackles problems using middleware and Supabase tackles problems using the database. Both are fine. Our approach is important (to us) as we evolve the product. For example, we are adding Row Level Security to our Realtime instance. Because it all sits in the database it's essentially just a Postgres extension, minimizing chatter between a middleware server and the database. Also because it's at the "bottom of the stack", other vendors/integrations can make use of the functionality we provide. (supabase cofounder)