Stellate

ICYMI on stage at #graphqlconf, The Guild Software announced acquisition of Stellate, the edge caching/CDN product for GraphQL APIs, as well as two v1 launches for open source projects GraphQL Mesh and Hive Gateway. Watch CEO Uri Goldshtein's announcement & learn more: https://hubs.la/Q02RvBGv0

Big news: Stellate has been acquired! 🎉 Stellate's eng team is joining Shopify to work on storefront performance and The Guild Software will be the new home for the product and all customers 😍 Read the story of why and how this came together: https://lnkd.in/dpxvwZYn 👈

To showcase our product at conferences and during sales calls, we at Stellate needed a demo that showcases realistic GraphQL traffic. So, we built a demo GraphQL API and traffic simulator that was great for demos, but also improved our local DX. 🚀 https://t.co/eq8beQhVWT 👈

Almost exactly two years ago I started my journey as GraphiQL contributor. A lot has happened in that time. Particularly exciting: The launch of GraphiQL v2 🚀 I've done a bunch of talks about that journey. I never wrote it down...until now! https://lnkd.in/dkVWDynG

Super excited to announce that we've open-sourced our GraphQL query parser written in Rust! 🎉🦀 graphql-query is ~8.7x faster than any other GraphQL query parser. 🤯 https://lnkd.in/df_iFmk2 👈

At Stellate, we just shipped @⁠defer support for our Partial GraphQL Query Caching… …which means we can stream back cache hits from the edge …while fetching non-cacheable parts from the origin …even though it's all in a single request from the client 🤯🤯🤯

🎙️Our latest FFP Podcast episode with our Executive Operations Manager, Maria Constantine, explores executive operations management, business development, and women in startupland.🚀🎧 Our Future Founder Promise podcast is available here: https://lnkd.in/d-32PrGy

You probably don't need GraphQL. You might be surprised to read that from the co-founder of a GraphQL company. Let me explain. https://lnkd.in/deq-QPcg 👈

We (obviously) love caching at Stellate, but caching isn’t for everyone. Stick with us; let’s explore when you might NOT need caching. 👇 𝟭. 𝗣𝗲𝗿𝘀𝗼𝗻𝗮𝗹𝗶𝘇𝗲𝗱 𝗱𝗮𝘁𝗮 If you only have personalized data unique to each user, caching won’t provide much benefit. The only way to get a cache hit is for the same user to send the same request again before their data changes—an unlikely scenario. 𝟮. 𝗛𝗶𝗴𝗵 𝗰𝗮𝗿𝗱𝗶𝗻𝗮𝗹𝗶𝘁𝘆 𝗱𝗮𝘁𝗮 High cardinality data, such as search results on a travel site, will have a low cache hit rate. With so many possible combinations of searches, the chance of a cache hit is like finding a needle in a haystack. 𝟯. 𝗛𝗲𝗮𝘃𝘆 𝗔/𝗕 𝘁𝗲𝘀𝘁𝗶𝗻𝗴 If you heavily rely on A/B testing, you must cache responses for the specific combination of variants the user is enrolled in—essentially making each response personalized. (see #1) 𝟰. 𝗗𝘆𝗻𝗮𝗺𝗶𝗰 𝗱𝗮𝘁𝗮 If your data rapidly changes, caching probably isn't for you. For example, caching the latest stock price is a terrible idea because it changes so frequently that you will have a 0% cache hit rate. In conclusion, caching is powerful, but it's not a one-size-fits-all. Evaluate your data and use cases carefully. Sometimes, the key to success is knowing when NOT to cache. Want to dive deeper into the world of caching and when to skip it? Let’s have a conversation. Your server (and sanity) might thank you! 

API caching can be a game-changer for performance and reliability, but it's easy to get it wrong and most API caches today don’t help get it right. Here’s why your API cache (most likely) sucks 👇 𝟭. 𝗕𝗲𝗰𝗮𝘂𝘀𝗲 𝗶𝘁 𝗰𝗮𝗻 𝗼𝗻𝗹𝘆 𝗰𝗮𝗰𝗵𝗲 𝗲𝗻𝘁𝗶𝗿𝗲 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲𝘀 API caching is not an all-or-nothing game: a bit of personalized data in a response shouldn't spoil the whole bunch. Great API caches are able to cache specific parts of responses. 𝟮. 𝗜𝘁 𝗼𝗻𝗹𝘆 𝗴𝗶𝘃𝗲𝘀 𝘆𝗼𝘂 𝗮𝗴𝗴𝗿𝗲𝗴𝗮𝘁𝗲 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 You can't fix what you can't see. Great API caches give you visibility into each individual request, not just overall cache hit rates. That way, you can debug user-facing issues caused by the cache. ("my order isn't showing up…") 𝟯. 𝗜𝘁 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗴𝗶𝘃𝗲 𝘆𝗼𝘂 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻𝘁𝗼 𝘁𝗵𝗲 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝗼𝗳 𝘆𝗼𝘂𝗿 𝘁𝗿𝗮𝗳𝗳𝗶𝗰 Not all traffic and data is equally cacheable. Great API caches track your traffic and calculate it's cacheability per endpoint. This will help you hit that sweet cache spot more often. 𝟰. 𝗜𝘁 𝘀𝗲𝗽𝗮𝗿𝗮𝘁𝗲𝘀 𝘆𝗼𝘂𝗿 𝗰𝗮𝗰𝗵𝗲 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 𝗳𝗿𝗼𝗺 𝘆𝗼𝘂𝗿 𝗰𝗼𝗱𝗲 Separating cache configuration from code is like trying to clap with one hand. Great API caches allow you to keep them together to avoid inconsistencies and ensure your cache is always in sync with changes to endpoints. 𝟱. 𝗜𝘁 𝗵𝗮𝘀 𝗻𝗼 𝘃𝗶𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗶𝗻𝘁𝗼 𝗰𝗮𝗰𝗵𝗲 𝗶𝗻𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗼𝗻𝘀 Cache invalidation is tough but crucial. Get it wrong, and you'll serve stale data. Great API caches know it's not just about invalidating the cache; it's about helping you understand when and what was purged. 𝟲. 𝗜𝘁 𝗰𝗮𝗻 𝗼𝗻𝗹𝘆 𝗰𝗮𝗰𝗵𝗲 𝗽𝘂𝗯𝗹𝗶𝗰𝗹𝘆 𝗼𝗿 𝗽𝗲𝗿-𝘂𝘀𝗲𝗿 Granularity is your friend in caching, generally the more specific you can make your cache keys, the better the cache hit rates you can get. Great API caches give you fine-grained control over caching groups based on e.g. JWT claims. Finally, remember that caching isn't a silver bullet. It's powerful, but only when used wisely. Assess your data, understand your application, and cache smart.