DEV Community

Building a Simple API on Deno with Express

Craig Morten on May 28, 2020

Deno is a new secure runtime for JavaScript and TypeScript created by Ryan Dahl, the original founder of Node.js. Unlike Node, Deno does not use N...
Read full post
Collapse
 
davidquartz profile image
David Quartey • • Edited

Great article. Unfortunately, this does not work any more. We should use the latest version of opine and include, json and Router in the export from './deps.ts'.

Also, opine is now in maintenance mode: Deno has introduced Node and NPM compat, considering using Express itself in Deno! -copied from deno.land/x/opine@2.3.3

Collapse
 
garronej profile image
Garrone Joseph •

Great article!

And thanks for the mention 👍

Collapse
 
dividedbynil profile image
Kane Ong • • Edited

Nice project! Do you mind to share the reason behind the inconsistencies between Express.js and Opine (other than the nature of Deno and Node.js)?

Collapse
 
craigmorten profile image
Craig Morten • • Edited

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!

Collapse
 
dividedbynil profile image
Kane Ong •

Thanks for the very detailed explanation! That's a wise decision to make the naming inconsistent from the abovementioned points.