Timeboxed to 3 days
See #1447
So far, LB4 persistence story is all about CRUD. Key-value stores are another common scenario we should support. LoopBack 3.x introduced KeyValue API and Redis + eXtremeScale connectors. For LoopBack 4, we need to add Repository implementations for KeyValue API and verify that all pieces work together as expected.
- Add necessary Repository APIs and implementations
- Verify the use case against real Redis instance
- Documentation, example app, blog post
LB 3.x resources for reference:
Proposed repository API:
interface KeyFilter {
match: string;
};
interface KeyValueRepository<T> {
get(key: string, options?: object): Promise<T>;
set(key: string, value: T, options: object & {ttl?: number}): Promise<void>;
expire(key: string, ttl: number, options?: object): Promise<void>;
ttl(key: string, options?: object): Promise<number>; // find a better name than ttl?
iterateKeys(filter: KeyFilter, options?: object): AsyncIterator<T>;
keys(filter: KeyFilter, options?: object): Promise<T[]>;
}
Acceptance criteria
Timeboxed to 3 days
See #1447
LB 3.x resources for reference:
Proposed repository API:
Acceptance criteria
KeyValueRepositoryas an addition toEntityCrudRepository.Discuss the proposed implementation in a pull request, get it approved at least by @raymondfeng and @bajtosRaymond went ahead and opened a pull request providing a full implementation - see feat(repository): add KVRepository impl using legacy juggler #1539