Refactor to use RequestEvent parameter from Deno native HTTP server

[Jesse Jackson]

In Deno v1.9, a native HTTP server was introduced, along with a new API for the request/response cycle. As time goes on, more developers will be familiar with and expect this pattern, and I think it makes sense for this runtime to eventually support it.

• Release announcement: https://deno.com/blog/v1.9#native-http%2F2-web-server
• Manual page: https://deno.land/manual@v1.11.4/runtime/http_server_apis

Here are the type docs for Deno's net extension (which includes the relevant types that I will summarize below):

• stable: https://doc.deno.land/https/raw.githubusercontent.com%2Fdenoland%2Fdeno%2Fmain%2Fextensions%2Fnet%2Flib.deno_net.d.ts
• unstable: https://doc.deno.land/https/raw.githubusercontent.com%2Fdenoland%2Fdeno%2Fmain%2Fextensions%2Fnet%2Flib.deno_net.unstable.d.ts

Essentially, the new pattern's AsyncIterator yields a RequestEvent instead of a ServerRequest.

So, the current API looks like this:

(req: ServerRequest) => void | Promise<void>

and my proposal looks like this:

(requestEvent: Deno.RequestEvent) => void | Promise<void>

Here is a "hello world" example for comparison:

current:

import type {
  ServerRequest,
  Response as ServerResponse,
} from "https://deno.land/std@0.100.0/http/server.ts";

const response: ServerResponse = {
  body: `Hello, from Deno v${Deno.version.deno}!`,
};

export default (req: ServerRequest) => req.respond(response);

proposed:

#!/usr/bin/env deno run --unstable

/*
 * The shebang is needed in this example because, currently (Deno 1.11.4),
 * the type `Deno.RequestEvent` is unavailable without the `--unstable` flag
 */

const response = new Response(`Hello, from Deno v${Deno.version.deno}!`);

export default (ev: Deno.RequestEvent) => ev.respondWith(response);

The Request and Response objects utilized by Deno.RequestEvent are the WHATWG fetch standard ones (you can check out the type docs and source if you'd like to inspect them for yourself).

These are familiar to web developers and widely-used, so this change should also improve code portability.

---

Considerations:

I haven't reviewed the source for this runtime, so I'm not sure whether or not it makes sense to implement the native HTTP server (Deno.serveHttp) at this point. (Maybe you don't want to implement unstable features — which is reasonable).

If not, the proposed API can still be implemented before Deno.serveHttp is stable — by transforming the current ServerRequest object into a RequestEvent by the runtime. This transformation function would be useful to many other consumers, I imagine.

[Jesse Jackson]

Just an update here: the native HTTP server API is now stable as of Deno v1.13:

https://deno.com/blog/v1.13#stabilize-native-http-server-api

and also a deprecation notice from that post:

If you are currently using std/http we encourage you to upgrade to the native HTTP server. std/http will be available in std for a few more releases, but will be removed soon. A guide for migration will be available in the manual soon. If you are using a recent version of oak, your application will seamlessly switch to using the native HTTP server after upgrading to Deno 1.13.

[Nathan Rajlich]

Hey, thanks for bringing this to my attention, sorry for the delay. Your proposed new API looks like the natural progression to me, so at first glace I'm definitely down to support that.

Will try to get around to it soon unless a PR pops up sooner!