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.
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.