Discussion on: Building a Simple API on Deno with Express

More than happy to - any ones in particular? I'm happy to expand on them 😄

I'd say atm it comes down mostly to time spent on the project, it's quite new and (first commit 9 days ago) and getting the volume of features / API that Express has ported across in a way that allows for early adoption in a short space of time has meant that some things have dropped of the priority. Differences atm fall into 2 buckets:

1. The feature hasn't been implemented. For example I have yet to port the view engine logic and app.params() API over yet. These are more complicated, less used (could be wrong) features that aren't essential for a core framework - both could be implemented as custom middleware. I do however very much intend to deliver these - PRs / contributions also welcome!
2. The feature has been implemented, but has a subtly different API / functionality. This is due to 2 reasons:
   1. Time again, there is nothing stopping the feature / API fully mirroring Express.
   2. Deno has a different API. With this one there are a few places, such as cookies, where the std Deno library ships cookie methods, but they don't support the functionality levels of Express - with these we can either wait till they do, write our own implementation in Opine, or contribute the feature gaps to Deno itself. In other places it becomes a little difficult. A prime example is the req.body property in Express on Node vs Opine on Deno. In Node the IncomingMessage class supports a body parameter that can be overwritten allowing for body-parsers to drop the parsed body in place. With Deno, the body attribute of the ServerRequest class is actually a getter with no set method so natively there is no way to overwrite it. It does make use of a private req._body which we could use, but that would be breaking all sorts of programming rules. With this particular issue I've paused for now but am fairly certain, if it is highly desired, there is a suitable workaround using a Proxy or more specifically a Revokable Proxy which could act as an interface to the user during middleware execution, and then be revoked to allow the private internals of Deno's std http library to do it's thing undisturbed upon sending of the headers + body. This could be flagged similarly to how the res.headersSent boolean is implemented in Express.

Let me know if there was anything else you wanted to know!