Add Deno as a Runtime

[KamiQuasi]

Deno is a JavaScript runtime that is gaining popularity in JavaScript development communities.
As a developer at Red Hat, I have used it in containers (2021 Summit Technical Demo) as well as local development for a variety of frontend and backend projects .

It has some great things going for it including:

• Built with Rust
• Secure by default
• Native TypeScript support
• Built-in linting, formatting, benchmarking, native executable compiling, and testing
• NodeJS and npm compatibility
• Browser APIs where applicable

I would love to see Deno offered as an option in the list of runtimes available with func and would be happy to put the work in to make that a reality.

I spoke with Luke briefly about what would be involved with adding a new runtime, and he showed me some of the new things that are coming, like the scaffolding and think that I could definitely handle contributing the Deno portion of that.

I would ask for additional input and discussion on what would be involved with making Deno an additional option for the func runtime list.

[lkingland]

Hello @KamiQuasi ,

Thanks for opening the discussion. This seems like it would be a fantastic addition, and I am really looking forward to the contribution. Please take a look at this functions overview video, which includes a slide going over the high-level steps the system takes when building and deploying a function. This hopefully will help with a starting point when exploring the code.

To answer your question about what would be involved with making Deno a core (embedded) runtime, the parts to look into would be

1. Templates

The repository will need a basic template added in templates/deno/http and templates/deno/cloudevents. Embedded templates implement an "echo" of the request received. The template is a Function which is structured like a library (aka module) rather than an "app".

2. Scaffolding

In a directory named templates/deno/scaffolding is where the code which exposes the "library" template as an "app" (creates the process boundary). This is just glue which imports the template function from a relative local path, imports a Deno Function runtime library, and calls some form of a "start" method. This middleware would eventually reside at github.com/knative-extensions/func-deno.

There are four different core supported scaffolding distinctions at this time, along the dimensions http/cloudevent and static/instanced. For Go, this actually requires four slightly different implementations, but for more dynamic, interpreted languages this may not be necessary.

3. Deno Signature Detector

Within the OCI build process, the scaffolding to write is determined by a "signature detector" as is explained in the video. The signature returned is used to choose which of the four scaffolding implementtions to chose. If Deno is indeed able to detect all four signatures entirely at runtime, then this signature detector can be essentially a no-op, returning a single shared scaffolding implementation.

4. Deno Language Builder

When building the OCI image from the sourece code, after scaffolding is written, a language builder implementation is invoked once for each platform chosen for the resultant image. If there is anything platform-specific to do, this is the place for that. As with the Function signatures, this step may be unnecessary, and can thus be a no-op.

5. Deno Function Runtime (middleware)

The middleware which is imported by the scaffolding and invoked with a reference to the Function "library" is responsible for starting the HTTP listener and routing requests to the handler or the four primary lifecycle event handlers. These method signatures will of course look a bit different depending on the language, but should instantiate the user's Function via a constructor, and invoke the user's Function instance for the major lifecycle events Start, Stop, Alive (the check sent to /health/liveness), and Ready (the check sent to /health/readiness). Also a convenience path for when the Function does not provide a constructure, but instead a simple "static" event handling method. The Go middleware demonstrates this conceptually, though of course using Go's idioms. For example, HTTP services can take several forms, and are exported using a service which invokes methods provided. Though Deno and Go are quite different, that might be illustrative.

With those five key additions, the use-cases shown in the video should also work for Deno!