Hey community!

We're starting this thread to collect feedback and share early exploration results about Microcks' SCRIPT features. Let's start with a problem statement!

SCRIPT dispatcher is a super flexible way of adding smartness to your dispatching logic and simulating complex business behavior. Over the years - and surprisingly to me, I have to admit - we heard about people extending scripting with libs, performing complex computations for more dynamic responses, we also implemented the stateful mocks features on top of it and made recent huge performance improvements. However, we have an issue. The SCRIPT dispatcher is not working on our new native-compiled container images we provided since Microcks 1.9. What at first seems anecdotic, now becomes "a problem" because of the success of these images 😉 and more globally of the microcks-uber distribution (more than 50k fresh downloads just on March 2025 🚀 )

So we've started exploring whether/how it could be enhanced or replaced to still offer this SCRIPT in native images. To keep this message light and open the discussion, I'll just list below the options we've looked at or are currently considering with our first observations. As usual, everything here is opinionated! So please share your opinion and experience so that we can make the best decision and implement it!

Options

1. Is it possible to still use current groovy scripts in native images? After some investigations, this seems not do-able. Groovy's compilation seems to always involve bytecode generation and reflection and this cannot play well in native mode. We found some extensive articles like here but nothing compared to our scenario or dynamic execution within binding to native-compiled Java object.

2. We looked at Web Assembly and especially the WASI as the ability to use the language of your choice is appealing! We've gone through experimentations trying out Chicory (a pure Java implementation) and GraalVM Wasm. Our first observations were that the tooling ecosystem looks mature for Go and Rust guest modules, but other languages (like Javascript/TypeScript) are not on the same level. We don't even get to the point of trying it out in native mode as making a Java-WASM-Javascript was a real pain. As we think that our target audience for SCRIPT dispatchers is not hard-core developers but rather people close to the business constraints and able to write simple scripts, we think script language support is a must-have.

3. By looking at GraalVM Wasm, we discovered GraalJS, which typically allows us to do the same things as we did with Groovy. As we're in the GraalVM ecosystem, we validated that native compilation was possible, and we now have a prototype that allows executing Javascript scripts in Microcks compiled in native mode!

Call for action

1. What's your take on the above observations? We're excited about having direct Javascript support as well as keeping the Groovy one in Microcks. What about you?

2. How are you using SCRIPT today? Have you identified some limitations/caveats in the way we implemented it? What would you like to improve?

3. More generally, do you foresee any other use cases where extending the Microcks behavior with custom scripts could make sense? Please share your story with us!

Looking forward to getting the most feedback possible!