DEV Community: Kenwanjohi

Solving GraphQL N+1 problem in fastify with loaders and conditional queries

Kenwanjohi — Fri, 30 Apr 2021 19:36:22 +0000

What is 1+N, err, N+1 ?

To understand this, let's give an example.

Lets start by defining our graphql schema in a schema.graphql file

type Song {
 songid: ID!
 songname: String!
 genre: String!
}
type Query {
 songs: [Song]
}

Normally we would have a songs table and a genres table in a relational database, say PostgreSQL:
Songs table:

CREATE TABLE Songs (
    SongID UUID NOT NULL PRIMARY KEY,
    SongName VARCHAR(75) NOT NULL,
    GenreID SMALLINT NOT NULL,
);

Genres table

CREATE TABLE Genres (
    GenreID SMALLINT NOT NULL PRIMARY KEY,
    GenreDescription VARCHAR(75) NOT NULL
);

Here, a genre can be in many songs, we're linking the two tables by having a foreign key (genreid ) in our songs table that references the genreid column in the genres table.

 ALTER TABLE songs
    ADD CONSTRAINT FK_Songs 
    FOREIGN KEY (GenreID)
    REFERENCES Genres(GenreID);

Now let's define a query to fetch our songs and their genres from our server.

query {
 songs{
  songid
    songname
    genre
 }
}

We define our resolvers in resolvers.js file:

const resolvers = {
    Query: {
        songs: async (_, args, {client, reply}) => {
            reply.log.info("getting all songs")
            let {rows} = await client.query(`
            SELECT songs.songid, songs.songname, songs.genreid FROM songs LIMIT 5;
            `)
            return rows
            }
    },
    Song: {
        genre: async (parent, args, {client, reply}) => {
            reply.log.info("getting genre") 
            let {rows} = await client.query(`
            SELECT genredescription AS genre FROM genres WHERE genreid = $1
            `, [parent.genreid])
            return rows[0].genre
        }
    }
}
module.exports = {resolvers}

If we ran our query and inspect the logs we see:

{"msg":"getting all songs"}
{"msg":"getting genre"}
{"msg":"getting genre"}
{"msg":"getting genre"}
{"msg":"getting genre"}
{"msg":"getting genre"}

What's happening?

We are fetching all songs from our database and for each song we are also making
a database request to get the genre, hence the "N + 1" problem.

That's really not efficient, especially with nested queries in many to many relations. A GraphQL API should fetch data efficiently as possible.

Solutions

Solution 1: Using a join

One of the solution would be to perform a SQL INNER JOIN.

Now our reslovers will look like this:

const resolvers = {
    Query: {
        songs: async (_, args, {client, reply}) => {
            reply.log.info("getting all songs and genres")
            let {rows} = await client.query(`
            SELECT songs.songid, songs.songname, genres.genredescription AS genre
            FROM genres
            INNER JOIN songs
            ON genres.genreid = songs.genreid
            LIMIT 5
            `)
            return rows
            }
    },
}

In our logs we'll see this:

{"msg":"getting all songs and genres"}

Great! we have eliminated the extra SQL queries from our previous resolvers.

Have we really?

The problem with this:

Let's say our API user now creates a query to fetch the songid and songname only, no genre.

query {
 songs{
  songid
  songname
 }
}

If you could check your database logs, you'll notice that we still have the join which is really unnecessary in this case.

The same SQL query will be executed even though we don't need the genre. That's not very efficient right?

Solution 2: Conditional queries

What if we could be able to look into the query fields, see which fields our users have requested and create conditional SQL queries that returns only the data they requested.

That sounds great, but how do we do that?

The GraphQL info object

Our resolver function takes four arguments: parent, args, context and info. The info object contains, well, information on the incoming GraphQl query. What we are interested in are the fields requested in the info.

We could parse the info ourselves but there are some libraries we could use for that.

graphql-parse-resolve-info

It parses the info object and returns the fields that are being requested by our API user enabling us to optimise our resolvers.

npm i graphql-parse-resolve-info

Usage

In our reslovers.js file require the module

const {parseResolveInfo,simplifyParsedResolveInfoFragmentWithType} = require('graphql-parse-resolve-info');

We use the first function to parse the info object and the second function as a helper to obtain the fields in our returnType, in our case Song. From these, we can create conditional SQL queries.

By using the hasOwnproperty() method, we can check whether our Song object has the field we need and execute the SQL queries conditionally.

Now our resolvers will look like this:

