4 ms·

I really like the concept. We use Supabase as the backend for a Vue application. We end up pulling in very large amounts of data to the frontend (details on ev

I really like the concept. We use Supabase as the backend for a Vue application. We end up pulling in very large amounts of data to the frontend (details on every alert and event in kubernetes clusters) and then filter it multiple ways and graph it on a timeline. So we end up implementing lots of db like logic in typescript. I've long wished for a simpler and more reusable way to do this that still let's me process the data clientside. Here's an example of a simple timeline graph (built with vegalite) which needs the ability to filter by several columns and do various groupings https://ucarecdn.com/0c76c5ef-1eb4-4320-8e46-abb9c3956658/-/crop/1528x816/520,0/-/preview/imageonline-co-roundcorner-(2)-(1).png https://ucarecdn.com/0c76c5ef-1eb4-4320-8e46-abb9c3956658/-/...

vaughan 5y ago
I think most dbs, paas, frameworks skip this use case. For a snappy data-centric app, you pretty much need your entire app logic to run client-side. Everyone always ends up with this terrible denormalized client-side cache with duplicated Server side logic. What you really want is the exact same db running server-side and client-side. I thought for a while this would be an sql db but now I think sql and the relational model is the wrong approach for web app data as they are inefficient for watching queries and syncing.
- nyellin 5y ago
  Hmm, interesting. I'm using supabase which essentially autogenerates the entire server-side part. So all my logic is client side. What's missing is tighter integration between swrv/vue-swrv and the supabase client so that when you run a query it can be smart enough to know if you apply it locally or remotely.