DEV Community: Dmytro Danylov

A Guide to Handling Date and Time for Full Stack JavaScript Developers

Dmytro Danylov — Tue, 25 May 2021 05:13:42 +0000

Introduction
Date formats
Time zones
Unix timestamp
The Date object
Calculating the difference between dates
Formatting the date
Time zone on the back end
Storing dates in the database
Conclusion
Useful resources

Introduction

Time plays an essential role in our lives. Therefore, as developers we get to work with date and time quite frequently. Computer software is used by people from anywhere in the world and the time in one region can differ from the time in another region. And, generally in the software we build we capture and process the date and time of various data records and events. Therefore, it's important to understand various nuances around working with date and time.

Date formats

Date and time can be represented in many different formats. In Ukraine, the date is usually written in the format "DD-MM-YYYY" (the day is first), while in the United States the common format is "MM-DD-YYYY" (the month is first).

Time zones

Depending on the geographical area or a political unit (e.g., a country), the time zone can differ. For example, in the summer, while in Kyiv the time is 21:00, in New York the time is 14:00 (minus seven hours). Also, it's important to mention that the time zone choice/definition in a particular country/region may be affected by a political decision. A country can choose a UTC offset that differs from that country's actual georgraphical location's UTC offset.

All time zones are defined as offsets to Coordinated Universal Time (UTC), ranging from UTC-12:00 to UTC+14:00. The geographical reference point for UTC is the prime meridian (longitude = 0°), that runs through the Royal Observatory in Greenwich, London, United Kingdom.

Additionally, in various regions of the world people practice Daylight Saving Time (DST) or in other words - summer time. This is the practice of turning the clock forward one hour from standard time during the warmer months in order to get more daylight during the hours we're usually awake. For example, in Ukraine we turn the clock forward one hour on the last Sunday of March at 03:00 and we return back to the standard time (turning the clock backward one hour) in the last Sunday of October at 04:00. The date and time DST starts and ends depends on a country or a political unit (e.g., European Union.)

Also, a political region's time zone offset and/or the date and time when the DST starts and ends could have been changed at some point in history. Therefore, there is a number of databases where the information about the time zone changes is tracked. The most popular one is IANA - Time Zone Database, also known as tz or zoneinfo. Operating systems and other computer software use these databases for time zone processing and conversions.

Unix timestamp

A common format to represent date and time values in computer programming is the Unix timestamp, which is a number of seconds between the Unix epoch (1 January 1970 00:00:00 UTC) and another date (e.g., 1620758838). Positive integers represent the dates after the Unix epoch, while negative integers represent the dates before the Unix epoch.

The Unix timestamp is one of the common formats for storing date and time in operating systems and databases.

Learn more about the Unix timestamp on Wikipedia: Unix time.

The Date object

Fundamentally, a JavaScript date is specified as the number of milliseconds from the 1 January 1970 00:00:00 UTC. This number looks similar to the Unix timestamp. The difference is that the Unix timestamp is the number of seconds since the Unix epoch while in JavaScript it is the number of milliseconds.

In JavaScript we use the Date object to work with date and time:

const date = new Date();

The Date object holds the current date and time in UTC internally. However, by default, when we output the date and time, the Date object converts the output to the local time zone, the time zone of the environment where the JavaScript code is running (e.g., a browser, Node.js, etc.)

When instantiated without parameters, the date object holds the current date and time (new Date() holds the current date).

We can set the date and time in the Date's constructor or after the instantiation:

let currentDate = new Date();
let someDate = new Date('December 12, 2020 18:30:01');
let someDate = new Date('2021-12-12T18:30:01');
let someDate = new Date(2021, 11, 12, 18, 30, 1); // Month's index is zero-based
let someDate = new Date(1639326601000); // Number of milliseconds from Jan 1, 1970 00:00:00 UTC

When we instantiate the Date class, the specified date is converted to and tracked in UTC internally. However, when we access the date using the basic methods (e.g., toString, toLocaleString, getHours, etc) the date is returned in the local time zone:

const myDate = new Date('11 May 2021 18:30:01 UTC');

console.log(myDate);
// Tue May 11 2021 21:30:01 GMT+0300 (Eastern European Summer Time)

console.log(myDate.getHours());
// 21, not 18 as you might have expected

Here we instantiate the Date class specifying the date in UTC, but when we print the instantiated date object, we get the date in the local time zone, which for me is UTC+03:00 (Eastern European Summer Time). So, the date is stored in UTC internally, but when we access the date using the basic methods, it's converted to the local time zone.

The most popular methods of the Date object are:

Date.now();
// number of milliseconds since the Unix Epoch

new Date().getTime();
// same

Date.UTC(2021, 4, 14, 0, 0, 0);
// number of milliseconds since the Unix epoch until the specified date

const dateBasedOnUTC = new Date(
  Date.UTC(2021, 4, 14, 0, 0, 0)
);

const date = new Date();

// Access and modify the date based on local time zone:
date.getFullYear(); // for example, 2021
date.setFullYear(2021);

date.getMonth(); // zero-based month index (0 - 11)
date.setMonth(0);

date.getDate(); // day of the month (1 - 31)
date.setDate(28);

date.getHours(); // 0 - 23
date.setHours(23);

date.getMinutes(); // 0 - 59
date.setMinutes(8);

date.getSeconds(); // 0 - 59
date.setSeconds(59);

// Access and modify the date based on UTC:
date.getUTCFullYear();
date.setUTCFullYear(2021);

date.getUTCMonth();
date.setUTCMonth(11);

date.getUTCDate();
date.setUTCDate(12);

date.getUTCHours();
date.setUTCHours(9);

date.getUTCMinutes();
date.setUTCMinutes(0);

date.getUTCSeconds();
date.setUTCSeconds(0);

// Other useful methods:
date.toISOString();
// Get the date string in simplified extended ISO format (ISO 8601)

date.toLocaleString('uk', { timeZone: 'UTC' });
// Get the date string in the format according to a given locale and various options

date.toLocaleString('en', { month: 'long' });
// Get the name of the month in a given locale (e.g., June, July, etc)

Learn more about the Date object on MDN Web Docs: Date

Calculating the difference between dates

const date1 = new Date(Date.UTC(2021, 4, 11, 0, 0, 0));
const date2 = new Date(Date.UTC(2021, 4, 12, 0, 0, 0));
const diffInMilliseconds = date2 - date1;
const diffInHours = diffInMilliseconds / 1000 / 60 / 60;
console.log(diffInHours); // 24

Here, we create two date objects, 11 May 2021 and 12 May 2021. Then, we subtract 11 May 2021 (date1) from 12 May 2021 (date2) and get 24 hours of difference.

When you work with date objects, take into account the time zones these date objects were instantiated with. Check another example:

const date1 = new Date('2021-05-12T00:00:00.000Z'); // ISO 8601 string
const date2 = new Date('12 May 2021 01:00:00 UTC+3');
const diffInMilliseconds = date2 - date1;
const diffInHours = diffInMilliseconds / 1000 / 60 / 60;
console.log(diffInHours); // 1 or -2?

Here, the answer is -2, because the time zone of date1 is UTC while the time zone of date2 is UTC+3. Let's see what happens in more detail:

We set date1 to 12 May 2021 00:00:00 UTC using the ISO 8601 format. We specify the UTC time zone using the character Z. We could specify the time zone using an offset as well, like this: 2021-05-12T00:00:00.000+00:00 (+00:00 is UTC).
We set date2 to 12 May 2021 01:00:00 using another date and time format with the time zone offset UTC+3 (or UTC+03:00).
Then we subtract date1 from date2 (date2 - date1). When we use a mathematical operation on an object, JavaScript converts the object to a number using the object's valueOf() method if it's present. In the case of the Date object, the valueOf method returns the date and time as the number of milliseconds since the Unix epoch, which is a UTC-based date and time representation. So, date1 has been set in UTC, while date2 has been converted to UTC from UTC+3. So, actually, we subtract 12 May 2021 01:00:00 UTC (date1) from 11 May 2021 22:00:00 UTC (date2) and that's how we get -2 for the result.

Formatting the date

One way to format a date is to use the getter functions like getFullYear, getMonth, getDate, etc. For example, to create the date and time string in local time in the format 'YYYY-MM-DD hh:mm:ss' we can do the following:

const date = new Date();
const year = date.getFullYear();
const month = date.getMonth(); // getMonth returns a zero-based index of the month: 0-11
const day = date.getDate(); // 0 - 31
const hours = date.getHours(); // 0 - 23
const minutes = date.getMinutes(); // 0 - 59
const seconds = date.getSeconds(); // 0 - 59

const addZero = (num) => `${num}`.padStart(2, '0');

const formatted =
  year +
  '-' +
  addZero(month + 1) +
  '-' +
  addZero(day) +
  ' ' +
  addZero(hours) +
  ':' +
  addZero(minutes) +
  ':' +
  addZero(seconds);

In order to get the date and time values according to UTC, we can use the UTC-based getter functions like getUTCFullYear, getUTCMonth, getUTCDate, etc.

Furthermore, we can get the date and time string from the Date object formatted according to a given locale and various options using the Date's toLocaleString method:

new Date('2021-05-16').toLocaleString('uk');
// 16.05.2021, 03:00:00

new Date('2021-05-16').toLocaleString('en', {
  month: 'long',
});
// May

new Date('2021-05-16').toLocaleString('en', {
  month: 'long',
  day: 'numeric',
  year: 'numeric',
});
// May 16, 2021

Please note that if you don't specify the time zone in the options, toLocaleString will output the date in the local time zone:

new Date('2021-05-16T00:00:00').toLocaleString('en', {
  timeZoneName: 'short', // include the time zone name
});
// "5/16/2021, 12:00:00 AM GMT+3" (GMT+3 is my local time zone)

new Date('2021-05-16T00:00:00').toLocaleString('en', {
  timeZoneName: 'short',
  timeZone: 'Europe/Amsterdam',
});
// 5/15/2021, 11:00:00 PM GMT+2

First, we instantiate the Date object with the local time zone and get the localized date and time string. When the Date is instatiated the date and time value is converted internally from the specified time zone (or the local time zone if the time zone is not specified) to UTC.

Then, we instantiate another Date object with the local time zone. This time we set the timeZone option to "Europe/Amsterdam" (according to IANA Time Zone Database). Therefore, we get the localized date and time string based on the "Europe/Amsterdam" time zone. In more detail: my current time zone is UTC+3, so the Date object is instantiated with the date and time 2021-05-16 00:00:00 UTC+3 which is converted to UTC internally and becomes 2021-05-15 21:00:00. Then, the toLocaleString method converts this date from UTC to "Europe/Amsterdam" and the result is 5/15/2021, 11:00:00 PM GMT+2. The resulting offset is +2, because it's the Daylight Saving Time offset of the "Europe/Amsterdam" time zone.

Time zone on the back end

Usually, computer software (e.g., Node.js, databases, etc) by default uses the system date and time configuration. Therefore, make sure that all the servers that belong to your app use the same time zone. UTC is commonly used.

In Linux you can check the time zone using one of the following commands:

date
date +"%Z %z"
timedatectl

To change the system time zone you can use the following commands:

# Check available time zone names
timedatectl list-timezones

# Set the time zone
timedatectl set-timezone Europe/Amsterdam

To check the time zone of the Node.js process:

node -e "console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)"

In Node.js you can set the time zone using the TZ environment variable:

TZ=UTC node -e "console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)"
# UTC

If the TZ variable is not set, Node.js will attempt to use the operating system's time zone.

Storing dates in the database

Usually, web applications are available from anywhere around the world. This means, that if we store dates in the database, we need to make sure that we store all dates in a single (consistent) time zone or at least track the time zone of the dates we store. Various databases have their specifics as to how they treat date and time values. So, in this section I'd like to briefly explain how to store the date and time values in different databases and mention some of those specifics.

Usually, software (especially web apps) serves users from all over the world. Each user's local time depends on their location. For example, for the user from Kyiv the local time in the summer is 17:00 and at the same time for the user in Amsterdam the local time is 16:00.

