feat: web sdk example with topic client that refreshes disposable tokens #1437
Conversation
| // In your own setup, the token vending machine would likely be a separate service. | ||
| // See https://github.com/momentohq/client-sdk-javascript/tree/main/examples/nodejs/token-vending-machine | ||
| async function tokenVendingMachine(): Promise<{token: string; expiresAt: ExpiresAt}> { | ||
| const authClient = new AuthClient({}); |
There was a problem hiding this comment.
probably I'm not understanding the whole picture here but don't we need a super user api key to call the getDisposableToken?
There was a problem hiding this comment.
Yes, that's used only in the localTokenVendingMachine example for anyone who wants to run the example completely locally (in case they don't have a deployed TVM). Then they can just run this example like any other one, export MOMENTO_API_KEY=<api key> npm run tokens.
If they want to run the example against their own deployed TVM, then they can pass in an endpoint instead and switch to using the tokenVendingMachine function in the example code. Running the example that way would look like: TVM_ENDPOINT=<their TVM url> npm run tokens
There was a problem hiding this comment.
@anitarua
So localTokenVendingMachine is something they will integrate into their backend so that api can be called from each iPad?
But where is localTokenVendingMachine using MOMENTO_API_KEY?
There was a problem hiding this comment.
Yes, their backend would call generateDisposableToken and return that token to the iPads (or other end user devices).
MOMENTO_API_KEY is used to create an AuthClient. This auth client in the example is using default configuration settings: CredentialProvider that expects a MOMENTO_API_KEY environment variable and default AuthClientConfiguration. These default settings are now optional, which is why the new AuthClient({}) constructor call doesn't contain anything.
Their backend component that creates the AuthClient and calls generateDisposableToken could be a Lambda function, like the TVM example is, or it can be something they write into their own server.
| return disposableToken; | ||
| } | ||
|
|
||
| async function tokenVendingMachine(): Promise<{token: string; expiresAt: ExpiresAt}> { |
There was a problem hiding this comment.
@poppoerika I'm late reviewing this PR but this is the function that they would implement on their ipads. It will just call fetch with whatever URL, headers, query params are necessary to get a token from their server-side token vending endpoint.
Their server-side token-vending endpoint will be the thing that uses AuthClient to actually get the tokens.
| // for each active subscription, unsubscribe from the old topic client and subscribe to the new one | ||
| for (const key in this.activeSubscriptions) { | ||
| const value = this.activeSubscriptions[key]; | ||
| const newSubscription = await newTopicClient.subscribe(value.cacheName, value.topicName, { |
There was a problem hiding this comment.
@anitarua I think maybe you need to call your local subscribe function here so that you get the wrapped version, don't you?
Closes https://github.com/momentohq/dev-eco-issue-tracker/issues/1013
Implements a wrapper class
TokenRefreshingTopicClientthat automatically refreshes disposable tokens and active topics subscriptions before tokens expire.A standalone example exists in a single file under
examples/web/cache/refresh-disposable-tokens.tsand can be run completely locally by using alocalTokenVendingMachine()method, or can be run against a deployed TVM by passing the endpoint to the example code.Sample output:
The existing Vite chat app was also updated to use the TokenRefreshingTopicClient. Also fixed some bugs with the TVM and web app setup while testing and updated the CSS to be more Momento-themed.