Forge Cache is now available as part of Forge Early Access Program (EAP). To start testing this feature, sign up using this form.

Forge Cache is an experimental feature offered to selected users for testing and feedback purposes. This feature is unsupported and subject to change without notice. Do not use Forge Cache in apps that handle sensitive information and customer data.

For more details, see Forge EAP, Preview, and GA.

Cache (EAP)

The Forge Cache lets you read and write key-value pairs with higher throughput and lower latency. To do this, data is stored in memory and with no encryption. This provides storage with high performance, but with less security and no persistence. See Forge hosted storage for more information about persistent storage options.

To start using the Forge Cache, install the package in your project by running:

1
2
npm install @forge/cache

Next, import the package into your app:

1
2
import cache from '@forge/cache';

// ...
const App = () => {
  // ...
  const cacheClient = cache.connect();

Each installation of your app is subject to the Forge Cache limits.

Known issues

The following methods appear in @forge/cache, but they do not work:

rpop
lpush
scan

These are deprecated methods, and will be removed soon.

Cache connection

With the current Node runtime, apps need to initialise a Cache connection on every invocation. For example:

1
2
import cache from '@forge/cache';

const App = async () => { 
  const cacheClient = cache.connect();
  await cacheClient.set('key', 'value', { 
    ttlSeconds: 60
  });
}

Declaring the connection outside of an invocation will lead to socket timeout errors between invocations.

Time-To-Live (TTL)

Each key-value pair stored in the Forge Cache is subject to an expiry period, or Time-To-Live (TTL). The Forge Cache deletes keys that are not updated within the TTL.

The default TTL is 600 seconds. You can set a custom TTL through the ttlSeconds parameter. Custom TTLs can be between 30 and 3600 seconds.

Warning

Keys stored in the Forge Cache may sometimes be deleted before the TTL expires. See Volatility for more details.

Evaluation of TTL limits

We’re currently evaluating suitable values for minimum and maximum TTL. These values may change partly based on the data collected during the EAP. We recommend that you set appropriate TTL values based on your app’s needs.

If your app requires a higher limit, request a TTL increase through this form. We will review each request and adjust the limit based on demand, available resources, and use case validity.

Tunneling

The forge tunnel supports Forge Cache methods, but with the following limitations:

TTL is ignored, so keys do not expire.
Forge Cache methods will store data in your local environment. This means any latency or throughput results are not indicative the Cache functions' performance in production.
Forge Cache tunneling will not work with apps running on the legacy runtime. We recommend migrating your app to the latest runtime version.

No encryption

Forge Cache won’t encrypt keys when storing it in memory. As such, we strongly recommend against storing sensitive data on the Forge Cache.

Volatility

The Forge Cache’s high-performance storage infrastructure cannot store data for long periods. Keys stored in Forge Cache may also be deleted unexpectedly due to operational reasons, such as:

Scheduled or unscheduled maintenance periods
Data evictions due to load spikes
Product is pinned or migrated to a region (for Data residency purposes)

In cases like these, keys can be deleted even before their TTL expires.

Consistency

Forge Cache reads are eventually consistent. This means that it’s possible for data returned from reads to be slightly outdated.

Monitoring

You can monitor and track cache performance in the developer console. See Monitor cache metrics for more details.