Beam uses ts-serialize-closures in order to serialize objects (including
functions with closures) to be sent to remote workers. This requires
serializing the transitive closure of things that may be reached from the
root object, which in particular may encounter objects that cannot be
serialized (such as classes and closures from libraries that were not
compiled with the ts-serialize-closures hook).
This function can be used to register "terminal" objects to prevent
serialization errors. The module in question will be imported and all its
exported members registered. Additional (e.g. private) members to be
registered may be passed as well.
In addition to registering the objects for serialization at pipeline
construction time, the given module will be imported (and their members
registered for deserialization) on the remote workers. If any extra
objects are passed, it should be arranged that importing the indicated
module will cause this registration call to be executed.
Concretely, if I had a module 'myModule' that exported func, I could write
requireForSerialization('myModule');
which would then regester myModule.func for serialization and cause
myModule to be imported on the worker. If myModule had a private member,
say MyClass, that could be exposed externally (e.g. instances of MyClass
were returned) one would write
which would allow instances of MyClass to be serialized and, as myModule
will also be executed on the worker, this registration code would be run
allowing these instances to be deserialized there.
Beam uses ts-serialize-closures in order to serialize objects (including functions with closures) to be sent to remote workers. This requires serializing the transitive closure of things that may be reached from the root object, which in particular may encounter objects that cannot be serialized (such as classes and closures from libraries that were not compiled with the ts-serialize-closures hook).
This function can be used to register "terminal" objects to prevent serialization errors. The module in question will be imported and all its exported members registered. Additional (e.g. private) members to be registered may be passed as well.
In addition to registering the objects for serialization at pipeline construction time, the given module will be imported (and their members registered for deserialization) on the remote workers. If any extra objects are passed, it should be arranged that importing the indicated module will cause this registration call to be executed.
Concretely, if I had a module 'myModule' that exported func, I could write
requireForSerialization('myModule');
which would then regester
myModule.funcfor serialization and cause myModule to be imported on the worker. If myModule had a private member, say MyClass, that could be exposed externally (e.g. instances of MyClass were returned) one would writerequireForSerialization('myModule', {'MyClass': MyClass});
which would allow instances of MyClass to be serialized and, as myModule will also be executed on the worker, this registration code would be run allowing these instances to be deserialized there.