The problem
A lot of application APIs are considered non-cacheable either because:
- the underlying data changes frequently
- they use GraphQL making it difficult to cache
- they’re REST APIs that fetch using POST because they have their search parameters within the body
Solution
SuperAPI makes such APIs cacheable by monitoring your incoming POST / PUT / PATCH API calls, and your database updates to invalidate stale data immediately.
Because we listen to your database changes, SuperAPI can also update your cache in-place. This means, any updates in your database will only modify the relevant portions of your cached API responses.
This reduces the amount of computations on your database & compute instances, helping reduce your cloud spend.
Can SuperAPI prevent stale cache data completely?
Yes. Since SuperAPI is able to watch incoming API calls, we can monitor all POST / PUT / PATCH API calls that could modify your cached API responses and invalidate immediately. This makes sure that your users never see any stale data.
You can read more about how this works here.
How does SuperAPI monitor my database updates?
SuperAPI listens to updates in your database through the replication mechanism.
This helps us identify which API responses require need to be updated, and we update these cached API responses in-place.
What kind of latencies can SuperAPI provide?
We have an average latency of 30ms, and a p99 latency of 55ms, as measured on the end user device.
If this is only about API caching - what about the first load time of the API?
SuperAPI pre-caches your most used APIs on a regular basis, which helps with first load timings.
We find patterns in your API traffic automatically to start pre-caching them, but you can always modify these patterns from your dashboard. Pre-caching also works for multiple chained APIs too, (ie) if your second API is derived from your first API response etc.
Some of your APIs have application logic computing the API responses - how would that work?
SuperAPI allows you to import functions that compute these API responses into our configuration file. This means, we can now run your existing code as-is without you having to write or maintain any new code.
Hold on - if SuperAPI already has a diff of our API responses, can we use this to make our clients reactive?
Yes you can 🙂
Our POP locations allow your clients to subscribe to changes to one or more APIs for a user. Anytime a change occurs, we instantly push these down to your subscribed clients.
How is this different from a traditional CDN?
Traditional CDNs were built for static content that does not change often. Most application APIs though change very often, requiring developers to build mechanisms to invalidate these API caches by themselves.
Also, since most CDNs were built for non-changing data, their time to invalidate is often high. This makes them impractical for application APIs.
