Manuel Salinardi's blog

Fastify & Typescript: with the new Node.js flag --experimental-strip-types

Manuel Salinardi — Tue, 01 Oct 2024 15:12:26 GMT

Read the article in italian language

Since Node.js version v22.6.0, a new experimental flag has been introduced:

This flag allows us to run a .ts file directly with Node.js without needing external libraries or compiling to JavaScript first, using the "type stripping" technique.

To use this new flag you need to use a Node.js version equal to or greater than v22.6.0

In this article I will be using Node.js 22.8.0

--experimental-strip-types in Node.js

Let's create a file, for example node-typescript.ts

interface Person {
    name: string
    surname: string
}

const manuel: Person = {
    name: 'Manuel',
    surname: 'Salinardi'
} 

console.log(`Hello ${manuel.name} ${manuel.surname}`)

Let's try to run it with node:

node node-typescript.ts

And boom!

interface Person {
          ^^^^^^

SyntaxError: Unexpected identifier 'Person'
    at wrapSafe (node:internal/modules/cjs/loader:1469:18)
    at Module._compile (node:internal/modules/cjs/loader:1491:20)
    at Module._extensions..js (node:internal/modules/cjs/loader:1691:10)
    at Module.load (node:internal/modules/cjs/loader:1317:32)
    at Module._load (node:internal/modules/cjs/loader:1127:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:217:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:166:5)
    at node:internal/main/run_main_module:30:49

Wow what a nice error, and rightly so because "interface" does not exist in Javascript but is a Typescript feature.

This is where the new experimental flag comes into play, allowing us to run Typescript files directly with Node.js.

node --experimental-strip-types node-typescript.ts

And now as output we will see:

Hello Manuel Salinardi
(node:98118) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

Wow it works!

We also see a warning that we are using an experimental flag.

--experimental-strip-types in Fastify

Let’s create the Fastify project

We use fastify-cli to create the Fastify project.

npx fastify-cli generate fastify-type-stripping --lang=ts --esm

Let's go into the "fastify-type-stripping" folder we just created and install the dependencies

npm install

Now let's launch the newly created server

npm start

If all goes well we should see output like this:

{"level":30,"time":1725951422786,"pid":8786,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://127.0.0.1:3000"}
{"level":30,"time":1725951422787,"pid":8786,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://[::1]:3000"}

Let’s use --experimental-strip-types

fastify-cli generated this package.json:

{
  "type": "module",
  "name": "fastify-type-stripping",
  "version": "1.0.0",
  "description": "This project was bootstrapped with Fastify-CLI.",
  "main": "app.ts",
  "directories": {
    "test": "test"
  },
  "scripts": {
    "test": "npm run build:ts && tsc -p test/tsconfig.json && FASTIFY_AUTOLOAD_TYPESCRIPT=1 node --test --experimental-test-coverage --loader ts-node/esm test/**/*.ts",
    "start": "npm run build:ts && fastify start -l info dist/app.js",
    "build:ts": "tsc",
    "watch:ts": "tsc -w",
    "dev": "npm run build:ts && concurrently -k -p \"[{name}]\" -n \"TypeScript,App\" -c \"yellow.bold,cyan.bold\" \"npm:watch:ts\" \"npm:dev:start\"",
    "dev:start": "fastify start --ignore-watch=.ts$ -w -l info -P dist/app.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "fastify": "^5.0.0",
    "fastify-plugin": "^5.0.0",
    "@fastify/autoload": "^6.0.0",
    "@fastify/sensible": "^6.0.0",
    "fastify-cli": "^7.0.1"
  },
  "devDependencies": {
    "@types/node": "^22.1.0",
    "c8": "^10.1.2",
    "ts-node": "^10.4.0",
    "concurrently": "^9.0.0",
    "fastify-tsconfig": "^2.0.0",
    "typescript": "^5.2.2"
  }
}

Let's analyze the package.json start script:

"start": "npm run build:ts && fastify start -l info dist/app.js"

The "start" script consists of two commands:

npm run build:ts
fastify start -l info dist/app.js

So we see that it first runs the "build:ts" script:

"build:ts": "tsc"

"build:ts" runs the command "tsc", which converts the TypeScript code into JavaScript according to the settings found in the tsconfig.json file, which in our case is:

{
  "extends": "fastify-tsconfig",
  "compilerOptions": {
    "outDir": "dist",
    "sourceMap": true,
    "moduleResolution": "NodeNext",
    "module": "NodeNext",
    "target": "ES2022",
    "esModuleInterop": true
  },
  "include": ["src/**/*.ts"]
}

As we can see, there's the property "outDir": "dist", which tells the compiler to put the compilation output, that is, the generated JavaScript files, in the "dist" folder.

Then the command fastify start -l info dist/app.js is executed, which starts our server from the dist/app.js file autogenerated by the TypeScript compiler.

So we see that every time we start the server, there's always this intermediate step of converting TypeScript files to JavaScript. Then the server is actually started from the JavaScript files.

Let's launch the server without Typescript compilation

Let's try using the new Node.js feature --experimental-strip-types to directly launch the server with the TypeScript source code without first converting the files to JavaScript.

We'll proceed with trial and error and fix any issues we encounter.

Attempt 1: Initial State

Let's start by just removing the compilation and launching the server directly with the TypeScript file and enjoy the explosion:

"start": "fastify start -l info src/app.ts"

> fastify-type-stripping@1.0.0 start
> fastify start -l info src/app.ts

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/src/app.ts
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:217:9)
    at defaultGetFormat (node:internal/modules/esm/get_format:243:36)
    at defaultLoad (node:internal/modules/esm/load:123:22)
    at async ModuleLoader.load (node:internal/modules/esm/loader:567:7)
    at async ModuleLoader.moduleProvider (node:internal/modules/esm/loader:442:45)
    at async ModuleJob._link (node:internal/modules/esm/module_job:106:19) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

Boom!!!

We have an error telling us the .ts file is not supported, but we saw that we can add the new Node.js flag --experimental-strip-types for this.

But where?

Attempt 2: Passing the --experimental-strip-types flag

The --experimental-strip-types flag needs to be passed to the node executable, but we are launching the server with:
fastify start -l info src/app.ts. In this case, we can use the environment variable: NODE_OPTIONS which allows us to pass Node.js options like this:

"start": "NODE_OPTIONS='--experimental-strip-types' fastify start -l info src/app.ts"

 *  Executing task: source ~/.zshrc && npm run start 


> fastify-type-stripping@1.0.0 start
> NODE_OPTIONS='--experimental-strip-types' fastify start -l info src/app.ts

(node:57588) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
file:///Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/src/app.ts:2
import AutoLoad, {AutoloadPluginOptions} from '@fastify/autoload';
                  ^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Named export 'AutoloadPluginOptions' not found. The requested module '@fastify/autoload' is a CommonJS module, which m
ay not support all module.exports as named exports.                                                                                CommonJS modules can always be imported via the default export, for example using:

import pkg from '@fastify/autoload';
const {AutoloadPluginOptions} = pkg;

    at ModuleJob._instantiate (node:internal/modules/esm/module_job:171:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:254:5)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:482:26)
    at async requireServerPluginFromPath (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/fastify-c
li/util.js:83:22)                                                                                                                      at async runFastify (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/fastify-cli/start.js:115:1
2)                                                                                                                                 
 *  The terminal process "/bin/zsh '-l', '-c', 'source ~/.zshrc && npm run start'" terminated with exit code: 1.

Wow, the error has changed!

Now we see that the flag --experimental-strip-types was correctly recognized because we have this warning:

(node:57588) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

But there is an error with the plugin @fastify/autoload:

SyntaxError: Named export 'AutoloadPluginOptions' not found. The requested module '@fastify/autoload' is a CommonJS module, which m
ay not support all module.exports as named exports.

There is something wrong with an import in our src/app.ts file:

import AutoLoad, {AutoloadPluginOptions} from '@fastify/autoload';

This is due to the behavior of the type stripping flag --experimental-strip-types. If we import a TypeScript type without explicitly using the keyword “type,” Node.js will treat it as a regular value, causing a runtime error, as explained in more detail here: https://nodejs.org/docs/latest-v22.x/api/typescript.html#type-stripping.

Attempt 3: Using “import type” for TypeScript types

To ensure we correctly import TypeScript types with “import type” so that type stripping can properly remove them, we add a TypeScript compiler setting: verbatimModuleSyntax to our file:

tsconfig.json

{
  "extends": "fastify-tsconfig",
  "compilerOptions": {
    "outDir": "dist",
    "sourceMap": true,
    "moduleResolution": "NodeNext",
    "module": "NodeNext",
    "target": "ES2022",
    "esModuleInterop": true,
    "verbatimModuleSyntax": true
  },
  "include": ["src/**/*.ts"]
}

Now we will see the import errors directly from our editor:

So let's go fix all the errors:

src/app.ts

import AutoLoad, { type AutoloadPluginOptions } from '@fastify/autoload';
import { type FastifyPluginAsync } from 'fastify';

src/routes/root.ts

import { type FastifyPluginAsync } from 'fastify'

src/routes/example/index.ts

import { type FastifyPluginAsync } from 'fastify'

src/plugins/sensible.ts

import sensible, { type FastifySensibleOptions } from '@fastify/sensible'

Now that we have solved all the import problems let's try to launch the server and cross our fingers.