const resolvers = {
    Query: {
        songs: async (_, args, {client, reply}, info) => {
            reply.log.info("getting all songs")
            const parsedInfoObject = parseResolveInfo(info);
            const {fields} = simplifyParsedResolveInfoFragmentWithType(parsedInfoObject, info.returnType);
            if (!fields.hasOwnProperty('genre')) {
                let {rows} = await client.query(`
                SELECT songs.songid, songs.songname FROM songs LIMIT 5
                `)
                return rows
            }
            let {rows} = await client.query(`
                SELECT songs.songid, songs.songname, genres.genredescription AS genre
                FROM genres
                INNER JOIN songs
                ON genres.genreid = songs.genreid
                LIMIT 5
                `)
                return rows
        }


    },
}

The problem with this:

This is a good solution for simple query types, in our case, we only check whether the API user includes the genre in the query fields and perform the conditional SQL queries.

However, with complex query types, our resolvers could get really messy and verbose.

Solution 3: Loaders

From mercurius documentation:

Each defined loader will register a resolver that coalesces each of the request and combines them into a single, bulk query.

Loaders enable us to write resolvers that batch requests.

Mercurius - the graphql adapter for fastify - comes with great set of features including automatic loaders integration to solve 1 + N queries.

We just need to define our loaders and add them in the options object where we register the mercurius plugin.

In theserver.js we have:

fastify.register(mercurius,{
    schema: makeExecutableSchema({
        typeDefs,
        resolvers
    }),
    context: () => {
        return {
          client: fastify.db.client
        } 
    },
    loaders,
    graphiql: 'playground'
})

Refactor our resolver and add our loader

const resolvers = {
    Query: {
        songs: async (_, args, {client, reply}) => {
            reply.log.info("getting all songs")
            let {rows} = await client.query(`
            SELECT songs.songid, songs.songname, songs.genreid FROM songs LIMIT 5;
            `)
            return rows
            }           
    },
}

const loaders = {
    Song: {
            genre: async (queries, {client}) => {     
            let genreids = queries.map(({ obj }) => obj.genreid)  
            let {rows} = await client.query(`
            SELECT genreid, genredescription genre FROM genres WHERE  genres.genreid = ANY ($1)
            `,[genreids])     
            return genreids.map(genreid => {
               return rows.filter(genreitem => genreitem.genreid === genreid)[0].genre
            })
        },
    }
}

We have created a resolver for the genre in our Song object type. The loader receives two arguments, queriesand context. queries is an array of objects in our case this:

[
    {
      obj: {
        songid: 'f4b800b9-5093-49a7-9bc8-37561b2d7041',       
        songname: 'Let Me Down Slowly (feat. Alessia Cara)',  
        genreid: 2
      },
      params: {}
    },
    {
      obj: {
        songid: '8a3416e9-a4ab-468c-b81d-b58c214ed3fd',       
        songname: 'stupid',
        genreid: 2
      },
      params: {}
    },
    // more objects
  ]

We map this object to obtain all the genreids, and perform a SQL batch query.

let genreids = queries.map(({ obj }) => obj.genreid)  
let {rows} = await client.query(`
            SELECT genreid, genredescription genre FROM genres WHERE  genres.genreid = ANY ($1)
            `,[genreids])

We then return the result ordered by the genreids.

 return genreids.map(genreid => {
               return rows.filter(genreitem => genreitem.genreid === genreid)[0].genre
            })

Our resolvers can now query our database efficiently.

References

Mercurius documentation

Fastify and PostgreSQL REST API

Kenwanjohi — Tue, 20 Apr 2021 17:23:48 +0000

Enter the 'speed force'

From the documentation, fastify is a fast and low overhead web framework for Node.js.

So, I decided to explore some of the awesome features that fastify offers including but not limited to, speed, extensibility via plugins and decorators, schema validation, and serialization and logging. I dived into their documentation, which is excellent by the way, with the help of some GitHub repositories and decided to build some REST API endpoints powered by fastify and a PostgreSQL database.

You can check out the source code or follow along in this post.

Getting Started

Setting up the project

Navigate to the root folder of your project and run npm init to initialize your project. Create an src folder for your project source code and create an index.js file as the entry point.

Installing dependencies

Installing nodemon

nodemon is a dev dependency that'll monitor your file changes and restart your server automatically.

You can install nodemon locally with npm:

npm install nodemon --save-dev

Add this npm script to the scripts in the package.json file

"start": "nodemon src/index.js"

Installing Fastify

Install with npm:

npm i fastify --save

Hello World: Starting and running your server

