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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: cache notification template by trigger identifier #3074

Merged

Conversation

djabarovgeorge
Copy link
Contributor

@djabarovgeorge djabarovgeorge commented Mar 23, 2023

What change does this PR introduce?

Created this approach in order to make sure we store in cache queries by fetching by triggerIdentifier.

So how it will work:
In order to make sure that we can store the notification-template both by id and triggerIdentifier, I reused the CachedQuery logic, meaning that all the queries will be stored as queries (the fetch will be cache get O(1))

Key structure:
template: {type}:{keyEntity}:{environmentIdPrefix}={environmentId}:{QUERY_PREFIX}={JSON.stringify(query)}
example: query:notification-template:e=12345678:QUERY_PREFIX={json: example}

But now the invalidation will be the same as on CachedQuery, meaning we will store all the notification-templates that are in the same environment( + the duplication one by id and one by triggerIdentifier), and on invalidate we will delete all of the available notification-templates stored in the cache in the same environment.( cache get hset O(1), create pipeline and loop all the key in order to delete them, pipeline execute) that way we will make sure that all the stale cache is deleted.

I chose this solution because it will produce the most accurate data for our users, the other solution is to remove this suggestion and adjust the TTL in order to handle the stale cache but then we won't ensure that the data is updated in the cache storage.

TYI: I created this branch PR so the solution will be isolated, but please note that the new logic is still the WIP, I will create a new branch from this one with the refactoring.

Why was this change needed?

In order to store the notification-templates findByTriggerIdentifier queries on the trigger flow.

Other information (Screenshots)

Comment on lines 194 to 202
/*
* const notificationTemplate = ({ _id, _environmentId }: { _id: string; _environmentId: string }): string =>
* buildCommonKey({
* type: CacheKeyTypeEnum.ENTITY,
* keyEntity: CacheKeyPrefixEnum.NOTIFICATION_TEMPLATE,
* environmentId: _environmentId,
* identifier: _id,
* });
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗑️

identifiers,
}: {
_environmentId: string;
identifiers: ({ id: string } & { triggerIdentifier?: string }) | ({ id?: string } & { triggerIdentifier: string });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been trying to find a way to be able to express mutually exclusive optional properties but I haven't been able to found it. Not sure if something along these lines would be possible but changed to make the other property optional.
microsoft/TypeScript#14094 (comment)

@djabarovgeorge djabarovgeorge merged commit ae2747c into poc-chached-entity Mar 30, 2023
@djabarovgeorge djabarovgeorge deleted the cache-notification-template-by-trigger branch March 30, 2023 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants