Disclaimer

To start with, the framework I am currently using OAK/Snowlight is to write a RESTful API which is currently stable Deno version 1.0.0

There are several speculations and hypothesis amongst Developers as follows saying,

Is Deno going to replace Node?

Is Deno better than Node?

Is all the amount of efforts, time and energy put on learning Node completely pointless?

As Ryan Dahl claimed in JSConf in his talk 10 Things I Regret About Node.js

“ Node could have been much nicer ”

When Ryan started out Node; he missed out on very essential aspects which he recalled in his speech delivered in 10 Things I Regret About Node.js

To summarize those design flaws in the Node.js that Ryan had mentioned are as follows;

1. Security: Node has no security. Since you use NPM packages and you don’t completely know what’s in that code; maybe these codes may have unfound loopholes or severe vulnerabilities making network attacks or hacks easier. Easy access to the computer was very much open.
2. Deno overcame this security concern by putting the Deno environment in a sandbox, by default, where each operation beyond the execution context was permitted explicitly by the user.
3. Importing URLs: One major change was requiring modules from the folder node_modules where Node.js used syntax omitting the extensions in files, caused issues with the browser standards. To resolve this issue, they had bundle up the Module Resolution Algorithm to find the requested module in Node.
4. To overcome this, Deno came up with the use of import instead of the require. You did not have the packages locally; instead, you could fill it in with URL from which you need the module from. This throws the light on another aspect; explained in the next point.
5. The unnecessary need of node_modules: With Node, NPM packages had too many codebases whose vulnerabilities were not surely known. Apart from that, every time you need to use a module from node_modules; you had require it; which would have to again run Module Resolution Algorithm which itself is quite complex.
6. In Deno, there was no need for the node_modules folder. Modules are imported using URLs; which are cached and used for the project you are executing available globally. This might make you wonder; does it always need an internet connection to run?
7. Well, no. When packages are initially imported; they are downloaded and cached, just like how it works with NPM. They are cached in a folder called .deno_plugins in the first run.
8. package.json: With the above two major drawbacks; maintaining package.json was an unnecessary abstraction. Semantic Versioning was one of the main purposes that package.json served.
9. On the contrary, Deno does not support the use of a package manager like npm. Hence, the need for Semantic Versioning is eliminated, eliminating the need for package.json like the manifest.
10. Handling Asynchronous Operations: In Node, the initial evolution of handling asynchronous operations was, using Callbacks Pattern. As time passed, it evolved using the Promise API in the early versions of v8; which were included in late 2009 and removed in early 2010. There was an outbreak since by then, there were several packages/libraries which used Callback patterns for async operations. Node was designed much before Javascript had Callbacks / Promises API.
11. In Deno, the most fundamental or let us say lowest level binding Promises API is “ops” binding to handle Asynchronous Operations.
12. Out of the box, TypeScript Compiler Built in: Node supports JavaScript scripts, with .js files. If we had to write TypeScript in Node Environment; we had to set up the TypeScript Configuration for the project along with the TypeScript package.
13. This pain of set up is over with Deno, which gives right away without the initial configuration of the application. The use is confined to default configurations of the Deno’s TypeScript Compiler. Anyhow, if your want to override the default configuration, you can add the ‘tsconfig.json’ file; using flag ‘- -config=tsconfig.json’.
14. Normal JS also works too with Deno; basically even files with .js extensions.
15. Lastly, the usage of the await supported by v8 - Top level Async: Node supported the async-await pattern of handling asynchronous operation after the release of ES5/ES6. If you are defining a function that does some asynchronous operation, then you will have to use this standard pattern of async-await.
16. Deno had the awesome feature of using await directly since it was binded directly to the promises. In simpler terms, you could use ‘await’ without using the async keyword in a program.

With these flaws around, and each of them being handled in Deno; Deno looks quite promising.

Yet need to see how this environment and frameworks built on Deno, based on their adoption rate and flexibility, will see how Deno turns the industry around.

In this article, I will be discussing about an Application Server setup using Oak Framework connected to MongoDB database using deno_mongo native Deno Driver.

Let us dig into Deno and then start with Creating a RESTful API using Deno [ Oak Framework — Inspired by Koa Framework ].

What is this Deno?

• Simple, Modern & Secure Runtime for JavaScript and TypeScript that uses v8 engine built using Rust.
• Recently in May 2020, v1.0.0 of Deno was out officially.
• Deno is built with Rust in the core.
• Supports TypeScript without explicit setup.
• Not compatible with node modules and npm

Further details can be found in the official Deno v1.

Now starting with creating simple RESTful API using Deno’s framework called Oak.

In this article, we will be creating Application Server using

Oak: A Middleware Framework for Deno’s HTTP server; inspired by Koa Framework.

deno_mongo: It is a MongoDB database driver built for the Deno Platform. A native database driver for MongoDB.

To get started, before starting to build the application, this is a simple application to build an Application Server, to create a user and fetch user details.

Below given is the folder structure of the mini-project as follows

• models contains the model definition, in our case only User Interface
• routers contains API routes to handle API Requests
• controllers will be holding the files that deal with validation of the data, whatever that is been sent from the frontend.
• services contain all the business logic of the API routes.
• repository contains the files that deal with all the queries related to the database.
• middlewares contains the files that have different route-level middlewares
• helpers contains files that deal with some sort of helper functions
• keys contain files that store the .json/.js/.ts file to store constant values or key values
• .deno_plugins upon first execution; this folder is generated, just cached version of the libraries or modules that imported in the codebase.
• app.ts is the entry point of the applications

#deno #node #api #javascript #typescript