DEV Community: Jino Antony

BunJs a New JS Runtime

Jino Antony — Mon, 02 Oct 2023 07:55:22 +0000

New frameworks and libraries are not a new thing in the Javascript ecosystem. In fact, new JS libraries are released almost every week! So what makes Bun different from other libraries/frameworks? Let's find out.

What is BunJs?

Bun is a "fast all-in-one javascript runtime". It is similar to Node or Deno. It was created by Jarred Sumner. Bun started out as a javascript webserver and later evolved into being a complete rewrite of the javascript ecosystem.

At its core is the Bun runtime, a fast JavaScript runtime designed as a drop-in replacement for Node.js. It's written in Zig and powered by JavaScriptCore under the hood, dramatically reducing startup times and memory usage.

Bun was built from scratch to focus on three main things:

Start fast
Provide new levels of performance
Being a great and complete tool

Bun is written in ZIG language and uses the JavascriptCore engine instead of V8 which was used in node and deno. It is designed as a drop-in replacement for nodejs.

Why BunJs?

Let's take a look into the why part of bun, why it exists?

According to the official site,

The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity.

So you can say Bun is an all-in-one package for JavaScript development. This makes Bun stand out from its alternatives like node and deno where we need some external tools/packages for the development.

The built-in features offered by Bun are:

Javascript runtime
Package manager
Test runner
Transpiler/Bundler
Typescript & JSX Support
env support
Sqlite client

Blazing Fast

The standout feature of bun is its blazing fast speed compared to its alternatives. It is said to be 4x times faster than node.js. We can verify this ourselves with a simple script.

The following code is a simple script to create an http server which listens on port 3000

const http = require('node:http');

const server = http.createServer((req, res) => {
    res.end('Hello World!');
});

server.listen(3000);

Let's benchmark this using apache bench

ab -k -c 20 -n 250 "http://localhost:3000/"

It produces the following output