Basically, we should convert and store the dates in a unified time zone; usually developers store the dates in UTC. So, before storing a date we should convert it from local time to UTC. For example, a user from Amsterdam creates a reminder in a calendar app. The user selects the date and time of the reminder in local time ("Europe/Amsterdam" time zone - UTC+01:00 standard time and UTC+02:00 DST). Let's say the user sets the reminder date to 12 May 2021 17:00 using a calendar widget. Now, before we store this date in the database, we should convert it to UTC, and the date becomes: 12 May 2021 15:00 in UTC, because Daylight Saving Time in Amsterdam (UTC+02:00) became active on 28 March 2021 at 02:00:00. Luckily, we usually don't have to deal with the time zone conversion logic, because it's usually built into the programming language and software (e.g., a database) we use. For example, in JavaScript we can get the current date and time in UTC using the Date object:

new Date().getTime();
// number of milliseconds from Unix epoch

new Date().toISOString();
// ISO 8601 date string in UTC

MySQL

In MySQL the dates are usually stored using the DATETIME and TIMESTAMP column types.

MySQL TIMESTAMP

MySQL converts TIMESTAMP values from the current time zone (e.g., the global time zone or the client session time zone) to UTC for storage, and back from UTC to the current time zone for retrieval. MySQL doesn't do this with the other column types, like DATETIME. So, TIMESTAMP values are converted to UTC for storage, but when they are retrieved, they are converted to the current time zone (SELECT @@SESSION.time_zone;). Please check this example:

CREATE TABLE timestamp_test (
    id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
  created_at TIMESTAMP NOT NULL
);

-- Set the current time zone to UTC+3
SET time_zone = '+03:00';

SELECT @@SESSION.time_zone;
-- +03:00

INSERT INTO timestamp_test (created_at) VALUES ('2021-05-12 21:00:00');

SELECT * FROM timestamp_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 21:00:00 |
+----+---------------------+

-- Set the current time zone to UTC+4
SET time_zone = '+04:00';

SELECT * FROM timestamp_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 22:00:00 |
+----+---------------------+

As of MySQL 8.0.19 we can add the time zone offset when inserting TIMESTAMP and DATETIME values into a table:

-- 1.
SET time_zone = '+02:00';

-- 2.
INSERT INTO timestamp_test (created_at) VALUES ('2021-05-12 21:00:00-01:00');

-- 3.
SELECT * FROM timestamp_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 20:00:00 |
|  2 | 2021-05-13 00:00:00 |
+----+---------------------+

-- 4.
SET time_zone = '+03:00';

SELECT * FROM timestamp_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 21:00:00 |
|  2 | 2021-05-13 01:00:00 |
+----+---------------------+

Let's see what happens in this example:

We set the current time zone to UTC+2
We insert a date value with time zone offset UTC-1: 2021-05-12 21:00:00-01:00. MySQL converts this date and time value from UTC-1 to UTC for storage: 2021-05-12 22:00:00.
We select the rows from our table and MySQL converts the TIMESTAMP values from UTC to the current time zone (UTC+2) upon retrieval: 2021-05-13 00:00:00
Then, we set the time zone to UTC+3 and select the rows again, and because MySQL converts the TIMESTAMP values from UTC to the current time zone upon retrieval, we get the date we've inserted earlier in UTC+3 this time: 2021-05-13 01:00:00

The TIMESTAMP type has a range of 1970-01-01 00:00:01 UTC to 2038-01-19 03:14:07 UTC.

MySQL DATETIME

MySQL DATETIME is stored and retrieved as is:

CREATE TABLE datetime_test (
    id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
  created_at DATETIME NOT NULL
);

-- Set the current time zone to UTC+3
SET time_zone = '+03:00';

INSERT INTO datetime_test (created_at) VALUES ('2021-05-12 21:00:00');

SELECT * FROM datetime_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 21:00:00 |
+----+---------------------+

-- Set the current time zone to UTC+4
SET time_zone = '+04:00';

SELECT * FROM datetime_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  1 | 2021-05-12 21:00:00 |
+----+---------------------+

MySQL does not convert DATETIME values from the current time zone to UTC and vice versa.

However, something interesting happens when we insert a DATETIME value with a time zone offset:

-- Set the current time zone to UTC+3
SET time_zone = '+03:00';

-- Insert a date with the time zone offset UTC+0
INSERT INTO datetime_test (created_at) VALUES ('2021-05-12 21:00:00+00:00');

SELECT * FROM datetime_test ORDER BY id ASC;
+----+---------------------+
| id | created_at          |
+----+---------------------+
|  ...                     |
|  2 | 2021-05-13 00:00:00 |
+----+---------------------+

In the example above we can see that when we insert a DATETIME value with a time zone offset, MySQL converts this date value to the current time zone for storage: 2021-05-12 21:00:00+00:00 + current time zone offset (+03:00) = 2021-05-13 00:00:00

The DATETIME type has a range of 1000-01-01 00:00:00 to 9999-12-31 23:59:59.

To store a date and time value I'd convert the local date and time value to UTC in the application code and store this value in the DATETIME column. Basically, I'd handle the time zone conversion on the application side and store all dates in UTC. I'd use DATETIME instead of TIMESTAMP, because TIMESTAMP is actually a 32 bit integer and doesn't allow to store dates beyond 2038-01-19 03:14:07 UTC, while DATETIME allows us to store dates up to 9999-12-31 23:59:59.999999.

PostgreSQL

In PostgreSQL we usually store date and time values using the column types timestamp without time zone (or simply timestamp) or timestamp with time zone (or simply timestamptz). Both types have a range of 4713 BC to 294276 AD.

PostgreSQL timestamp without time zone

The timestamp without time zone values are stored and retrieved as is:

CREATE TABLE without_time_zone(
  id SERIAL PRIMARY KEY,
  created_at TIMESTAMP NOT NULL
);

INSERT INTO without_time_zone (created_at) VALUES ('2021-05-12 09:00:00');

SELECT * FROM without_time_zone ORDER BY id ASC;
-- 1    "2021-05-12 09:00:00"

INSERT INTO without_time_zone (created_at) VALUES ('2021-05-12 09:00:00 +01:00');

SELECT * FROM without_time_zone ORDER BY id ASC;
-- 1    "2021-05-12 09:00:00"
-- 2    "2021-05-12 09:00:00"

In this example, we create a timestamp without time zone column called created_at. And, we can clearly see that the date and time value is stored and retrieved from this column as is. If we specify the time zone, the time zone is ignored.

PostgreSQL timestamp with time zone

The timestamp with time zone (timestamptz) values are converted from the specified time zone to UTC. If you don't specify the time zone when inserting a timestamptz value, PostgreSQL will assume that this date value is based on the current time zone (SHOW time zone;).

-- 1.
CREATE TABLE with_time_zone(
  id SERIAL PRIMARY KEY,
  created_at TIMESTAMP WITH TIME ZONE NOT NULL
);

-- 2.
-- Set current time zone for the session to UTC+3
SET time zone 3;

-- 3.
SHOW time zone;
-- <+03>-03

-- 4.
INSERT INTO with_time_zone (created_at) VALUES ('2021-05-12 09:00:00 +01:00');

-- 5.
SELECT * FROM with_time_zone ORDER BY id ASC;
-- 1    "2021-05-12 11:00:00+03"

-- 6.
INSERT INTO with_time_zone (created_at) VALUES ('2021-05-12 09:00:00');

-- 7.
SELECT * FROM with_time_zone ORDER BY id ASC;
-- 1    "2021-05-12 11:00:00+03"
-- 2    "2021-05-12 09:00:00+03"

What happens in this example is the following:

We create a table with a column called created_at which has type timestamp with time zone.
We set the current time zone for the session to UTC+3. Please note, that in PostgreSQL we can specify the current time zone using an integer offset or the time zone name (e.g., America/New_York). To get a list of supported time zone names query the pg_timezone_names table: SELECT * FROM pg_timezone_names
We ensure that the time zone offset has been set properly.
We insert a row with the created_at value of 2021-05-12 09:00:00 +01:00 into the new table. Because created_at column has type timestamp with time zone, PostgreSQL converts the date value from the specified time zone (+01:00 in our case) to UTC for storage. So, the value that has been actually stored is "2021-05-12 08:00:00".
We select the inserted row from the table and the date value is converted from UTC to the current time zone offset, which is UTC+3.
We insert another row into the table, but this time without specifying the time zone offset. If we don't include a time zone offset, PostgreSQL assumes that the date value we provide is based on the current time zone, which in our case is UTC+3. So, before storing this date value PostgreSQL will convert it from the current time zone (UTC+3 in our case) to UTC, and the following date value will be stored: 2021-05-12 06:00:00 UTC
Finally we select all rows from our table again and see that the date value we've just inserted is displayed in the current time zone: 2021-05-12 09:00:00+03

To store a date and time value in PostgreSQL I'd use the timestamp with time zone (timestamptz) type. Basically, I'd choose timestamptz instead of timestamp, because of the reasons mentioned in the following article from the PostgreSQL Wiki: Don't Do This - Date/Time storage.

DynamoDB

You can use the string and number data types to store dates and timestamps. We can use the string data type to store date and time values in ISO 8601 format (e.g., 2021-05-12, 2021-05-12T21:00:59.123Z). And we can use the number data type to store date and time values as UNIX timestamps (Epoch time) - a number of seconds since 1 January 1970 00:00:00 UTC. This will allow us to sort and query items by date and time.

MongoDB

In MongoDB, internally, dates are stored as 64-bit signed integers representing a number of milliseconds since the Unix epoch (1 January 1970 00:00:00 UTC). Negative values represent the dates before the Unix epoch.

To insert a date in the Mongo shell, we can use the Date object:

// Specifying the current date and time value when inserting an item:
db.books.insertOne({ title: 'Book 1', createdAt: new Date() })
db.books.find()
/*
{
  "_id" : ObjectId("60a5481cdff09849800652de"),
  "title" : "Book 1",
  "createdAt" : ISODate("2021-05-19T17:17:16.634Z")
}

You can pass an ISO 8601 string or a number of milliseconds since the Unix epoch into the Date constructor:

new Date('2021-05-19');
new Date('2021-05-19T00:00:00Z');
new Date(1621382400000);

If you specify a time zone offset, the date will be converted to UTC:

new Date('2021-05-19T00:00:00+02:00');
// becomes 2021-05-18T22:00:00Z

Conclusion

Take care when working with date and time. Always check if the dates you store and work with are based on the time zone you expect. Ensure that the environments you use for running different parts of your app (e.g., a web server, a database, etc.) have the correct and consistent time zone configuration.

Useful Resources

Getting Started with TypeORM

Dmytro Danylov — Wed, 07 Apr 2021 19:42:43 +0000

What is TypeORM

TypeORM is an Object Relational Mapping (ORM) tool. An ORM maps the entity objects in your application (e.g., an employee, a company, etc.) to the tables and rows in a database. An ORM helps us to interact with a database; it maps the data stored in the database (in tables, columns, and rows) to objects we can use in our applications.

Let's say, we have a table "customers":

CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(100) NOT NULL
);

SELECT * FROM customers WHERE id = 1;

id    name    email
1     John    john@example.com

TypeORM allows us to select rows from this table and map those rows to objects:

const customer = customersRepository.findOne({ id: 1 });

console.log(customer);

/*
The customer is an object:
{
  id: 1,
  name: "John",
  email: "john@example.com"
}
*/

Instead of using SQL to compose queries, we use the API provided to us by the ORM tool which transforms our API calls like findOne({ id: 1 }) to SQL like SELECT * FROM some_table WHERE id = 1 And then, the ORM transforms the received data to objects and passes these objects to us.

As any other ORM, TypeORM allows us to declare relationships between data, such that when we use its API, the relationships between tables are taken into account.

ORM Patterns

TypeORM supports two ORM patterns: Active Record and Data Mapper.

These patterns define the way we access the data on the side of the application.

The Active Record pattern is when we add the methods to access and modify the data directly to the object that represents the data:

// user.entity.ts
import {
  Entity,
  BaseEntity,
  PrimaryGeneratedColumn,
  Column,
} from 'typeorm';

@Entity()
export class User extends BaseEntity {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  email: string;
}

// user.service.ts
import { User } from './user.entity';

export const createUser = async () => {
  const user = new User();
  user.email = 'john@example.com';
  await user.save();

  // Or, to get the data:
  const user2 = User.findOne({ id: 1 });
};

The Data Mapper pattern is when we use so-called repository objects to access and modify the data. The repository objects map the data to simple entity objects (e.g., user, car, hotel, etc.) which only represent the data:

// user.entity.ts
import {
  Entity,
  PrimaryGeneratedColumn,
  Column,
} from 'typeorm';

@Entity()
class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  email: string;
}

