The examples in the article seem awfully contrived. Can someone please explain what a real-world use case for something like this would be? Why not just do it all in Go?
Or is the point of it to be able to use existing JS scripts within a Go application?
I just found this excellent comment in an relevant Reddit post[1], which clarifies things quite nicely for me.
---
Let’s set up the scenario. You have a program that a user can manage via a config file. That tune knobs and dials, and everything works. They then ask you one day, “I’d like to add some custom logic for they have.”
Do you add another option to the configuration file to support their one use case? Or provide a mechanism for them actually to write some code?
If it’s the latter, do you want them to have to recompile your program to be able to run that custom code? Or do you have a runtime in your application for that custom code?
The latter is what a browser does. You can write JavaScript for a website without recompiling the browser just for the website. The user doesn’t have to worry about your event loops, SDKs, APIs, wiring code in rust/C, etc. This feature allows others to add custom logic to your application's runtime.
This is the purpose of embedding JavaScript into an application. It’s not the whole program, but it allows someone to provide code in your program event loop to do something custom. Not every program needs this. Sometimes, a config file of YAML or command line arguments works, too.
Not doing it all, Go allows my API endpoint to accept sandboxed javascript code to enable users to run more complex queries against my data. It is also faster because they don't have to make individual API calls for each data set. Therefore, more data is required to be sent over the wire to them.
I've been using goja in a logical replication tool to make it field-programmable by the end users. No two deployments look alike, so a great deal of flexibility is needed for ETL uses. There's a tendency for configuration languages to become Turing-complete, so we started with a Turing-complete language for configuration.
JS, or in Replicator's case, TypeScript (shout-out to esbuild), is sufficiently well-known that any dev group will have some experience with it. On the whole, I've been very impressed with how straightforward it's been to have user-scripts integrated into the processing pipeline.
Ah, that makes a lot of sense - far easier to expose a JS api for user-extension than Golang (which is probably not even all that possible, except for via wasm, which would still be challenging)
And, I suppose my initial hunch is probably correct - for the dev/application to be able to use existing JS libraries (be it part of your broader application/system or external) within a Go app.
Check out my other comment [1] in this post for a newer, better version/fork of Goja - from the grafana/k6 team.
On top of the previous comments describing how to use JS as an embedded scripting language, I've seen in production (series B startup) an architecture where:
a) non-technical users describe, in plain English, what they would like from the data;
b) an LLM with lots and lots of prompt-engineering massaging translates the English into JS,
c) the JS gets executed in a sandbox,
d) the results get returned to the user
For a real-worl use case, look towards the 'script' processor in Elastic' Beats family of data shippers [1] (example is from Metricbeat but it exists in other Beats too)
They can be configured to mutate the data with some basic DSL syntax, but if you have more advanced needs, you can break out to JavaScript and transform the JSON any way you want.
This is very useful because now any transformation becomes possible. And because this is the user of your product who writes that JavaScript more as configuration than code.
And since there's no build step, it is just part if the configuration loaded at startup.
I am using otto[0] (similar to goja) in the headless cms I maintain [1] in "actions" api [2]. So one can customize actions according to needs by writing JS. The JS is executed inside a transaction. Sort of a mini-lambda kind of api
I didn't use Goja (this was maybe a decade ago) but I used Otto, which is the same concept.
I used it for game scripting. Lots of stuff is just easier to write in a high level language. I was able to use inheritance to compose behaviors for entities, and I could restart entities with new code without having to restart the server.
Or is the point of it to be able to use existing JS scripts within a Go application?