Implement Request Batches with callBatch
#306
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
faultyserver
commented
Sep 29, 2022
Comment on lines
+313
to
+320
| export type RequestBatchRequest<T = keyof OBSRequestTypes> = T extends keyof OBSRequestTypes ? OBSRequestTypes[T] extends never ? { | ||
| requestType: T; | ||
| requestId?: string; | ||
| } : { | ||
| requestType: T; | ||
| requestId?: string; | ||
| requestData: OBSRequestTypes[T]; | ||
| } : never; |
There was a problem hiding this comment.
This feels really dirty, but without it, requests that have never as the requestData value still want a requestData parameter, which is an impossible constraint to satisfy. So this is the compromise.
faultyserver
added a commit
to spyrothon/graphics
that referenced
this pull request
Sep 29, 2022
I published [`@faulty/obs-websocket-js`](https://www.npmjs.com/package/@faulty/obs-websocket-js) with the changes made to implement request batches, and also [opened a PR](obs-websocket-community-projects/obs-websocket-js#306) to get the feature merged into an official release. But with the first step done, we no longer need a vendored copy of the library and can skip a lot of the build time it was taking up as well.
t2t2
reviewed
Sep 30, 2022
t2t2
approved these changes
Sep 30, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related Issue (if applicable):
#292
Description:
This PR implements a
callBatchfunction that allows consumers to use theRequestBatchfunctionality from obs-websocket.RequestBatchwas already part of the generated types (and in the protocol), so this doesn't change anything other than adding the function and the related types.Because of the granularity of obs-websocket-v5's protocol design, getting the entire state of an input often requires multiple requests, and then multiple of those groups of requests for each input that you want to know about (example, just getting some audio-related state for all relevant inputs). In the context of any meaningfully-sized OBS setup, that could mean hundreds of requests in succession every time you want to refetch the state of OBS. Especially when the OBS host and the websocket client are not on the same computer (or are potentially even on different local networks), the latency of sending individual requests also adds up quickly.
Request batches are a really useful feature to avoid all of these issues and instead group requests into much more manageable and relevant bundles. Batches can contain large numbers of requests that obs-websocket will run when possible and then return all of the results together, saving on back and forth round trip times and encoding overhead.
I needed this feature for an event I was running a few months ago under exactly those circumstances and ended up implementing it myself using a vendored copy of obs-websocket-js, so this PR is largely just bringing those changes back here so that I can ditch the vendored copy and come back to using an official release.
Limitations
I tried for a while to get some smart typing for
callBatch, like knowing what specificOBSRequestTypeswould be in each slot of the returned array ofresults. It feels like there's some way to use mapped tuple types, but I couldn't figure it out with the way theOBSRequestTypesandOBSResponseTypesare currently structured as a single interface.So, instead, consumers will currently need to cast each result to the type they are expecting, like: