Resolver Caching

[tonyketcham]

We can store resolved fields which will come in handy for advanced, nested filtering. This can prevent the same node field from being calculated tens or even thousands of times over the course of sequential queries.

Some options to consider:

• https://medium.com/yld-blog/node-js-databases-an-embedded-database-using-leveldb-b1beb191d0a2
• https://github.com/typicode/lowdb
• https://www.npmjs.com/package/lru-cache
• https://www.npmjs.com/package/flat-cache <- this may be useful for persisting query caches between builds via a checksum
• https://www.npmjs.com/package/cache-manager

[odama626]

what if we do hashing and dump everything into an sqlite db during generate schema and then filters can just be sql queries?

[tonyketcham]

I don't necessarily want to depend Flatbread's core directly on SQL. But I agree re: hashing and dumping into a DB of sorts; having the schema cached along with hashing loaded nodes & resolved fields should prevent unnecessary recalculations. Combined with a granular cache invalidation strategy for CRUD workflows, Flatbread should scale well to tens of thousands of content nodes with high performance.

[tonyketcham]

We could stand on the shoulders of giants and follow Gatsby's DB choice with LMDB, which is the fastest in-memory Node DB in town https://github.com/kriszyp/lmdb-js