 *  Executing task: source ~/.zshrc && npm run start 


> fastify-type-stripping@1.0.0 start
> NODE_OPTIONS='--experimental-strip-types' fastify start -l info src/app.ts

(node:24423) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.js:148
    throw new Error(`@fastify/autoload cannot import ${isHook ? 'hooks ' : ''}plugin at '${file}'. To fix this error compile TypeScript to JavaScrip
t or use 'ts-node' to run your app.`)                                                                                                                         ^

Error: @fastify/autoload cannot import plugin at '/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/src/plugins/sensible.ts'. To fi
x this error compile TypeScript to JavaScript or use 'ts-node' to run your app.                                                                         at handleTypeScriptSupport (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.j
s:148:11)                                                                                                                                               at processFile (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.js:124:3)
    at processDirContents (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.js:101
:7)                                                                                                                                                     at buildTree (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.js:41:9)
    at async findPlugins (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/lib/find-plugins.js:14:3
)                                                                                                                                                       at async autoload (/Users/manuelsalinardi/coding/blogs/fastify/fastify-type-stripping/node_modules/@fastify/autoload/index.js:20:22)

Node.js v22.8.0

 *  The terminal process "/bin/zsh '-l', '-c', 'source ~/.zshrc && npm run start'" terminated with exit code: 1.

Boom! Oh no another error!

The error comes from the @fastify/autoload module and it tells us:
To fix this error, compile TypeScript to JavaScript or use 'ts-node' to run your app.

It is a check done by @fastify/autoload. To disable it, we need to start the server with the environment variable: FASTIFY_AUTOLOAD_TYPESCRIPT

Attempt 4: FASTIFY_AUTOLOAD_TYPESCRIPT

Let's also add the environment variable: FASTIFY_AUTOLOAD_TYPESCRIPT to the "start" script.

"start": "NODE_OPTIONS='--experimental-strip-types' FASTIFY_AUTOLOAD_TYPESCRIPT=1 fastify start -l info src/app.ts"

