RFC: 001 - FEATURE: add cache pattern to hyper63 client

[twilson63]

• Start Date: 2021-02-10

Feature: Flag to cache data documents

Summary

hyper63's data port takes json documents as data and a common pattern is to want to cache these documents so that the api can reduce the amount of repetitive read requests performed on the database, giving more bandwidth for write requests. This request for change is to modify the setup process of the client to specify the types of documents that will be stored in the hyper63 data store for a given database. On each document description add a boolean property called cache, if the property is set to true, when a document is created or updated then the client will also add the document to the cache, and when the document is deleted it will also remove the document from the cache, finally when the document is referenced by id, it will get the document from the cache. Or if the document type is referenced by a basic list/pagination request, it will also reference the cache.

Motivation

There are two motivations with this request, one motivation is that it is developer experience to be able to set a boolean flag to cache documents could be a significant time saver and performance boost, the other is validate the feature pipeline process for hyper63, implement feature in user land, migrate to the hyper63 client, then migrate to hyper63 core if deemed valid.

Detailed design

This is the bulk of the RFC.

Explain the design in enough detail for somebody
familiar with the framework to understand, and for somebody familiar with the
implementation to implement. This should get into specifics and corner-cases,
and include examples of how the feature is used. Any new terminology should be
defined here.

How we teach this

What names and terminology work best for these concepts and why? How is this
idea best presented? As a continuation of existing Atlas patterns, or as a
wholly new one?

Would the acceptance of this proposal mean the Atlas guides must be
re-organized or altered? Does it change how Atlas is taught to new users
at any level?

How should this feature be introduced and taught to existing Atlas
users?

Drawbacks

Why should we not do this? Please consider the impact on teaching Atlas,
on the integration of this feature with other existing and planned features,
on the impact of the API churn on existing apps, etc.

There are tradeoffs to choosing any path, please attempt to identify them here.

Alternatives

What other designs have been considered? What is the impact of not doing this?

This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.

Unresolved questions

Optional, but suggested for first drafts. What parts of the design are still
TBD?

With the hyper63 client add the ability to setup a database or document type as cachable, which means that everytime that document type is added, updated or deleted it would also update the cache, and when a document get by id is requested it is pulled from the cache first. and if a list docs is called, the list queries the cache, which means the cache documents will need to be prefixed with the type

A potential implementation would look like this

client.setup.db({types: [
  {name: 'movie', cache: true }, 
  {name: 'actor', cache: true }, 
  { name: 'producer', cache: false}
]})

This would only allow the document types of with the following names and would cache each type that was flagged as cache true.

---

[twilson63]

Why implement these features in the client and not in core?

My initial thoughts is to treat the client as a place to test patterns and gauge adoption early on, if the pattern is proven and it should reside in core, then take steps to migrate to the core service.

By taking this approach we can keep core as minimal as possible until we know the right solution and then implement in core to get the performance benefits.

[twilson63]

I am recommending we hold off on this RFC because it feels like it is too much too fast, I think we should revisit when the pattern is validated and repetitive in userland