The solution implemented under #695 is a necessary backstop for allowing applications to provide new auth tokens on demand in a reactive fashion, however it's inefficient - in that a failed network operation is required before the application is even aware that it needs a new auth token, in order to then repeat that network operation again. It looks like this in practice, for the case of adding a new trackable:
sequenceDiagram
participant App as Customer App (Publisher)
participant Ably as Ably Realtime Service
participant Backend as Customer Service
Note over App: Receive New Delivery
App ->> Backend: Trackable Details Request
Backend ->> App: Trackable Details Response (id)
Note over App: ADD TRACKABLE with id
Note over App: Attempt 1 of 2
App ->> Ably: Attach Channel Request (for trackable id)
Ably ->> App: Attach Channel Response: Denied
Note over App: Authorize (RTC8)
App ->> Backend: Auth Token Request
Backend ->> App: Auth Token Response (permission for all trackables assigned to this publisher)
App ->> Ably: AUTH message with new AuthDetails
Ably ->> App: CONNECTED message: Authentication Succeeded
Note over App: Attempt 2 of 2
App ->> Ably: Attach Channel Request (for trackable id)
Ably ->> App: Attach Channel Response: Success
This can be avoided by expanding our publisher API to allow the new auth token to be supplied at the same time a trackable is added or removed. This would then allow the flow to be optimised in practice, again for the case of adding a new trackable:
sequenceDiagram
participant App as Customer App (Publisher)
participant Ably as Ably Realtime Service
participant Backend as Customer Service
Note over App: Receive New Delivery
App ->> Backend: Trackable Details Request
Backend ->> App: Trackable Details Response (id and auth token, with permission for all trackables assigned to this publisher)
Note over App: ADD TRACKABLE with id and auth token
Note over App: Authorize (RTC8)
App ->> Ably: AUTH message with new AuthDetails
Ably ->> App: CONNECTED message: Authentication Succeeded
Note over App: Attempt 1 of 1
App ->> Ably: Attach Channel Request (for trackable id)
Ably ->> App: Attach Channel Response: Success
As discussed, perhaps we should also consider the option that you just specify that the time of adding/removing that you want token renewal to be triggered, instead of explicitly providing the token.
The solution implemented under #695 is a necessary backstop for allowing applications to provide new auth tokens on demand in a reactive fashion, however it's inefficient - in that a failed network operation is required before the application is even aware that it needs a new auth token, in order to then repeat that network operation again. It looks like this in practice, for the case of adding a new trackable:
This can be avoided by expanding our publisher API to allow the new auth token to be supplied at the same time a trackable is added or removed. This would then allow the flow to be optimised in practice, again for the case of adding a new trackable:
┆Issue is synchronized with this Jira Task by Unito