Deno differentiates itself with some unique features like:
An application may have a need to create a temporaries (file or directory) for quick use, and the temporary file/directory would be discarded after the application is done with it. Usually the time between creation and discard is short. For example — saving the HTTP request body in a file (for quick debugging), or copying a file to another for temporary use, collecting large amount of output from a child process in a file, etc.
A developer can do this by coming up with a random file name and open the file. …
Query params are one of the basic mechanisms to carry data in RESTful APIs requests. The query params are especially useful in conveying additional (many times optional) data for GET APIs. This is because, in a lot of implementations, GET with body is rejected.
As Deno supports web APIs, processing query params is very easy. In this article, we’ll see how to natively process query params.
The query params can be processed using web APIs that are part of Deno’s core runtime. There is no need to import anything.
There are two steps in processing query params:
It’s quite common to have REST APIs that accepts file uploads. For example — uploaded images for product reviews, general images, documents, logs, etc.
Generally, such REST APIs handles uploaded files in three ways:
One of the biggest advantage of Deno is providing commonly used functionality through web APIs (wherever possible). A few web APIs were supported since the inception of Deno. Off recently, the number has been increasing at a fast pace. These are the same web APIs that developers have been using in browser. This makes it easier for developers to write code in Deno.
One of the web API is crypto. Till release v1.11, Deno had support for a single web crypto API: getRandomValues. From release v1.11, Deno has expanded web crypto API support with:
To learn about file upload through fetch API, check the story here.
Deno supports web standard’s fetch API to make HTTP requests (aka HTTP client). The fetch API is a pretty common & versatile API used in browsers. It can be used from easily making simple HTTP requests involving simple data like JSON, URL encoded, form data, etc. to making file upload and download requests.
The fetch API supports web’s Request and Response interfaces. A request object is created with all the data and given to fetch API. The fetch API makes the HTTP request, and returns a Response object…
Deno supports web standard’s fetch API to make HTTP requests (aka HTTP client). The fetch API is a pretty common & versatile API used in browsers. It can be used to easily make HTTP requests with built-in support for content types like:
The fetch API supports web’s Request and Response interfaces. A request object is created with all the data and given to fetch API. The fetch API makes the HTTP request, and returns a response object to the caller. A great documentation of fetch API is available here.
There are generally two phases in CI/CD or any other automatic deployer:
The CI/CD pipeline would start the installation procedure with the base application installation (i.e. application’s code). The next part of installation is to fetch and install all the dependencies. At the end of installation phase, the application has got everything it needs to run. Following the fail early principle, the CI/CD pipeline would move to the running phase only when installation succeeds. The installation errors shouldn’t be detected when the application runs.
One of the most highlighted features of Deno is sandboxing. Deno is secure by default. This means that there is no network, file, environment access by default. All the accesses need explicit enablement.
In this graphical article, we’ll go over the different types of sandboxing supported by Deno.
Even if access is enabled in Deno, further user level access control is imposed by the operating system
By default, there is no access for the Deno process. It can only execute ECMAScript code. It can’t read, write from/to file system, listen on sockets, make API calls, start a child process, etc…
Before v1.9.0, Deno’s HTTP server implementation was in TypeScript. Up to TCP connection handling, the implementation was in Rust, then the entire HTTP handling was done in TypeScript. In other words, the HTTP server was scripted (or interpreted). Even though the HTTP server was scripted, the performance was pretty decent.
From v1.9.0 (though still under unstable umbrella), Deno has moved HTTP server implementation to Rust, utilizing a high performance HTTP server library called Hyper. Hyper is an asynchronous, low-level, fast, and performant HTTP server. It is also backed by extensive production use. Off recently, there has been a lot of…
Mayank has more than 17 years of software experience, with last few years in developing high performance production grade microservices in Node.js.