Added callbacks to purge cache

[manojnaidu619]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Description

When a new article was created, then the existing articles cache was not getting flushed. Because of which, newly created article was not showing up in the response until that stale cache was purged by some other action.

Proposed Solution

Added different callbacks which performs under various stages of article lifecycle to purge cache data and maintain consistency.

• after_create - it invokes :purge_all and clears existing cache collection. So that, next request would hit server and stores fresh copy of data as cache.
• after_save - It invokes :purge and purges only itself from cache collection. (like, when an article gets updated)
• after_destroy - It invokes both :purge and :purge_all clearing record and also the collection holding that record.

Article creation, updation and destruction happens at different parts of application. In order to stay consistent, attached these purge actions to activerecord callbacks.

Related Tickets & Documents

This PR is related to issue #6417

QA Instructions, Screenshots, Recordings

NOTE - It is not possible to test the functionality in local environment. We need to deploy to live server to verify the changes.

Steps to validate:

• After an article is created/updated/destroyed, next request involving article(s) retrieval will have x-cache: MISS in its response headers.
  • This is because, the stale cache was purged and response was fetched from server.
• Next consecutive requests will now have x-cache: HIT as it is served from cache.
• Not all endpoints will show this behaviour. Those endpoints which set surrogate_key inside response headers will respond to cache miss/hit. Rest all endpoints related to articles will always contain x-cache: MISS.
• Endpoints which set surrogate_key in response headers are...
  • https://dev.to/api/articles
  • https://dev.to/api/articles/:id
  • https://dev.to/api/articles/:slug

Added/updated tests?

• Yes
• No, and this is why: please replace this line with details on why tests
  have not been included
• I need help with writing tests

[Forem core team only] How will this change be communicated?

Will this PR introduce a change that impacts Forem members or creators, the
development process, or any of our internal teams? If so, please note how you
will share this change with the people who need to know about it.

• I've updated the Developer Docs or
  Storybook (for Crayons components)
• This PR changes the Forem platform and our documentation needs to be
  updated. I have filled out the
  Changes Requested
  issue template so Community Success can help update the Admin Docs
  appropriately.
• I've updated the README or added inline documentation
• I've added an entry to
  CHANGELOG.md
• I will share this change in a Changelog
  or in a forem.dev post
• I will share this change internally with the appropriate teams
• I'm not sure how best to communicate this change and need help
• This change does not need to be communicated, and this is why not: please
  replace this line with details on why this change doesn't need to be
  shared

Are there any post deployment tasks we need to perform?

Yup, validating this fix. Making sure data is purged after creation/updation/destruction of an article by monitoring x-cache key of the request(s) made to those endpoints which set and deliver surrogate_key inside response headers.

[github-actions]

Thank you for opening this PR! We appreciate you!

For all pull requests coming from third-party forks we will need to
review the PR before we can process it through our CI pipelines.

A Forem Team member will review this contribution and get back to
you as soon as possible!

[citizen428]

Requested a review from @benhalpern and @atsmith813 as they are generally most familiar with all things caching.

[benhalpern]

The absence of purge_all is on purpose. We just don't want to purge all articles when we save one... We have other specific logic here.

I won't entirely close this because maybe there is a conversation to be had about cache logic — there are definitely improvements to be made in a fairly convoluted system, but I don't think this is what we want.

[manojnaidu619]

@benhalpern there is definitely a scope for discussion on this ticket. But, I cannot able to continue on it at this moment.
It was an amazing learning through out 🙂

[msarit]

@manojnaidu619 @benhalpern @atsmith813 hello folks! 👋🏾
Are y'all still having the caching discussion on this PR?

[citizen428]

Since the original author stated they will no longer be able to work on this so I'll close this PR now and we can have the caching discussion elsewhere if needed.