This blog post contains information about using JavaScript libraries with the Orchex Enterprise Orchestration Engine, and perspective on differences between orchestration and applications.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
Introduction
Orchex, which is written in Rust, uses virtual machines to execute JavaScript. Generally, each orchestration process requires passing numerous statements for the virtual machine to execute.
We implemented infrastructure for loading libraries into the virtual machines, whether using inline JavaScript or loading the libraries from URLs.
Processor vs. Block Libraries
We had implemented library support at the processor level, assuming that the functions would be available to all subsequent JavaScript executions. At the time of this writing, we are using quick_js virtual machines. We discovered a limitation. Unlike variables, which persist between execution calls, we must define functions in the execution calls that use those functions.
So, we added library support at the LogicBlock level, meaning that one can now specify libraries at the processor level and at the LogicBlock level, where one use of LogicBlocks is to represent stages within a processor.
- https://deliverystack.net/2025/02/03/orchex-logicblocks/
- https://deliverystack.net/2025/02/04/orchex-orchestration-processor-stages/
Assuming that libraries define functions, any libraries specified at the processor level get passed to each execution block, even if they are not relevant to that block. Since some libraries may just define variables rather than functions, we may add a flag to cause certain libraries to execute only once.
Any libraries specified at the block level get passed only when executing that block.
Orchestration vs. Applications
This brings up an important point, which is that an orchestration engine is not an application. The intention is to facilitate the use of webservice APIs in other applications, not to implement application logic in the EOE. That doesn’t mean it isn’t possible to implement custom services in the EOE, but philosophically, the EOE may not be the right place to implement complex logic with significant JavaScript library requirements. Such logic belongs in a dedicated services that the EOE can invoke.
It’s worth noting that JavaScript virtual machines are not complete node.js processing environments. We can’t load arbitrary npm packages into them, and some code that works in standard JavaScript libraries won’t work in virtual machines.
The intention of library support in Orchex is not to allow usage of arbitrary JavaScript libraries, but to encapsulate logic specific to the EOE.
deliverystack.net 