 *  Executing task: source ~/.zshrc && npm run start 


> fastify-type-stripping@1.0.0 start
> NODE_OPTIONS='--experimental-strip-types' FASTIFY_AUTOLOAD_TYPESCRIPT=1 fastify start -l info src/app.ts

(node:36950) ExperimentalWarning: Type Stripping is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
{"level":30,"time":1727709779182,"pid":36950,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://127.0.0.1:3000"}
{"level":30,"time":1727709779183,"pid":36950,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://[::1]:3000"}

Wow, it finally works!

Now we can run our server directly from the TypeScript source code without needing to compile it anymore.

We can do the same for the "test" script in package.json and remove the "ts-node" library from "devDependencies" because we can do it natively in Node.js thanks to the new --experimental-strip-types flag.

How to Customize the Fastify Logger

Manuel Salinardi — Fri, 02 Aug 2024 08:35:47 GMT

read the article in italian language

Intro

Fastify uses pino as its logger, one of the most performant loggers for Node.js.

So generally, to customize the Fastify logger, you apply the same concepts to customize pino, with a few exceptions that we will see in this article.

For this article, Node.js v20.13.1 was used.

Enable the logger

By default, the Fastify logger is disabled. To enable it, simply set it to true when initializing Fastify.

const fastify = Fastify({
  logger: true
})

Let's write the first log

To see the first log example, let's create a simple Fastify project, which we will use for all the other examples in this article.

Let's create the Fastify project

Let's create and enter the project folder

mkdir my-logger
cd my-logger

Let's install Fastify in the project

npm install fastify

This is the content of the generated package.json file:

{
  "dependencies": {
    "fastify": "^4.28.1"
  }
}

Let's create the index.js file

// import Fastify
const Fastify = require('fastify')

// initialize Fastify
const fastify = Fastify({
  logger: true // enable the logger (disabled by default)
})

// start logging
fastify.log.info('Hello Log!')

We haven't started any server; we have only initialized Fastify, and this is enough to start logging.

Run the file with the command:

node server

As output, we will get an object similar to this:

{"level":30,"time":1721369918925,"pid":85758,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello World!"}

Let's format it better to analyze it:

{
   "level":30, // 30 represents the level of information due from: fastify.log.info
   "time":1721369918925, // Unix time in milliseconds ( epoch time )
   "pid":85758, // process id (equivalent to process.pid)
   "hostname":"Manuels-MacBook-Pro.local", // the host name of the operating system. ( equivalent to require('os').hostname() ) 
   "msg":"Hello World!" // the string we logged
}

We can see from our simple log call:

fastify.log.info('Hello Log!')

Only "msg" is actually what we wrote; all the other fields were added by Pino and will be included with every call to the logger.

Customize the Logger

We have seen that by default, when we make a call to the logger, a JSON object is logged where our message is placed as the value of the "msg" field.

But Pino also adds the fields:

"level"
"time"
"pid"
"hostname"

In this section, we will see how to customize them one by one.

level

Before customizing the "level" field, let's see how it works.

In Pino, there are different log levels:

For each level, there is a corresponding method:

const Fastify = require('fastify')

const fastify = Fastify({
  logger: true
})

fastify.log.fatal('Hello fatal!')
fastify.log.error('Hello error!')
fastify.log.warn('Hello warn!')
fastify.log.info('Hello info!')
fastify.log.debug('Hello debug!')
fastify.log.trace('Hello trace!')

The code above will generate the following output:

{"level":60,"time":1722405654790,"pid":57113,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello fatal!"}
{"level":50,"time":1722405654790,"pid":57113,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello error!"}
{"level":40,"time":1722405654790,"pid":57113,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello warn!"}
{"level":30,"time":1722405654790,"pid":57113,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello info!"}

But there's something strange, because from the code we called the logger 6 times, but only 4 were generated?

"Hello fatal!"
"Hello error!"
"Hello warn!"
"Hello info!"

Missing are:

"Hello debug!"
"Hello trace!"

Where did they go?

Pino associates a numeric value to each level:

"fatal" = 60
"error" = 50
"warn" = 40
"info" = 30
"debug" = 20
"trace" = 10

Which we can see in the "level" field of the generated logs.

By default, logs below level 30, or "info", are discarded.

To change this default and see logs of all levels, you need to set the logger level field like this:

const fastify = Fastify({
  logger: {
    level: 'trace'
  }
})

Now we see that all 6 logs are there:

{"level":60,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello fatal!"}
{"level":50,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello error!"}
{"level":40,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello warn!"}
{"level":30,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello info!"}
{"level":20,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello debug!"}
{"level":10,"time":1722406770355,"pid":57832,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello trace!"}

Now that we understand how the "level" field works, let's see how to customize it:

const fastify = Fastify({
  logger: {
    formatters: {
      level (label, number) {
        // these fields will be replaced by the default "level" field
        return {
          myLevel: `${label}-${number}`,
          levelName: label,
          levelNumber: number 
        }
      }
    }
  }
})

Now the generated logs will be in this format:

{"myLevel":"fatal-60","levelName":"fatal","levelNumber":60,"time":1722576879835,"pid":90770,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello fatal!"}
{"myLevel":"error-50","levelName":"error","levelNumber":50,"time":1722576879835,"pid":90770,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello error!"}
{"myLevel":"warn-40","levelName":"warn","levelNumber":40,"time":1722576879835,"pid":90770,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello warn!"}
{"myLevel":"info-30","levelName":"info","levelNumber":30,"time":1722576879835,"pid":90770,"hostname":"Manuels-MacBook-Pro.local","msg":"Hello info!"}

As we can see from the logs, now instead of the "level" field we find 3 more:

"myLevel"
"levelName"
"levelNumber

time

You can customize the time field by setting the "timestamp" field as follows:

const Fastify = require('fastify')
const pino = require('pino')

const fastify = Fastify({
  logger: {
    timestamp: pino.stdTimeFunctions.isoTime, // convert from epoch time to ISO time
  }
})

fastify.log.info('Hello info!')

{
   "level":30,
   "time":"2024-07-18T06:48:52.040Z", // ISO Time
   "pid":19929,
   "hostname":"Manuels-MacBook-Pro.local",
   "msg":"Hello info"
}

Pino provides us with the following functions for formatting the "timestamp":

pino.stdTimeFunctions.epochTime: Milliseconds since Unix epoch (Default)
pino.stdTimeFunctions.unixTime: Seconds since Unix epoch
pino.stdTimeFunctions.nullTime: Clears timestamp property (Used when timestamp: false)
pino.stdTimeFunctions.isoTime: ISO 8601-formatted time in UTC

From the official documentation: Pino stdTimeFunctions

pid e hostname

To customize the "pid" and "hostname" fields you need to customize the bindings.

Bindings are additional data that can be associated with a logger to be included in all logs generated by that logger. This data is used to enrich the log information without having to manually specify this information each time a log call is made.

By default Pino logger adds in the bindings: "pid" and "hostname", so to remove them and add fields to our liking we have to modify the bindings in this way:

const Fastify = require('fastify')
const os = require('os')

const fastify = Fastify({
  logger: {
    formatters: {
      bindings: (bindings) => {
        return { 
          osMachine: os.machine(),
          osType: os.type()
        };
      },
    },
  }
})

fastify.log.info('Hello info!')

{
   "level":30,
   "time":1721283756521,
   "osMachine":"arm64",
   "osType":"Darwin",
   "msg":"Hello info!"
}

We see that "pid" and "hostname" are gone, but in their place are "osMachine" and "osType".

Instead of replacing "pid" and "hostname" we can also keep them and add fields like this:

const fastify = Fastify({
  logger: {
    formatters: {
      bindings: (bindings) => {
        return { 
          pid: bindings.pid,
          hostname: bindings.hostname,
          osMachine: os.machine(),
          osType: os.type()
        };
      },
    },
  }
})

fastify.log.info('Hello info!')

{
   "level":30,
   "time":1722577623975,
   "pid":91371,
   "hostname":"Manuels-MacBook-Pro.local",
   "osMachine":"arm64",
   "osType":"Darwin",
   "msg":"Hello info!"
}

What is Request Logger?

Up until now we have used the Fastify logger but without ever starting a server. Fastify provides us with a very useful feature called "Request Logger". Now with some practical examples we will see how it works and how to customize it.

Let's create the server

 const Fastify = require('fastify')

const fastify = Fastify({
  logger: true
})

// Declare the route GET /
fastify.get('/', async function handler (request, reply) {
  fastify.log.info('Fastify logger!')
  // note that request.log is used instead of fastify.log
  // unlike the previous examples
  request.log.info('Request logger!')
  return { hello: 'world' }
})

// Start the server on port 3000
fastify.listen({ port: 3000 }, (err) => {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  }
})

In this server we have defined only one GET route "/" which:

log the string "Fastify logger!" (with fastify.log)
log the string "Request logger!" (with request.log)
returns the object as response: { hello: 'world' }

Note that for the first log "fastify.log" is used for the second "request.log". Then we will see with an example what is the difference between the two.

Let's start the server with:

node server

When the server starts we will see some logs automatically generated by Fastify like this:

{"level":30,"time":1720591420640,"pid":69286,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://127.0.0.1:3000"}
{"level":30,"time":1720591420643,"pid":69286,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://[::1]:3000"}

First HTTP call

Now let's try to make an HTTP call, for example with Postman to our newly created single route.

This call generated 4 logs:

// auto generated by Fastify (when receiving an HTTP request)
{
   "level":30,
   "time":1720678823876,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/",
      "hostname":"127.0.0.1:3000",
      "remoteAddress":"127.0.0.1",
      "remotePort":63548
   },
   "msg":"incoming request"
}

// generated by us with fastify.log.info('Fastify logger!')
{
   "level":30,
   "time":1720678823877,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "msg":"Fastify logger!"
}

// generated by us with request.log.info('Request logger!')
{
   "level":30,
   "time":1720678823877,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "msg":"Request logger!"
}

// auto generated by Fastify (when sending an HTTP response)
{
   "level":30,
   "time":1720678823880,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "res":{
      "statusCode":200
   },
   "responseTime":3.9882499873638153,
   "msg":"request completed"
}

There is an intruder among the four logs, can you see it?

The intruder is the second one: "Fastify logger!"

In fact we can see that it is the only one that does not have the "reqId". It does not have the "reqId" because it is the only one that was not generated by the request logger.

For each request Fastify generates a "reqId" useful to connect all the logs to that specific request, in our case:

"incoming request" was generated by Fastify upon receiving the request, and a unique id "reqId":"req-1" was created for this request.
"Fastify logger!" was generated by us with fastify.log.info('Fastify logger!'), but since we used fastify.log, this log will not be part of the request context, so "reqId":"req-1" will not be logged.
"Request logger!" was generated by us with request.log.info('Request logger!'), in this case since we used request.log, this log will be part of the request context so "reqId":"req-1" will be logged.
"request completed" was generated by Fastify when the request was completed and the response was sent.

Disable the request logger

const app = Fastify({
  disableRequestLogging: true, // disable the request logger
  logger: true
})

Simply set disableRequestLogging to true to prevent Fastify from automatically generating logs when receiving the request and sending the response.

Let's see the previous example with the request logger disabled:

 const Fastify = require('fastify')

const fastify = Fastify({
  disableRequestLogging: true, // disable the request logger
  logger: true
})

// declare the route GET /
fastify.get('/', async function handler (request, reply) {
  fastify.log.info('Fastify logger!') // logged
  request.log.info('Request logger!') // it is still logged
  return { hello: 'world' }
})

// start the server on the port 3000
fastify.listen({ port: 3000 }, (err) => {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  }
})

Let's start the server:

node server

{"level":30,"time":1722320649945,"pid":20123,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://[::1]:3000"}
{"level":30,"time":1722320649947,"pid":20123,"hostname":"Manuels-MacBook-Pro.local","msg":"Server listening at http://127.0.0.1:3000"}

Automatic logs at server startup are still generated.

Let's make the HTTP call again with Postman:

{"level":30,"time":1722320840449,"pid":20123,"hostname":"Manuels-MacBook-Pro.local","msg":"Fastify logger!"}
{"level":30,"time":1722320840449,"pid":20123,"hostname":"Manuels-MacBook-Pro.local","reqId":"req-1","msg":"Request logger!"}

We see that now there are only 2 logs, the ones automatically generated by Fastify are missing:

"incoming request"
"request completed"

But the request logger we invoked manually with:

request.log.info('Request logger!')

It is still logged.

Customize the Request Logger

The Request Logger is used in the following cases:

explicitly called with method: "request.log"
automatically called by Fastify on every new HTTP request received
automatically called by Fastify on every HTTP response sent
automatically called by Fastify for every exception thrown inside a route (we haven't seen it yet but we'll see it later)

Let's review them one by one:

// called explicitly with the method: "request.log"
{
   "level":30,
   "time":1720678823877,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "msg":"Request logger!"
}

// automatically called by Fastify with each new HTTP request received
{
   "level":30,
   "time":1720678823876,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/",
      "hostname":"127.0.0.1:3000",
      "remoteAddress":"127.0.0.1",
      "remotePort":63548
   },
   "msg":"incoming request"
}

// automatically called by Fastify with each HTTP response sent
{
   "level":30,
   "time":1720678823880,
   "pid":2292,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "res":{
      "statusCode":200
   },
   "responseTime":3.9882499873638153,
   "msg":"request completed"
}

// automatically called by Fastify on every exception thrown within a route 
{
   "level":50,
   "time":1720766398542,
   "pid":40069,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/",
      "hostname":"127.0.0.1:3000",
      "remoteAddress":"127.0.0.1",
      "remotePort":54858
   },
   "res":{
      "statusCode":500
   },
   "err":{
      "type":"Error",
      "message":"Boom!",
      "stack":"Error: Boom!\n    at Object..."
   },
   "msg":"Boom!"
}

So we can see that the following fields are added from the Request Logger:

"reqId"
"req"
"res"
"err"

In this section we will see how to customize them one by one.

reqId

The first thing we can customize about the request logger is the "reqId", with the method: genReqId

let currentId = 1

const fastify = Fastify({
  logger: true,
  genReqId: (req) => {
    return `my-custom-id-${currentId++}`
  }
})

{
   "level":30,
   "time":1722580879611,
   "pid":93284,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"my-custom-id-1", // generated by our genReqId
   "msg":"Request logger!"
}

req e res

How do we customize the "req" and "res" objects that are logged? For example, add or remove fields?

You use the serializers object for this:

const fastify = Fastify({
  logger: {
    serializers: {
      req (request) { // in req we only want: method and url
        return {
          method: request.method,
          url: request.url,
        };
      },
      res (reply) { // in res we want: method, url and statusCode
        return {
          method: reply.request.method,
          url: reply.request.url,
          statusCode: reply.statusCode
        }
      },
    }
  }
})

// req now contains only method and url
// instead of the default: method, url, hostname, remoteAddress, remotePort
{
   "level":30,
   "time":1720765071638,
   "pid":38418,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/"
   },
   "msg":"incoming request"
}

// this log is not affected by serializers because it contains neither req nor res
{
   "level":30,
   "time":1720765071638,
   "pid":38418,
   "hostname":"Manuels-MacBook-Pro.local",
   "msg":"Fastify logger!"
}

// This log is also not affected by the serializers because it contains neither req nor res
{
   "level":30,
   "time":1720765071638,
   "pid":38418,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "msg":"Request logger!"
}

// now res contains: method, url, statusCode
// instead of the default: statusCode
{
   "level":30,
   "time":1720765071640,
   "pid":38418,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "res":{
      "method":"GET",
      "url":"/",
      "statusCode":200
   },
   "responseTime":2.362499952316284,
   "msg":"request completed"
}

err

If an exception is generated inside a route, Fastify handles it and logs it for us automatically, let's see an example.

Let's throw an exception in our route:

fastify.get('/', async function handler (request, reply) {
  throw Error('Boom!') // this will generate the error
  fastify.log.info('Fastify logger!')
  request.log.info('Request logger!')
  return { hello: 'world' }
})

If we try to make the HTTP call to GET "/" we will see this log generated:

{
   "level":50,
   "time":1720766398542,
   "pid":40069,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/",
      "hostname":"127.0.0.1:3000",
      "remoteAddress":"127.0.0.1",
      "remotePort":54858
   },
   "res":{
      "statusCode":500
   },
   // fastify by default logs an err object, with inside: type, message and stack
   "err":{
      "type":"Error",
      "message":"Boom!",
      "stack":"Error: Boom!\n    at Object.handler (/Users/manuelsalinardi/..."
   },
   "msg":"Boom!"
}

We see that for the error, Fastify generates a log with the object "err" inside.

What if we don't want to log the stack for security reasons?

Again, we can customize the "err" object as we did with the "req" and "res" objects, using the serializers object:

const fastify = Fastify({
  logger: {
    serializers: {
      req (request) {
        return {
          method: request.method,
          url: request.url,
        };
      },
      res (reply) {
        return {
          method: reply.request.method,
          url: reply.request.url,
          statusCode: reply.statusCode
        }
      },
      // here we customize the err object
      err (error) {
        return {
          type: error.name,
          message: error.message,
        }
      }
    }
  }
})

This is the log generator:

{
   "level":50,
   "time":1720767139181,
   "pid":40774,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-1",
   "req":{
      "method":"GET",
      "url":"/"
   },
   "res":{
      "method":"GET",
      "url":"/",
      "statusCode":500
   },
   // now stack is no longer present
   "err":{
      "type":"Error",
      "message":"Boom!"
   },
   "msg":"Boom!"
}

How to add new fields to the Request Logger

Fastify helps us to correlate all the logs of a specific request with each other via the "reqId" field.

We have seen that we can also customize "reqId", but how do we add another field similar to "reqId", but chosen to our liking?

For example, we want to add the "user" field to the request logger, which is passed to us as a parameter in the URL by the person making the HTTP call.

To do this you need to call the Fastify method setChildLoggerFactory:

const Fastify = require('fastify')

const fastify = Fastify({
  logger: true,
})

// adds fields to the Request Logger
fastify.setChildLoggerFactory((logger, bindings, opts, rawReq) => {

  // retrieve user from URL
  const urlString = rawReq.url || ''
  const queryString = urlString.split('?')[1]
  const searchParams = new URLSearchParams(queryString)
  const user = searchParams.get('user')

  // adds user to bindings
  bindings.user = user

  return logger.child(bindings, opts)
})

// declare the route
fastify.get('/', async function handler (request, reply) {
  request.log.info('Request logger!')
  return { hello: 'world' }
})

// start the server
fastify.listen({ port: 3000 }, (err) => {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  }
})

Now let's make an HTTP call with the user query URL parameter:

We will see logs like this:

{
   "level":30,
   "time":1722583839646,
   "pid":95780,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-2",
   "user":"manuel", // new field: user
   "req":{
      "method":"GET",
      "url":"/?user=manuel",
      "hostname":"127.0.0.1:3000",
      "remoteAddress":"127.0.0.1",
      "remotePort":52098
   },
   "msg":"incoming request"
}{
   "level":30,
   "time":1722583839646,
   "pid":95780,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-2",
   "user":"manuel", // new field: user
   "msg":"Request logger!"
}{
   "level":30,
   "time":1722583839648,
   "pid":95780,
   "hostname":"Manuels-MacBook-Pro.local",
   "reqId":"req-2",
   "user":"manuel", // new field: user
   "res":{
      "statusCode":200
   },
   "responseTime":1.4203753471374512,
   "msg":"request completed"
}

Now the Request Logger will have the new field "user" in addition to the "reqId".

Manuel Salinardi

Fastify: Type safe with Type-Providers

Manuel Salinardi — Fri, 28 Jun 2024 14:51:39 GMT

In this article we will see how to automatically type Fastify routes via the JSON schema, using the Type-Provider: TypeBox.

click here to read the article in italian language

Pre-requirements

Node.js v20.13.1

What are Type-Providers?

Documentation: Type-Providers

Type-Providers are a feature only for Fastify projects that use Typescript as a language.

There are different types of Type-Providers, for this article, we will use: TypeBox.

Let's create the Fastify project with Typescript

We open the terminal and type this command:

npx fastify-cli generate my-app --lang=ts

This command will generate a Fastify project with Typescript, using the utility fastify-cli.

Project structure

At this point, we have a project with the following structure:

Contents of the package.json generated

{
  "name": "my-app",
  "version": "1.0.0",
  "description": "This project was bootstrapped with Fastify-CLI.",
  "main": "app.ts",
  "directories": {
    "test": "test"
  },
  "scripts": {
    "test": "npm run build:ts && tsc -p test/tsconfig.json && c8 node --test -r ts-node/register \"test/**/*.ts\"",
    "start": "npm run build:ts && fastify start -l info dist/app.js",
    "build:ts": "tsc",
    "watch:ts": "tsc -w",
    "dev": "npm run build:ts && concurrently -k -p \"[{name}]\" -n \"TypeScript,App\" -c \"yellow.bold,cyan.bold\" \"npm:watch:ts\" \"npm:dev:start\"",
    "dev:start": "fastify start --ignore-watch=.ts$ -w -l info -P dist/app.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@fastify/autoload": "^5.0.0",
    "@fastify/sensible": "^5.0.0",
    "@fastify/type-provider-typebox": "^4.0.0",
    "fastify": "^4.26.1",
    "fastify-cli": "^6.2.1",
    "fastify-plugin": "^4.0.0"
  },
  "devDependencies": {
    "@types/node": "^20.4.4",
    "c8": "^9.0.0",
    "concurrently": "^8.2.2",
    "fastify-tsconfig": "^2.0.0",
    "ts-node": "^10.4.0",
    "typescript": "^5.2.2"
  }
}

Let's install the package.json dependencies

Enter the folder of the newly created "my-app" project and install all the dependencies of the package.json with this command:

npm install

Default route root

fastify-cli has already created 2 routes for us, we can find them inside the files:

src/routes/root.ts
src/routes/example/index.ts

Let's see the generated code for the root route:

import { FastifyPluginAsync } from "fastify"

const example: FastifyPluginAsync = async (fastify, opts): Promise<void> => {
  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })
}

export default example;

This route defines an HTTP GET call that returns a response string: 'this is an example'.

Let's add our route

To make an example as simple as possible, let's add a route that takes text as input and returns the text in uppercase as a response.

import { FastifyPluginAsync } from "fastify"

const example: FastifyPluginAsync = async (fastify, opts): Promise<void> => {

  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })

  fastify.post('/uppercase', async function (request, reply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
  })

}

export default example;

We have added a POST type route, the route expects a single 'text' property in the body and returns an object with a single 'textResult' property.

Typescript error

At this point Typescript will generate an error because initially, the body object is of type unknown, so we need to type the body object.

We could type the body object directly with a Typescript interface. Still, since we will be using a schema to validate the route, we will let Typescript generate the types directly from our schema, to have a single source of truth.

Let's install the type-provider-typebox library

npm i @fastify/type-provider-typebox

Let's create the schema with Typebox

import { Type } from '@fastify/type-provider-typebox'
import { FastifyPluginAsync } from "fastify"

const example: FastifyPluginAsync = async (fastify, opts): Promise<void> => {

  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })

  fastify.post('/uppercase', {
    schema: {
      body: Type.Object({
        text: Type.String(),
      }),
      response: {
        200: Type.Object({ 
          textResult: Type.String() 
        }),
      }
    }
  }, async function (request, reply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
  })

}

export default example;

Now we have created a schema that defines that:

If the customer does not pass exactly one object with a string-type 'text' property in the body, he will receive a 404 error
If the server does not return exactly one object with the string-type 'textResult' property inside, the client will receive a 500 error

But there is still a problem, the schema is right but Typescript still doesn't compile because request.body is still of type unknown.

Let's use the schema to generate the types for the route

import { Type, FastifyPluginAsyncTypebox } from '@fastify/type-provider-typebox'

const example: FastifyPluginAsyncTypebox = async (fastify, opts): Promise<void> => {

  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })

  fastify.post('/uppercase', {
    schema: {
      body: Type.Object({
        text: Type.String(),
      }),
      response: {
        200: Type.Object({ 
          textResult: Type.String() 
        }),
      }
    }
  }, async function (request, reply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
  })

}

export default example;

We just replaced the type:

FastifyPluginAsync (type for plugin imported directly from 'fastify')

With the type:

FastifyPluginAsyncTypebox (type for plugin imported from '@fastify/type-provider-typebox')

Refactoring

Now everything works, but personally, for better readability, I prefer to separate the function of the route and the schema from the declaration of the route itself.

import { Type, FastifyPluginAsyncTypebox } from '@fastify/type-provider-typebox'
import { FastifyReply, FastifyRequest } from 'fastify'

const example: FastifyPluginAsyncTypebox = async (fastify, opts): Promise<void> => {

  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })

  const schemaPostUppercase = {
    body: Type.Object({
      text: Type.String(),
    }),
    response: {
      200: Type.Object({ 
        textResult: Type.String() 
      }),
    }
  }

  async function postUppercase(request: FastifyRequest, reply: FastifyReply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
  }

  fastify.post('/uppercase', { schema: schemaPostUppercase }, postUppercase)

}

export default example;

This way we separated the schema into the variable: schemaPostUppercase and the route handler into the function: postUppercase.

But now Typescript is no longer able to type the body and return of the function and generates the error:

And also note that the return is no longer typed. Typescript allows us to do this:

return { hello: text.toUpperCase()}

Returning the 'hello' property should generate a Typescript compilation error because it does not respect the schema which instead defines that only the 'textResult' property is present in the response.

This is because the route no longer takes types from the schema.

Route handler type

import { Type, FastifyPluginAsyncTypebox, TypeBoxTypeProvider } from '@fastify/type-provider-typebox'
import { ContextConfigDefault, FastifyBaseLogger, FastifyInstance, FastifyReply, FastifyRequest, FastifySchema, RawReplyDefaultExpression, RawRequestDefaultExpression, RawServerDefault, RouteGenericInterface } from 'fastify'
import { ResolveFastifyReplyReturnType } from 'fastify/types/type-provider'

type FastifyInstanceTypebox = FastifyInstance<
  RawServerDefault,
  RawRequestDefaultExpression,
  RawReplyDefaultExpression,
  FastifyBaseLogger,
  TypeBoxTypeProvider
>

type FastifyRequestTypeboxextends FastifySchema> = FastifyRequest<
  RouteGenericInterface,
  RawServerDefault,
  RawRequestDefaultExpression,
  TSchema,
  TypeBoxTypeProvider
>

type FastifyReplyTypeboxextends FastifySchema> = FastifyReply<
  RawServerDefault,
  RawRequestDefaultExpression,
  RawReplyDefaultExpression,
  RouteGenericInterface,
  ContextConfigDefault,
  TSchema,
  TypeBoxTypeProvider
>

export type RouteHandlerTypeboxextends FastifySchema> = (
  this: FastifyInstanceTypebox,
  request: FastifyRequestTypebox,
  reply: FastifyReplyTypebox
) => ResolveFastifyReplyReturnType

const example: FastifyPluginAsyncTypebox = async (fastify, opts): Promise<void> => {

  fastify.get('/', async function (request, reply) {
    return 'this is an example'
  })

  const schemaPostUppercase = {
    body: Type.Object({
      text: Type.String(),
    }),
    response: {
      200: Type.Object({ 
        textResult: Type.String() 
      }),
    }
  }

  const postUppercase: RouteHandlerTypebox<typeof schemaPostUppercase> = async function (request, reply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
  }

  fastify.post('/uppercase', { schema: schemaPostUppercase }, postUppercase)

}

export default example;

Unfortunately, in order to separate the declaration of the 'postUppercase' function from the route definition, we have to create its type manually.

For simplicity, I have defined all the types within the same file, but in a real project, you generally define the types in a separate file and import them into the files in which they are used.

Let's see this process step by step:

We transformed the postUppercase function from this:

async function postUppercase(request: FastifyRequest, reply: FastifyReply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
}

To this:

const postUppercase: RouteHandlerTypebox<typeof schemaPostUppercase> = async function (request, reply) {
    const body = request.body
    const text = body.text
    return { textResult: text.toUpperCase()} 
}

postUppercase becomes from a function to a variable that contains an anonymous function, this syntax allows us to define the types for the parameters, the return, and the context (this) of the function with a single type:

RouteHandlerTypebox<typeof schemaPostUppercase>

Let's see its definition:

export type RouteHandlerTypeboxextends FastifySchema> = (
  this: FastifyInstanceTypebox,
  request: FastifyRequestTypebox,
  reply: FastifyReplyTypebox
) => ResolveFastifyReplyReturnType

In the RouteHandlerTypebox type, we are going to define types for:

this: the context of the function i.e. when you want to access the 'fastify' object via 'this'
request: the first parameter of the function
reply: the second parameter of the function
function return: ResolveFastifyReplyReturnType

Manually typing with the schema: request, reply, and the return of the function, which takes the generic type: TSchema.

Manuel Salinardi

Dev Retro 2022: My journey as a freelance developer

Manuel Salinardi — Thu, 22 Dec 2022 03:07:39 GMT

Hello devs! 👋

I am a freelance full stack developer and I have been collaborating full time for years for an Italian company: Icona, of which I am part of the development team of one of their products: Acty, an amazing app for remote technical assistance.

Luckily Acty is an innovative product and during my working days it allows me to work with exciting technologies such as:

Javascript
Typescript
React
WebRTC
WebSocket with Socket.io
Webdriver.io
Node.js
Express
Fastify
Swagger
MongoDB
Redis
Augmented reality
and more...

In this article I won't talk about what I've accomplished in this working year 2022 for Icona, also because I would need a whole book, but about my activities outside the working day.

♦️ Web 3.0

My year 2022 began by studying and deepening everything related to the so-called Web 3.0, in particular, I studied:

Blockchain
Ethereum ecosystem
Smart contracts
Solidity
NFT

I started by taking these 2 courses on Udemy:

Then read this book: Mastering Ethereum: Building Smart Contracts and Dapps.

Both the courses and the book have been excellent resources, many times it is not easy to find good material, but this time I was lucky.

NFT

After that I felt the need to put into practice the concepts learned on a real project, fate has it that a childhood friend called me and told me that he had to create an NFT project on behalf of one of his clients.

I took the opportunity and created the project, with interesting features such as:

Smart contract upgradable
Metadata revealing
Addresses in the white list with different price
Minting web app
Max 4 NFT per wallet
Block public mint
Drops NFT

The project was deployed on the Ethereum main net and the collection is visible on the major Marketplaces such as Opensea: CryptoMadonne, for information about the project: https://cryptomadonne.com

♦️ TopTal

To look for some extra projects I started exploring the various platforms for freelancers such as:

Doing some research, I concluded that the best for me was TopTal. The difference between TopTal and the other platforms is that TopTal has a high barrier to entry, i.e. to join TopTal you must pass a 4-step Screening Process, but then to continue being part of it you must continue to excel. They claim that only 3% of applicants make it through all steps, more info here: https://www.toptal.com/top-3-percent

This could discourage many, but for me, it is a great advantage because, in the other platforms where everyone can enter even without skills, you would find yourself competing with people with little or no experience who obviously can afford to make much lower prices than yours.

So I applied, went through all stages and I passed 🎉

I can confirm that the standards are very high.

The final step was a project to be done in a week. Afterward, during a call with a TopTal expert, the project is evaluated and he makes sure that the project has all the requested features, but also that the code is secure and scalable and that all edge cases are managed correctly.

Now I'm working on my first project with TopTal and for now, I'm really satisfied!

This is my TopTal profile: https://www.toptal.com/resume/manuel-salinardi

♦️ Node.js Certification

I feel that a great way to study a programming language, or framework/library is by getting its official certification, because many times during normal use of it, for example within a project, all its potential is not explored.

Node.js has 2 official certifications:

The first is with a focus on knowledge of Node.js core APIs, which I had taken in 2021.

In 2022 I took the second 🎉 with a focus on knowledge of RESTful Node.js Servers and Services.

In this link, there is my Credly profile with the certifications I have obtained: https://www.credly.com/users/manuel-salinardi/badges

♦️ Blogging

And we have reached the end of this 2022 and the desire to write coding tutorials are starting to grow in me, for various reasons, for example:

Improving my writing
Improving my communication
Learn to write programs with graphs and charts
Learning by teaching and explaining concepts
Start building an online presence

For my new adventure, I have to thank Hashnode, which allows me to start writing articles like this one, only focuses on writing, without dealing with technical stuff, and also encourages me to do it with initiatives like #DevRetro2022

This new blogging challenge bet will be the hardest because I have never written articles or books, and I'm better at coding than I am at English 🤓.

I've always been a big content customer. Content creation is definitely more complex, I hope I can make it and don't give up! 👊

♦️ Goals for 2023

Blogging
The 2 official MongoDB certifications
Study PostgreSQL
Study Web Audio API
Study WebGL
Study WebXR with a focus on AR