Lazy Shapes

[KyleAMathews]

I was thinking through some scenarios for shapes and I was curious how you'd handle this one.

Imagine a very large table — too big to sync and also it's quite random what rows a user would want to fetch e.g. an articles table or build logs table.

To fetch this data, the docs suggest you'd want to create a sync shape for that specific document and then wait for it to be synced.

My question though isn't there quite a bit of overhead for setting up a new shape? If so, what would be ideal is if you had a lazy shape that didn't sync any data until loaded e.g. await articlesTable.load(id) — perhaps you could setup a capped LRU cache for these as well e.g. 100. Then loading individual rows for visiting a new screen would be very cheap e.g. ~25-100ms.

[thruflo]

I think the LazyShape concept is cool. We've thought about ways to defer loading of lower parts of a shape until either higher parts have synced or some user action triggers it.

In the case of fetching a row from a big table, I'm not sure but I don't think the overhead of e.g.: db.articles.sync({where: {id: 1234}}) is very high. You send the shape to the server. It performs an initial query or queries and then streams the row(s) through. Are you thinking the query may take time because the table may be big and need a sequence scan or some other slow query? I can see then maybe somehow having run the query or maintaining the rows in shape server side could pre-run the initial query. But it feels like quite a lot of complexity to maintain.

[KyleAMathews]

I wrote this too quickly yesterday 😅 my argument basically rested on they're being overhead — which I didn't test thoroughly — I do see ~500ms sync times for the initial sync but if I just delay one of those until later, the time drops to ~1ms. Also I was counting time for auth, etc. So yeah, it looks like the overhead is quite low!