|
3 | 3 | ZenStack Cache |
4 | 4 | </h1> |
5 | 5 |
|
6 | | - Reduce response times and database load with query-level caching integrated with the ZenStack ORM. |
| 6 | +Reduce response times and database load with query-level caching integrated with the ZenStack ORM. |
| 7 | + |
7 | 8 | </div> |
8 | 9 |
|
9 | 10 | <div align="center"> |
|
19 | 20 | <a href="https://discord.gg/2PaRSu7X"> |
20 | 21 | <img alt="Join the ZenStack Cache channel" src="https://img.shields.io/discord/1035538056146595961"> |
21 | 22 | </a> |
22 | | - <a href="https://github.com/visualbravo/zenstack-cache/blob/76a2de03245c26841b04525dd8b424a8799d654c/LICENSE"> |
| 23 | + <a href="https://github.com/visualbravo/zenstack-cache/blob/dev/LICENSE"> |
23 | 24 | <img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-green"> |
24 | 25 | </a> |
25 | 26 |
|
|
29 | 30 | </div> |
30 | 31 |
|
31 | 32 | ## Features |
32 | | -* 🌐 **Redis Cache:** A central cache to scale across different systems. |
33 | | -* 🖥️ **Memory Cache:** A simple cache when scale is not a concern. |
34 | | -* 🛟 **Type-safety:** The caching options appear in the intellisense for all read queries. |
35 | | -* 🏷️ **Tag-based Invalidation:** Easily invalidate multiple related cache entries. |
| 33 | + |
| 34 | +- 🌐 **Redis Cache:** A central cache to scale across different systems. |
| 35 | +- 🖥️ **Memory Cache:** A simple cache when scale is not a concern. |
| 36 | +- 🛟 **Type-safety:** The caching options appear in the intellisense for all read queries. |
| 37 | +- 🏷️ **Tag-based Invalidation:** Easily invalidate multiple related cache entries. |
36 | 38 |
|
37 | 39 | ## Requirements |
38 | 40 |
|
39 | | -* ZenStack (version >= `3.3.0`) |
40 | | -* Node.js (version >= `20.0.0`) |
41 | | -* Redis (version >= `7.0.0`) |
42 | | - * ℹ️ Only if you intend to use the `RedisCacheProvider` |
| 41 | +- ZenStack (version >= `3.3.0`) |
| 42 | +- Node.js (version >= `20.0.0`) |
| 43 | +- Redis (version >= `7.0.0`) |
| 44 | + - ℹ️ Only if you intend to use the `RedisCacheProvider` |
43 | 45 |
|
44 | 46 | ## Installation |
45 | 47 |
|
@@ -115,21 +117,22 @@ After performing a query, you can check where the result came from. |
115 | 117 | const publishedPostsStatus = client.$cache.status // 'hit' | 'miss' | 'stale' |
116 | 118 | ``` |
117 | 119 |
|
118 | | -* `hit` - a cache entry in the `ttl` window was found, and the database was not queried. |
119 | | -* `miss` - a cache entry was not found, and the database was queried. |
120 | | -* `stale` - a cache entry in the `swr` window was found, and the database was queried in the background to revalidate it. |
| 120 | +- `hit` - a cache entry in the `ttl` window was found, and the database was not queried. |
| 121 | +- `miss` - a cache entry was not found, and the database was queried. |
| 122 | +- `stale` - a cache entry in the `swr` window was found, and the database was queried in the background to revalidate it. |
121 | 123 |
|
122 | 124 | ## Revalidation |
123 | 125 |
|
124 | 126 | If the result was stale, you can choose to await its revalidation. |
| 127 | + |
125 | 128 | ```typescript |
126 | 129 | const revalidatedPublishedPosts = await client.$cache.revalidation as Post[] |
127 | 130 | ``` |
128 | 131 |
|
129 | 132 | ## Cache Options |
130 | 133 |
|
131 | | -* `ttl` reduces response times and database load by serving cached results. |
132 | | -* `swr` reduces response times by serving cached results, but does not reduce database load because it performs a revalidation in the background after each request. |
| 134 | +- `ttl` reduces response times and database load by serving cached results. |
| 135 | +- `swr` reduces response times by serving cached results, but does not reduce database load because it performs a revalidation in the background after each request. |
133 | 136 |
|
134 | 137 | > [!NOTE] |
135 | 138 | > The total TTL of a cache entry is equal to its `ttl` + `swr`. The `ttl` window comes first, followed by the `swr` window. You can combine the two options to best suit the needs of your application. |
|
0 commit comments