GraphQL Edge Caching

Optimize GraphQL API Performance and Efficiency with GraphQL Edge Caching.

V
I
S
I
T
O
R
S
MAX LOAD
16:00
20:00
24:00
04:00
08:00
12:00
16:00
20:00
24:00
04:00
Without Stellate
GraphQL
Client
GraphQL
Backend

Eliminate downtime. Maximize performance. Protect users.

Stellate’s GraphQL Edge Caching sits in front of your existing infrastructure and supports all GraphQL APIs.

It can handle POST requests, cache private data per authenticated user, and proxy through to your server of choice.

20.5%

Less API traffic

The requests our origin has to handle dropped by more than 50% — we don't even notice traffic spikes anymore!

Ivan Vanderbyl

CPO & Co-Founder, Airheart

Airheart logo
Compare Performances

Lengthy loading is so 2020

Activate Stellate’s GraphQL Edge Caching in the example below and fetch data (almost) instantly.

Stellate

Set up in minutes

Enter your own API endpoint, have it up and running in 5min.

Partial Query Caching

Automatically split GraphQL queries to maximize caching

Cache data that was previously uncacheable and only the data you want, ensuring accuracy and freshness for dynamic content.

Peak performance

Boost performance, reduce downtime

  • Global p95 response time

    50ms

    There is no excuse for slow performance.

  • Server load reduction

    90%+

    You build your product, we handle your traffic.

  • Stellate uptime

    100%

    We’re up all night so you stay lucky.

30.6%

Faster p50 API response time

For 80% of our queries, performance went up significantly: Our GraphQL API’s overall p95 response time has decreased by over 10 seconds!

Matt MacGillivray

Founder, InnerSpace

InnerSpace logo
Performance Features

Cache it like it's hot

  • {
    posts { # Post: maxAge 900s swr 900s
    nodes {
    id
    title
    slug
    status # Post.status: swr 180s
    author {
    node { User: scope AUTHENTICATED
    id
    name
    }
    }
    }
    }
    }
  • Fine-grained cache control

    Create custom rules to determine which GraphQL query results to cache for how long based on types and fields.

    For example: Cache posts results for 900s and its status for 180s.

  • Automatic mutation invalidation

    Invalidate any changed data sent to your GraphQL API automatically.

    For example: editPost(id:5) will invalidate all cached query results containing the post with id 5.

  • Instant global cache purging

    Purge specific data globally in about ~150ms.

    For example: Purge the post with id 5 and any cached query results containing it.

Works natively with Stellate Metrics

Continuously optimize with advanced caching metrics

  • Understand your global latency

    Most GraphQL APIs sit in one data center. Monitor your global latency and verify the performance boost your users get through edge caching.

    Map showing P95 latencies for North America (512ms), South America (1208ms), Europe (159ms) and Africa (747ms)
  • Get cache hit rate insights

    Understand how the attributes of your various data types affect the cache hit rate of individual queries.

    A card where we see Different types of our application with their corresponding cache hit rate on the left side, on the right side there are different unused types and when they were last seen
  • Monitor how your Cache Hit Rate changes

    Understand your caching strategy by observing Cache Hit Rate over time. Analyze trends, identify patterns, and adapt your cache rules to boost your API caching performance.

    A card where we see the Cache Hit Rate chart over a period of time
  • Optimize your cache rules performance

    Evaluate cache rules performance. Optimize your caching strategy by understanding how requests and operations are affected by your cache rules.

    Two cache rules showing the details and the affected types
  • Check your purging analytics

    Whether auto invalidated from mutations or manually invalidated from the API, Metrics show when and what is being purged from the cache.

    A statistic showing that a mutation named updateOrder resulted in an expected latency increase of 1537ms because it invalidated a set of types and queries
  • Become a pro in cache debugging

    Track every request and its cache state. Monitor your cache hit rate and understand why certain requests are being cached and others are not.

    A query named getCategories resulted in a cache-pass because the request body was too big, we can also derive that we retried the request three times, it it failed twice due to a Bad Gateway error and ended up in a success.
  • One-Click Cache Purging

    Stay in control of content changes even if you can't rely on webhooks. Instantly purge the entire cache or use Purge actions to remove cache items based on specific operations or types from our metrics dashboard.

    A query named caseStudyCollection is displayed accompanied by a P99 latency of 103ms alongside a Purge button that allows you to purge the cache for this query

What are you waiting for?

Set up Stellate in less than 5 minutes to unlock the full potential of your GraphQL API.