Prototype: Run debuggable blueprints as separate process SOFIE-1548 #985
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.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feature prototype
What is the new behavior (if this is a feature change)?
This allows for running the blueprints as their own process, to allow for easier debugging, avoiding the need to attach a debugger to the whole of Sofie and stepping through a lot of core code.
This is very incomplete, with a lot of TODOs and bits which havent been implemented, most notably this is only done for the studio blueprint and not showstyle or system.
The approach I have taken is to add this
ProxiedStudioBlueprint
class to Sofie, which implements theStudioBlueprintManifest
exported by blueprints. Inside of this class, it sets up a socket.io client, which is utilised to call methods on the remote blueprints service.Inside of the blueprints this can be utilised with a simple script:
For this to work, any importing of png or svg files has to be disabled, and some other changes may need to be made to get it to run happily outside of webpack. It was not investigated on how to improve this to avoid needing to make many hacks.
Inside of
runForBlueprints
it is setting up the socket.io server, and is reconstructing the contexts as proxied versions and calling into the proper blueprint methods.Being sent over socket.io when calling a method is any required data to construct the appropriate
Context
class, and any other parameters being provided to the method. Various methods on the Context classes are now returning Promises. This does require changes to the blueprint interfaces and usages, but this is a necessary cost of this change. These async methods make a call back to Sofie over the socket.io, to perform their operation. This may not be required for every method, but it was done to many for consisntency, and to avoid adding any real logic to the proxy or needing to change it in the futureLimitations:
Other information:
Socket.io was chosen as a quick and easy way to prototype with hacked together but bidirectional RPC abilities. A final implementation should review if this is the right tool to use. Plain HTTP was considered, but as that would require calls being performed in both directions, would add complexity and more fragility to the setup.
Status