// user.service.ts
import { getRepository } from 'typeorm';
import { User } from './user.entity';

export const createUser = async () => {
  const user = new User();
  user.email = 'john@example.com';

  const userRepository = getRepository(User);
  await userRepository.save(user);

  // Or, to get the data:
  const user2 = await userRepository.findOne({ id: 1 });
};

Active Record VS Data Mapper

Active Record couples the entity's data representation and data access together in a single object. On the other hand, Data Mapper decouples the data representation and data access.

People say that Active Record is easy to use and understand and it is suitable for small projects, while Data Mapper is a little more complex to understand, but it brings more benefit in terms of organising the code in larger projects.

Personally, at the time I'm writing this, I'd prefer to use Data Mapper in both, large and small projects, because it allows me to separate the application's entities from the way the data is accessed. Such that, the entities are represented by simple objects without any additional methods for querying and updating data.

Though, choosing either of these patterns is up to you.

Adding TypeOrm to an Express Project

I prepared a simple app based on Express and TypeScript for this example.

Now we need to do two things:

Launch a local database server for development
Add TypeORM to the project

Launching a Local Database Server Using Docker Compose

For a local database server, I'm going to launch PostgreSQL in a Docker container and use Docker Compose to manage this container.

This section is based upon the assumption that you have experience with Docker and have it installed. If you don't, you can learn more about it here: https://www.docker.com/get-started To be able to use Docker on my machine, I installed Docker Desktop.

If you don't want to use Docker, you can install PostgreSQL server directly.

Let's start by defining the container's configuration using docker-compose.yml (create this file in the project's root):

version: '3.1'

services:
  postgres:
    image: postgres
    restart: always
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    ports:
      - 127.0.0.1:5432:5432

In this file we say that we want docker-compose to launch a container using the image "postgres" and forward port 5432 in the host machine to the same port in the container.

Also, we use environment variables to pass the credentials we want the database server to be created with. Now, let's set these environment variables using a .env file (create this file in the project's root):

POSTGRES_USER=myapp
POSTGRES_PASSWORD=123456
POSTGRES_DB=myapp

Docker-compose should read our .env file automatically.

Ensure that you don't commit .env file to the repository, because it has sensitive information. You can add this file to .gitignore:

node_modules
/build
.env

Now, we should be able to launch our local database container using the following command:

docker-compose up

This command creates the necessary Docker setup for the containers defined in docker-compose.yml and launches the containers (in our case, one postgres container). Then, our postgres container starts the PostgreSQL server with the credentials we supplied in docker-compose.yml.

You can stop docker-compose up by focusing the terminal window where you started it and pressing CTRL + C.

Also, you can run docker-compose up in detached mode: docker-compose up -d. This way, the command runs in the background, so you'll be able to continue working with the current terminal window.

To list the containers that were started, run docker-compose ps.

To stop docker-compose up both, in normal and detached (-d) modes, you can run: docker-compose stop in the same directory.

Finally, to destroy the containers run docker-compose down.

You should run docker-compose commands in the same directory where the docker-compose.yml file is located or in a subdirectory (docker-compose looks for the config file in the parent directories as well).

Setting Up TypeORM

First, let's install TypeORM. It depends on a couple of other packages:

yarn add typeorm pg reflect-metadata

Together with TypeORM we install pg, a database client that TypeORM will use to connect to the PostgreSQL database and run the queries.

Also, we install reflect-metadata. TypeORM's API is heavily based on decorators and TypeORM uses this package to parse the decorators.

Next, let's add the configuration. There is a number of ways to configure TypeORM:

Store the configuration in ormconfig.json or ormconfig.js. TypeORM will read these files automatically.
Or pass the configuration object directly when connecting to the database.

In this tutorial, I'll store the configuration in ormconfig.js, because this file is used automatically by TypeORM, not only when connecting to the database within the app, but also when running the TypeORM's CLI commands (like typeorm migration:create or typeorm migration:run).

Now, that we installed TypeORM, let's go ahead and create ormconfig.js in the project's root:

module.exports = {
  type: 'postgres',
  host: process.env.POSTGRES_HOST,
  username: process.env.POSTGRES_USER,
  password: process.env.POSTGRES_PASSWORD,
  database: process.env.POSTGRES_DB,
  port: process.env.POSTGRES_PORT,
  entities: ['src/entities/*.ts'],
};

TypeORM supports a number of databases. Therefore, we use the type setting to inform TypeORM that we will work with postgres.

We use two environment variables that we haven't defined yet: POSTGRES_HOST and POSTGRES_PORT. Let's add them to our .env:

...
POSTGRES_HOST=127.0.0.1
POSTGRES_PORT=5432

We use the entities setting to tell TypeORM where we keep our entity classes. We'll add an entity class later in this tutorial.

Now that the configuration is ready, let's connect to the database. Open src/index.ts and modify it as follows:

import 'reflect-metadata';
import { createConnection } from 'typeorm';
import app from './app';

const port = process.env.PORT || 3000;

const start = async () => {
  await createConnection();

  app.listen(port, () => {
    console.log(`The server is listening on port ${port}`);
  });
};

start().catch(console.error);

We need to import reflect-metadata in a global place in our app, so I decided to import it in index.ts.

Here, we ensure that TypeORM is ready to run the database queries before the application is started. The createConnection function sets up a connection pool. Learn more about it here: https://github.com/typeorm/typeorm/blob/master/docs/connection.md#what-is-connection

If you run the app now, yarn dev, TypeORM should be able to connect to the database if you started it earlier using docker-compose.

Creating, Running, and Reverting Migrations

Let's create a table for users and do it using a migration.

TypeORM includes a CLI for creating and running migrations. But, there is a gotcha. By default the CLI works with .js files only. To use .ts files with TypeORM CLI we have to run the CLI itself using ts-node. So, let's open package.json and create a script for this:

{
  "scripts": {
    "typeorm": "node --require ts-node/register ./node_modules/typeorm/cli.js"
  }
}

Now we can run TypeORM CLI over ts-node using a simple command: yarn typeorm ...

Before creating a migration, let's add a few settings to ormconfig.js:

module.exports = {
  // ...
  migrations: ['db/migrations/*.ts'],
  cli: {
    migrationsDir: 'db/migrations',
  },
};

We use these settings to specify where we'd like to store migrations.

Now let's create a migration for the users table:

yarn typeorm migration:create -n users

This command should have created a migration file in the folder db/migrations. Let's modify this file to create the users table:

import { MigrationInterface, QueryRunner } from 'typeorm';

export class users1617475742590
  implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(
      `
        CREATE TABLE users (
          id SERIAL,
          email VARCHAR(255) NOT NULL,
          name VARCHAR(255) NOT NULL,
          CONSTRAINT unique_users_email UNIQUE (email),
          CONSTRAINT pk_users_id PRIMARY KEY (id)
        );
      `
    );
  }

  public async down(
    queryRunner: QueryRunner
  ): Promise<void> {
    await queryRunner.dropTable('users');
  }
}

A migration has two methods: up and down. The method up is called when you apply the migration and down is called when you revert it.

Now, let's run this migration:

yarn typeorm migration:run

This command applies all migration files from the migrations directory that haven't been applied already. To know if a migration has been applied already or not, TypeORM creates the migrations table to keep track of all migrations that have been applied.

To revert the latest migration, you can run:

yarn typeorm migration:revert

Querying the Database

Let's start by creating an entity class for the users (src/entities/user.ts):

import {
  Column,
  Entity,
  PrimaryGeneratedColumn,
} from 'typeorm';

@Entity('users')
class User {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column({ type: 'varchar', unique: true })
  email!: string;

  @Column({ type: 'varchar' })
  name!: string;
}

export default User;

We should create the entity files in the directory we specified earlier in ormconfig.js using the entities setting:

module.exports = {
  // ...
  entities: ['src/entities/*.ts'],
  // ...
};

Next, let's add a route for creating users to src/app.ts:

import 'express-async-errors';
import { getRepository } from 'typeorm';
import User from './entities/user';
// ...
app.post('/users', async (req, res) => {
  const { email, name } = req.body;

  const user = new User();
  user.email = email;
  user.name = name;

  await getRepository(User).save(user);

  res.status(201).json({
    user: {
      id: user.id,
      email: user.email,
      name: user.name,
    },
  });
});
// ...

I installed express-async-errors for catching and handling errors from async route handlers. Without this package, errors thrown by async route handlers will not be caught and the requests with errors will timeout instead of returning an error code 500 immediately.

Now, let's add a route for getting users:

// src/app.ts
// ...
app.get('/users', async (_req, res) => {
  const userRepo = getRepository(User);
  const users = await userRepo.find({ take: 10 });
  res.json({
    users: users.map((user) => ({
      id: user.id,
      email: user.email,
      name: user.name,
    })),
  });
});
// ...

Adding Relationships

I want to allow a user to create blog posts. One user can have many blog posts and one blog post can have just one user. So, there is a one-to-many relationship between users and posts and many-to-one relationship between posts and users. In this section we'll add the posts table and set up the relationships.

First, let's create a migration for the posts table:

yarn typeorm migration:create -n posts

Now you should see a new migration file in db/migrations. Let's add the schema for the posts to this file:

import { MigrationInterface, QueryRunner } from 'typeorm';

export class posts1617772850315
  implements MigrationInterface {
  public async up(queryRunner: QueryRunner): Promise<void> {
    await queryRunner.query(
      `
        CREATE TABLE posts (
          id SERIAL,
          title VARCHAR(255) NOT NULL,
          user_id INT NOT NULL,
          CONSTRAINT fk_users_posts FOREIGN KEY (user_id) REFERENCES users (id),
          CONSTRAINT pk_posts_id PRIMARY KEY (id)
        );
      `
    );
  }

  public async down(
    queryRunner: QueryRunner
  ): Promise<void> {
    await queryRunner.dropTable('posts');
  }
}

The posts table has a foreign key "user_id" that references "id" in the users table. This defines our one-to-many/many-to-one relationship between users and posts.

Next, let's create an entity class for the posts:

import {
  Column,
  Entity,
  JoinColumn,
  ManyToOne,
  PrimaryGeneratedColumn,
} from 'typeorm';
import User from './user';

@Entity('posts')
class Post {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column({ type: 'varchar' })
  title!: string;

  @Column({ type: 'integer', name: 'user_id' })
  userId!: number;

  @ManyToOne(() => User, (user) => user.posts)
  @JoinColumn({ name: 'user_id' })
  user?: User;
}

export default Post;

Here, we use ManyToOne decorator to declare that the post entity can have only one user.

In the "userId" column declaration I specify the actual name of the "userId" column in the posts table, which is "user_id". TypeORM will use this info to map the user_id column in the posts table to the userId property in the Post entity class.

Next, let's declare the one-to-many relationship from users to posts in the existing User entity class (src/entities/user.ts):

import {
  // ...
  OneToMany,
} from 'typeorm';
import Post from './post';

@Entity('users')
class User {
  // ...

  @OneToMany(() => Post, (post) => post.user)
  posts?: Post[];
}

export default User;

Now, let's run the migration:

yarn typeorm migration:run

Next, let's make it possible for a user to create posts. For this let's add a route handler to src/app.ts:

// ...
app.post('/posts', async (req, res) => {
  const { userId, title } = req.body;

  const user = await getRepository(User).findOne({
    id: userId,
  });

  if (!user) {
    throw new Error('User not found');
  }

  const post = new Post();
  post.title = title;
  post.user = user;

  await getRepository(Post).save(post);

  res.status(201).json({
    post: {
      id: post.id,
      title: post.title,
      user: {
        id: post.user.id,
      },
    },
  });
});
// ...

Finally, I want to show how to fetch all the user's posts through the User entity just to show how the relationships setup works in TypeORM:

app.get('/users/:id/posts', async (req, res) => {
  const { id } = req.params;
  const user = await getRepository(User).findOne({
    where: { id: parseInt(id, 10) },
    relations: ['posts'],
  });

  if (!user) {
    throw new Error('User not found');
  }

  res.json({
    posts: user.posts,
  });
});

By default, TypeORM won't fetch the associated relations. You have to specify which relations you'd like to fetch together with the entity. If you won't add relations: ['posts'] to the findOne options, user.posts will be undefined.

Learn more about different kinds of relationships on the TypeORM's website: Relations

Query Builder

You can build complex SELECT, INSERT, UPDATE, and DELETE queries using a query builder. Have a look at this example:

import { getConnection } from 'typeorm';

