Overview - Forest Documentation

Translation vs. Replication

	Translation	Replication
How it works	Translates Forest’s query interface into your API’s query language and calls the source live on every request	Maintains a local copy (replica) of the source data in a cache controlled by the back-end, and queries that copy
Data freshness	Always live: every request hits the source	Eventually consistent: refreshed on a schedule, by polling, or via push/webhooks
Query translation	You implement it (filters, sort, pagination, aggregation)	None: filtering, sorting, search, and charts work out of the box against the cache
Effort	High: a full-featured translation layer often exceeds 1000 lines	Lower: you mostly implement how data is fetched and (optionally) written back
Best for	Sources that already support rich querying and where data must always be live	Slow, rate-limited, or query-poor APIs where a cached copy is acceptable
Availability	Node.js and Ruby	Node.js only

Choosing a strategy

Reach for Translation when your source is a capable database or API that can filter, sort, and paginate efficiently, and you need every read to reflect the latest state.

Reach for Replication when the source API is slow, rate-limited, or hard to query, and a periodically synced copy is good enough. It is the simpler path and gives you Forest’s full feature set with no query translation.

Don’t see the datasource you need? Contact us to request a connector, or share your own through the Forest experimental repository.

​Translation vs. Replication

​Choosing a strategy

Translation vs. Replication

Choosing a strategy