Concurrency Level:      20
Time taken for tests:   0.107 seconds
Complete requests:      250
Failed requests:        0
Keep-Alive requests:    0
Total transferred:      21750 bytes
HTML transferred:       3000 bytes
Requests per second:    2330.22 [#/sec] (mean)
Time per request:       8.583 [ms] (mean)
Time per request:       0.429 [ms] (mean, across all concurrent requests)
Transfer rate:          197.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      0       4
Processing:     1    8   3.8      7      19
Waiting:        0    4   2.8      4      14
Total:          2    8   3.7      8      19

Now let's run the same script using Bun. We don't need to make any changes in the script since Bun supports most of the node libraries. We can replace the start command form node server.js to bun server.js and it will just work.

Concurrency Level:      20
Time taken for tests:   0.051 seconds
Complete requests:      250
Failed requests:        0
Keep-Alive requests:    0
Total transferred:      32000 bytes
HTML transferred:       3000 bytes
Requests per second:    4945.01 [#/sec] (mean)
Time per request:       4.044 [ms] (mean)
Time per request:       0.202 [ms] (mean, across all concurrent requests)
Transfer rate:          618.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.6      1       3
Processing:     0    3   1.9      2       8
Waiting:        0    3   1.8      2       8
Total:          2    4   1.9      3       8

From the benchmark result we can clearly see bun outperfoms nodejs in speed. Bun can handle 2x more requests/sec than node with node's http server.

Now let's benchmark Bun with its own server.

export default {
    port: 3000,
    fetch(req) {
        return new Response('Hello world!');
    }
}

It's pretty simple to create an http server in Bun. The script need to make a default export with an object with a port and fetch function, it will automatically creates an http server listening on the specified port.

Concurrency Level:      20
Time taken for tests:   0.033 seconds
Complete requests:      250
Failed requests:        0
Keep-Alive requests:    0
Total transferred:      32000 bytes
HTML transferred:       3000 bytes
Requests per second:    7585.18 [#/sec] (mean)
Time per request:       2.637 [ms] (mean)
Time per request:       0.132 [ms] (mean, across all concurrent requests)
Transfer rate:          948.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      1       2
Processing:     0    2   0.8      1       4
Waiting:        0    1   0.8      1       4
Total:          1    2   0.9      2       5

Bun's own server is blazing fast and handles 3x requests/sec more than node's server.

Package Manager

Let's take a look at Bun's package manager, which is also nodejs compatible. It can be used as a standalone tool for existing nodejs applications.

To install all dependencies of a project using the bun package manager we can use the following command.

bun install

To install specific packages:

bun add package-name

We can run a benchmark test on Bun's package manager against yarn and npm. The benchmark is run for the following package.json.

{
  "name": "Bun-test",
  "private": true,
  "dependencies": {
    "express": "4.18.2"
  }
}

It have only one dependency express.

Running benchmark produced the following results

As per the benchmark results bun install is 26x times faster than npm install and 23x times faster than yarn install

Future of Bun

The future of Bun looks promising. The JavaScript community is really excited about the new kid in town. The success of any new technology depends on community adaptation. People usually don't like to change things they have the most comfort in unless the change brings new levels of comfort. Similar is the case with technology. But in the case of Bun, the features, especially the speed, might be a huge factor in its adaptation. Also, even if we don't need to replace Node.js entirely, we can still use Bun as a package manager, test runner, transpiler, etc.

Will Bun replace Nodejs? Well, we need to find out, but I think Bun is in the right way for that!

Async vs Sync NodeJs: A Simple Benchmark

Jino Antony — Tue, 07 Jul 2020 16:37:43 +0000

Async and sync are probably two of the most heard words among javascript developers, they refer to asynchronous and synchronous programming respectively. Asynchronous programming in javascript can be done using callbacks, Promise, and async and await.

Javascript handles asynchronous tasks with the help of event loop. We know that it increases performance and doesn't block the rest of the code. But everything is theoretical, how do we know is it actually increases performance?

By doing some benchmarks!!

In this article, we won't discuss how to program asynchronously or synchronously, instead, we are going to run some benchmarks against sync and async methods.

For the test case, we are going to use the bcrypt package which has sync and async methods to hash a given string. We also need express.

let's start by installing the dependencies.

yarn add express bcrypt

The following script can be used for benchmarking.

import express from 'express'
import bcrypt from 'bcrypt'

const app = express()

app.get('/sync', (req, res) => {
    let hashed = bcrypt.hashSync('secret', 10)
    return res.send(hashed)
})

app.get('/async', async (req, res) => {
    let hashed = await bcrypt.hash('secret', 10)
    return res.send(hashed)
})

app.listen(3000, () => console.log('Server started on port 3000'))

It's a simple express application with two routes both of them will return the hashed value of string "secret". /sync route will use bcrypt.hashSync() method to hash the value synchronously, while /async route use bcrypt.hash() method to hash the value asynchronously.

We can now run the benchmark test using apache bench.

Apache bench is a tool for benchmarking HTTP servers.

Sync mode benchmark

The following command is used to run the benchmark for sync mode.

ab -k -c 20 -n 250 "http://localhost:3000/sync"

If you don't know what the above command does, it simply calls the apache bench (ab) with the URL to be benchmarked (http://localhost:3000/sync) as input and some options( -k, -c, -n).

-k - Enable the HTTP KeepAlive feature
-c - Number of multiple requests to perform at a time.
-n - Number of requests to perform for the benchmarking session

The result is given below.

Concurrency Level:      20
Time taken for tests:   23.247 seconds
Complete requests:      250
Failed requests:        0
Keep-Alive requests:    250
Total transferred:      66250 bytes
HTML transferred:       15000 bytes
Requests per second:    10.75 [#/sec] (mean)
Time per request:       1859.754 [ms] (mean)
Time per request:       92.988 [ms] (mean, across all concurrent requests)
Transfer rate:          2.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   1.6      0      10
Processing:    90 1783 414.3   1804    3655
Waiting:       90 1783 414.4   1804    3655
Total:         90 1783 414.5   1804    3655

Async mode benchmark

Now let's benchmark the asynchronous mode.

ab -k -c 20 -n 250 "http://localhost:3000/async"

And the results are as follows.

Concurrency Level:      20
Time taken for tests:   10.141 seconds
Complete requests:      250
Failed requests:        0
Keep-Alive requests:    250
Total transferred:      66250 bytes
HTML transferred:       15000 bytes
Requests per second:    24.65 [#/sec] (mean)
Time per request:       811.281 [ms] (mean)
Time per request:       40.564 [ms] (mean, across all concurrent requests)
Transfer rate:          6.38 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       3
Processing:    97  776 120.5    802     874
Waiting:       95  776 120.6    802     874
Total:         97  776 120.3    802     874

Comparison

Metrics	sync	async
Concurrency Level	20	20
Time taken for tests:	23.247 seconds	10.141 seconds
Complete requests:	250	250
Failed requests:	0	0
Keep-Alive requests:	250	250
Total transferred:	66250 bytes	66250 bytes
HTML transferred:	15000 bytes	15000 bytes
Requests per second:	10.75 #/sec	24.65 #/sec
Time per request:	1859.754 ms	811.281 ms
Time per request:	92.988 [ms] (mean, across al	40.564 ms
Transfer rate:	2.78 [Kbytes/sec] received	6.38 [Kbytes/sec] received

As you can see, async mode performs better than sync mode. The async mode handles more request/sec than sync mode and its time/request is less compared to that of sync mode.

Conclusion

As per the benchmark results, async mode performs better than sync mode when performing I/O (even though the test case doesn't perform any I/O operations). Hashing using bcrypt is a CPU intensive operation and when hashing strings using bcrypt in async mode, it uses the thread pool and doesn't block the event loop.

Always use async mode when your code needs to perform some blocking I/O operations as it doesn't block the event loop.

setImmediate() vs process.nextTick() in NodeJs

Jino Antony — Mon, 22 Jun 2020 12:38:32 +0000

NodeJs is famous for its non-blocking, event-driven architecture. Handling asynchronous tasks in node is quite easier than any other server programming language. Node offers several built-in functions to handle asynchronous tasks.

Asynchronicity

In order to achieve asynchronicity, node uses an event loop. The event loop is a single-threaded semi-infinite loop, which uses an event queue to queue all the io and/or timer callbacks and execute them one by one sequentially. The event queue is not a single queue, rather a collection of queues and heaps.

The above diagram shows the event loop's order of execution. Each box will be referred to as a phase of the event loop.

Phases of event loop

Event loop consists of the following phases.

Timers - in this phase callbacks of expired timers added using setTimeout or interval functions added using setInterval are executed.
Pending callbacks - executes I/O callbacks deferred to the next loop iteration.
Idle handlers - perform some libuv internal stuff, used internally.
Prepare handlers - perform some prep-work before polling for I/O, used internally.
I/O poll - retrieve new I/O events; execute I/O related callbacks.
Check handlers - setImmediate() callbacks are invoked here.
Close callbacks - execute close handlers

In this article, we are going to discuss only the Check handlers phase of the event loop. If you want to know about the event loop in detail check out the event loop series by Deepal and official nodejs docs here.

setImmediate() and process.nextTick() are two functions which allows us to control the order of execution of our code in the event loop. Both of these functions schedule our callback handlers in the event queue. But they are executed at different phases of the event loop.

setImmediate()

setImmediate(callback[, ...args]) takes a callback and add it to the event queue( specifially the immediate queue).

setImmediate(() => console.log('Queued using setImmediate'))

callbacks scheduled using setImmediate() will be executed in the Check handlers phase of the event loop.

console.log('Start')

setImmediate(() => console.log('Queued using setImmediate'))

console.log('End')

The output of the above script will be

Start
End
Queued using setImmediate

Since the event loop starts processing only if the call stack is empty, the callbacks queued in the event queue will be processed after the script is run to completion.

process.nextTick()

process.nextTick(callback[, ...args]) will also takes a callback and optional args parameters like setImmediate() function. But instead of "immediate queue", the callbacks are queued in the "next tick queue".

process.nextTick(() => console.log('Queued using process.nextTick'));

Callbacks scheduled using process.nextTick() will be processed after the execution of the current phase. That is, the next tick queues are processed in between each phase of the event loop. Also, the next tick queues are processed once the script is run to completion and before the event loop starts.

console.log('Start')

process.nextTick(() => console.log('Queued using process.nextTick'))

console.log('End')

The output of the above script will be

Start
End
Queued using process.nextTick

setImmediate() vs process.nextTick()

Now let's look at the differences between setImmediate() and process.nextTick() and when to use which.

setTimeout() is processed in the Check handlers phase, while process.nextTick() is processed at the starting of the event loop and between each phase of the event loop.
On any given context process.nextTick() has higher priority over setImmediate().

setImmediate(() => console.log('I run immediately'))

process.nextTick(() => console.log('But I run before that'))

Output:

But I run before that
I run immediately

If process.nextTick() is called in a given phase, all the callbacks passed to process.nextTick() will be resolved before the event loop continues. This will block the event loop and create I/O Starvation if process.nextTick() is called recursively.

let count = 0

const cb = () => {
    console.log(`Processing nextTick cb ${++count}`)
    process.nextTick(cb)
}

setImmediate(() => console.log('setImmediate is called'))
setTimeout(() => console.log('setTimeout executed'), 100)

process.nextTick(cb)

console.log('Start')

Output:

Start
Processing nextTick cb 1
Processing nextTick cb 2
Processing nextTick cb 3
Processing nextTick cb 4
Processing nextTick cb 5
Processing nextTick cb 6
Processing nextTick cb 7
Processing nextTick cb 8
Processing nextTick cb 9
Processing nextTick cb 10
...

As you can see recursive calls to process.nextTick() are processed continuously and I/O is starved. So setImmediate() and setTimeout() callbacks won't be executed.

Unlike process.nextTick(), recursive calls to setImmediate() won't block the event loop, because every recursive call is executed only on the next event loop iteration.

let count = 0

const cb = () => {
    console.log(`Processing setImmediate cb ${++count}`)
    setImmediate(cb)
}

setImmediate(cb)
setTimeout(() => console.log('setTimeout executed'), 100)

console.log('Start')

Output:

Start
Processing setImmediate cb 1
Processing setImmediate cb 2
Processing setImmediate cb 3
Processing setImmediate cb 4
...
Processing setImmediate cb 503
Processing setImmediate cb 504
setTimeout executed
Processing setImmediate cb 505
Processing setImmediate cb 506
...

Here even though setImmediate() is called recursively, it won't block the event loop and the setTimeout() callback is executed after the specified timeout.

Use case

As the official docs, always use setImmediate().

We recommend developers use setImmediate() in all cases because it's easier to reason about.

So when to use process.nextTick() ?

Consider the following code snippet.

function readFile(fileName, callback) {

    if (typeof fileName !== 'string') {
        return callback(new TypeError('file name should be string'))
    }

    fs.readFile(fileName, (err, data) => {
        if (err) return callback(err)

        return callback(null, data)
    })
}

The problem with this code is that readFile() can be synchronous or asynchronous based on the input params. It may result in unpredictable outcomes.

So how can we make it 100% asynchronous? process.nextTick() can help us here.

Using process.nextTick() we can rewrite the function like this.

function readFile(fileName, callback) {

    if (typeof fileName !== 'string') {
        return process.nextTick(
            callback, 
            new TypeError('file name should be string')
        )
    }

    fs.readFile(fileName, (err, data) => {
        if (err) return callback(err)

        return callback(null, data)
    })
}

Now the function is completely asynchronous. It will now throw an error if the filename is not a string, only after running the script to completion and before the event loop starts.

process.nextTick() is also useful in other situations where the callback must be executed immediately after the script is run to completion.

Conclusion

process.nextTick() and setImmediate() allows the user to schedule callbacks in the event loop. process.nextTick() is processed after every phase of the event loop and setImmediate() is only processed on the check handler phase of the event loop.

Names of both functions are confusing. process.nextTick() fires immediately on the same phase and setImmediate() fires on the following iteration or 'tick' of the event loop.

Code to Interface: An Example in Laravel

Jino Antony — Sun, 17 May 2020 20:24:55 +0000

Code to an interface is a technique used in programming where you build your application based on abstractions (interface) and not concretions (classes).

If you are a programmer then you might have heard the phrases like code to interfaces, not implementations, program to interfaces, use abstractions instead of concretion, etc.

It all refers to the same thing. We should code our application in such a way that it should depend on abstractions (interfaces) instead of concretions (classes).

Why?

This is my exact reaction when I first heard the phrase. Why would I use interfaces instead of classes? Even if I created an interface I would also need to create a class implementing that interface. Isn't it a wastage of time?

Certainly No!!

The one constant thing in this world that doesn't change is change itself, or to put it in other words, change is the only constant.

In the case of programming also there is no exception for this rule. Business requirements change over time and so does our code.

So our code must be flexible.

Code to interface makes our code loosely coupled and flexible.

How?

Consider the code sample below.

class Logger {

    public function log($content) 
    {
        //Logs content to file.
        echo "Log to file";
    }
}

This is a simple class that logs content to a file. We can use it in our controller.

class LogController extends Controller
{
    public function log()
    {
        $logger = new Logger;
        $logger->log('Log this');
    }
}

But what if we want to log to multiple targets like db, file, cloud, etc.

Then we can change our LogController class and Logger class to accommodate these changes.

class Logger {

    public function logToDb($content) 
    {
        //Logs content to db.
    }

    public function logToFile($content) 
    {
        //Logs content to file.
    }

    public function logToCloud($content) 
    {
        //Logs content to cloud.
    }

}

class LogController extends Controller
{
    public function log()
    {
        $logger = new Logger;

        $target = config('log.target');

        if ($target == 'db') {
            $logger->logToDb($content);
        } elseif ($target == 'file') {
            $logger->logToFile($content);
        } else {
            $logger->logToCloud($content);
        }
    }
}

Okay, now we can log to different targets. But what if we want to add another target such as log to a redis server. We will end up modifying both the Logger class and the LogController class.

As you can see this quickly get out of our hands and code becomes messy. The Logger class quickly became a monolith. This is a nightmare to maintain.

So we need to split things. Following the SOLID principles, we can move responsibilities to their corresponding classes.

class DBLogger
{
    public function log()
    {
        //log to db
    }
}

class FileLogger
{
    public function log()
    {
        //log to file
    }
}

class CloudLogger
{
    public function log()
    {
        //log to cloud
    }
}

And the Controller is changed to

class LogController extends Controller
{
    public function log()
    {
        $target = config('log.target');

        if ($target == 'db') {
            (new DBLogger)->log($content);
        } elseif ($target == 'file') {
            (new FileLogger)->log($content);
        } else {
            (new CloudLogger)->log($content);
        }
    }
}

Much better. Now if we want to add other targets for logging we can create a new class and add it to the if-else in the Controller.

But still, our controller is responsible for choosing a logger. For the controller, it doesn't need to be aware of different loggers and choose between them. It only needs a logger class with a log() method for logging content.

Interface for the win

This is an apt situation for using an interface. So what is an interface?

An interface is a description of the actions that an object can do.

Coming to our example, the controller needs only a logger class with a log() method. So our interface must describe that it must have a log() action.

interface Logger
{
    public function log($content);
}

As you can see it contains only function declaration and not its implementation, which is why it is called as abstraction.

When implementing an interface, the class which implements the interface must provide the implementation details of the abstract methods defined in the interface.

In our example, any class which implements the Logger interface must provide the implementation details for the abstract method log().

We can then type-hint this interface in our controller.

class LogController extends Controller
{
    public function log(Logger $logger)
    {
        $logger->log($content);
    }
}

Now the controller doesn't care which type of logger is passed to it. All it needs to know is that it must implement the Logger interface.

So we need to modify our logger classes to implement this interface.

class DBLogger implements Logger
{
    public function log()
    {
        //log to db
    }
}

class FileLogger implements Logger
{
    public function log()
    {
        //log to file
    }
}

class CloudLogger implements Logger
{
    public function log()
    {
        //log to cloud
    }
}

We can now add more loggers without touching the existing code. All we have to do is create a new class that implements our Logger interface.

class RedisLogger implements Logger
{
    public function log()
    {
        //log to redis
    }
}

Our code is now flexible and loosely coupled. We can swap the implementations any time we want without touching the existing code.

Dependency Injection

When using a framework like Laravel, we can leverage its Service Container to automatically inject the implementations for the interface.

Since Laravel supports method-injection out of the box, we only need to bind the interface to its implementation.

First, we need to create a configuration file for the logger. So create a file config/log.php

<?php

return [
    'default' => env('LOG_TARGET', 'file'),

    'file' => [
        'class' => App\Log\FileLogger::class,
    ],

    'db' => [
        'class' => App\Log\DBLogger::class,
    ],

    'redis' => [
        'class' => App\Log\RedisLogger::class,
    ]
];

And in your AppServiceProvider.php inside app/Providers add the following code.

class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
        $default = config('log.default');
        $logger = config("log.{$default}.class");

        $this->app->bind(
            App\Contracts\Logger::class, // the logger interface
            $logger
        );
    }
}

What this does is, it reads the default logger from the config file, and binds it to the Logger interface. So whenever we request Logger interface, the container resolves it and returns the default logger instance.

Since the default logger is specified using env() helper we can use different loggers in different environments like file in local environment and db in production environment.

Conclusion

Interfaces allow us to create loosely coupled code while providing a level of abstraction. It allows us to change our implementations at any time without changing the context they are used. So always code to an interface all the variable parts in your application.

How Composer Autoloads PHP Files

Jino Antony — Mon, 27 Apr 2020 12:26:25 +0000

Composer is an application-level dependency manager for PHP. Dependency simply means libraries/packages your application depends upon. Apart from managing the dependencies, composer will also autoload the files needed for the application. Most of the frameworks (Laravel, Symfony, etc) use composer and it's autoloading by default.

What is autoloading?

Autoloading means the automatic loading of the files required for your project/application. That is including the files required for your application without explicitly including it with include() or require() functions.

Autoloading allows us to use PHP files without the need to require() or include() them and is considered a hallmark of modern-day programming.

Why do we need it?

Including files using include() or require() will be ok if your project contains less no. of files. But most of the real-world applications contain a huge no. of files. So including files using the above-mentioned functions will become a tedious task. It will become even more difficult if our project depends on a lot of external libraries/packages.

So we need an easy way of loading files. Autoloading can help us here.

How It works?

Let's take a look at a simple autoloader.

class Autoloader
{
    public function autoLoad($className) 
    {
        //logic for finding class path
        include $fullyResolvedPath;
    }
}

spl_autoload_register(['Autoloader', 'autoLoad']);

$obj = new DemoClass;

Here we used the built-in php function spl_autoload_register() to register our autoload function. What this does is it tells php

"Hey if you can't find the class yourself, let me find it for you. If I can't find it, then throw an error."

Inside the autoloader we provided, we can find the path to the class and then include it using the include() function.

Types of autoloading

Composer supports the following types of autoloading.

Classmap
PSR-0
PSR-4
Files

Autoloading types and its rule can be defined in the composer.json file. You can configure multiple types of autoloading in a single application. Among these PSR-4 and PSR-0 are the autoloading standards proposed by the PHP-FIG Group.

Classmap

Classmap, as its name implies, creates a mapping of all the classes inside the specified directories into a single key => value array, which can be found in the generated file vendor/composer/autoload_classmap.php. The automatic file generation happens on composer install/update.

{
    "autoload": {
        "classmap": ["src/", "lib/", "Something.php"]
    }
}

The mapping is done by scanning for all classes inside .php and .inc files in the specified directories. This is the fastest way of autoloading since it uses array lookup for finding the classes.

PSR-0

This is the PSR standard for autoloading files before PSR-4 and it is now Deprecated. You can define the PSR-0 rules in the config file as a mapping from namespace to paths, relative to the package/application root.

{
    "autoload": {
        "psr-0": {
            "Acme\\Foo\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
}

All PSR-0 references are combined into a single key => value array, which can be found in the generated filevendor/composer/autoload_namespaces.php. During autoloading PSR-0 looks for the namespace in the generated array and resolves the path from its value.

For example, Acme\Foo\Bar would resolve to src/Acme/Foo/Bar.php. PSR-0 also supports underscores(_) in class names. Each _ character in the class name is converted to a DIRECTORY_SEPARATOR. So that Acme_Foo_Bar would also be resolved to src/Acme/Foo/Bar.php.

PSR-4

PSR-4 is currently the recommended way of autoloading since it offers greater ease of use.

{
    "autoload": {
        "psr-4": {
            "Acme\\Foo\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

Unlike PSR-0 underscores will not be converted to DIRECTORY_SEPARATOR and the namespace prefix is not present in the path.

For example, Acme\Foo\Bar would resolve to src/Bar.php.

All the PSR-4 references are combined, during install/update into a single key => value array, which can be found at vendor/composer/autoload_psr4.php.

Files

Classmap, PSR-0, and PSR-4 deal with classes only. If you want to autoload functions, you can use files autoloading. This can be useful to load your helper functions. These files will be loaded on every request.

{
    "autoload": {
        "files": ["src/helpers.php"]
    }
}

Note on Classmap and PSR-4

Classmap autoloading is the fastest among autoloaders since it loads classes from the prebuilt array. But the problem with classmap is that you need to regenerate the classmap array every time you create a new class file. So in the development environment PSR-4 autoloading will be the most suited one.

PSR-4 autoloading will be slower compared to classmap because, it needs to check the filesystem before resolving a classname conclusively. But in production you want things to be as fast as possible.

For this reason, composer offers classmap generation from PSR-4. Classmap generation converts all PSR-4/PSR-0 rules into classmap rules. So autoloading will be faster. If a PSR-4 class is not found in the generated classmap, the autoloading fallback to PSR-4 rules.

Classmap generation can be enabled in any of the following ways.

Set "optimize-autoloader": true inside the config key of composer.json
Call install or update with -o / --optimize-autoloader
Call dump-autoload with -o / --optimize

Putting it all together

Now we can look into how composer autoloads our files combining all these autoloaders. First of all, we need to include composer's autoload.php file.

require __DIR__.'/../vendor/autoload.php';

It requires another file composer/autoload_real.php and calls the getLoader() method on the generated composer autoloader class.

require_once __DIR__ . '/composer/autoload_real.php';

return ComposerAutoloaderInitcac18dc222d8ea1e03bdef8b44290883::getLoader();

In the getLoader() method, composer loads all autoloader arrays which are generated on composer install/update or on composer dump-autoload and it also registers the autoload function using the spl_autoload_register() which is mentioned earlier.

// autoload_real.php
public static function getLoader()
{
    // ...
    self::$loader = $loader = new \Composer\Autoload\ClassLoader();
    // Loads all autoloader arrays
    $loader->register(true);
    // ...
    return $loader;
}

The register() method in ClassLoader class register the autload function loadClass().

class ClassLoader
{
    public function register($prepend = false)
    {
        spl_autoload_register(array($this, 'loadClass'), true, $prepend);
    }
}

The loadClass() method is simple. It calls another method findFile() with the class name and if the method returns a valid file path, then it class another helper function includeFile() with the file path, which simply includes the file at the given file path.

public function loadClass($class)
{
    if ($file = $this->findFile($class)) {
        includeFile($file);

        return true;
    }
}

The findFile() method is responsible for finding the file path. Since its implementation is a little bit complex, we won't discuss it here. But all you need to know is that it checks for file path lookup in the following way.

Check if classmap contains the specified class if found return immediately with the file path.
If the file is not found in classmap, psr-4 lookup is made, if found return with the generated file path.
If the psr-4 lookup is not successful, psr-0 lookup is made, if found return with the generated file path.

That's it. Composer does a good job of autoloading your files and provides you with a variety of options to configure them and make development a breeze.

Nullish Coalescing Operator Explained

Jino Antony — Sun, 19 Apr 2020 08:21:58 +0000

Nullish coalescing operator is a new operator in javascript, which is actually an ES2020 specification. It is a short-circuiting operator much like the && and || operators.

What is it?

Nullish coalescing operator (??) is a logical operator that returns its RHS operand when the LHS operand is nullish (null or undefined), otherwise returns its LHS operand.

const name = null ?? 'John Doe'
// output: John Doe

Why do we need it?

Prior to nullish coalescing operator, the logical OR (||) operator is used to check for nullish values.

const name = null || 'John Doe'
// output: John Doe

But the problem is || check for truthy or falsy value. That is it returns RHS operand when LHS operand is falsy (null, undefined, false, 0, '', NaN), otherwise it returns LHS operand.

const name = '' || 'John Doe'
// output: John Doe

const name = '' ?? 'John Doe'
// output: ''

To better understand the problem, consider the following code sample.

function joinArray(array, delimiter) {
  delimiter = delimiter || ',';
  return arr.join(delimiter);
}

In this example, the delimiter parameter is optional. , will be the default value if no value is passed for the delimiter parameter. But there is a bug in this code. What happens if we want to join the array without any delimiters, that is using '' as the parameter?

let joined = joinArray(['Find', 'the', 'bug'], '');
// expected output: Findthebug
// actual output: Find,the,bug

As you can see, the expected output is 'Findthebug', but the actual output is 'Find,the,bug'. This is because the || operator only checks if the operands are truthy or falsy and the empty string ('') evaluates to false. So the RHS operand, comma (,) in this case is returned.

We can fix this bug easily by replacing || with ??.

function joinArray(array, delimiter) {
  delimiter = delimiter ?? ',';
  return arr.join(delimiter);
}

And we get the correct results.

let joined = joinArray(['Find', 'the', 'bug'], '');
// output: Findthebug

Note on Chaining with AND or OR operators

It is not possible to chain AND (&&) and OR (||) operators directly with ??. Combining this will throw a syntax error.

const name = null || undefined ?? 'John Doe'
//Uncaught SyntaxError: Unexpected token '??

If you need you to combine them, then you must wrap one of the operator groups in parenthesis.

const name = (null || undefined) ?? 'John Doe'

This will remove the ambiguity and anyone reading the code can immediately understand what it does. Happy Coding!

Optional Chaining In Javascript

Jino Antony — Wed, 15 Apr 2020 16:12:08 +0000

Optional Chaining is a new feature available in Javascript. It is actually an ES2020 specification. Optional chaining allows developers to write code which are more readable and less verbose.

What is it?

Optional chaining as its name implies, helps us to chain the properties
of an object optionally. That is, we can chain properties of an object to many levels without having to expressly validate that each reference in the chain is valid.

What problem does it solve?

Consider the code sample below.

let person = {
  name: "John Doe",
  address: {
    place: "New York",
    city: "New York"
  }
}

We can access the person's Place like this

let place = person.address.place

But this will throw an error if the address property is missing.

So we have to check if address property exists before accessing its children

let place = person.address && person.address.place

Ok, but what if we have to access the children attribute of place. We have to add validation check for place also.

let place = person.address 
  && person.address.place 
  && person.address.place.name

This became a nightmare when we have to access deeply nested objects or attributes.

So let's see how this problem can be solved using optional chaining.

let place = person.address?.place?.name

Much more readable and neater 🥰

How does it work?

The .? operator functions similar to the . chaining operator, except when an attribute or reference is null or undefined, the expression short-circuits with a value of undefined.

For the above one-line code, it works like this.

First it check if person.address is nullish (null or undefined) or not. If it is nullish, then the expression immediately return undefined without executing the remaining parts. Otherwise, it continues executing the next part of the expression.

Tell me more

Optional chaining is a great feature to easily access deeply nested object properties without intermediatory condition checks, but it is not limited to that.

Optional chaining became real handy on several other occasions.

Optional Chaining with function calls

Optional chaining operator can also validate function calls.

let message = resultObject.getMessage?.()

Dealing with optional callbacks

Optional chaining can also be used to check if a callback is defined.

function fetchApi(url, onSuccess, onError) {
  // if error occured
  onError?.('An error occured')
}

Accessing array items

It can also validate if an array has the specified index.

let item = arr?.[1]

Browser Support

At the time of writing, optional chaining is supported by only a few browsers. You can check the detailed browser compatibility here

How Arrow Functions aka Short Closures Can Improve Your Code

Jino Antony — Mon, 30 Dec 2019 19:08:03 +0000

Arrow Functions aka Short Closures is a new feature available in PHP 7.4. The new version of PHP comes with various new features, out of which arrow functions are the most awaited one. In this article I want to show you how arrow functions can improve your code.

Syntax

Ok, let's start by analyzing the syntax for arrow function.

fn($arg) => $arg

Looks a bit weird. But it's pretty awesome once you get over it. To understand what the above code does, we can take a look at its equivalent normal function.

function ($arg) {
    return $arg;
}

Yeah, the function just takes an argument and returns it. So arrow function is a normal function with a special fn keyword and no return statement? Probably Not!

Features

These are some notable features of arrow functions.

They start with the fn keyword.
They can have only one expression.
No return keyword.
They inherit outer scope.

Arrow functions are quite known in the JS community. However short closures in PHP is not the same as arrow functions in JS. As the name suggests short closures are intended to use as simple Closures and they are not a replacement for normal functions.

So let's look into how short closures can improve your code.

PHP

Consider the below code sample. It's just a program to transform an array of names to capitalized valid names.

$names = ['alex', 'john', null, 'michael'];

$validNames = array_filter($names, function($name) {
  return !is_null($name);
});
// ['alex', 'john', 'michael']

$capitalizedNames = array_map(function($name) {
  return ucfirst($name);
}, $validNames);
// ['Alex', 'John', 'Michael']

Now we can use arrow functions to transform the above code.

$names = ['alex', 'john', null, 'michael'];

$validNames = array_filter($names, fn($name) => !is_null($name));
$capitalizedNames = array_map(fn($name) => ucfirst($name), $validNames);

🥰 Much neater and readable.

Laravel

This can be transformed

$apiKey = config('app.api_key');

$this->app->bind(PaymentInterface::class, function ($app) use ($apiKey) {
  return new Stripe($apikey);
});

to this

$apiKey = config('app.api_key');

$this->app->bind(PaymentInterface::class, fn($app) => new Stripe($apikey));

As you can see there is no need to pass the outer scope variable using the use keyword.

When using eloquent, this can be transformed

$place = 'New York';

$users = User::whereHas(['address' => function($q) use ($place) {
  $q->where('place', $place);
}])
->get();

into this

$place = 'New York';

$users = User::whereHas([
    'address' => fn($q) => $q->where('place', $place)
])->get();

Arrow functions will make you write less code and are more readable. While it's still not possible to write multi-line arrow functions in PHP, it may be possible in future versions.