How does FFI works ?

[deslunes]

Hello ! First of all, I'm not asking for help in writing code, but rather to ask what's possible to do with Deno.

I'm interested in a Rust project called PumpkinMC, which is a reimplementation of the minecraft server protocol in Rust, and they have a plugin API (in early stages) and they are opened ideas and interested in exposing their PluginAPI to other languages, but they still didn't decided how to do it and if they'll do it, as far as I saw. I don't want to speak in their name as I'm not a contributor, just really enthusiast in their work.

I thought about Deno because I saw that Deno had a FFI support so I was wondering if Deno could be a good option in order to make a plugin in Javascript. I saw this repo but it seems to be inactive. I don't expect Deno to be an out of the box solution to execute and access Rust code from javascript, but I wonder if it would be a good idea.

[mgkvibez]

Great use case to think through, and the answer is: yes, this is precisely what Deno's embeddable core is for — but the important thing to understand is that FFI and embedding are two opposite directions, and the right one depends on who calls whom.

Direction 1 — Deno calls Rust: FFI. Deno.dlopen() lets a Deno script load a .so/.dylib/.dll with a C ABI and call exported symbols. This fits if Pumpkin's plugin API ever ships as a native C-ABI library: your JS plugin would dlopen it and call functions directly. Fast, but the plugin (JS) is the caller — you need a stable C interface already exposed by the host, and Rust↔JS boundary crossings are explicit and typed.

const lib = Deno.dlopen("./libpumpkin_plugin.so", {
  send_packet: { parameters: ["pointer", "u32"], result: "i32" },
});

Direction 2 — Rust calls JS: embedding deno_core. This is the one that matches "expose Pumpkin's plugin API to other languages": you embed a JS runtime into Pumpkin. The deno_core crate gives you a JsRuntime you can drive from Rust, and you expose your plugin API as ops — native functions registered with the runtime that JS can call:

#[op2]
#[string]
fn op_send_packet(#[string] player: String, #[serde] payload: serde_json::Value) -> Result<(), AnyError> {
    // call into Pumpkin internals here
}

deno_core::extension!(pumpkin_api,
    ops = [op_send_packet, /* ... */],
);

// build the runtime:
let mut runtime = JsRuntime::new(RuntimeOptions {
    extensions: vec![pumpkin_api::init_ops()],
    ..Default::default()
});
runtime.execute_script("plugin.js", plugin_code)?;

Plugins are then plain .ts/.js files calling Deno.core.ops.op_send_packet(...) (or a nicer JS wrapper you layer on top). This is exactly how deno itself is structured — every deno/ext/* module is an extension built on op2/deno_core, which makes the deno/ext/ tree the best reference documentation that exists for this pattern.

Practical notes for a plugin system specifically: one JsRuntime per plugin (isolation), load each plugin's JS from a snapshot or a byte-for-byte controlled source (you don't want plugins relying on ambient FS access), and keep the op surface small and serializable — #[serde] on payloads keeps your boundary version-tolerant as Pumpkin's own API evolves. Also worth telling the Pumpkin folks: exposing a plugin API surface (a stable set of ops) is a much smaller commitment than adopting Deno wholesale — the embedder path means the host stays a pure Rust program that happens to speak JS.