Introducing short-lived cache #62
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
Put yourself in the service controller's POV:
Versioning
No breaking changes, so this belongs to
v0.6.x
Description
This PR introduces a 5 minutes, light-weight, in-memory cache that saves some calls to the service registry by caching repetitive tasks. The very nature of the problem is hierarchical and repetitive: at each step, the object's parent's existence must be verified as well as its status, and this action "bubbles up" the deeper we go in the hierarchy -- e.g. if we are updating an endpoint we need to check that the service exists, but before that we need to do the same for the namespace.
Caching should save potentially many calls to the service registry, especially in those cases where a namespace has just been enabled and a lot of services must be registered, e.g. when registering 6 services only 1 call to the sr is needed to check for the namespace existence, making the whole process smoother and faster.
Data on cache is retained for only 5 minutes, after which a MISS occurs.