In the index.js file add this block of code:

const fastify = require('fastify')({logger: true}) 
fastify.get('/', async (request, reply) => { 
     reply.send({ hello: 'world' }) 
  }) 
async function start()  { 
    try{ 
        await fastify.listen(3000) 
    } catch(err) { 
        fastify.log.error(err) 
        process.exit(1) 
    } 
} 
start()

On the first line, we create a fastify instance and enable logging, fastify uses pino as its logger. We then define a GET route method, specify a homepage endpoint '/' and pass in the route handler function which responds with the object {hello: 'world'} when we make a get request to the homepage.

We instantiate our fastify server instance (wrapped in our start function) and listen for requests on port 3000. To start the server, run npm start on your terminal in the root folder. You Server should now be running and the following will be logged in the terminal:

{"level":30,"time":1618477680757,"pid":5800,"hostname":"x","msg":"Server listening at http://127.0.0.1:3000"}

When you visit the homepage you should see the response:

curl http://localhost:3000/ 
{"hello":"world"}

Great we have our server!

Plugins

We can extend fastify's functionality with plugins.
From the documentation:

A plugin can be a set of routes, a server decorator, or whatever.

We can refactor our route into a plugin and put it in a separate file i.e routes.js, then require it in our root file and use the register API to add the route or other plugins.

Create a routes.js file and add this code:

async function routes(fastify, options) { 
    fastify.get('/', async (request, reply) => { 
        reply.send({ hello: 'world' }) 
    }) 
} 
module.exports= routes

We then require our module in index.js and register it.

const fastify = require('fastify')({logger: true})
const route  = require('./routes')
fastify.register(route)
async function start()  {
   ...
}
start()

A request on the homepage should still work. Great, we have our first plugin.

Creating our database

To create a database we first need to connect to psql, an interactive terminal for working with Postgres.

To connect to psql run the command in the terminal:

psql -h localhost -U postgres

Enter your password in the prompt to connect to psql.

The CREATE DATABASE databaseName statement creates a database:

CREATE DATABASE todos;

To connect to the created database run the command:

\c todos

To create our table run the statement

CREATE TABLE todos ( 
    id UUID PRIMARY KEY, 
    name VARCHAR(255) NOT NULL, 
    "createdAt" TIMESTAMP NOT NULL, 
    important BOOLEAN NOT NULL, 
    "dueDate" TIMESTAMP, 
    done BOOLEAN NOT NULL 
);

Connecting our database

To interface with postgreSQL database we need node-postgres or the pg driver.

To install node-postgres:

npm install pg

Database connection plugin

Let's create a plugin to connect to our database. Create a db.js file and add the following code:

const fastifyPlugin = require('fastify-plugin') 
const { Client } = require('pg') 
require('dotenv').config() 
const client = new Client({ 
    user: 'postgres', 
    password:process.env.PASSWORD, 
    host: 'localhost', 
    port: 5432, 
    database: process.env.DATABASE 
}) 
async function dbconnector(fastify, options) { 
    try { 
        await client.connect() 
        console.log("db connected succesfully") 
        fastify.decorate('db', {client}) 
    } catch(err) { 
        console.error(err) 
    } 
} 
module.exports= fastifyPlugin(dbconnector)

Let's skip the fastifyPlugin part first.

We require Client module from node-postgres and create a client instance, passing in the object with the various fields.

Make sure to create a .env file and add:

PASSWORD='yourpassword'

Install and require the dotenv module to load the environment variables

npm i dotenv

We then create our dbconnector plugin and inside the try block, we connect to our postgres database.

Inside the block you can also see:

fastify.decorate('db', {client})

What is the decorate function?

In fastify, to add functionality to the fastify instance, you use decorators. We use the decorate API, pass the property name 'db' as the first argument and the value of our client instance ({client}) as the second argument. The value could also be a function or a string.
We export the plugin wrapped in a fastifyPlugin module.

Require the module in the index.js file and register it.

const dbconnector = require('./db')
fastify.register(dbconnector)
fastify.register(route)
async function start()  {
  ...
}
start()

We can now access our client instance in other parts of the application for instance in our routes to query data using fastify.db.client.

Let's take a step back to the fastifyPlugin module. Why wrap our plugin with fastifyPlugin? When we register a plugin, we create a fastify context (encapsulation), which means access to the data outside our registered plugin is restricted. In this case, we can't access our database client instance using fastify.db.client anywhere in our application.

To share context, we wrap our plugin in a fastifyPlugin module. We can now access our database client instance anywhere in our application.

