DEV Community: Samanta Fluture

Node.JS: Asynchronous Functions

Samanta Fluture — Sat, 16 Apr 2022 21:53:16 +0000

When working on projects with Node.JS, we need at some point to use asynchronous functions, especially when it comes to data input and output (I/O - Input/Output). And for that we can use promises, but they can make our code complex and verbose, so we can use async and await and make our code simpler and more beautiful, and that's what we're going to see in this article.

Synchronous and asynchronous processing?

We need to understand these two concepts: synchronous processing is the one that happens in sequence and order, following a queue, and the other asynchronous processing only starts after the current one is completed. This happens in browsers that load files and resources in an orderly fashion, where one load only starts after the other has been completed.

Asynchronous processing is when processes are executed at the same time, with nothing preventing another process from starting while the one that was started previously ends. So a process can start even if another is running. This happens a lot when sending messages or emails, we can send a message, but it hasn't even arrived at the destination and even then we can already create and send another message.

Node.JS uses asynchronous processing, and this can be quite difficult to understand if we compare it to another language like PHP for example. We could use the following code to do a SELECT, INSERT, UPDATE, or anything else in the database:

$result = $connection->query('SELECT * FROM table_name');

echo $result ;

<rest of the code...>

This way the “rest of the code” will only be executed after the SELECT on the table is performed, in Node.JS we need to use something like:

connection.query('SELECT * FROM table_name', function (error, results) {
    console.log(results);
});

<rest of the code...>

The “rest of the code” would be executed soon, “before” the SELECT completed, but we always need to close the connection when the processing is done. But when will it end? We don't know, so we have a problem!

Using promises (promises)

We can use promises (promises, in free translation). In other words: we are going to make a promise that at some point will be fulfilled and we will have a return, or we will be able to do something when it is completed.

Assuming our database connection already returns a promise, we could do something like:

connection.query('SELECT * FROM table_name').then(rows=> {
    console.log(results);
});

<rest of the code...>

And using promises would be easy to solve our problem of closing the connection when the SELECT completes, we can simply chain another then, like so:

connection.query('SELECT * FROM table_name').then(rows=> {
    console.log(results);
}).then(rows => connection.close());

<rest of the code...>

If we need to chain several promises in a row, we will have a problem reading the code and understanding how this processing will actually be.

Improving code with async and await

To solve this other problem, we can use async and await that is present in Node.JS since version 7.6. With it we can make our code simple and easy to understand.

If we have the idea that the code must be easily understood, this may not be so simple using promises, but asynchronous functions make this task easier, as it will work as in PHP, for example, the “rest of the code” will only be executed when the SELECT has been completed.

We can have the following code:

async list() {
const result= await connection.query('SELECT * FROM table_name');

<rest of the code...>
};

Ready! We use an asynchronous function ( async), and inside it the “rest of the code” will only be executed when connection.query('SELECT * FROM table_name') finishes, that is, the result variable will receive the result that is “waiting” ( await) of the SELECT in the database.

Conclusion

Simple, fast! Using async and await makes usability, writing and reading easy to understand. It's so cool that when we start using async and await we hardly ever want to use promises again.

JavaScript: When should I use forEach and map?

Samanta Fluture — Sat, 16 Apr 2022 21:38:35 +0000

Whenever I advance in JavaScript course classes, I noticed that the moment I leave the conventional loop and go to a forEach, many students get a little lost at the beginning and the idea of this post is to immortalize this explanation in text, helping whoever it is. my student or student, how much you may have this doubt right now.

Introduction

If you take the 3 codes below, they will all have the same return in the browser.

const names= ['Whinds', 'Freeway', 'Teste', 'Maria'];

for(let i = 0; i < names.length; i = i + 1 ) {
    console.log('[for]', names[i]);
}

const names = ['Whinds', 'Freeway', 'Teste', 'Maria'];

names.forEach(function(name, i) {
    console.log('[forEach]', name, i);
})

const names = ['Whinds', 'Freeway', 'Teste', 'Maria'];

names.map(function(name, i) {
    console.log('[forEach]', name, i);
})

At first, you can assume that if the result is the same, they do the same thing. But it is clear if we look a little at forEach and map that here we don't have to worry about an index variable (which we usually call i), which is used to control the looping as it is an element that is normally incremented or decremented.