// ...

app.get('/users-stats', async (_req, res) => {
  const results = await getConnection()
    .createQueryBuilder()
    .select('user.id', 'userId')
    .addSelect('COUNT(post.id)', 'postsCount')
    .from(User, 'user')
    .innerJoin(Post, 'post', 'post.user_id = user.id')
    // .where('user.role = :role', { role: 'guest' })
    .orderBy('COUNT(post.id)', 'DESC')
    .offset(0)
    .limit(10)
    .groupBy('user.id')
    .getRawMany();
  // or .getMany()

  res.json({
    results: results.map((result) => ({
      userId: result.userId,
      postsCount: Number(result.postsCount),
    })),
  });
});
// ...

Learn more about the query builder here: Select using Query Builder

Raw SQL Queries

Finally, if the query builder doesn't let you build a query that you want, you can run raw SQL queries as well using the EntityManager API.

import { getManager } from 'typeorm';

// ...

type PostsSQLQueryResult = {
  id: number;
  title: string;
  user_id: number;
}[];

app.get('/posts', async (req, res) => {
  const { limit = 10, offset = 0 } = req.query;
  const manager = getManager();
  const rawData: PostsSQLQueryResult = await manager.query(
    'SELECT * FROM posts ORDER BY id DESC LIMIT $1 OFFSET $2',
    [limit, offset]
  );
  res.json({
    posts: rawData.map((row) => ({
      id: row.id,
      title: row.title,
      userId: row.user_id,
    })),
  });
});
// ...

Learn more here: EntityManager API

Useful links

Source code

Concurrency in AWS Lambda

Dmytro Danylov — Wed, 02 Dec 2020 09:50:41 +0000

Introduction

To be able to choose the right tool for a task, it is helpful to understand how the tools you choose from work behind the scenes (so you know what to expect from these tools).

In this article I will briefly explain what happens behind the scenes when we invoke a Lambda function to process an event. Then, I will explain how a Lambda function scales to handle multiple events in parallel (concurrently). Finally, I'll talk about the result of a basic test that I ran to see how a Lambda function handles a burst of traffic.

Lambda Execution Environment

To execute a function Lambda creates an execution environment specifically for that function. It's a temporary, secure and isolated runtime environment that includes the dependencies of the function. And each function has its own execution environment.

To invoke a function Lambda has to set up an execution environment for it. Once the execution environment for the function is ready the function is invoked and the environment is reused for the subsequent invocations of that function for some time.

Execution environments are temporary. When a function is idle for some time, its execution environment is removed. And when the function is needed again in a while to handle another event, the environment is created from scratch. Also, the execution environments are periodically recreated behind the scenes by Lambda to keep them fresh (for example, to ensure that the underlying resources are up to date).

When a function needs to be invoked and there are no execution environments available, Lambda has to set up a new environment. When Lambda creates a new environment instead of reusing an existing one to invoke a function, such case is called cold start.

Concurrency in Lambda

Another important concept that we need to understand is that a single execution environment can process a single event at a time. If there are multiple concurrent events for a function (for example, 100 HTTP requests at a time that need to be processed), Lambda will have to set up multiple execution environments to process those events concurrently.

The number of concurrent function invocations is limited. All Lambda functions in the same AWS account and region share a single concurrency limit. By default the limit is 1000 concurrent invocations per region. You can increase this limit by submitting a request in the Support Center Console.

A Lambda function scales by creating enough execution environments to be able to process the amount of concurrent requests it receives at any given time. The scaling works as follows:

Let's say I have set the total number of concurrent executions in my AWS account to 5000.
Then, a popular news website mentions my product and my function suddenly receives a burst of traffic, and the number of concurrent requests grows rapidly, up to more than 5000 requests.
Lambda will start from 500 to 3000 (this number depends on a region) instances of my function really fast. This is called burst concurrency limit. Let's say, my function is in the US East region and the burst limit is 3000. So, I'd get 3000 instances quickly to handle that burst of traffic.
Once the burst concurrency limit is reached, my function will scale by only 500 instances per minute until my account's concurrency execution limit is reached (until 5000 instances) and no more instances are being created to accommodate new concurrent requests.
If this concurrency limit won't be enough to serve additional requests, those requests are gonna be throttled.
Also, before the account's concurrency limit is reached, the requests for which Lambda won't be able to set up an execution environment on time are gonna be throttled as well.

To test how concurrency works I created a simple API endpoint using the Serverless Framework. It was a Lambda function (1024MB of memory) behind AWS API Gateway. Basically, this function handled HTTP requests at a given endpoint URL. The function looked like this:

module.exports.hello = async () => {
  await new Promise((resolve) => setTimeout(resolve, 1000));

  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Hello World' }),
  };
};

This function takes approximately one second to execute, because of the timeout.

Then, I ran a load test where for the duration of 30 seconds, every second around 100 new virtual users requested the endpoint. And I've set a limit on the amount of concurrent users to no more than 100 users at a time. The results of the test were as follows:

All virtual users finished
Summary report @ 19:52:40(+0000) 2020-11-30
  Scenarios launched:  2737
  Scenarios completed: 2737
  Requests completed:  2737
  Mean response/sec: 87.11
  Response time (msec):
    min: 1021.8
    max: 2057
    median: 1033
    p95: 1146.8
    p99: 1326
  Scenario counts:
    Hello: 2737 (100%)
  Codes:
    200: 2737

The total of 2737 requests have been made. The minimum response time was 1021.8 ms (a warm start) and the maximum was 2057 ms (most probably, a cold start). The average response time was 1033 ms and 95% of all tests took 1146.8 ms or less. So, only a small amount of requests were affected by a cold start.

According to CloudWatch it took 100 concurrent instances of the function to handle these requests. To handle concurrent events Lambda creates multiple execution environments for the function. I was making at most 100 requests concurrently in my test, so Lambda created 100 execution environments to be able to handle those requests. Basically, my function had approximately 100 cold starts. The execution environments were reused most of the time, because there were no more bursts of concurrent requests.

Be careful when load testing your apps, especially serverless apps. If you make a mistake and unexpectedly send a huge amount of requests, you'll incur additional costs that can get quite high and/or you may overload your app such that it won't be able to serve real users.

Finally, I'd like to mention that you can control Lambda concurrency in various ways:

You can change your concurrency limit per account by contacting AWS support
You can reserve concurrency for a specific function
You can provision concurrency for a specific function

Please read Managing concurrency for a Lambda function to learn more.

Useful Resources

A YouTube video: End Cold Starts in Your Serverless Apps with AWS Lambda Provisioned Concurrency. This is a very detailed video about Lambda concurrency.
An informative article about concurrency from AWS Documentation: Invocation Scaling.

Indexed Access Types (Lookup Types) in TypeScript

Dmytro Danylov — Mon, 16 Nov 2020 07:56:35 +0000

Indexed Access Types

In TypeScript you can reuse the type of a property of another type.

interface User {
  id: number;
  name: string;
  address: {
    street: string;
    city: string;
    country: string;
  };
}

In the code above we can reuse the types of the User interface's id and address properties.

Let's say, I need to create a function for updating the address of a user:

function updateAddress(
  id: User['id'],
  address: User['address']
) {}

Instead of using a number to describe the id parameter I described it using the User['id'] type which refers to the type of the id property from the User interface. This type is called index access type or lookup type. And for the address parameter I used the type of the address property.

We can access the types of nested properties as well:

type City = User['address']['city']; // string

And we can get the types of multiple properties at once:

type IdOrName = User['id' | 'name']; // string | number

Of course, I could split the User interface into multiple types and reuse those types instead of using the lookup types:

type UserId = number;

interface UserAddress {
  street: string;
  city: string;
  country: string;
}

interface User {
  id: UserId;
  name: string;
  address: UserAddress;
}

function updateAddress(id: UserId, address: UserAddress) {}

Splitting a large type into multiple types looks fine, as long as these smaller types are going to be reused frequently. There are cases when we need to use a part of a type just once and it doesn't make much sense to move that part into a separate type.

Also, the lookup type is useful when we need to reuse a part of some type that we cannot touch, like, for example, a type from a third-party library.

The keyof Operator

The keyof operator is used to query the names of the properties of a type and represent them as a union (key = property name):

interface User {
  id: number;
  name: string;
}

type UserProperties = keyof User; // "id" | "name"

So, the UserProperties type is a union of properties that are present in the User interface.

Also, the type keyof T is a subtype of string:

let userProperty: UserProperties = 'id';
let someString: string = userProperty; // OK

Assigning keyof T to a string works, but, assigning any string to keyof T doesn't:

userProperty = someString; // Error

Lookup Types + keyof Operator + Generics

Describing Access to Any Property in a Given Object

We can use the lookup type together with the keyof operator, for example, in order to describe a function that reads the value of a property from an object:

function getProperty<T, K extends keyof T>(obj: T, key: K) {
  return obj[key];
}

TypeScript infers the return type of this function to be T[K] and when we will call this function TypeScript will infer the actual type of the property that we're going to read:

let user = { name: 'John Doe', age: 25 };
let name = getProperty(user, 'name'); // string
let age = getProperty(user, 'age'); // number

The name variable is inferred to be a string and age - a number.

Also, TypeScript will produce an error if you try to assign anything other than a "name" or "age" to the key parameter in the getProperty function:

let age = getProperty(user, 'nonexistentProperty'); // Error

Inferring the Type of a Parameter Based on Another Parameter in a Function

A similar pattern is used to describe document.addEventListener in the DOM library included with TypeScript (lib.dom.d.ts):

// I shortened the original declaration
addEventListener<K extends keyof DocumentEventMap>(type: K, listener: (..., ev: DocumentEventMap[K]) => any, ...): void;

This pattern allows TypeScript to infer the type of the event object ev that is passed to the listener callback, based on the type of the event - K. For example, for the event type "click", the event object in the callback should be of type MouseEvent:

document.addEventListener('click', (e) => {
  // e is inferred to be MouseEvent
});

document.addEventListener('keypress', (e) => {
  // e is inferred to be KeyboardEvent
});

This pattern looks useful, so I recreated a simple example:

interface MyMouseEvent {
  x: number;
  y: number;
}

interface MyKeyboardEvent {
  key: string;
}

interface MyEventObjects {
  click: MyMouseEvent;
  keypress: MyKeyboardEvent;
}

function handleEvent<K extends keyof MyEventObjects>(
  eventName: K,
  callback: (e: MyEventObjects[K]) => void
) {
  // ...
}

handleEvent('click', (e) => {
  // e is inferred to be MyMouseEvent
});

I created two types to describe two different event objects: MyMouseEvent and MyKeyboardEvent. Then, I created MyEventObjects type to map event names to the corresponding event objects. And I created a generic function called handleEvent, that allows to register a callback for a specific event.

Then I tried to implement the handleEvent function:

function handleEvent<K extends keyof MyEventObjects>(
  eventName: K,
  callback: (e: MyEventObjects[K]) => void
) {
  if (eventName === 'click') {
    // Here, I expected e to be MyMouseEvent
    callback({ x: 0, y: 0 }); // ERROR
  } else if (eventName === 'keypress') {
    // Here, I expected e to be MyKeyboardEvent
    callback({ key: 'Enter' }); // ERROR
  }
}

Basically, I tried to narrow the parameter of the callback to a more specific type.

When I checked whether the event name is "click", I expected TypeScript to infer the parameter of the callback to be MyMouseEvent, because TypeScript infers the type of this parameter correctly when the handleEvent function is called (check the earlier example).

Basically, inside of the "click" if block I told TypeScript that generic type parameter K is equal to "click" and expected TypeScript to substitute "click" for the parameter K in the declaration of the callback: callback: (e: MyEventObjects["click"]) => void. But, this didn't happen, because TypeScript didn't recognise the relationship between eventName: K and callback: (e: MyEventObjects[K]) => void.

Then, I figured out that TypeScript infers the type of the callback's parameter e to be an intersection(&) of MyMouseEvent and MyKeyboardEvent:

e: MyEventObjects[K]  >>>>  e: MyMouseEvent & MyKeyboardEvent

And it doesn't narrow this type down to a more specialised type after the parameter K becomes known inside of the function.

So, to fix the errors we'd have to use an assertion:

if (eventName === 'click') {
  callback({ x: 0, y: 0 } as MyEventObjects[K]);
} else if (eventName === 'keypress') {
  callback({ key: 'Enter' } as MyEventObjects[K]);
}

