Show HN: Modus, serverless framework for intelligent APIs powered by WebAssembly (github.com)
We built Modus to put code back at the heart of development.
You write a function.
export function sayHello(name: string): string {
return `Hello, ${name}!`;
}
Then, Modus:- extracts the metadata of your functions
- compiles your code with optimizations based on the host environment
- caches the compiled module in memory for fast retrieval
- prepares an invocation plan for each function
- extracts connections, models, and other configuration details from the app’s manifest
- generates an API schema and activates the endpoint
You query the endpoint.
query SayHello {
sayHello(name: "world")
}
In a few milliseconds, Modus:- loads your compiled code into a sandboxed execution environment with a dedicated memory space
- runs your code, aided by host functions that power the Modus APIs
- securely queries data and AI models as needed, without exposing credentials to your code
- responds via the API result and releases the execution environment
Now you have a production ready scalable endpoint for your AI-enabled app. AI-ready when you’re ready. Launch and iterate.
Read more in the announcement blog post: https://hypermode.com/blog/introducing-modus-code-first-inte...
Come join our Discord, we’d love to hear your feedback: https://discord.hypermode.com
Follow us on GitHub: https://github.com/hypermodeinc/modus
Modus docs: https://docs.hypermode.com/modus
Modus quickstart video: https://youtu.be/3CcJTXTmz88
3 comments
[ 4.6 ms ] story [ 18.6 ms ] thread- Language support: At the moment we're supporting Go and AssemblyScript. We plan to add more languages in the future. Python is definitely on our wish list. I'm also looking into ways to support advancements in the WASM/WASI space to be more language-neutral in the future (but for now, it's just these languages).
- Performance: We leverage Wazero for its AOT compilation capabilities to take a WASM binary and convert it to a native x86 or arm64 in-memory instruction set. We do this when _loading_ the module, so it's cached and prepared ahead of time - before the function executes. We also do a lot of leg work on building an invocation plan (similar to how a database builds an execution plan) that instructs the Modus runtime in how to marshal data in and out of the WASM memory space on each request, in a manner that is compatible with the guest language's default import and and export calling conventions. Thus when the function runs, the hot path is very fast.
- Sandboxing: Each function call executes in its own dedicated memory space, with its own instance of the compiled wasm module. You could completely crash one instance without ever affecting the another. You can't accidentally leak memory, or access memory of the host process or another function execution, because each function run is starting fresh. On top of that, the only system resources are those explicitly exposed to the function instance. So there's zero risk of (for example) accessing a system credential or spawning some other process.
Hope you'll give it a try! :)