Cache Rules Everything Around Me
It is well known that there are three hard things in software engineering:
- off by one errors
- naming things
- cache invalidation
An experienced software engineer might say, “A.D., what’s the point of mentioning this?”.
My goal with writing this article is to share a tip based off my experiences around the configuration of CNN Digital services in Fastly. There is one caveat, I am not the foremost expert when it comes to knowing all bits around edge caching.
There are smarter and more experienced persons outside of myself.
Why should you continue to read this article? To see one example of thinking “around” the box regarding POST requests.
It is commonly known that GET requests are easily cacheable. GET requests have a predictable pattern that can be used as part of a cache key. The cache key is the unique identifier that is used to reference cached objects. This is similar to how the DBMS uses a primary key to uniquely reference items in a database. For example a request for www.cnn.com/2018/08/29/health/avocado-study-trnd/index.html can be matched on the URI path/2018/08/29/health/avocado-study-trnd/index.html.
So AD, why are you are talking about POST caching? Simply use GET requests and call it a day.
When building a REST API, the use of POST requests is a way to read objects that are stored. Make a request and the response is full payload of an object. This means that a front end app will get the a full object payload even if there is only one field needed from the response. When it comes to the delivery digital content the speed of a front end app is dependent on the performance of the underlying APIs. The size of objects being transported between the front end app and the underlying APIs has a direct impact on speed.
There is more than one way to address object sizes from an API. One solution is to build a GraphQL API. Facebook developed GraphQL internally and it was open sourced in 2015. The most important thing to note is that it allows front end apps to request defined fields that are important to it. This article is not about building GraphQL APIs but how thinking around the box enables the use of an edge cache to deliver responses from an API built on the technology.
AD, use GET requests and leave it be!
The constraint with GET requests are that they have a size limit and that is a limitation. There are front end applications that can produce some exotic queries and it makes more sense to use POST requests. Thanks to Fastly, they will automatically use the POST body as part of the cache key when the body is less than a certain limit. Because we like to control our own destiny, we did not want to be bound by this limit.
The use of the hash is part of the solve. However, we still have to be smart about security and DDoS attacks by making the necessary precautions as with any service. That’s an entirely different conversation….
So what did we do that was so revolutionary?
Nothing.
Recreate a hash of POST body. Pass the value as a header. Cache with that value. Period.
We are not bound by Fastly’s limits. We are not bound by the limits of GET requests. Let’s party!