And that's how it works, at least at the moment.

Finally, let's have a look at the following code:

type JustObjects = MyEventObjects[keyof MyEventObjects]; // MyMouseEvent | MyKeyboardEvent

Here, JustObjects is a union of the types of the values of MyEventObjects interface.

A Practical Introduction to Using Redux with React

Dmytro Danylov — Tue, 04 Aug 2020 10:20:28 +0000

Introduction
What is Redux?
What is the State?
How to Modify the State?
Unidirectional Data Flow
Setting Up Redux in a React App
Using React Hooks to Read the State
Using React Hooks to Dispatch Actions
Using "json-server" for the Local Fake API
Async Actions
Multiple Reducers
Feature Folders and Ducks
Using the "Ducks" Pattern in Our Example App
Using Redux Toolkit (Recommended)

Introduction

In this tutorial I'd like to explain briefly what is Redux and how to set it up in a React project.

This tutorial would be useful for you if you've learned React already and would like to learn how Redux can help managing the app's state globally.

Many of us have heard that the Redux code we have to write using original Redux API is a little verbose (e.g., initializing store, creating actions and reducers, etc). Therefore, the team behind Redux created a package called Redux Toolkit which makes developing Redux apps easier and more fun. Moreover, using Redux Toolkit for writing Redux logic is official recommended approach.

In this tutorial we'll start with the basics, then we'll build a simple app using just Redux (without the toolkit). Finally, we'll add Redux Toolkit to improve our Redux code.

So, let's get started.

What is Redux?

Redux is a state management library. Commonly, it is used together with React, but it can be used with other view libraries too.
Redux helps us to keep the state of the whole app in a single place.

What is the State?

I would describe "state" as the data that is used to render the app at any given time. We keep this data in a JavaScript object. For example, in a simple app which renders a list of muffins, the state could look like this:

let state = {
  muffins: [
    { name: 'Chocolate chip muffin' },
    { name: 'Blueberry muffin' }
  ]
}

How to Modify the State?

To modify the state from within a component we dispatch an action:

// SomeComponent.js
dispatch({
  type: 'muffins/add',
  payload: {
    muffin: { name: 'Banana muffin' },
  },
});

Dispatching actions is the only way to change the state.

An action is represented by an object with the type property. The type property is the action's name. You can add any other property to this object (this is how you pass the data to reducer).

There are no formal rules as to how you should name your actions. Give your actions descriptive and meaningful names. Don't use ambiguous names, like receive_data or set_value.

It is a common practice to share actions through the action creator functions. Such functions create and return the action objects. We store action creators outside of the component files (e.g., src/redux/actions.js). This makes it easy to see what actions are available in the app and to maintain and reuse them.

// actions.js
export function addMuffin(muffin) {
  return {
    type: 'muffins/add',
    payload: { muffin },
  };
}

// SomeComponent.js
dispatch(addMuffin({ name: 'Banana muffin' }));

Once an action is dispatched, Redux calls the reducer with the previous state and the dispatched action object as the arguments. Reducer is a function which decides how to change the state according to a given action. We create this function and register it with Redux.

This is how a basic reducer looks like:

let initialState = {
  muffins: [
    { id: 1, name: 'Chocolate chip muffin' },
    { id: 2, name: 'Blueberry muffin' },
  ],
};

function reducer(state = initialState, action) {
  switch (action.type) {
    case 'muffins/add':
      let { muffin } = action.payload;
      return { ...state, muffins: [...state.muffins, muffin] };
    default:
      return state;
  }
}

When this reducer identifies the muffins/add action it adds the given muffin to the list.

IMPORTANT. The reducer copies the previous state object instead of mutating it. The rule is that the state must be immutable (read-only). The reducer should copy any object that it would like to change before changing it. This includes the root object and any nested objects.

We need to copy the state for Redux to be able to check (using shallow checking) if the state returned by the reducer is different from the previous state. Check this for more details about shallow checking: How do shallow and deep equality checking differ?. It is important to follow this rule for Redux to respond to our state changes correctly. Also, when using redux with react-redux this helps react-redux to decide which components should be re-rendered when the state changes.

The other important rule is that the reducer function should be pure. Given the same input it should always produce the same output without causing any side effects. A side affect is something that reads or changes the environment around the function. Examples of side effects are reading or writing a global variable, running a network request, etc. This rule helps us reproduce the look and behavior of the app given a particular state object.

Also, both of these rules make sure that Redux's time travel feature works properly with our app. Time travel allows us to easily undo actions and then apply them again. This helps a lot with debugging using Redux DevTools.

To summarize:

Our app has a single state.
To change this state we dispatch actions.
The reducer function handles the dispatched actions and changes the state accordingly.
Redux and react-redux check the state returned by the reducer for changes using shallow checking.

Unidirectional Data Flow

So, we've learned the following about Redux: we dispatch an action from the view layer (e.g., a React component), reducer gets this action and changes the state accordingly, the store notifies the view layer about the state change and the view layer renders the app according to the latest state. And the cycle repeats when we need to change the state again.

So, the data in a Redux app flows in a single way circular pattern. It is also called a unidirectional data flow. This is how we could represent it using a diagram:

This pattern makes it easier to understand how a Redux app works.

Setting Up Redux in a React App

In this post we will be building a simple app which lists a number of muffins.

I've initialized a basic React app using create-react-app:

npx create-react-app my-react-redux

I removed extra code and rendered a hard-coded list of muffins. This is what I've got: View on GitHub

Let's go ahead and store the muffins in the state.

First, let's install "redux" and "react-redux" packages:

npm i -S redux react-redux

Remember, Redux can be used with other view libraries. So we need the "react-redux" package to connect React components with Redux store.

Next, we should prepare the Redux store. The store is an object which keeps the app's state and provides the API for working with it. It allows us to:

read the state
dispatch actions to change the state
and subscribe/unsubscribe to/from the state changes

IMPORTANT. Your app should have a single store.

Let's go ahead and set up the store for our example app.

Let's keep the Redux functionality in the folder called "redux":

mkdir src/redux

Let's write the store initialization code in the file src/redux/store.js:

// File: src/redux/store.js
import { createStore } from 'redux';

const initialState = {
  muffins: [
    { id: 1, name: 'Chocolate chip muffin' },
    { id: 2, name: 'Blueberry muffin' },
  ],
};

const reducer = (state = initialState, action) => {
  switch (action.type) {
    default:
      return state;
  }
};

const store = createStore(reducer);

export default store;

We use the createStore function from the redux package to create the store. When the store initializes, it obtains the initial state by calling our reducer function with undefined for the state and a dummy action (e.g., reducer(undefined, { type: 'DUMMY' })).

Now we should provide the store to the React components.
For this, we open the src/index.js and wrap the <App /> component into the <Provider /> component from the "react-redux" package:

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import './index.css';
import App from './components/App';
import store from './redux/store';

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

The <Provider /> component provides the store to the child component tree using React context. Now we can use the React hooks or the connect function from the "react-redux" package to get the state and dispatch actions from any component in the tree.

View the code on GitHub

Using React Hooks to Read the State

Instead of hard-coding the muffin list in the "Muffins.js", let's use the useSelector hook from "react-redux" to select the muffins array from the state.

// file: src/redux/selectors.js
export const selectMuffinsArray = (state) => state.muffins;

// file: src/components/Muffins/Muffins.js
import React from 'react';
import { useSelector } from 'react-redux';
import { selectMuffinsArray } from '../../redux/selectors';

const Muffins = () => {
  const muffins = useSelector(selectMuffinsArray);

  return (
    <ul>
      {muffins.map((muffin) => {
        return <li key={muffin.id}>{muffin.name}</li>;
      })}
    </ul>
  );
};

export default Muffins;

The useSelector hook expects a selector function as the first argument. We create selector functions to provide a reusable API for selecting different parts of the state.

We use the state in many components. If we select things from the state directly (e.g. let muffins = state.muffins) and at some point we change the structure of the state (e.g., state.muffins becomes state.muffins.items) we'd have to edit each component where we access the state properties directly. Using selector functions we can change the way we select the state in a single place (in our example, it is the "selectors.js" file).

View the code on GitHub

Using React Hooks to Dispatch Actions

Let's add a "Like" button to each muffin in the list.

First, let's add the "likes" property to the state (number of likes).

// file: src/redux/store.js
const initialState = {
  muffins: [
    { id: 1, name: 'Chocolate chip muffin', likes: 11 },
    { id: 2, name: 'Blueberry muffin', likes: 10 },
  ],
};

Next, let's render the number of likes and the "Like" button.

// file: src/components/Muffins/Muffins.js
<li key={muffin.id}>
  {muffin.name} <button>Like</button> <i>{muffin.likes}</i>
</li>

Now, let's get the dispatch function in the component using the useDispatch hook from "react-redux".

// file: src/components/Muffins/Muffins.js
import { useSelector, useDispatch } from 'react-redux';
// ...
const dispatch = useDispatch();

Let's define an action for the "Like" button.

// File: src/redux/actions.js
export const likeMuffin = (muffinId) => ({
  type: 'muffins/like',
  payload: { id: muffinId },
});

Next, let's create the "click" event handler for the "Like" button:

// {"lines": "2,4-9,12"}
// file: src/components/Muffins/Muffins.js
import { likeMuffin } from '../../redux/actions';

// ...

{
  muffins.map((muffin) => {
    const handleLike = () => {
      dispatch(likeMuffin(muffin.id));
    };
    return (
      <li key={muffin.id}>
        {muffin.name} <button onClick={handleLike}>Like</button>{' '}
        <i>{muffin.likes}</i>
      </li>
    );
  });
}

If we click this button, nothing happens, because we didn't create a reducer for the action that is dispatched (muffins/like).

So, let's go ahead and reduce this action.

// {"lines": "4-14"}
// file: src/redux/store.js
const reducer = (state = initialState, action) => {
  switch (action.type) {
    case 'muffins/like':
      const { id } = action.payload;
      return {
        ...state,
        muffins: state.muffins.map((muffin) => {
          if (muffin.id === id) {
            return { ...muffin, likes: muffin.likes + 1 };
          }
          return muffin;
        }),
      };
    default:
      return state;
  }
};

It's important NOT to mutate the state. So, I copy the state object, copy the muffins array (the map method returns a new array). Finally, I copy only the muffin which is being changed. I don't touch the other muffins to signify that they do not change.

Now, if we click the "Like" button, the muffins/like action is dispatched and the reducer changes the state accordingly. The number of likes of the chosen muffin increments.

View the code on GitHub

Using "json-server" for the Local Fake API

"json-server" is a fake REST API server which is really easy to set up. We can use it to mock API endpoints while working on a front end app. I'd like to use this server for the examples in this post. So let me show you how to install and run it.

To install:

npm i -D json-server

To tell the server what data it should serve we create a JSON file. Let's call it db.json.

{
  "muffins": [
    { "id": 1, "name": "Chocolate chip muffin", "likes": 11 },
    { "id": 2, "name": "Blueberry muffin", "likes": 10 }
  ]
}

Now let's open package.json and add the script which will start this server:

// {"lines": "2"}
"scripts": {
  "json-server": "json-server --watch db.json --port 3001"
}

To run it:

npm run json-server

The server should start on http://localhost:3001.

To stop it, focus on the terminal window where you started it and press CTRL + C.

We can use the following routes ("json-server" generates them by looking at db.json)

GET /muffins
POST /muffins
PUT /muffins/{id}
DELETE /muffins/{id}

View the code on GitHub

Async Actions

Please check the section Using "json-server" for the Local Fake API.

Usually, we run network requests to get and edit the data. Let's see how to do it the Redux way.

By default, Redux allows us to dispatch an action only in the form of an object with the type property.

However, Redux allows us to alter the way it dispatches actions using a middleware function. One such function is called "redux-thunk".

Let's install and register this middleware function with Redux.

npm i -S redux-thunk

// file: src/redux/store.js
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
// ...
const store = createStore(reducer, applyMiddleware(thunk));

applyMiddleware is a utility function which takes a list of middleware functions and groups them in a single middleware function which we pass to createStore as the second argument.

Also, let's empty the muffins array in the initial state, because we are going to load muffins from the fake API.

// file: src/redux/store.js
const initialState = {
  muffins: [],
};

"redux-thunk" allows us to dispatch not only objects, but also functions:

dispatch((dispatch, getState) => {
  let state = getState();
  // do something async and
  dispatch(/* some action */);
});

The thunk function gets the original dispatch function as the first argument and the getState function as the second argument.

So, what we can do with a thunk function is, for example, to fetch the data from the network and when the data is ready we can dispatch an action object with this data, so reducer can add this data to the state.

Let's create the actions.js file and add the async action creator function for loading muffins.

// file: src/redux/actions.js
export const loadMuffins = () => async (dispatch) => {
  dispatch({
    type: 'muffins/load_request',
  });

  try {
    const response = await fetch('http://localhost:3001/muffins');
    const data = await response.json();

    dispatch({
      type: 'muffins/load_success',
      payload: {
        muffins: data,
      },
    });
  } catch (e) {
    dispatch({
      type: 'muffins/load_failure',
      error: 'Failed to load muffins.',
    });
  }
};

A thunk function can be either sync or async. We can dispatch multiple actions in this function. In our example we dispatch the muffins/load_request action to signify that the request starts. We can use this action to show a spinner somewhere in the app. Then, when the request succeeds we dispatch the muffins/load_success action with the fetched data. Finally, if the request fails, we dispatch the muffins/load_failure action to show the error message to the user.

Now, let's create the reducers for these actions.

// file: src/redux/store.js
const reducer = (state = initialState, action) => {
  switch (action.type) {
    // ...
    case 'muffins/load_request':
      return { ...state, muffinsLoading: true };

    case 'muffins/load_success':
      const { muffins } = action.payload;
      return { ...state, muffinsLoading: false, muffins };

    case 'muffins/load_failure':
      const { error } = action;
      return { ...state, muffinsLoading: false, error };
    // ...
  }
};

Let's dispatch the loadMuffins action in the Muffins component, when it mounts.

// file: src/components/Muffins/Muffins.js
import React, { useEffect } from 'react';
import { loadMuffins } from '../../redux/actions';

// ...

const dispatch = useDispatch();

useEffect(() => {
  dispatch(loadMuffins());
}, []);

We are loading muffins in the effect hook, because dispatching an action is a side effect.

Finally, let's handle the loading and error states.

Create the following selector functions:

// file: src/redux/selectors.js
export const selectMuffinsLoading = (state) => state.muffinsLoading;
export const selectMuffinsLoadError = (state) => state.error;

And render the loading and error messages:

// file: src/components/Muffins/Muffins.js
const muffinsLoading = useSelector(selectMuffinsLoading);
const loadError = useSelector(selectMuffinsLoadError);

// ...

return muffinsLoading ? (
  <p>Loading...</p>
) : loadError ? (
  <p>{loadError}</p>
) : muffins.length ? (
  <ul>
    {muffins.map((muffin) => {
      // ...
    })}
  </ul>
) : (
  <p>Oh no! Muffins have finished!</p>
);

Now, let's check if we did everything correctly.

We should run the local "json-server" and the app.

In one terminal window:

npm run json-server

And in the other:

npm start

In the browser you should see the list of muffins which is, now, fetched from the fake API server.

View the code on GitHub

Multiple Reducers

Usually, in a large app, state won't be that simple. It will look like a huge tree of data.

The reducer function will become bloated.

So, it's a good idea to split the reducer into multiple smaller reducers where each reducer handles only a part of the state.

For example, in order to handle the state from the picture above, it would be a good idea to create 3 reducers:

const muffinsReducer = (state = initialMuffinsState, action) => {
  // ...
};
const notificationsReducer = (state = initialNotificationsState, action) => {
  // ...
};
const cartReducer = (state = initialCartState, action) => {
  // ...
};

and combine them using the utility function called combineReducers:

const rootReducer = combineReducers({
  muffins: muffinsReducer,
  notifications: notificationsReducer,
  cart: cartReducer,
});

const store = createStore(rootReducer);

combineReducers creates a root reducer function which calls each sub reducer when the action is dispatched and combines the parts of the state they return into a single state object:

{
  muffins: ...,
  notifications: ...,
  cart: ...
}

Combining reducers makes it easy to modularize the reducer logic.

Feature Folders and Ducks

The Redux documentation recommends structuring Redux functionality as feature folders or ducks.

Feature Folders