Serialization

Lets refactor our homepage route to return information from our database:

async function routes(fastify, options) {  
    //Access our client instance value from our decorator
    const client = fastify.db.client
    fastify.get('/', {schema: allTodos}, async function (request, reply) { 
            try { 
                const {rows} = await client.query('SELECT * FROM todos') 
                console.log(rows) 
                reply.send(rows) 
            } catch(err) { 
                throw new Error(err) 
            } 
        })
}  
module.exports= routes

We First access our database client instance and assign it to a client variable.
Inside our routes we query all columns from our database using the shorthand * and send the returned todos using reply.send(rows) - you could also use return rows.
Make sure you add some todos in your database first in the psql terminal i.e:

INSERT INTO todos (id, name, "createdAt", important, "dueDate",  done) 
VALUES ('54e694ce-6003-46e6-9cfd-b1cf0fe9d332', 'learn fastify', '2021-04-20T12:39:25Z', true, '2021-04-22T15:22:20Z', false); 
INSERT INTO todos (id, name, "createdAt", important, "dueDate",  done)  
VALUES ('d595655e-9691-4d1a-9a6b-9fbba046ae36', 'learn REST APIs', '2021-04-18T07:24:07Z',true, null, false);

If an error occurs, trying to query our database, we throw the error.

When you look closer at our get route method, you can see have an object as our second argument with a schema key and allTodos as the value.

Fastify uses fast-json-stringify to serialize your response body when a schema is provided in the route options.

To add the schema create a schemas.js file and add the allTodos schema:

const allTodos = {
    response: {
        200: {
            type: 'array',
            items: {
                type: 'object',
                required: ['id', 'name', 'createdAt', 'important', 'dueDate', 'done'],
                properties: {
                    id: {type: 'string',  format: 'uuid'},                                                              
                    name: {type: 'string'},                                           
                    createdAt:{type: 'string',format: "date-time"},                  
                    important: {type: 'boolean'},
                    dueDate: {type: 'string',format: "date-time"},
                    done: {type: 'boolean'},
                }
            }
        }
    }
}

Fastify recommends using JSON Schema to serialize your outputs, you can read how to write JSON schema here.

We're specifying the response, the response status code, and the entity which is an array type. The items specify each entry in the array as an object with the required keys and the properties with the various fields and types.

Remember to require the module in the routes.js file.

Validation

In the routes.js file, let's add a POST method route inside our route plugin to add todos to our database.

fastify.post('/', {schema: addTodo}, async function(request, reply) {
            const {name, important, dueDate} = request.body
            const id = uuidv4()
            const done = false
            createdAt = new Date().toISOString()
            const query = {
                    text: `INSERT INTO todos (id, name, "createdAt", important, "dueDate", done)
                                    VALUES($1, $2, $3, $4, $5, $6 ) RETURNING *`,
                    values: [id, name, createdAt, important, dueDate, done],
                    }
            try {
                    const {rows} = await client.query(query)
                    console.log(rows[0])
                    reply.code(201)
                    return {created: true}
            } catch (err) {
                    throw new Error(err)
            }

    })

We allow the client to send a JSON object in the body with name of the todo, important, and dueDate properties.

We then generate a unique id, assign false to done and a timestamp assigned to createdAt.

To generate the unique id install uuid:

npm install uuid

Require the module in the routes.js:

const { v4: uuidv4 } = require('uuid');

We then construct a query object with a text property with the SQL statement to insert the todos in the database and the values property containing the values to be inserted into the respective columns.

After a successful insert we send a 201 Created status code back to the client.
In the schemas.js file, let's add the validation schema for our todos:

const addTodo = {
    body: {
        type: 'object',
        required: ['name'],
        properties: {
            name: {type: 'string',},
            dueDate: {type: 'string', format: 'date-time', nullable: true, default: null},
            important: {type: 'boolean', default: false},
        }
    },
    response: {
        201: {
            type: 'object',
            properties: {
                created: {type: 'boolean'}
            }
        }
    }

}

Fastify uses Ajv to validate requests.
We expect the client to always send the name of the todo by adding it in the required property array.

The dueDate property can be omitted by the client whereby it will be null by default. This is made possible by setting the nullable property to true which allows a data instance to be JSON null. When provided it has to be of the format 'date-time'.

The client can optionally indicate whether a todo is important or it falls back to the default.

If the above conditions are not satisfied, fastify will automatically send an error object with the error message.

For instance, if you omit a name, you should see an error like

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "body should have required property 'name'"
}

