You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Writing a JS plugin should be as easy as exporting an async function that receives a request and returns a response.
This issue tracks the required bits to make writing JS plugins easy like any helper libraries or code in the host that loads the scripts and runs the right function. For JavaScript support in the server see #12
The text was updated successfully, but these errors were encountered:
What exactly differentiates the work required for this issue from #12? It seems that in order for this to be sensible, the deno runtime must be integrated simultaneously. I'd like to attempt this once I get a better idea of what the desired architecture is here.
I think I'll probably close this issue once #10 is merged. This issue is about the API of how a JS plugin writer should expose his/her handler. I ended up tackling this as well in the PR by loading the JS or WASM plugin with the import('/some/module.js') and expecting the file to be a module that(at least for now) exports an async handler function that receives a JS Request and returns a JS Response, when written in Rust compiled to WASM the proc_macro converts the JS Request and Response to the http_types equivalents. #12 is the real deal, it's the one to bring the JS runtime to the server side with Deno.
Writing a JS plugin should be as easy as exporting an async function that receives a request and returns a response.
This issue tracks the required bits to make writing JS plugins easy like any helper libraries or code in the host that loads the scripts and runs the right function. For JavaScript support in the server see #12
The text was updated successfully, but these errors were encountered: