Scripting Bee

[mkrauser]

I would love to see a Scripting-Bee where you can invoke Scripts (PHP, JS, Go, Perl, ...).

I thought about this a lot, and in my opinion it is too much effort to include the scripting languages within beehive. Instead the respective interpreters/compilers should be installed on the host system.

The Event-Data can be provided as command-line parameters or via StdIn.

What would you think of this:

• The scripting-Bee provides an action for each implemented scripting language, the interpreter should can be configurable.
• A small script can be entered and edited in the beehive admin (with ace or a similar syntax-highlighting editor) and is then saved on the filesystem.
• If an action gets invoked, a json-document with the event data is passed to some wrapper-script. This wrapper parses the json-document, creates and object from it and calls the script configured in the bee. Ideally the entered script contains a function and receives the event-object created by the wrapper as parameter.
• The output can then trigger other events again.

Additional 3rd party libraries for the respective language should be usable.

Do you see any red flags or have more ideas or other input for such a bee?

Thanks for the good work!

[prologic]

Why not just do what Consul Template does and just allow arbitrary binary/scripts/whatever to be used as Bees. Define the interface as a set of required Stdin/Stdout and. Why should this have anything specific to do with any interpreted scripting language intepreter?

[muesli]

You can already use the ExecBee to communicate via stdin/out and run arbitrary binaries, but that's obviously just an action you can execute. You couldn't trigger any defined events, and you can't keep a script running for continuous communication.

Some more food for thought:

The same concept could be used for arbitrary scripts that communicate via a (well-defined) JSON protocol over stdin/out. At that point we're getting dangerously close to a full-blown RPC interface, which we could use to turn all hives into external processes that just communicate with the core, and are language agnostic by design.

The more hives we are integrating and offering, the more valuable such an approach would become. It makes it easier to keep the core slim and - ideally - lets the user only build & run those hives they actually want to use. It would also mean you can build & update a Hive on-the-fly, without re-building & re-starting all of Beehive.

[mkrauser]

You are right, all this can already be done with the ExecBee. But there would be some boilerplate-code which is required everytime (read from StdIn and convert the json-string).

What I'm proposing is a Bee where the customer can enter some Code and this is executed when the action is triggered. The boilerplate-code should be pre-pended to this script automatically to provide the input already parsed and converted. Kind of like the Handler-Argument in AWS-Lambda.

My Idea did initially not include long running scripts for continuous communication or triggering other Events, although this sounds interesting.

RPC also has lots of benefits, but this goes way outside of my idea.

[mkrauser]

btw: Zapier offers something similar: Code on Zapier

[prologic]

Looks like it supports execution of Javascript as triggers. If we went down that route we could use otto.

[CalmBit]

That might not be a terrible idea. For all that I don't like about javascript, it's a great scripting language.

[muesli]

@mkrauser Ok, understood. A defined protocol for scripts to receive & return values via a JSON interface is certainly a good idea. This will stand or fall by the quality of the provided documentation, though, so please try to keep that in mind!

[prologic]

Recommend the use of Protobuf here to:

• Ensure backwards/forward compatibility of the format
• Be type safe
• Mostly self-documenting

Even if we marshal it as JSON -- that's fine.

[mkrauser]

@prologic That sound really nice, I will have a look at it. Thank you!