Great! Our validation is working

Adding other REST endpoints

Update todo
Let's allow users to set their todo as done or importance of the todo or change dueDate. To do that let's add a PATCH method route to our routes plugin.

fastify.patch('/:id',{schema: updateTodo}, async function (request, reply) {
        const id = request.params.id
        const {important, dueDate, done} = request.body
        const query = {
                text:  `UPDATE todos SET 
                                important = COALESCE($1, important), 
                                "dueDate" = COALESCE($2, "dueDate"), 
                                done = COALESCE($3, done) 
                                WHERE id = $4 RETURNING *`,
                values : [important, dueDate, done, id]
        }
        try {
                const {rows} = await client.query(query)
                console.log(rows[0])
                reply.code(204)
        } catch (err) {
                throw new Error(err)
        }
})

We're extracting the id of the todo we want to update from the parameter and the values from the request body.

We then create our query statement, updating the columns provided optionally using the COALESCE function. That is, if the clients omit some properties in the JSON body, we update only the provided properties and leave the rest as they are in the todo row.

We then respond with a 204 No Content.

Lets add a validation schema for our route:

const updateTodo = {
    body: {
        type: 'object',
        properties: {
            dueDate: {type: 'string', format: 'date-time'},
            important: {type: 'boolean'},
            done: {type: 'boolean'}
        }
    },
    params: {
        type: 'object',
        properties: {
          id: { type: 'string', format: 'uuid' }
        }
    }
}

params validates the params object.

Delete todo

To delete a todo, we just need the id sent in the URL parameter.
Add a DELETE method route:

