You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The use case for this API call seems to revolve around recording that a resource has been accessed by a user. The current implementation of WorkOS::AuditLogs.create_event blocks the execution thread and delays the response until the audit trail has been logged.
It would be nice to have a create_event_async where the SDK could perform the call on a separate thread, or to default that API to async. This would shave off 200-500ms off our backend APIs.
We will try to mitigate this on our end and see if we can manage the threading. Maybe this would be good to mention in the documentation as well in lieu of any SDK changes.
I'm also very curious why this API call performs so poorly. We are seeing an average of 240ms on this with p95 of 450ms.
The use case for this API call seems to revolve around recording that a resource has been accessed by a user. The current implementation of
WorkOS::AuditLogs.create_event
blocks the execution thread and delays the response until the audit trail has been logged.It would be nice to have a
create_event_async
where the SDK could perform the call on a separate thread, or to default that API to async. This would shave off 200-500ms off our backend APIs.We will try to mitigate this on our end and see if we can manage the threading. Maybe this would be good to mention in the documentation as well in lieu of any SDK changes.
I'm also very curious why this API call performs so poorly. We are seeing an average of 240ms on this with p95 of 450ms.
wrapping the actual API call in a
Thread.new
seems to at least take it of the main execution thread so it's not blocking the render:The text was updated successfully, but these errors were encountered: