DEV Community: Rajika Imal

JavaScript quick tips: Array.copyWithin()

Rajika Imal — Sat, 31 Oct 2020 07:01:17 +0000

Array.prototype.copyWithin() does a copy (shallow) of the selected elements within the same array, to a specified index.

To copy value in index 3 to index 1

const myArray = [1, 2, 3, 4, 5];
myArray.copyWithin(1, 3, 4); // [1, 4, 3, 4, 5]

To copy all values from specified index to the end to a given index

const myArray = [1, 2, 3, 4, 5];
myArray.copyWithin(1, 3); // [1, 4, 5, 4, 5]

JavaScript quick tips: filter arrays

Rajika Imal — Fri, 30 Oct 2020 12:07:26 +0000

Filter only numbers in an array,

const myArray = [1, "const", 2, 3]
myArray.filter(Number); // 1, 2, 3

Remove all falsy values in an array

const myArray = [1, "const", 2, 3, undefined, null]
myArray.filter(Boolean); // 1, "const", 2, 3

JavaScript Array.flat()

Rajika Imal — Fri, 30 Oct 2020 05:49:50 +0000

Arrays with embedded sub arrays can be concatenated using Array.flat()

const array = [1, 2, 3, 4, [5, 6]]
const flatArray = array.flat() // [1, 2, 3, 4, 5, 6]

The depth can be specified using an argument. Array.flat(depth)

const array = [1, 2, 3, 4, [[[5, 6]]]]
const flatArray = array.flat(1) // [1, 2, 3, 4, [[5, 6]]]

const array = [1, 2, 3, 4, [[[5, 6]]]]
const flatArray = array.flat(3) // [1, 2, 3, 4, 5, 6]

Future of JavaScript tooling

Rajika Imal — Sun, 11 Oct 2020 17:47:17 +0000

Recently I've seen a transition of building tooling infra in the JavaScript ecosystem using languages other than JavaScript! Specifically with compiled languages such as Rust and Go. The main goal is performance.

JavaScript is a great language for most of the use cases in software development. But when it comes to creating high performant tooling, there are better options out there.

Here are a few tools built with compiled languages,

esbuild - https://github.com/evanw/esbuild
RSLint - https://github.com/RDambrosio016/RSLint
volta - https://github.com/volta-cli/volta

Even at the early stage of development, these tools have shown better performance compared to their counterparts written in JavaScript.

esbuild performance comparison,

The Scale Cube

Rajika Imal — Tue, 06 Oct 2020 14:06:18 +0000

Scaling can be achieved by following the above axes.

x-axis, horizontal scaling - When the traffic increases the application can be scaled by adding more instances. This is a simple strategy. However, concerns like handling state should be taken into consideration as multiple instances are working at the same time.
y-axis, microservice/functional decomposition - Once the number of instances is increased, and still, if the system underperforms, logic can be decomposed into microservices. This allows scaling different parts of the application individually by adding more instances.
z-axis, partitioning/sharing - This concerns the data layer. As the traffic increases, the data layer needs to handle the spikes. As an improvement sharding can be implemented by dividing the records to the different DBs based on a sharding function.

All the above techniques come with certain costs and the decisions need to be taken depending on the requirements of the application like availability, consistency, and partition tolerance.

Promise.race()

Rajika Imal — Mon, 28 Sep 2020 16:31:53 +0000

Promise.race() resolves whenever one of the promises resolves. If there are multiple promises, the first promise that gets resolved will be returned.

const promise1 = new Promise((resolve, reject) => {
  setTimeout(() => { resolve('one'); }, 500);
});

const promise2 = new Promise((resolve, reject) => {
  resolve('two');
});

Promise.race([promise1, promise2]).then((value) => {
  console.log(value);
  // Both resolve, but promise2 is faster
});
// expected output: "two"

If an empty array is passed, it'll be in forever pending state.

Promise.any() has a similar behavior. But unlike .any(), .race() will return the first fulfilled or rejected promise value. .any() returns fulfilled values only.

Caching 101

Rajika Imal — Tue, 22 Sep 2020 17:44:14 +0000

Caching is one of the most used techniques to improve application performance. There are few means of managing caches based on the application use cases. An example of a cache is in-memory storage sitting in between an application server and a database.

Read through cache

When a record is read from the application, it looks in the cache before requesting from the persistence store (database). If the data is present, it will return the result avoiding the round trip to the database.

Write through cache

An operation that adds new data to an application adds records to the database. Before adding the data, the write-through cache is updated and then the database is updated. This way the cache is up to date with the new records.

Write behind cache

In this case, the cache is updated asynchronously after writing data to the database. The time which takes to update the cache can be configured.

Refresh ahead cache

Caches have invalidation periods, meaning data can be expired after a certain defined period of time. With refresh-ahead, the cache can be reloaded to load new data so that the cache is updated with the recently accessed data before invalidating data.

Notes on pre-rendering

Rajika Imal — Sun, 20 Sep 2020 09:01:26 +0000

Typical single page applications needs to load all JavaScript before rendering the application. This increases the time for FP (First Paint) and FCP (First Contentful Paint). However this can be mitigated using pre-rendering. Pre-rendering is generating the HTML from server and sending to the browser.

There are two types of pre-rendering techniques. SSR (Server Side Generation) and SSG (Static Site Generation). Both of these techniques create the HTML in the server and send back to the client, thus improving FP and FCP. However the difference is that,

SSR, HTML is generated for each request.
In SSG, HTML generation is done at the build step of the application.

With SSR dynamic content as such data from APIs are fetched at each time. But with SSG if such dynamic content is present they can become stale. In different frameworks there are techniques to overcome this issue to a certain extent. In Next.js, it is possible to SSG an application without the dynamic content or add incremental static site generation. SSG can provide better performance with CDN cache.

Run GitHub Actions locally

Rajika Imal — Sun, 06 Sep 2020 18:28:23 +0000

GitHub Actions are a great way to run continuous integration and continuous deployment tasks. Actions are defined using YAML files and there are tons of existing ones which you can use to develop a pipeline. However Actions should be run on GitHub to know the output, which means at development it is not possible to run Actions and test them.

act provides a way to run Actions locally. This simplifies the development of actions and running them locally. Therefore this gives faster feedback for the developer.

Installation

$ brew install nektos/tap/act #for macOS
$ curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash
$ choco install act-cli #for choco
$ scoop install act #for scoop

Usage

Make sure you have Actions defined in .github/workflows/ directory

To confirm this run,

$ act -l

To run all

$ act

To run a specific job, use -j flag,

$ act -j test

To invoke an event,

$ act pull request

The complete list of flags are available here.

JavaScript `this` in a flash!

Rajika Imal — Tue, 01 Sep 2020 10:45:59 +0000

this in JavaScript can be the one of the most confusing concepts to grab at first. If you want to understand this, just remember only ONE rule. Yeah, just one rule. Consider the following two scenarios below,

function person() {
    console.log(this === global)
}

person(); //true

var person = {
    getPerson: function() {
        console.log(this === person);
    }
}

person.getPerson(); //true

In the first snippet, the function is called directly. If that's the case, it'll always have the context (this) set as global. (In the browser it's window).

In the second snippet, the function is called from an object. In this instance this is the object itself.

Therefore the rule is: "If it's called directly without creating an object, this equals to global context, if a function is called by creating an object, then this equals to the context of the calling object".

By following this rule, other behaviors can be understood very easily. In JavaScript, there are different way to call methods. call, and apply are used to call methods by specifying objects and arguments explicitly. Both of these can change the context based on the provided object. Again apply the singular rule. The context of the method will depend on the object that is calling the method. Below snippets shows this behavior. (Note: call and apply differs with the way arguments are passed)

var person = {
    getPerson: function() {
        console.log(this.name);
    }
}

var jack = {
    name: "jack"
}

person.getPerson.call(jack); //jack, reason: even though the method is called from person object, jack object is given as the argument in call function explicitly, therefore it binds to jack object. 

person.getPerson(); //undefined, reason: person object doesn't have name in it's context

In the below snippet, person.getPerson.call(jack); and person.getPerson(); will give two outputs.

var person = {
    name: "nancy",
    getPerson: function() {
        console.log(this.name);
    }
}

var jack = {
    name: "jack"
}

person.getPerson.call(jack); //jack

person.getPerson(); //nancy, reason: as method is called from the object and it has a name in it's context.

When we consider all the above scenarios, it comes down to the singular rule that we established at the start.

Tracing in express.js

Rajika Imal — Thu, 27 Aug 2020 18:40:46 +0000

Tracing is tracking the details of each request. With tracing it is possible to track down the execution of the code for each user request in the context of a web application. This is important when debugging an application as it might be necessary to track a user and the corresponding path of the code. With threaded languages, this is quite straightforward with the thread id.

In Node.js, it is not simple as it is single threaded and depends on the event loop to execute asynchronously. However rtracer provides a straight forward solution to accomplish this.

rtracer provides APIs to use it in multiple frameworks such as express.js, and fastify.

To use it in express.js, rtracer has to be registered as a middleware. That's it. After that the id generated by rtracer can be used with any type of logger. An id is generated as follows,

app.use(rTracer.expressMiddleware());
app.get('/', (req, res) => {
  const requestId = rTracer.id();
  console.log(`Request Id: ${requestId}`);

  res.json({ status: true });
});

This repository contains a minimal example that demonstrates rtracer with winston logger.

System Design - Back To Basics

Rajika Imal — Tue, 18 Aug 2020 14:43:43 +0000

What we'll look into

Vertical Scaling
Horizontal Scaling
Load balancer
RAID
Caching
Cache servers

It is important to know different aspects of system designing in order to create a rigid system with characteristics such as availability, redundancy and scalability. Most of the topics discussed in this post are related to web applications.

Vertical Scaling

Vertical scaling refers to adding resources to the underlying machine. Once the traffic to web site or application increases, the first instinct is to increase the amount of resource to add to the running machine. Adding more memory and CPU power usually copes with the performance requirements. However adding resources can be costly and at some point there will be a limit to adding resource continuously to cater the high amount of requests.

Horizontal Scaling

Horizontal scaling as the name implies is the opposite of vertical scaling, where more machines are added instead of adding more resources to a single machine. One of the advantages is the cost can be minimized if the cheaper machines are added compared to adding high cost resources as in the case of vertical scaling. With cloud computing adding more machines is quite easy with virtual machines or containers. However, if the server side code implemented sessions with a single server, these might get broken as many machines are added and user can be directed to different machines for different requests. To fix a common database can be introduced to store session data, but this adds a single point of failure.

Alternatively sticky sessions can be implemented. Sticky sessions make sure that the requests of a particular user gets directed to the same machine. This can be implemented in many different ways. A common method is to use cookies with the unique id of the server.

Once many machines are introduced, a load balancer has to be added to the design to redirect the requests to different machines.

Load balancer

Load balancer is responsible to sit in-front the multiple worker machines, and redirect the requests to the corresponding machine. The redirection is dependent upon the algorithm implemented. Round-robin algorithm is used for basic scenarios to distribute the requests evenly. However in cases where the requests must be redirected to a certain machine, different strategies such as sticky sessions with cookies might be used.

RAID

When a system makes use of separate box to store centralized data such as sessions, there would be risks such as single point of failure and not having a fault tolerant solution. To overcome this RAID (Redundant Array of Independent Disks) can be used as a strategy. RAID can solve different types of issues such as redundancy, fault tolerance, performance and data recovery. Depending on the requirement, a type of RAID level should be selected for the solution. This post explains few of the RAID levels with their pros and cons.

Caching

As we expand our solutions to to include databases, and eventually there will be bottlenecks with the queries specially if the application is read heavy. If the same query is made 100000 time to the databases, these round trips can cost some serious issues in terms of the performance. Thus caching comes into the picture. In the case of read heavy operations, the first step is to identify the bottlenecks. Once the read heavy queries are identified, a read-through cache can be applied. In this way before actually doing the query to the database, the cache is checked. If the cache contains the necessary record, it is returned and the query never makes the round trip to and from the database. Similarly there are many other caching mechanisms.

Cache servers

To implement caching there are different methodologies. Simply a custom in memory cache can be implemented based on the requirements. This can be done using in the same runtime context of the application itself, using the same programming language. However when the work-load increases, a caching server can be used. A caching server bundles many of the common features required by applications when integrating a cache such as invalidation, scaling, and fault tolerance. Redis, and memcached are few examples of widely used caching solutions.