Automatic API Caching with Redis: One Setting, Under a Millisecond

Intro

0:00 Some reads make the database do the same work again and again. In this video, one setting keeps their answers in Redis, a write drops them on its own, and a read of a million rows answers in about a millisecond.

A cache, the usual way

0:13 A cache usually means get and set code around every query, a key designed by hand, which may serve one caller the answer of another, stale data after an update someone forgot to purge, and the same work again in every service. With API Maker, caching is one setting of a table, a database or an API. The key is made of the caller and the request. Every write through API Maker drops the cached answers of its table, and code or a header resets them when you need it.

0:44 In this video : caching turned on, the same read twice, the answer in Redis, a write that drops it, resets from code and headers, custom APIs, and what to know.

Caching turned on

0:55 The support team of Calm Home looks up the events of an order by its request id. They are in MySQL, in the database sales, in order_events : a million rows. Its Collection Settings : the default code lists what a table can set. enableCaching, true. Save. Every read API of the table is cached now.

The same read twice

1:18 In API Testing, Get all of order_events, with the find of one request id : the table has no index for it. Send : over a hundred milliseconds, from the database ; the bar says api. Send again : a few milliseconds. The bar says cache. From a terminal, the response header x-am-data-source tells where each answer came from. The first read : over a hundred milliseconds, from the database.

1:46 The next ones : about a millisecond, from Redis. About a hundred times faster, and the database did nothing.

The answer in Redis

1:54 Redis Dashboard shows what is kept. Expand all : the key of the account, instance API, mysql, sales, order_events. The answer is kept as it was sent, for two hours by default : the timer counts down. A second key keeps its status and content type. The key is the table, and a hash of the request : the API user and the tokens of the person who asks, the headers that change an answer, the query, the body and the parameters.

2:26 Two callers with different rights never share an answer, and each tenant has its own.

A write drops it

2:32 Now the order is delivered. Among the APIs of the table, Update by id : the id, five hundred thousand, and the body, event type, DELIVERED. Send. Every cached answer of order_events is dropped. The same read : from the database again, and it says DELIVERED. Then from the cache again.

Resets from code and headers

2:54 Data can change outside API Maker : an import, a job of the database. One line of code resets a table : g dot sys dot cache dot resetCacheDB, or the system API it calls. A caller can ask for a fresh answer : the header x-am-cache-control, reset_cache. From the terminal : the next read goes to the database, and is kept again.

Custom APIs

3:20 A custom API is cached the same way, per body, query and caller. resetCacheOnModificationOf names the tables whose writes drop its answers : the orders report forgets its answers when order_events changes.

What to know

3:35 A cached answer runs no hook. A hook that limits rows to the caller still holds : the caller is part of the key. Answers longer than a limit are not kept, and every answer expires after two hours, both in the configuration. The Redis is the external Redis the root user sets in Deployment Settings, shared by every server.

Built on standards

3:58 The setting is a file in git, next to the table. No API has cache code in it, so nothing forgets to purge. And one rule holds for every API of the table : read, cached ; write, dropped.

Recap

4:11 To sum up. Caching is one setting. A repeated read answers in about a millisecond. The key keeps callers and tenants apart. Every write drops the cached answers of its table. Code and a header reset them when data changes outside. Next : Index Maker, for the reads a cache can not hold. API Maker. Build faster, spend smarter, deliver better.