Response caching

[neel1996]

Initial requests without caching

After caching mock response

[codecov-commenter]

Codecov Report

Patch coverage: 82.81% and project coverage change: -4.26 ⚠️

Comparison is base (a4f39ba) 93.99% compared to head (bfda260) 89.73%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #273      +/-   ##
============================================
- Coverage     93.99%   89.73%   -4.26%     
- Complexity      477      490      +13     
============================================
  Files            96      288     +192     
  Lines          1615     4044    +2429     
  Branches        122      495     +373     
============================================
+ Hits           1518     3629    +2111     
- Misses           56      359     +303     
- Partials         41       56      +15     

Impacted Files	Coverage Δ
...om/arbindo/mimock/common/constants/CacheNames.java	0.00% <0.00%> (ø)
...ava/com/arbindo/mimock/entities/RequestHeader.java	100.00% <ø> (ø)
...indo/mimock/generic/GenericMockRequestService.java	98.55% <ø> (ø)
...manage/mimocks/service/MockActionsServiceImpl.java	86.20% <ø> (ø)
...rc/main/java/com/arbindo/mimock/entities/Mock.java	50.00% <44.44%> (-16.67%)	⬇️
...ck/manage/mimocks/service/helpers/CacheHelper.java	81.48% <81.48%> (ø)
...ain/java/com/arbindo/mimock/MimockApplication.java	92.85% <100.00%> (ø)
...com/arbindo/mimock/caching/CacheConfiguration.java	100.00% <100.00%> (ø)
...com/arbindo/mimock/caching/CustomKeyGenerator.java	100.00% <100.00%> (ø)
...age/mimocks/service/MockManagementServiceImpl.java	94.18% <100.00%> (+0.03%)	⬆️

... and 188 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[cypress]

Passing run #54 ↗︎

0

17

0

0

0

Details:

Merge bfda260 into 0f727b8...
Project: mimock	Commit: 085c61c128 ℹ️
Status: Passed	Duration: 02:32 💡
Started: Jun 16, 2023 7:59 AM	Ended: Jun 16, 2023 8:02 AM

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[neel1996]

Caching & Eviction considerations

Caching

• The mock response for existing mocks will be cached whenever a mock endpoint is invoked by a client. A unique hash will be generated using the following parameters to be used as the cache key

Route + Http method + Query param string + Request headers + Request body

• When a new mock gets created, the same unique parameters mentioned above will be used to generate an unique hash for the key

Eviction

• The cache will be evicted based on sliding expiry policy. The cache that has not been accessed for the past 60 minutes will be evicted
• ** The entire cache will be evicted when a mock is updated or archived. The thought process behind this decision is that when the user updates an existing mock, then evicting the unique mock will not be possible if a client has already triggered the caching with a different set of request headers. This will lead to inconsistencies if we try to evict a cache based on the unique key generated from the mock fetched from the Database

E.g:

Let's assume "client-x" invokes a "mock_a" with the following request headers 

- Authorization
- Content-type
- Host

These headers will decide the cache key. However, it is not necessary for the mock stored in the DB to have the same set of headers if strict header matching is not enabled for the mock.

In this case, if the user updates "mock_a", then the eviction will not remove the mock data from the cache as the hashed key will be different. Hence, all the existing cache needs to be evicted to ensure consistency