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

Introduce celery (opt-in?) for certain workflows #5

Open
sergei-maertens opened this issue Dec 20, 2022 · 0 comments
Open

Introduce celery (opt-in?) for certain workflows #5

sergei-maertens opened this issue Dec 20, 2022 · 0 comments
Labels
Refactor Refactor/rework to future proof again
Milestone

Comments

@sergei-maertens
Copy link
Member

sergei-maertens commented Dec 20, 2022

For example: ETag updates

On create/update of resources we schedule etag (re-)calculations that are currently done in the request-response cycle. Since the caching decorator only emits this header for detail resources (retrieve action), this does not have to commit in that cycle - meaning we can delegate that to celery.

This can seriously boost performance, especially if the involved resource is input for many other resources that may need to be recalculated (e.g. zaak-status).

Alternatively, we should investigate a mechanism to better avoid queries that don't matter anyway and/or better de-duplicate etag updates.

Possibly it must be possible per operation/endpoint/viewset to specify whether the update should be sync or async.

@sergei-maertens sergei-maertens added the Refactor Refactor/rework to future proof again label Dec 20, 2022
@sergei-maertens sergei-maertens added this to the 2.0 milestone Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Refactor Refactor/rework to future proof again
Projects
None yet
Development

No branches or pull requests

1 participant