Instead of grouping all actions and reducers by the type of code (for example, all the app's actions in actions.js and all reducers in reducers.js), we could group them by feature.

Let's say there are two features: "users" and "notifications". We could keep their actions and reducers in separate folders. For example:

redux/
  users/
    actions.js
    reducers.js
  notifications/
    actions.js
    reducers.js
  store.js

Ducks

The "ducks" pattern says that we should keep all Redux logic (actions, reducers, selectors) for a specific feature in its own file. For example:

redux/
  users.js
  notifications.js
  store.js

Using the "Ducks" Pattern in Our Example App

In the app we've got different Redux functionality around muffins. We can group this functionality into a duck. In other words, let's just move everything related to mufffins into a JavaScript file and call it src/redux/muffins.js.

Let's move the actions, selectors and the reducer to this file:

export const likeMuffin = (muffinId) => ({
  type: 'muffins/like',
  payload: { id: muffinId },
});

export const loadMuffins = () => async (dispatch) => {
  dispatch({
    type: 'muffins/load_request',
  });

  try {
    const response = await fetch('http://localhost:3001/muffins');
    const data = await response.json();

    dispatch({
      type: 'muffins/load_success',
      payload: {
        muffins: data,
      },
    });
  } catch (e) {
    dispatch({
      type: 'muffins/load_failure',
      error: 'Failed to load muffins.',
    });
  }
};

export const selectMuffinsArray = (state) => state.muffins;
export const selectMuffinsLoading = (state) => state.muffinsLoading;
export const selectMuffinsLoadError = (state) => state.error;

const initialState = {
  muffins: [],
};

const reducer = (state = initialState, action) => {
  switch (action.type) {
    case 'muffins/like':
      const { id } = action.payload;
      return {
        ...state,
        muffins: state.muffins.map((muffin) => {
          if (muffin.id === id) {
            return { ...muffin, likes: muffin.likes + 1 };
          }
          return muffin;
        }),
      };

    case 'muffins/load_request':
      return { ...state, muffinsLoading: true };

    case 'muffins/load_success':
      const { muffins } = action.payload;
      return { ...state, muffinsLoading: false, muffins };

    case 'muffins/load_failure':
      const { error } = action;
      return { ...state, muffinsLoading: false, error };

    default:
      return state;
  }
};

export default reducer;

Now, in the src/redux/store.js, let's create the root reducer using the combineReducers function:

// {"lines": "6-10"}
// File: src/redux/store.js
import { createStore, applyMiddleware, combineReducers } from 'redux';
import thunk from 'redux-thunk';
import muffinsReducer from './muffins';

const rootReducer = combineReducers({
  muffins: muffinsReducer,
});

const store = createStore(rootReducer, applyMiddleware(thunk));

export default store;

Now, the app's state looks like this:

{
  muffins: {
    muffins: [],
    muffinsLoading: boolean,
    error: string
  }
}

Since the structure of the state has changed, to make the app work, we should update the parts of the code where we read the state. Luckily, we use selector functions to select parts of the state object instead of working with the state object directly. So, we only have to update the selector functions:

// File: src/redux/muffins.js
export const selectMuffinsState = (rootState) => rootState.muffins;

export const selectMuffinsArray = (rootState) =>
  selectMuffinsState(rootState).muffins;

export const selectMuffinsLoading = (rootState) =>
  selectMuffinsState(rootState).muffinsLoading;

export const selectMuffinsLoadError = (rootState) =>
  selectMuffinsState(rootState).error;

Finally, let's update the import statements:

// {"lines": "6,7"}
// File: src/components/Muffins/Muffins.js
import {
  selectMuffinsArray,
  selectMuffinsLoading,
  selectMuffinsLoadError,
} from '../../redux/muffins';
import { likeMuffin, loadMuffins } from '../../redux/muffins';

That's it! We used the "ducks" pattern to move the Redux functionality around managing the muffins state into a single file.

View the code on GitHub

Using Redux Toolkit (Recommended)

The Redux team recommends to use the Redux Toolkit for writing Redux logic. This toolkit contains a set of utilities that make it easier to write Redux apps. Pure Redux is a little verbose, so this toolkit wraps the complex code you had to write using pure Redux in utilities that help you writing less code. Also, it includes additional libraries that are commonly used with Redux.

Let's improve our Redux code using Redux Toolkit.

The toolkit is distributed as a separate package. Let's install it:

npm i -S @reduxjs/toolkit

Then, let's open src/redux/store.js and update it to initialize the store using Redux Toolkit.

// src/redux/store.js
import { configureStore } from '@reduxjs/toolkit';
import muffinsReducer from './muffins';

const store = configureStore({
  reducer: {
    muffins: muffinsReducer,
  },
});

export default store;

We replaced createStore, applyMiddleware, combineReducers, and redux-thunk with a single function, configureStore. This function wraps the Redux createStore, adds default configuration and provides additional functionality for configuring the store.

configureStore applies the thunk middleware by default, so we don't have to set it up manually and there is no need to install the redux-thunk package as well. Also, this function combines reducers for us, so we no longer need Redux combineReducers. We add the reducers for handling different parts of the state to the reducer object.

To learn more about configureStore please visit it's documentation.

Redux Toolkit includes wonderful functionality for helping us with creating reducers. There is a function called createReducer(initialState, caseReducers). The first argument is the initial state and the second argument is an object that maps action types to reducer functions that handle that actions.

Let's go ahead and use createReducer to create our reducer. In src/redux/muffins.js please replace the old reducer code with the new:

import { createReducer } from '@reduxjs/toolkit';

// ...

const reducer = createReducer(initialState, {
  'muffins/like': (state, action) => {
    const { id } = action.payload;

    return {
      ...state,
      muffins: state.muffins.map((muffin) => {
        if (muffin.id === id) {
          return { ...muffin, likes: muffin.likes + 1 };
        }
        return muffin;
      }),
    };
  },

  'muffins/load_request': (state) => {
    return { ...state, muffinsLoading: true };
  },

  'muffins/load_success': (state, action) => {
    const { muffins } = action.payload;
    return { ...state, muffinsLoading: false, muffins };
  },

  'muffins/load_failure': (state, action) => {
    const { error } = action;
    return { ...state, muffinsLoading: false, error };
  },
});

This looks better already, it's more declarative and each action is handled by its own reducer function compared to the switch statement where the scope is shared between case's.

We shouldn't stop here, we can improve this reducer even further with the help of createReducer.

Earlier in this post I've told that when changing the state a reducer function should not mutate the previous state. That's why in our reducer we always return a new state object and copy the parts of the state we're changing, creating new references for Redux to be able to quickly compare previous state with the new state to find out if the state changed.

In the createReducer function we no longer need to copy the state object, we can mutate it directly. This function applies Immer to turn our mutation to an immutable update. Let's turn our difficult to read immutable state update code to the mutable easy to read version which will be handled by Immer behind the scenes to make it immutable:

const reducer = createReducer(initialState, {
  'muffins/like': (state, action) => {
    const muffinToLike = state.muffins.find(
      (muffin) => muffin.id === action.payload.id
    );
    muffinToLike.likes += 1;
  },

  'muffins/load_request': (state) => {
    state.muffinsLoading = true;
  },

  'muffins/load_success': (state, action) => {
    state.muffinsLoading = false;
    state.muffins = action.payload.muffins;
  },

  'muffins/load_failure': (state, action) => {
    state.muffinsLoading = false;
    state.error = action.error;
  },
});

This code is much more readable, isn't it? However, there are a few gotchas. It's important that when modifying the state in a reducer you either mutate the state argument or return a new state. You can't do both. Also, please read about pitfalls of using Immer in its documentation.

IMPORTANT. You can mutate the state only inside the createReducer and createSlice functions. I'll talk about createSlice later.

Please have a look at the createReducer docs (https://redux-toolkit.js.org/api/createReducer) to learn more about it.

Now let's check what can we do with our actions. Redux Toolkit provides a helper function for generating action creators called createAction.

Let's generate our likeMuffin action using createAction:

// src/redux/muffins.js
import { createReducer, createAction } from '@reduxjs/toolkit';

// export const likeMuffin = (muffinId) => ({
//   type: 'muffins/like',
//   payload: { id: muffinId },
// });
export const likeMuffin = createAction('muffins/like', (muffinId) => {
  return { payload: { id: muffinId } };
});

createAction takes two arguments. The first one is the action type and it's required. The second argument is a so-called prepare function which you can use to accept arguments from the resulting action creator and attach these arguments as additional data to the action object. The prepare function is optional.

The actions created by createAction have their toString methods overridden such that they return the action type. So, if we place our new likeMuffin action creator where JS expects a string, likeMuffin will be turned into the "muffins/like" string through the likeMuffin.toString() method. This means that we can use our new action creator as action type key in our reducer:

// src/redux/muffins.js
const reducer = createReducer(initialState, {
  // 'muffins/like': (state, action) => {
  [likeMuffin]: (state, action) => {
    // ...
  },
  // ...
});

The other action we have - loadMuffins - is a thunk action. For generating thunk action creators Redux Toolkit provides a helper function called createAsyncThunk. Let's use this function to redo our loadMuffins thunk action:

// src/redux/muffins.js
export const loadMuffins = createAsyncThunk('muffins/load', async () => {
  const response = await fetch('http://localhost:3001/muffins');
  const muffins = await response.json();
  return { muffins };
});

createAsyncThunk takes the action type as the first argument and the callback function as the second argument. The callback function should return a promise. Whatever the promise resolves with will be added to the action object's payload property.

createAsyncThunk returns a thunk action creator. When we dispatch this action creator, based on the promise we return from the callback, it dispatches the following lifecycle actions: pending (muffins/load/pending), fulfilled (muffins/load/fulfilled) and rejected (muffins/load/rejected). The types of these lifecycle actions are available as the properties of the action creator (e.g., loadMuffins.pending).

So, let's use these types in our reducer instead of our own muffins/load_request, muffins/load_success, muffins/load_failure:

// src/redux/muffins.js
const reducer = createReducer(initialState, {
  // ...
  [loadMuffins.pending]: (state) => {
    state.muffinsLoading = true;
  },

  [loadMuffins.fulfilled]: (state, action) => {
    state.muffinsLoading = false;
    state.muffins = action.payload.muffins;
  },

  [loadMuffins.rejected]: (state) => {
    state.muffinsLoading = false;
    state.error = 'Failed to load muffins.';
  },
});

Finally, we can group the Redux functionality related to a single feature (like muffins) into a so-called "slice" (or "duck"). To accomplish this we'll use the createSlice function. Let's open src/redux/muffins.js and reorganize our Redux logic using createSlice:

// src/redux/muffins.js
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit';

// ...

// Selectors...

// ...

const muffinsSlice = createSlice({
  name: 'muffins',
  initialState,
  reducers: {
    likeMuffin: {
      reducer: (state, action) => {
        const muffinToLike = state.muffins.find(
          (muffin) => muffin.id === action.payload.id
        );
        muffinToLike.likes += 1;
      },
      prepare: (muffinId) => {
        return { payload: { id: muffinId } };
      },
    },
  },
  extraReducers: {
    [loadMuffins.pending]: (state) => {
      state.muffinsLoading = true;
    },

    [loadMuffins.fulfilled]: (state, action) => {
      state.muffinsLoading = false;
      state.muffins = action.payload.muffins;
    },

    [loadMuffins.rejected]: (state) => {
      state.muffinsLoading = false;
      state.error = 'Failed to load muffins.';
    },
  },
});

export const { likeMuffin } = muffinsSlice.actions;

export default muffinsSlice.reducer;

This change looks a little confusing at first. So, let's discuss it part by part.

First, we no longer need createReducer and createAction, because createSlice creates the reducer function and basic (non thunk) actions for us.

createSlice expects the name of the slice, we can name it after the feature we create the slice for, like muffins. The name is used as a prefix for action types that are created by createSlice from the reducers option.

Then, we provide the initialState of the slice.

Next, createSlice gives two options for creating reducers: reducers and extraReducers.

We use reducers to create both, actions and corresponding reducers. The reducers option is an object which maps an action type to a corresponding reducer function. createSlice takes this map and generates actions and reducers from it. If an action doesn't need to keep any data apart from the action type we can create an action and reducer like this:

createSlice({
  name: 'someSliceName',
  reducers: {
    helloWorld: (state) => {
      state.message = 'Hello World';
    },
  },
});

This creates the action creator function called helloWorld which returns the following action object: { type: 'someSliceName/helloWorld' }. If we need to add additional data to the action object, like some payload, we can add the prepare function:

createSlice({
  name: 'someSliceName',
  reducers: {
    helloWorld: {
      reducer: (state, action) => {
        state.message = `Hello, ${action.payload.name}`;
      },
      prepare: (name) => {
        return { payload: { name } };
      },
    },
  },
});

This example creates the action creator helloWorld(name) which takes the name argument and returns the following action object: { type: 'someSliceName/helloWorld', payload: { name } }.

We can use extraReducers to create reducers for existing actions and thunk actions. Basically, you can import an action from another slice and handle it here. In our example we use extraReducers to handle the lifecycle actions of the loadMuffins thunk action.

The difference between reducers and extraReducers is that createSlice does not auto-generate action creators for reducers in extraReducers.

Both, reducers and extraReducers allow us to mutate the state argument, because both of them will be passed to createReducer which uses Immer to turn our state mutation to an immutable update.

createSlice returns an object with the following structure:

{
  name: name of the slice
  reducer: reducer function that combines reducers from `reducers` and `extraReducers` options
  actions: action creators extracted from the `reducers` option
  caseReducers: reducer functions from the `reducers` option
}

In our example we extract the action creators from the muffinsSlice.actions and export them separately to make it easier to import and use them in other components. And we export the reducer function by default.

So, with the help of Redux Toolkit our code became shorter and more declarative which makes it easier to read and understand it.

So, you've completed the Redux + React intro tutorial. I tried to make it as short and as simple as I could. I recommend you to check the Redux Essentials Series in the Redux docs and the Redux Toolkit website. Both of them cover a lot of details, best practices and parts about Redux and Redux Toolkit that I haven't covered in this tutorial.

Thank you very much for reading my tutorial.

View the final code on GitHub

TypeScript: the skipLibCheck Option Explained

Dmytro Danylov — Fri, 17 Jul 2020 18:47:51 +0000

--skipLibCheck forces the compiler to skip type checking all declaration files.

Commonly, a program includes many dependencies, which may include large declaration files, which usually are checked by their authors already. But, the compiler spends a lot of time checking these declarations again anyway, so, large programs may take a lot of time to compile. So, the idea behind this option is to shorten the compile time by avoiding type checks of these declarations. But, when you use this option there are things you should note.

In this post, I'm going to explain skipLibCheck in detail and show you a few code examples.

What skipLibCheck does?

Enabling the skipLibCheck option instructs the compiler to skip type checking of all declaration (*.d.ts) files. This includes the *.d.ts files from the node_modules directory and your custom *.d.ts files:

But this doesn't mean TypeScript won't check your code against the declaration files (it doesn't check the declaration files as a whole). When you use a type from a declaration file, TypeScript still checks your code against that type as far as it can trace that type in that declaration file.

An Example of Using skipLibCheck

Suppose, we have a project with 2 files (app.ts and custom.d.ts) and skipLibCheck is enabled:

// FILE: ./custom.d.ts
declare function greetSomeone(name: string): string;

In custom.d.ts we declare a function called greetSomeone in the global scope.

// FILE ./app.ts
greetSomeone('Jack');

In app.ts we call greetSomeone and this call is type checked:

With skipLibCheck TypeScript still checks your code against the types in the declaration (.d.ts) files, but it does not check the declaration files themselves.

For example, if we make various mistakes in our custom.d.ts file, TypeScript won't spot them:

import { NonExistentType } from 'non-existent-module';

declare global {
  function greetSomeone(name: NonExistentType): string;
}

I clearly made a mistake here. I imported a non existent type from a non existent module and assigned it to the name argument. TypeScript didn't spot this, but it still did its job to check the greetSomeone call in app.ts as far as it could:

TypeScript replaced the NonExistentType type with any when checking our app.ts file. The third party declaration files (e.g., the @types project) are treated the same.

What are the benefits of skipLibCheck?

First, skipping the process of type checking the third party declaration files (which can be huge) reduces the compile time. For example, to compile a simple Express.js app with skipLibCheck disabled takes around 3 seconds on my machine, while enabling skipLibCheck shortens the compile time to around 1 second. I have used the compiler's --extendedDiagnostics option to get the compile time.

Second, the type declarations of a third party package may have been written with the compiler options that differ from your project's tsconfig.json. For example, in your project you may have enabled the strict option, while a third party package may have been compiled with the strict option disabled. If this happens your project may fail to compile, because a third party type declaration may have been written without following the strict guidelines.

Since, skipLibCheck hides errors in declaration files, it is suggested to enable this option only for reducing the build time of your app if necessary. Also, if some third party package's declarations produce compile errors, this option would be useful if you can't fix the errors on your side (for example, by updating the involved packages).

So, that's it for this post. Hope you found it useful. If so, please share it.

Useful Resources

Using the Serverless Framework With AWS

Dmytro Danylov — Thu, 18 Jun 2020 17:33:29 +0000

What is the Serverless Framework

Serverless Framework consists of two parts: the open source CLI and the dashboard.

In this post I'll talk about the CLI. The CLI helps you with the following:

You can describe your application's resources (functions and other cloud resources, like a database) using the config file called serverless.yml
The Serverless Framework bundles your code, creates necessary cloud resources (according to serverless.yml) and deploys your code to the cloud

Setting Up a Serverless API Project with TypeScript

To start with Serverless Framework you need to install their CLI. There are multiple ways to do this. Please check the Getting Started page and pick the way which is most appropriate for you.

I installed it using NPM: npm i -g serverless.

The fastest way to create a serverless project is to use the serverless create command choosing one of the available project templates. To see the list of available templates run serverless create --help.

Since I'm using AWS, Node.js, and TypeScript, I've chosen the aws-nodejs-typescript template:

serverless create --template aws-nodejs-typescript --path my-serverless-ts-app

This command generates the initial code for the app in the folder called my-serverless-ts-app.

I've got the following files in the generated folder:

handler.ts
serverless.yml
package.json
tsconfig.json
webpack.config.js

The project uses Webpack to compile and bundle the functions. In particular, it uses the serverless-webpack plugin. To compile TypeScript the project uses ts-loader Webpack loader.

The serverless.yml contains the configuration of the project and the necessary AWS resources.

The provider section contains the settings of the cloud provider you would like to deploy your functions to (AWS in our case):

provider
  name: aws
  runtime: nodejs12.x
  apiGateway:
    minimumCompressionSize: 1024 # Enable gzip compression for responses > 1 KB
  environment:
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1

The functions section contains the information about the functions you would like to deploy:

functions:
  hello:
    handler: handler.hello
    events:
      - http:
          method: get
          path: hello

We use the handler setting to specify the path to the actual function within our project's root directory. Here, we have got the function called "hello" which is processed by the hello function which is exported from ./handler.ts. The http part specifies that this function should be invoked by an http GET request with the path /hello. Basically, when it will be deployed it will be available through a URL which would look something like this:
https://tu4zgp10ol.execute-api.your-region.amazonaws.com/some-stage/hello.

The custom section is used to configure plugins and to set some custom settings which you will be able to reference in other parts of your serverless.yml config.

To run the code you should install the dependencies:

npm install

Now you can invoke the hello function locally using the invoke local command:

serverless invoke local --function hello

Deploying the Project to AWS

To be able to deploy your functions to AWS you need to grant the necessary access credentials to the Serverless Framework. For this you need to do the following:

1. Create an AWS account if you do not have one already. Sign up for an AWS account

2. Create the necessary access credentials for the Serverless Framework. There are a few ways to do this: Use the Serverless Framework Dashboard to set up an AWS Access Role or Create AWS access keys.

For starting out with Serverless, I have used the second way. I have created an IAM user, enabled Programmatic access for this user and attached the AdministratorAccess permission.

After creating the user take a note of the API key and secret temporarily. You will need them next.

Please note, that the AdministratorAccess permission grants the Serverless Framework administrative access to your account. But, for security, it is recommended to limit the access to your account as much as possible. It is better to determine the AWS resources which your app is going to use and grant the necessary access permissions for that resources only (you can create custom permissions for an IAM user).

3. Configure Serverless Framework to use your AWS API key and secret. There are two ways to do this:

Export the keys as environment variables in the shell where you run the Serverless CLI.
Use AWS Profiles.

I prefer the 2nd way.

Once you configure the credentials you will be ready to deploy the project to AWS. In this example Serverless will use the following AWS services:

S3 - for uploading and storing the project's code
CloudFormation - for provisioning the necessary resources
AWS Lambda - for hosting the functions
API Gateway - for routing the HTTP requests to the corresponding functions

Later in this article I'm explaining how the deployment process works.

Before deploying please learn about the costs. The AWS Lambda, CloudFormation, API Gateway, and S3 services have generous free tier, so most probably the setup I am describing in this article won't cost anything in the beginning.

To deploy the functions to the cloud we use the deploy command:

serverless deploy

This command outputs the deployment information. The most interesting part is the endpoints section. This is where we find the list of HTTP endpoints we can use to invoke the deployed functions:

endpoints:
  GET - https://tu4zgp10ol.execute-api.us-east-1.amazonaws.com/dev/hello

By default Serverless deploys to the us-east-1 region. The dev word in the endpoint URL is the default deployment stage.

A stage is a named reference to a particular deployment of your project. I have written more about stages in the article called A Practical Introduction to AWS Lambda (search for the word stage).

You can set the region and the stage either in the serverless.yml file:

provider:
  name: aws
  stage: somestage
  region: us-west-2

or in the deploy command:

serverless deploy --stage production --region eu-central-1

Once the project is deployed to AWS, and under the condition that you do not modify anything about this project directly through the AWS Console, you should be able to remove it from AWS by running the remove command:

serverless remove

Also, like in the deploy command, you can remove the app in the specific region and/or stage:

serverless remove --stage dev --region us-east-1

I'd recommend to remove this example deployment to avoid possible costs.

Useful Links:

What Happens Behind the Scenes While Deployment

A high level overview. When you hit the deploy command the Serverless Framework creates a CloudFormation template based on your serverless.yml file. It packages your functions into ZIP files, creates a CloudFormation stack in your account and uploads the functions using the AWS S3 service. You can find more details about this process in the AWS - Deploying - How It Works guide.

CloudFormation is a service which allows you to describe and provision a set of AWS resources (lambda functions, databases, etc) for your application using a YAML or JSON template. Basically, you create a template where you describe the resources you want and how to configure them. You feed your template to CloudFormation and it provisions the resources according to this template grouping them into an entity called CloudFormation Stack. You can inspect your CloudFormation stacks in the AWS Console: AWS CloudFormation.

CloudFormation allows you to describe your application's infrastructure as code. Your template code becomes the single source of truth for your application's resources. You can review all the resources used by your app by looking into a single file. You can track the changes to your infrastructure by version-contolling your code. All of this helps to simplify the maintenance of your applications.

A Practical Introduction to AWS Lambda

Dmytro Danylov — Wed, 20 May 2020 07:33:38 +0000

In this tutorial I'm writing about what AWS Lambda is, how it works, its pricing model, and how to use AWS API Gateway with Lambda to handle HTTP requests. In the end I'll show how to create a Lambda function to process HTTP requests from an API Gateway route.

What is the AWS Lambda?

AWS Lambda is a service which allows you to run your code in the cloud in response to some event without provisioning a server. You write some code and tell AWS when to execute it. For example, you can run your code in response to an HTTP request (from the API Gateway service), or process a file when it is uploaded to S3, or run some code when you create a row in DynamoDB, and other use cases. I'm really happy that AWS Lambda provides automatic scaling, it launches as many copies of your code as needed to satisfy the amount of incoming requests (events). This means you can use lambda for web applications without worrying what to do when the traffic grows. Well, you should still worry about the billing, because you pay money according to your usage. Basically, you can start from $0 if there are no events to process (e.g., no visitors), but be cautious, because when your traffic grows your bills grow as well.

Useful Resources

How It Works?

First, you create a function for a supported runtime, like Node.js, Python, Ruby, Java, Go, or .NET. Then, you post this function to the AWS Lambda service which invokes it in response to some event (trigger). When your function is invoked, AWS Lambda spins up an execution context for your function and executes it in this context.

The execution context is a temporary runtime environment initialized with the dependencies of your code (like database connections). AWS Lambda maintains the execution context for some time to be able to reuse it for subsequent invocations of the function.

Initializing the context takes time and resources, so AWS Lambda tries to reuse it for your function as much as it can. However, you shouldn't assume that AWS Lambda automatically reuses the context for subsequent function invocations. Various conditions may cause AWS Lambda to initialize a new context.

Let's have a look at a Lambda function example (for the Node.js runtime):

const db = createConnection();

export const handler = async (event, context) => {
  const posts = await db.getPosts();
  return posts;
};

When invoked, the async handler function receives two arguments from the runtime:

event is the object which contains some data from the invoker.
context is the object which contains the data about the invocation, function, and execution environment.

This function returns a promise which resolves to the value of the posts variable.

I initialized the database connection outside of the handler function to be able to reuse the connection between the function calls, because establishing a connection on each request is costly.

Also, the discussion about using databases in Lambda (or serverless overall) would take another blog post. You don't want to establish a traditional database connection (e.g., MySQL connection) on every function call, because this will exhaust your database server. So, the simplest and quite naive approach is to share a connection between function invocations like in the above example to reduce the load on the database. A more sophisticated approach would be to use Amazon RDS Proxy to handle connections to relational databases. Or, you can look at using databases which work nicely with serverless out of the box, like DynamoDB, FaunaDB, or Amazon Aurora.

Useful Resources

Pricing (as of March, 2020)

You pay only for what you use. So, it's great for running a side project (e.g., a web or a mobile app). You pay nothing until you get to some threashold of code invocations.

You pay for the number of requests of your code and the time it takes for your code to execute, the duration.

It costs approximately $0.20 per 1M requests and $0.0000166667 for every GB-second. The GB-second unit measures how long your code is running on the machine taking into account the machine's memory (RAM). The more memory you choose for running your code the more you pay for a GB-second.

X GB-seconds = machine's memory in gigabytes (e.g., 1GB) * X seconds

Now that we know the prices, let's calculate how much would we pay if our code got 1M requests and each request lasted for half a second, and this code ran on a 512MB machine:

We should convert 512MBs to GBs: 512MB / 1024MB = 0.5GB.
Let's calculate how long all the requests lasted: 1,000,000 requests * 0.5 seconds = 500,000 seconds.
Let's calculate the number of GB-seconds: 500,000 seconds * 0.5GB = 250,000 GB-seconds.
Finally, let's calculate the money:

For requests: $0.20 / 1M requests * 1M requests = $0.20
For GB-seconds: $0.0000166667 * 250,000 Gb-seconds = approx. $4.17

So, the total cost would be: $0.20 + $4.17 = $4.37

And, good news, AWS Lambda has a free usage tier. The first 1M requests per month and the first 400,000 GB-seconds per month are free.

Useful Resources

AWS API Gateway

Earlier I've mentioned that a Lambda function is invoked in response to an event. One of such events may be an HTTP request from AWS API Gateway.

By combining Lambda functions with API Gateway we can build a scalable API. API Gateway is a service which allows you to receive HTTP and WebSocket requests and route them for processing to some backend endpoint, like a Lambda function, or another AWS service like EC2, or some other existing HTTP endpoint.

You can choose one of the following options to build your API:

REST API. This option offers various features for building RESTful APIs.
HTTP API. This option is cheaper than the REST API, but it offers only the API proxy functionality.
WebSocket API. This option offers persistent connections over the WebSocket protocol. You can use it to build chat apps and real-time dashboards.
REST API Private. It's a REST API which is accessible only from a VPC.

API Gateway is a paid service. The pricing differs based on the service you choose: HTTP API, REST API, or WebSocket API. Please check the pricing page for more details.

Useful resources

Creating the Lambda Function

I assume you already have an AWS account.

Go to the AWS management console, choose a region and search for Lambda.

Open the Lambda dashboard and click Create function and fill in the function name (e.g., "hello-world") and choose the runtime (I chose Node.js 12.x):

Click Create function.

Once AWS finishes creating your function it should redirect you to your function's dashboard. Here you can edit the code and various settings, like the function's role, the execution environment's memory, and other settings. You can edit your function's permissions to allow it to access other AWS services.

This is how the initial code of my function looks like:

exports.handler = async (event) => {
  // TODO implement
  const response = {
    statusCode: 200,
    body: JSON.stringify('Hello from Lambda!'),
  };
  return response;
};

I'll leave it like this.

Creating the API Route

Search for the API Gateway service in the AWS Console.

Go to the service dashboard and click Create API. Select HTTP API and click Build. Fill in the API name (e.g., "hello-world") and click Next.

You'll get to the Configure routes step. We'll add a route later. Click Next. Then, you'll get to the Define stages step. Keep the defaults and click Next. Finally, you'll get to the Review and create step. Review your selections and click Create.

Once AWS creates your API, it should redirect you to your brand new API's dashboard.

Now, let's create a route. In the sidebar, click Routes. On the Routes page, click Create. Choose GET for the method and enter "/hello-world" for the path:

Click Create.

Now let's attach the lambda function we created earlier to this route. Select the GET method under the "/hello-world" route and click Attach integration:

Then, click Create and attach an integration. In the Integration with section, choose Lambda function. In the integration details section select the Lambda function you created earlier ("hello-world"). And click Create.

So far you've created the route and attached your "hello-world" lambda to this route. Now to be able to call this route you should deploy the API. Your changes to the API won't get online until you deploy them.

Before you deploy your API for the first time, you should create the stage you'd like to deploy to. A stage is a named reference to a particular deployment of your API. You can create multiple stages, like dev, test, prod, beta, etc. For example, you can demo a new version of your API to a client by deploying it to a stage called beta.

So, let's create the stage for production naming it prod. In the sidebar, click Stages, click Create. Enter prod for the name and click Create.

Finally, in the upper right corner click Deploy. Select prod for the stage and describe the changes somehow (e.g, "Initial deployment"). And click Deploy to stage.

In the Stage details block, you'll find the Invoke URL. This is the base URL of the API you deployed:

Open this URL in the browser and add the path of the route you've created earlier ("/hello-world"):

The endpoint should display the reponse of your "hello-world" lambda function.

Finally, do not forget to remove both the example function and the API you've created by following this post to keep your account neat.

So, that's it for now. We created a simple API endpoint which is handled by a Lambda function.

In the next blog post I'll explain how to create this setup using the Serverless framework.

Useful Resources

Deploying a REST API in Amazon API Gateway

DEV Community: Dmytro Danylov

A Guide to Handling Date and Time for Full Stack JavaScript Developers

Table of contents

Introduction

Date formats

Time zones

Unix timestamp

The Date object

Calculating the difference between dates

Formatting the date

Time zone on the back end

Storing dates in the database

MySQL

PostgreSQL

DynamoDB

MongoDB

Conclusion

Useful Resources

Getting Started with TypeORM

What is TypeORM

ORM Patterns

Active Record VS Data Mapper

Adding TypeOrm to an Express Project

Launching a Local Database Server Using Docker Compose

Setting Up TypeORM

Creating, Running, and Reverting Migrations

Querying the Database

Adding Relationships

Query Builder

Raw SQL Queries

Useful links

Concurrency in AWS Lambda

Introduction

Lambda Execution Environment

Concurrency in Lambda

Useful Resources

Indexed Access Types (Lookup Types) in TypeScript

Indexed Access Types

The keyof Operator

Lookup Types + keyof Operator + Generics

Describing Access to Any Property in a Given Object

Inferring the Type of a Parameter Based on Another Parameter in a Function

A Practical Introduction to Using Redux with React

Table of Contents

Introduction

What is Redux?

What is the State?

How to Modify the State?

Unidirectional Data Flow

Setting Up Redux in a React App

Using React Hooks to Read the State

Using React Hooks to Dispatch Actions

Using "json-server" for the Local Fake API

Async Actions

Multiple Reducers

Feature Folders and Ducks

Feature Folders

Ducks

Using the "Ducks" Pattern in Our Example App

Using Redux Toolkit (Recommended)

TypeScript: the skipLibCheck Option Explained

What skipLibCheck does?

An Example of Using skipLibCheck

What are the benefits of skipLibCheck?

Useful Resources

Using the Serverless Framework With AWS

What is the Serverless Framework

Setting Up a Serverless API Project with TypeScript

Deploying the Project to AWS

Useful Links:

What Happens Behind the Scenes While Deployment

A Practical Introduction to AWS Lambda

What is the AWS Lambda?

Useful Resources

How It Works?

Useful Resources

Pricing (as of March, 2020)

Useful Resources

AWS API Gateway

Useful resources