Prototype: Run debuggable blueprints as separate process SOFIE-1548

[Julusian]

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 the StudioBlueprintManifest 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:

import { runForBlueprints } from '@sofie-automation/blueprints-proxy/dist/host'

// @ts-expect-error Unknown property
global.VERSION = 'test'
// @ts-expect-error Unknown property
global.VERSION_TSR = 'test'
// @ts-expect-error Unknown property
global.VERSION_INTEGRATION = 'test'
// @ts-expect-error Unknown property
global.TRANSLATION_BUNDLES = '[]'

import studioManifest from './main/studio/index'
import showStyleManifest from './main/showStyle/index'

runForBlueprints(studioManifest, showStyleManifest)

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 future

Limitations:

• It is not handling that some methods can be optional
• Breakpoints can cause timeouts
• Calling an unknown blueprint method can cause the connection to hang
• Hardcoded address of the socket.io server, and the proxy is forced to enabled
• The static properties of the blueprint (blueprintVersion, studioConfigSchema etc are not being considered)
• A large payload may cause the connection to die due to packet size limits.

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

• [ ] Code documentation for the relevant parts in the code have been added/updated by the PR author
• [ ] The functionality has been tested by the PR author
• [ ] The functionality has been tested by NRK