Sharing Engines and Modules

[timia2109]

Hi everyone,

I'm currently building an extensible application using Jint. The main purpose for the app is to create (dashboard)-images for thin-client displays (ESP32). A current (working) draft is available here.

Therefore I write JavaScript files to define the content of the image and doing the heavy creation logic in C#. Im offering states of an external system (Home Assistant) to JavaScript to react to different conditions etc.

I've decided that scripts should work the following way:

/* 
This function "registers" the external state to my application and let my application know to keep this in-sync.
On an engine recreation, I build deltas of registered states to register new ones, keep existing ones and drop old ones.
*/
const indoorTemperature = registerHassState(
    "sensor.smart_hygrometer_0998_temperature"
);

export function render() {
    return Flexbox({
        children: [
           Text({
               content: `Temp is: ${indoorTemperature.getFloat()}`
           })
        ],
    });
}

This approach allows me to keep the modules loaded in-memory and reduce the overhead of holding all external states, but it comes with a few down sides:

• I need to load every available module at app start or on engine recreation
• When a script changes, I need to dispose the complete engine and recreate it
• It's an ASP.NET Core server, so I need to lock the engine for the current thread

Another problem which comes in my mind is, that I want to add cron jobs to fetch (web)-data or interacting with other systems. This is another source of locking the engine somewhere else.

Do you have better solutions or other ideas for this problem, while keeping the ability to change scripts at runtime?

Thank you!

[lahma]

For me your description is still a bit abstract (I didn't dig into example code). But some thoughts:

• is there a performance problem that you are seeing?
• can you create an Engine per request if state if the thing that you inject?
• Engine.PrepareScript gives you reusable script instance from string which is a bit cheaper and won't need any parsing

Sharing an engine is generally a bad idea in my opinion, so it should be avoided. I didn't quite grasp why you would need to share one. Just because you think it might be slow or has the engine instance actual state state has to be shared between multiple consumers?

[timia2109]

Thanks for your input. I was unsure what is the best option (recycling engine vs. share one). I guess I will change my behavior to use always an own engine for each request.

But if I keep on the approach to subscribe to script changes, I could also use the prepared versions.