Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃捇 [API] Enable response caching for mocks #272

Open
1 of 2 tasks
neel1996 opened this issue Feb 14, 2023 · 1 comment
Open
1 of 2 tasks

馃捇 [API] Enable response caching for mocks #272

neel1996 opened this issue Feb 14, 2023 · 1 comment
Assignees
Labels
area/api Mimock APIs
Milestone

Comments

@neel1996
Copy link
Member

neel1996 commented Feb 14, 2023

Summary

Explore springboot caching to enable it for mock responses. Use the hash generated from the request body + headers as the key for the cache

Scope of the issue

To improve mock response performance

Impacted area

  • UI
  • Backend

Supporting artifacts

No response

@neel1996 neel1996 added the area/api Mimock APIs label Feb 14, 2023
@neel1996 neel1996 self-assigned this Feb 25, 2023
@neel1996 neel1996 changed the title 馃捇 [API] Enable response caching for mock 馃捇 [API] Enable response caching for mocks Feb 25, 2023
@neel1996 neel1996 added this to the v0.0.3 milestone Jun 3, 2023
@neel1996
Copy link
Member Author

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 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Mimock APIs
Projects
None yet
Development

No branches or pull requests

1 participant