Thanks for replying. For my example application probably I will use the native AppSync cache for its simplicity, it allows me to cache the results based on user identity or arguments provided. For example certain actors or directors are more popular than the others so caching by arguments when users search for movies featuring a particular actor/director makes sense. The good point is you don't have to write a lot of custom code to handle the caching, you just specify what key and TTL to AppSync and it is handled for you. In this case if I cache results by arguments, I am also safe to set a higher TTL because the access pattern is not something that requires a strong consistency.
Caching with Cloudfront is also a solution, but I will consider caching with Cloudfront only if the native cache (basically a redis) cannot handle the load (i.e. thundering herd when many users query for the same movie at the same time). Caching with Cloudfront involves much more efforts, you have to find the optimal TTL settings on both Cloudfront and AppSync which is not simple work. But of course using Cloudfront to handle surge of request is going to be cheaper than paying for a larger instance of Redis.
So in conclusion, start small with the native cache in AppSync, if it doesn't work well, start think of Cloudfront. And besides caching, batching (using Dataloader for example) can also be employed, although you usually pick between caching and batching.
Besides caching, when using Lambda as resolver to query database, remember to set callbackWaitsForEmptyEventLoop to false in order to reuse DB connections. This is especially true in Node.js.
Thanks Gauis, after much consideration and reading, I've to move to API gateway to use Cloudfront caching for certain paths/endpoints. Because there is no cheap or easy alternative for implementing caching on Appsync, the appsync resolver cache costs you money straightaway and Cloudfront with Appsync can't be implemented without Redis.
Nice to hear that Rajat!
I agree caching on AppSync is not straightforward either unless using the provided Redis.
For me personally I am also evaluating between AppSync and Redis Streams for the pub-sub functionality in my new application (Cannot use SNS for some reason). Redis Streams is quite powerful not only as a cache but also moving data around, but at the end I decided to stick with AppSync because I want to go full serverless (My database is Timestreams which is also serverless)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for replying. For my example application probably I will use the native AppSync cache for its simplicity, it allows me to cache the results based on user identity or arguments provided. For example certain actors or directors are more popular than the others so caching by arguments when users search for movies featuring a particular actor/director makes sense. The good point is you don't have to write a lot of custom code to handle the caching, you just specify what key and TTL to AppSync and it is handled for you. In this case if I cache results by arguments, I am also safe to set a higher TTL because the access pattern is not something that requires a strong consistency.
Caching with Cloudfront is also a solution, but I will consider caching with Cloudfront only if the native cache (basically a redis) cannot handle the load (i.e. thundering herd when many users query for the same movie at the same time). Caching with Cloudfront involves much more efforts, you have to find the optimal TTL settings on both Cloudfront and AppSync which is not simple work. But of course using Cloudfront to handle surge of request is going to be cheaper than paying for a larger instance of Redis.
So in conclusion, start small with the native cache in AppSync, if it doesn't work well, start think of Cloudfront. And besides caching, batching (using Dataloader for example) can also be employed, although you usually pick between caching and batching.
Besides caching, when using Lambda as resolver to query database, remember to set callbackWaitsForEmptyEventLoop to false in order to reuse DB connections. This is especially true in Node.js.
mongodb.com/blog/post/optimizing-a...
Thanks Gauis, after much consideration and reading, I've to move to API gateway to use Cloudfront caching for certain paths/endpoints. Because there is no cheap or easy alternative for implementing caching on Appsync, the appsync resolver cache costs you money straightaway and Cloudfront with Appsync can't be implemented without Redis.
Nice to hear that Rajat!
I agree caching on AppSync is not straightforward either unless using the provided Redis.
For me personally I am also evaluating between AppSync and Redis Streams for the pub-sub functionality in my new application (Cannot use SNS for some reason). Redis Streams is quite powerful not only as a cache but also moving data around, but at the end I decided to stick with AppSync because I want to go full serverless (My database is Timestreams which is also serverless)