However, it is easy to notice that while we don't write it, this data is accessible to us, only this time we receive it as an argument of the function that we pass to forEach and map. To make this clearer, let's take a look at a possible implementation of forEach.

The implementation doesn't work in the array.map and array.forEach models, because for that we would need to mess with the prototype and that alone yields a post.

Understanding forEach

Earlier we saw that forEach loops through all the items in an array, just like the normal for loop, this is because internally it has a for lop. If we were to implement it, it would come out something like the code below:

function ourForEach(arr, function) {
    for(let i = 0; i < arr.length; i = i + 1) {
        function(arr[i], i);
    }
}

ourForEach(['name', 'name2'], function(name, index) {
    console.log(name, index)
})

Whenever you are going to do a for loop, it's worth using a forEach, as it eliminates the mental burden of having to deal with control variables and therefore can help make the code easier to read, taking into account that this is an overused form in the JavaScript world in general.

Understanding the map

In practice, as we saw at the beginning of the post, map and forEach seem to do the same thing, but the difference comes when we analyze the return of what comes out of them, the difference is clear.

const names = ['Whinds', 'Freeway', 'Teste', 'Maria'];

const returnForEach = names.forEach((currentName) => {
    console.log(currentName);

    return currentName.toUpperCase();
})
console.log(returnForEach) // undefined

const names= ['Whinds', 'Freeway', 'Teste', 'Maria'];

const returnMap = names.map((currentName) => {
    console.log(currentName);

    return currentName.toUpperCase();
})
console.log(returnMap ) // ['WHINDS', 'FREEWAY', 'TESTE', 'MARIA']

While the forEach was made to be an alternative to the for loop, the map was made to do a transformation/alteration operation on the items of an array and at the end of these operations we have a new list with the same number of items as the base list.

If we were to implement the map, we would end up with code on this line:

function ourMap(arr, function) {
    const newArray = [];
    for(let i = 0; i < arr.length; i = i + 1) {   
        newArray .push(function(arr[i], i));
    }    
    return newArray 
}

ourMap(['name', 'name2'], function(name, index) {
    console.log(name, index)
})

This makes it easier for us to concatenate operations such as making a map and adding a filter, given that the map's return is an array, we can write code on this line: .map().filter().

Conclusion

That's all for this post, I hope it was clear that if we just want a more elegant way to work with for, we use .forEach and if we want to transform/change values or even concatenate operations on top of arrays, .map is the most suitable .

How to resolve a Cross-Origin Resource Sharing (CORS) error?

Samanta Fluture — Sat, 16 Apr 2022 21:02:26 +0000

You must have already been through the situation of trying to log in to some application, type your data, click send and nothing happens on the page. The first thing a developer does is inspect the page and then open the browser console (by clicking the F12 button or pressing the right mouse button, then Inspect).

You get the error "blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome-extension, edge, https, chrome-untrusted." or similar.

But do you know what causes it?

Same-origin policy

The same-origin policy is a security mechanism that restricts the way a document or script from one origin interacts with a resource from another origin. And what is it for? Helps to prevent malicious attacks.

Two URLs share the same origin if the protocol, port (if specified), and host are the same.

how do we handle situations where our frontend needs to consume an API with different url without having issues with CORS? As in case we want to connect an API running on port 8000 with a React application running on port 3000?

When sending a request to a different origin API, the server needs to return a header called Access-Control-Allow-Origin. Inside it, it is necessary to inform the different origins that will be allowed, such as: Access-Control-Allow-Origin: http://localhost:3000/.

It is possible to allow access from any origin using the asterisk symbol: Access-Control-Allow-Origin:.* This is not a recommended measure as it allows unknown origins to access the server, unless it is intentional as in case of a public API.

After all, what is CORS?

CORS (Cross-origin Resource Sharing) is a mechanism used to add HTTP headers that tell browsers to allow a web application to run on one origin and access resources from a different origin. This type of action is called a cross-origin HTTP request.

It is used to enable cross-site requests for XMLHttpRequest or FetchAPI calls (cross different origins), web fonts (@font from CSS), WebGL textures, and drawing frames using drawImage().

Horror Card Game

Samanta Fluture — Wed, 22 Sep 2021 20:10:50 +0000

DevFlix

Samanta Fluture — Fri, 17 Sep 2021 21:30:12 +0000

My farovite movies about programmers and tech universe

Guess The Number

Samanta Fluture — Wed, 15 Sep 2021 16:40:40 +0000