fastify.delete('/:id', {schema: deleteTodo}, async function(request, reply) {
            console.log(request.params)
            try {
                    const {rows} = await client.query('DELETE FROM todos
                    WHERE id = $1 RETURNING *', [request.params.id])
                    console.log(rows[0])
                    reply.code(204)
            } catch(err) {
                    throw new Error(err)
            }
    })

Lets add a validation schema for our DELETE route:

const deleteTodo = {
    params: {
        type: 'object',
        properties: {
            id: {type: 'string', format: 'uuid'}
        }
    }
}

Conclusion:

Give fastify a try and "take your HTTP server to ludicrous speed" ~ Matteo Collina.

You can check out the project source code here

References:

Fastify examples; GitHub repos:

A valet key? OAuth 2.0 Delegated Authorization in Node.js

Kenwanjohi — Tue, 13 Oct 2020 20:33:11 +0000

How to implement OAuth 2.0 in Node.js with Spotify using the Authorization code flow.

What is Delegated Authorization?

First things first, Delegated Authorization is all about granting access to perform some task on your behalf.
Consider a valet key, you hand a valet parking attendant a valet key to park and retrieve your car on your behalf. Valet keys typically unlock the driver's door and start the car but can't unlock the trunk or the glove box.
For an application to perform such tasks, for instance make API requests in order to perform actions(read and write) on user's resources(in another application), they need to be authorized by the user to perform only a set of actions on the user's behalf.
OAuth is a delegation framework that enables all the parties involved to orchestrate such a process.

OAuth 2.0 in Node.js

Setup your node.js environment and have your server running using the framework of your choice.
We'll be using Spotify as an example to show the OAuth 2.0 authorization code flow in node.js.
You can check out the final application here

Step 1: Client registration and configuration

From the specification, a client is an application making protected resource requests on behalf of the resource owner (end-user) with its authorization. To register an application you need to provide the information required by the authorization server. This will vary depending on the service provider. With Spotify some of the information includes application name, description, website, Redirect URL.
After registering an application you are presented with a client ID and client secret. Save the client ID and client Secret in a .env file.

Client_id="your client_id" 
Client_secret="your client secret"

A client ID is a unique identifier and a client secret is used to authenticate the client with the authorization server.
In the app.js create an object to encapsulate the client details (client_id and client_secret). Use the dotenv module to load the environment variables. To install the module, run npm install dotenv.

require('dotenv').config()

const client = {
    client_id: process.env.Client_id,
    client_secret: process.env.Client_secret,
    redirect_uri: "http://localhost:3000/callback"
}

The redirect_uri is the endpoint URL that the authorization server redirects the user-agent back to the client with (previously used in client registration) after the resource owner grants or denies permission to your client.

Step 2: Send an authorization request

You need to include a link that initiates the process and also inform the user what service they are about to access. For instance, View your Spotify activity. This is done by sending the client to the authorization endpoint of the authorization server. The authorization endpoint can be found on the authorization guide.

Next, configure the authorization server details; just like the client details, enclose the details in an object.

const authProvider = {
    authEndpoint: 'https://accounts.spotify.com/authorize',
    tokenEndpoint:  'https://accounts.spotify.com/api/token'
}

From the specification, the authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The token endpoint is used by the client to obtain an access token by providing its authorization grant or refresh tokens.
To send the user to the authorization endpoint, you need the authorization endpoint URL and a few concatenated URL query parameters:
Client ID
The client id obtained after client registration.
response_type
code indicates the type of response returned.
redirect_url
The URI to redirect to after the user grants or denies permission to your client. We included it in the client's config object.
scope
This refers to the information the client wants to access the resource server.
state
A random non-guessable string used to protect against cross-site request forgery(CSRF) attacks.
To build the url with all the queries you can use the build-url library;a library that builds URLs. To install run npm install build-url --save.

const buildUrl = require('build-url');
const authorizeUrl = buildUrl(authProvider.authEndpoint, {
    queryParams: {
        client_id: client.client_id,
        redirect_uri: client.redirect_uri,
        state,
        response_type: "code",
        scope: "user-top-read"
    }
});

First, we pass the authorization endpoint as the first argument of the buildUrl function followed by the query parameters. The queryParams object is self-explanatory, except the state and scope maybe. The scope "user-top-read" from the Spotify guide gives access to a user's top artists and tracks.

So what is the state query parameter?

From the specification;

The client MUST implement CSRF protection for its redirection URI. .........The binding value used for CSRF protection MUST contain a non-guessable value

There is no specification on how to generate the non-guessable value. We can use the node.js crypto module to genetrate the random string to be used as state.

const crypto = require('crypto');
let state 
crypto.randomBytes(20, (err, buf) => {
  if (err) throw err;
  state = buf.toString('hex')
});

The state parameter is returned in the response callback and thus has to be compared with the one in the client, we therefore need to store it somewhere. We could store in session strorage. To use session storage we need express-session middleware. To install run the command npm install express-session.

const session = require('express-session');
app.use(session({
    name: 'SESSION_ID',
    secret: process.env.secret, //signs the cookie
    resave: false,
    saveUninitialized: false,
  }))

Send the request to the authorization endpoint.

app.get('/authorize', (req, res) => {
    req.session.state = state
    res.redirect(authorizeUrl);
})

The user initiates the process by clicking the authorize link, they are redirected to the service provider's authorization endpoint where they authenticate themselves first(if not already authenticated), they are then presented with the scopes; information that the client will have access to and whether they agree to grant the client access or not. Whether they agree or not the user is redirected back to the client with the redirect URL.

Step 3: Exchanging the authorization code for an access token

If the user grants the client access, the redirect URL contains the code and the state query parameters. If they deny the client access, the redirect URL contains the error parameter with a description why the authorization failed i.e access_denied.

At this point the client extracts the state parameter and compares it with the session state and if they don't match the client doesn't continue with the processing.

if(req.query.state !== req.session.state) {
        res.render('error', {error: 'State doesn\'t match'})
    }

If they match the client extracts the code and exchanges it for the access token via a post request to the authorization server token endpoint.

const code = req.query.code;
 const response = await axios({
                method: 'post',
                url: authProvider.tokenEndpoint,
                headers: {
                    'Content-Type': 'application/x-www-form-urlencoded',
                    'Authorization': 'Basic ' + stringToBase64(client.client_id, client.client_secret)
                },
                data: querystring.stringify({
                    code,
                    grant_type: "authorization_code",
                    redirect_uri: client.redirect_uri
                })
            })
            console.log(response.data)
            access_token = response.data.access_token

We've used http basic to authenticate the client; the client_id as the username and client_secret as the password encoded in Base64.

Step 4: Accessing user's resources

At this point you have the access_token. You can then use the access token to access the user's resources using the resource server API endpoints.

const fetch_lists = async () => {
        const axiosInstance = axios.create ({
            baseURL : 'https://api.spotify.com/v1/me/top/',
            headers: {
                'Authorization': 'Bearer ' + access_token
                }
          })
        try{
            const [response1, response2] = await Promise.all([
                axiosInstance.get('tracks'),
                axiosInstance.get('artists'),
            ])
            console.log(response1)
        } catch (error) {
                        console.log(error.response.data.message)
        }   
    }
    fetch_lists()

Conclusion

That's the gist of OAuth 2.0, You can check out the source code on Github.
You can check out the original post on my blog.