DEV Community: Andres Reales

What Does .pipe Mean in Node.js? How To Use It? Practical Guide

Andres Reales — Fri, 10 Sep 2021 11:18:35 +0000

Have you been using Node.js for a while and only until now have you heard about the word pipe? You tried checking the documentation but still can’t figure out what it means or does? In this article, I will clarify those doubts by explaining what .pipe or piping is and how to use it in Node.js. To ensure you understand the article, previous knowledge about streams is strongly recommended.

What Does .pipe() Method Do?

The method .pipe was added in v0.9.4 of Node.js and its purpose is to attach a writeable stream to a readable stream allowing to pass the readable stream data to the writeable stream. One good way to understand this concept is by thinking about PVC pipes and connecting two pipes.

For the sake of explanation, let’s assume the first PVC pipe is a readable stream and the second pipe is a writeable stream. The method .pipe will be the orange pipe fitting which will connect both pipes allow for the water, or the data, to flow from one pipe to another.

How to Use The .pipe() Method?

In this pipe implementation, we are going to create a simple HTTP server that will read data from a file and send the response to the client.

1. Let’s start by creating the HTTP server using the http package that returns some data.



const http = require('http');

http.createServer(function(req, res) {
  res.write('hello!');
  res.end();
}).listen(8080);

Let’s make sure it works, by making a request to our server using curl.



curl localhost:8080

Or another option is to open a new tab http://localhost:8080/. Once you make the request, you should receive “hello!”.

We are going to pause for a second. Let’s recall the anatomy of an HTTP transaction. An HTTP transaction is made of a server, created by the method createServer which in itself is an EventEmitter. When an HTTP request hits the server, node calls the request handler using the req and res objects, which are request and response respectively, for dealing with the transaction.

The req or request object is an instance of the IncomingMessage object. The IncomingMessage object is a child object of a ReadableStream.

The res or response object is an instance of the ServerResponse object. The ServerResponse object is a child object of a WriteableStream.

Therefore, we know we have a writeable and a readable stream.

2. We are going to create a data.txt file in the same directory folder, and save some information. For the sake of making things clear, I will save the following text: “This is data from the data.txt file”.

3. Remove the existing logic from the event handler.

4. We are going to read the content of the data.txt file using the fs package using fs.createReadStream. The fs.createReadStream will return a ReadableStream. We are going to use that ReadableStream to pipe or pass the data from data.txt file to the response object, which is a WriteableStream.



const http = require('http');
const fs = require('fs');

http.createServer(function(req, res) {
  // generete readable stream to read content of data.txt
  const readStream = fs.createReadStream(__dirname + '/data.txt');

  // pass readable stream data, which are the content of data.txt, to the 
  // response object, which is a writeable stream
  readStream.pipe(res);
}).listen(8080);

Once updated the event handler’s logic, make a request to http://localhost:8080/ and you should see data.txt data.

Only Works With Readable Streams

Remember, the pipe method can only be used in readable streams. Don’t let yourself fool by your IDE in case it suggests the pipe method in a writeable stream.

In case you attempt using the .pipe method using a writeable stream, like in the example below:

At the moment of executing this code, it will throw the following error.

Error [ERR_STREAM_CANNOT_PIPE]: Cannot pipe, not readable

Pushing Data No Matter Readable Stream’s Flowing Mode

If you are familiar with readable streams, you will know there are two modes in which data flows, flowing and paused mode. You can use the pause() or resume() method to update the flowing mode.



const http = require('http');
const fs = require('fs');

http.createServer(function(req, res) {
  const readStream = fs.createReadStream(__dirname + '/data.txt');

  readStream.on('data', function(chunk) {
    console.log('this is the data from file', chunk);
  });

  readStream.pause();
  console.log('on pause: readable flowing', readStream.readableFlowing);

  readStream.resume();
  console.log('on resume: readable flowing', readStream.readableFlowing);

  res.write('Hello!')
  res.end();
}).listen(8080);

If you run the example above, you will only read data from the data.txt file whenever the readable stream flowing mode is set to true which is enabled by using the resume() method. If the flowing mode is set to false, it will never read the content of the data.txt file.

However, when using the pipe method the flowing mode will automatically be set to true ensuring the data is passed from one stream to another. We can confirm this if we try to pause the flowing mode prior to piping both streams.



const http = require('http');
const fs = require('fs');

http.createServer(function(req, res) {
  // generete readable stream to read content of data.txt
  const readStream = fs.createReadStream(__dirname + '/data.txt');

  readStream.on('data', function(chunk) {
    console.log('this is the data from file', chunk);
  });

  readStream.pause();
  console.log('on pause: readable flowing', readStream.readableFlowing);

  readStream.pipe(res);

}).listen(8080);

After making a request to the server, we will still receive the content from the data.txt file.

Don’t Confuse The pipe Method With The Event pipe

If you have never heard of the word “pipe” or “piping” when working with streams, there is a slight chance you could find the wrong information if you go to Node.js documentation and start finding for the word “pipe”. When you do a quick search, you will find two options.

If you find the first option, you will notice it is an event listener that writeable streams can set when a readable stream uses the pipe method to pass the data from one stream to another. The event pipe is only available on writeable streams. We are going to use our simple server API to demonstrate the event pipes.



const http = require('http');
const fs = require('fs');

http.createServer(function(req, res) {
  const readStream = fs.createReadStream(__dirname + '/data.txt');

  // setting pipe event listener before triggering the pipe method in the readable stream
  // otherwise, the pipe event listener won't be triggered if set after triggering the pipe method
  res.on('pipe', function(src) {
    console.log('Triggered the pipe event listener whenever a source readable stream pipes the writeable stream');
  });

  readStream.pipe(res);

}).listen(8080);

In other words, calling the pipe method on the readable stream causes the pipe event listener to be triggered on the writeable stream.

It is important to mention to define the pipe event listener prior to calling the pipe method from the readable stream. Attempting to call the pipe method prior to setting the event listener in the writeable stream won’t work.

Why You Should Use .pipe Method?

Streams are one of the most powerful and fundamental concepts of Node.js applications. They allow us to handle data in a more efficient way as pieces of data can be transported in smaller chunks preventing you from running out of memory and maintaining good performance in your applications.

Therefore, using the pipe method is an effective and easy solution to push data between streams. In that way, we avoid storing too much data that needs to be manipulated or modified all at the same time. Also, the code will be shorter, elegant, and easy to follow.

Is It Normal To Be Stuck in Programming Problems? What to Do?

Andres Reales — Wed, 08 Sep 2021 13:09:00 +0000

Like many things in life, people get stuck doing certain things. We come across different challenges preventing us from moving forward and take steps to where we want to head towards to. In a similar way, you get stuck while programming. If you feel embarrassed about asking this question to someone and decided to anonymously find an answer on the web, let me tell you this is an excellent question! and there’s nothing to be ashamed of.

Whether you write code for a living or enjoy developing random projects during your free time, it is normal to get stuck when programming. Whether you are a new programmer or have 20 years of working in the industry, programmers always get stuck with a problem. Programming is not about the act of typing words and writing code, but solving problems.

Some problems will be more challenging than others. Some will seem simple but they are more complex than what we think. Sometimes you believe you can fix the problem in 5 minutes, but you end up spending 10 hours fixing it. Sometimes you don’t even know how long it could take to figure out something and you end up making it work in a couple of hours. Programming could be the best thing it could have ever happened to you when you figure something out or the worst thing that has existed on the planet if you are stuck for hours or days making something work.

Should I Quit Programming?

Thoughts about quitting programming often come across to new programmers. The main reason is that everything is hard at the beginning. Whether you make your first HTML table, or style the border of a card using CSS, or get data from the database using an API, etc, things seem simple and straightforward are not making you frustrated as your instructor or more senior coworkers can make things work in a matter of seconds while you can make it work in a matter of hours or even days.

It wouldn’t surprise me either if more experienced programmers have thoughts about quitting as well. Regardless of where you are in your programming journey, give it some time before you make any drastic decision.

Contrary to what most people will say, it is ok to quit programming. There is nothing stopping you from quitting programming. There will be people, especially those who are in the industry who will strongly encourage you to not stop programming. However, this decision is personal and people should understand no matter what they think. Sometimes, it is not the best time to program. Sometimes, you don’t have enough time to dedicate to programming. Sometimes people are better at learning other things, and that is normal.

However, before you make the decision of quitting, I will share my piece of advice. I strongly believe anyone can program and make a living of it. Anyone who is willing to go through the struggles and overcome them can learn how to program. That’s why should not quit programming right away. Getting stuck constantly is one of the many obstacles you will find when programming. Training your body to get used to being in uncomfortable situations is hard and sucks for anyone. Nevertheless, once you pass through those obstacles the feeling of satisfaction is priceless and cannot be described with the joy once you make things work out.

If you are reading this article, that means you have internet. Think about the people who wanted to be programmers at other times. There was no such thing as StackOverflow, or YouTube, or Google, or even worst no internet. Learning how to program had to come from a pure desire to make things work. Programmers had to buy and read through extensive technical books in hopes to get an answer to help them get unstuck.

Thinking about quitting programming in those times seemed more justifiable due to all the struggles programmers faced due to the technology stages they were during their times. The desire to move forward and develop great things lead to many programmers making it more accessible for newer generations to get their feet wet in the world of programming. With more and more available resources to learn how to program and even to solve common programmatic problems, there has never been a better time to get in the world of programming than now.

What to Do? 13 Tips Get You Unstuck as a Programmer

As previously mentioned, it is ok to get stuck. What matters is what we do to get out of that situation. As you gain more and more experience you start developing the skills to get unstuck quicker. There are some tips in case you need help trying to move forward. Chances are you have tried some of the following tips. In case you haven’t tried any, give them a try!

1. Recognize You Are Stuck

Recognizing you are stuck might not be that obvious at first. However, realizing you are in a place where there are more unknowns than clarity is more powerful than you think. Failing to recognize it could lead to spending unnecessary time trying to make things work that are not that necessary.

Not because you don’t know how to do something and can’t figure out how to make it work within 5 to 10 minutes that means you are stuck. Confusing the definition of getting stuck and not trying more could hurt your abilities to solve problems in the long term.

2. Relax (At Least Try To Calm Down)

As programmers, generally we encounter ourselves in the following scenario: Start working on a task, writing some code that works, come across with a bug, try to get it solved, if you haven’t solved it yet, try harder to get the problem solved, frustration starts to increase, try anything that works, become fully frustrated, destroy the keyboard. For some, this sounds funny as it is not too far from reality. The problem turns harder to solve when we start getting frustrated.

It is crazy to think how the way you feel impacts your ability to solve problems. Senior programmers often recommend coding when you don’t think of anything that is bugging your brain constantly such as paying the bills, worrying about your kids’ health, looking for another job, thinking about the discussion you had with your relative, etc. Your brain is not fully focused on what needs to be focused. Being frustrated leads to the same. By being frustrated, you become more concerned about not making things work rather than finding alternatives to making it work.

One of my bosses once told me: One of the best work happens when we are relaxed. It’s true. It gives freedom to your brain to explore and discover new ways to make things happen. Sometimes, frustration makes us keep the focus on the solution we are trying to implement which got us stuck at first. This leads us to not trying different alternatives because we insist on making work the first piece of code written.

3. Read and Try to Understand The Error

This one seems obvious, but it isn’t. It is not a secret we live in a world with access to information about anything. In the programming world, you can find just about any kind of solutions to common problems programmers come across. Unfortunately, that is not always the case.

Going directly to your favorite search engine and try finding a solution for the problem is what leads you to get stuck. Why? because you don’t have true clarity of what the error is. Oftentimes, we get error logs displayed in the terminal and we don’t even read at the whole log. We only see the part of the log that says “[Error]” or “error” and automatically turn our heads to googling.

Sometimes the bug is as simple as a variable name typo causing the application to crash. Take your time to read and understand the error as this will allow you to better choose what next to do, whether it is to try a different solution, ask someone else for help, or googling.

4. Talk it Outloud

Haven’t you had a time when you talked to someone about a problem but you needed to provide more context for that person to understand better what is going on for them to help you, but you ended up finishing the conversation before the other person talked as you realized what you needed to do?

One of the best ways to find solutions is by talking out loud the code, line-by-line, to someone else or to a rubber duck. This is more commonly known as the rubber duck debugging technique. This is useful sometimes and will help you come across a solution without you even trying to think of a solution.

5. Debug Your Code

Logging pieces of information can only get you so far in understanding the root cause of an error. Many programmers like to clutter the code full of logs making it harder to understand. A quick log can oftentimes provide meaningful information. However, that’s not always the case.

Programmers not debugging their code are making it hard on themselves to understand the problem and tu find a solution. There are cases where programmers don’t know how to debug in a specific programming language. Setting up your local environment must be the first thing you do before starting to write code, which includes setting up debugging tools. This could be time-consuming if you haven’t done it before. However, being able to debug your code is a blessing when you have code with thousands of lines and you are trying to spot the problem.

In case you already have your debugging tools set up, I encourage you to take advantage of them. Sometimes we think we understand how the code works. However, once we start debugging we find behaviors we didn’t anticipate when we initially added our piece of code.

6. Implement an Ugly Solution

Implementing an ugly solution is a hard choice for those who always look for quality code. The reason being is because there is a pre-existing high expectation of delivering high quality all the time, whether it is a highly reusable function or a more performant solution, or following best practices, your brain focuses the attention on writing quality code.

Sometimes an ugly solution can be the best solution. At the end of the day, programmers make things work and not write reusable and high performant code that fails. If something small fails, the whole project could fail, and users quickly lose trust in the software. A better approach is to make things work first, then optimize or improve off of an existing solution. Overengineering is very common when there shouldn’t be. Keep it simple. Keep it ugly. That’ll do the trick sometimes.

7. Comment Out Chunks of Code

This is one of my favorite techniques to understanding what the problem is. Computers run the code that is written. They don’t guess or decide whether or not to execute a piece of code. They just do it. If the code doesn’t exist or is commented out, it won’t run it.

Commenting out chunks of code is a simple and effective approach to getting you unstuck. Sometimes you don’t know what the code does or cannot figure out an unexpected behavior. By commenting out certain pieces of code, you will start getting helpful cues of where the code breaks. Sometimes we think it is failing at the end of a function when in reality it is breaking at the beginning of a function.

Commenting out code won’t get you unstuck, but having a clear understanding of the problem is better than trying all things possible to make something work without knowing what you wrote in the first place.

8. Google it, aka Research, Research, and Research

It is funny how we have adopted the word “google” to mean to search it online. Programmers should be ok googling as many times as they need to. At the end of the day, it is a tool. It is not about the quality of the tools, but how well you know how to use the tools. Like many things in life, it takes time to master how to use the tools and it is no different when googling.

Sometimes you notice other people googling for the same solution you are stuck for hours and they are successful after you had spent hours and hours googling in hopes to get a solution. With more time and experience, you will be able to improve your research skills and discover search patterns that will allow you to find the information you need to move forward rather than remain stuck.

9. Ask Questions to Someone Else

There is nothing wrong with asking for help or having a second pair of eyes to look at our code. Although oftentimes junior programmers ask questions to more experienced programmers, there is nothing wrong if you have 15 years of experience and you ask someone who has a few years of experience on their back.

It is complex to know it all in the world of programming. There will always be something someone knows that you don’t know. It is surprising sometimes to see where some of the best answers come from, and some of them might be from people you never thought they could.

10. Ask Questions in Forums

Many programmers look for other solutions to common problems, read StackOverflow and GitHub forums but never post a question. There might be different reasons why many don’t do it.

Some people are afraid to ask questions publicly and expose themselves to being pointed at as unintelligent. However, sometimes is surprising to see how many people have the same question you have.

Other people don’t do it because of laziness. We become lazy at doing certain simple things without realizing it. For instance, some programmers don’t ask questions in forums because they don’t have an account in that forum, even if they visit the forum over and over. It is quick to create an account. However, the desire for looking for similar questions leads up to not even try posting the question. In other cases, programmers need the answer right away and can’t wait for someone to answer the question in the forum. Posting the question in a forum and working on sometime while you get some answers might most efficient use of your time in some case.

11. Check the Documentation

Not everyone does this at first. However, the documentation is made to provide a single source of truth to how a programming language, library, framework, or architecture works. Spending some time reading through the documentation gives you a better understanding of how things work as well as provides you with ideas on how to tackle the same problem using different approaches.

12. Take Breaks or Walk Away

When you have tried several things and researched a lot of information but you can’t still make things work, you become tight and stressed. Taking a break is your best bet at this point. Going for a walk or stepping away from the computer are simple, yet effective ways to declutter your mind and relax for a little bit.

You could opt to walk away but still think about the problem you can’t solve. The main difference here is you are not staring at a screen reading your code or online information that distracts you from thinking clear after a while. Being able to put pieces of information in a zero to low distraction environment helps many with coming up with solutions. Just make sure to take a pen and paper so you write it whenever you come across them.

13. Let it Go

There have been cases where software has a particular error that never gets solved as it doesn’t impact the user’s experience or doesn’t compromise the business logic. In other cases, it is an error nobody in the team has been able to solve before due to its complexity.

Regardless of what the reasoning behind is, it is ok to not moving forward with attempting to make something work. Initially, you might not feel good about this as per your desire of making things work as a programmer. However, sometimes not insisting to make work things that were not meant to work is the best decision.

Shower Aha! Moments

The best moments are whenever you are doing something different than trying to fix a programming problem and unexpectedly you come across a solution. Aha! Those are the moments you enjoy the best as a programmer and also find it hard to explain to someone why you wanted to work on complex stuff at first. Therefore, if you are stuck, don’t let it get you down. Find that as an opportunity to challenge yourself and demonstrate you can make anything work!

Is Node.js Single-Threaded or Multi-Threaded? and Why?

Andres Reales — Tue, 07 Sep 2021 11:39:13 +0000

Have you been reading multiple articles trying to understand whether Node.js is single-threaded or multi-threaded? Why are there many of them saying single-threaded and others saying multi-threaded? I’ve been there and after reading one article after another, it seems there’s always a doubt in the back of your mind telling you the concept is still not clear. In this article, I hope to clarify this confusion.

According to Node.js documentation, a Node.js application runs using the event loop. The event loop is what allows Node.js to perform non-blocking I/O operations and explains how Node.js can be asynchronous. The event loop, aka the main thread, allows running one thing at a time. Having said that, Node.js JavaScript code runs on a single thread.

Now, there are several points you have probably read about in different articles such as using worker_threads making it multi-threaded, or the programming language used to develop Node.js applications makes it single-threaded, etc. I will cover those relevant points, but before we move forward, I’ll refresh your knowledge with regards to what single and multi-thread processes are.

What a Single-Threaded Process is

A single-threaded process is the execution of programmed instructions in a single sequence. Having said that, if an application has the following set of instructions:

Instruction A
Instruction B
Instruction C

If these set of instructions are executed in a single-threaded process, the execution would look like the following:

What a Multi-Threaded Process is

A multi-threaded process is the execution of programmed instructions in multiple sequences. Therefore, instructions won’t have to wait to execute unless multiple instructions are grouped within different sequences.

Why Node.js is Single-Threaded?

Now you know Node.js architecture is single-threaded. However, why is it single-threaded? My first question for you is, do you understand how the event loop works? If not, I recommend you check this article.

However, to keep things simple, the event loop runs one process at a time. That means it can only execute one function at a time, and since functions can have multiple instructions, the event loop will execute one instruction at a time.

At first, it sounds not efficient providing poor performance. However, quite the opposite it turns out to be more performant and scalable than other multithreaded alternatives such as Java.

Running a multithreaded solution involves leveraging multiple cores of a system. Having said that, if one thread is waiting for an I/O response, the other threads could still be in progress. In theory, multithread seems the way to go, but what we are not taking into consideration is that a thread could still be blocked regardless of other threads being available.

The beauty of the event loop is not of running everything in a single thread, but it’s available to “put aside” long time-consuming I/O operations to keep the execution of other instructions. This is the reason why we get fast responses even though we could have multiple users making requests to a Node.js API at the same time.

The first thing to clarify is there is no such thing as making requests at the same time. It is perceived to have run requests at the same time, but in reality, the event loop runs processes defined for each request based on the order in which it arrived. Let’s make this concept simple to understand by using an example. In this case, we are going to assume we have the following API endpoints:

/getCars
/updateCar
/updateDriver

Remember, request are not made at the same time. The event loop will handle the requests in the following order assuming that was the order they were requested:

/getCars
/updateCar
/updateDriver

The event loop will execute the first instructions from the /getCars endpoint. At some point, there will be an instruction which is a request from the API to a database to fetch the cars. This is considered an I/O operation. This process can take a short or long time to execute. Regardless of how fast this gets executed. The event loop will trigger this request and move it “aside” to prevent blocking the thread from executing other instructions. However, it will resume triggering the set of instructions for the /getCars endpoint once a response is sent back from the database.

Therefore, while the request made from the /getCars endpoint to the database is triggered and waiting for a response, the /updateCar endpoint will trigger its set of instructions. If there is not I/O operation within the /updateCar endpoint, the /updateCar endpoint will return a response before the /getCars endpoint returns a response.

In a similar way, if the /updateCar endpoints have an instruction to execute an I/O operation, the event loop will trigger it but won’t block the thread from executing instructions. In this way, it could either start executing the set of instructions from the /updateDriver endpoint, or resume the execution of the /getCars endpoint once it receives a response from the database. This is based on whichever is added first in the event queue.

If you think about it, the major benefit of Node.js architecture is not the fact of being single-threaded, but its ability to not block the thread from executing other instructions. This is one of the main reasons Node.js is an excellent choice for developing APIs as these are heavily based on I/O operations. The event loop’s smart system to execute intensive I/O operations and resume processes once the I/O operations are completed while not worrying about issues that can come with using multithreaded solutions such as deadlocks or race conditions makes it a no brainer for many teams to use Node.js.

Don’t Block the Event Loop (aka the Main Thread)

Like most solutions, there are advantages and disadvantages, and Node.js is not an exclusion of this. Since we know Node.js runs using the event loop, aka as the main thread, blocking the loop will indeed prevent the system from running other instructions regardless of whether they belong to a single process or multiple different processes.

Didn’t you say the event loop “triggers intensive operations and move them aside, resuming a process once the operations get a response”?

Yes.

However, it is important to clarify the event loop’s ability to “resume” an I/O operation process doesn’t mean it will be capable of getting away around with an intensive CPU operation. The beauty of an I/O operation is to use external CPU processing power to execute a process. However, if our Node.js application is the one using intensive CPU processing power to execute power, it means we cannot execute other sets of instructions until the heavy processing power instruction completes. This is called blocking the event loop.

Confusing JavaScript and Node.js Threading Process

It is important to not say Node.js is single-threaded because the JavaScript programming language is single-threaded. This is incorrect. JavaScript can run in different programming environments, and Node.js being among the most popular environments using JavaScript. Therefore, it is a common misconception to think JavaScript is single-threaded. When speaking about single-threaded or multi-threaded, we should look at how the programming environment operates rather than how the language in itself.

What About Worker Threads in Node.js? Does it Make Node.js Multi-threaded?

While the implementation of worker threads in v10.5.0 allows the use of threads that execute JavaScript in parallel, Node.js event loop architecture is single-threaded based.

What really happens when spawning multiple threads using worker_threads is the generation of multiple V8 engines sharing memory. Workers threads are useful for performing CPU-intensive JavaScript operations. This frees up the main thread’s event loop from CPU-heavy processes and keeps it available for what is best for intensive I/O operations.

The expense of generating worker threads doesn’t result in a positive impact around I/O intensive work as in the end, each thread will have the same mechanism: one event loop per thread, which won’t be any different than opting not to use worker threads. Node.js’s built-in asynchronous I/O operations are more efficient than workers can be.

Having said that, each thread will use the same Node.js architecture which is single-threaded based. You can achieve multithreading by generating multiple nodes or Node.js V8 engines which in isolation are single-threaded. It is still correct to say Node.js is not multi-threaded.

How Frequently Programmers Google? Is It Bad? Is It Normal?

Andres Reales — Wed, 01 Sep 2021 11:52:52 +0000

Starting in the programming world is never easy, but it can turn into one of the most rewarding things you can do for a living. If you are relatively new or have a couple of years of programming, you probably had an infinite amount of questions, some of them could be along the following lines:

How often pro programmers use google?
How often expert programmers use google?
Is it ok to google all the time as a programmer?
Am I a programmer or am I a googler?
Am I cheating if I constantly google as a programmer?
Do I use too much StackOverflow to find answers?

Let me tell you something, I’m glad you are asking yourself those questions. That’s often a hint telling me you are looking to level up your programming skillset, and googling is one of those skills needed for those who are serious about programming.

How Frequently Should I Google as a Programmer?

It is funny how we included google as a verb in our vocabulary. This has been due to the impact that Google (and other search engines) has had in our daily lives. Google is our dictionary where you can find just about everything within seconds. On top of that, we use it all the time. Every day, every hour, and even every minute.

Having said that, regardless of whether you are a programmer, an artist, a mechanic, an accountant, etc. We all google all the time.

Why? Because we don’t know all the answers. Our brain can store only so much information. The internet can have an infinite amount of information and Google is capable to find answers to our questions without us having to do research.

Therefore, **programmers should use google as frequently as they need. Sometimes this could be 10 times a day, 10 times a morning, or 10 times an hour. You can google as many times as you want. The important questions to ask are:

How good are you at googling?
Are you effective at googling?

Is It Normal to Google Too Much as a Programmer?

Yes, it is normal. Enthusiasts, Junior, Mid-Level, and Senior programmers google too much. The reasons can be different: to find a solution to a problem, to learn a new programming language, to learn how to develop a feature, to learn how to improve soft skills, to learn how much money the software development industry pays, etc.

The reasons are infinite and all of them are related to programming. Therefore, there is not such a thing as “too much googling” because chances are you can’t keep up with the number of times you already google in a day unless you code an application that does that.

Is It Bad to Google as a Programmer?

No, it is not bad to google. It is how you use google as a programmer that matters. In fact, googling is a skill programmers should master.

Am I a Good Programmer or a Good Googler?

If you are good at googling, chances are you are a good programmer. However, we need to clarify what is googling. Googling is the process of searching for valid information based on our doubts or lack of knowledge with regards to a topic.

Or in simple words: googling is the act of doing online research.

The number of times programmers spend searching for information is more than the amount of time spent at coding. A common misconception about programmers is they write 24/7 or 8 of the 8 hours of their workdays.

This is not realistic.

Journalists and bloggers spend more time writing articles than programmers. I can validate this point as I am both, a blogger and a programmer. It takes more time to write about relevant content other people are interested in.

Blogs and articles often require an in-depth level of explanation. Software applications might be complex but may not require large amounts of code. Most likely, it will require large amounts of documentation, which in theory is not the act of programming, even though it is part of what a programmer should do.

Google is a Tool

Depending on your level of expertise, programmers know a number of languages: Python, JavaScript, Golang, Java, C#, PHP, etc. If we look further, you can use frameworks or libraries based on the programming language: React, Angular, Vue, Node.js, Express.js, Laravel, .NET Framework, Django, etc. All of them are tools that help you build software, in this case, web applications (there are other frameworks or libraries for game development, machine learning, mobile applications, etc.).

Think about it, just because you have weights and a treadmill doesn’t make you fit. What makes you fit is using those tools to make you fit. Let’s suppose other people have the same gym equipment. However, you notice some of them are not as fit as you are, or some are in better shape than you. It comes down to how to use to their best knowledge the tools available to maximize the benefits.

Coming back to our programming world, what matters most is not the number of programming languages you know, but the way you use them. You might know React, Angular, and Vue. All of them are frontend frameworks. Maybe, you are good at using any of them to develop web applications. However, whenever you start facing slow performance in your application, do you know how to improve this deficiency? This can hurt the business by impacting the number of customers they lose just because the application is slow.

The same way we could think about googling. Many programmers use google, which several of them find information related to issues they are trying to solve, but only a few of them know what to look for to fix the problem they are trying to fix, without the need of copying and pasting code from StackOverflow.

Senior Programmers Spend Minutes Googling, Junior Programmers Spend Hours

No matter how gifted you are, everyone starting their programming journey will spend a lot of time searching for information to help them pass a roadblock in the development process. Googling is a skill not often taught in school or bootcamps. Hence, junior programmers are not the most effective at finding the correct information.

As you keep practicing and googling more often, you become better at recognizing reliable sources of information and finding articles that provide meaningful value making you spend less time researching and more time coding.

Now, let’s say you can recognize a good number of websites where you can find good information. Some of the many popular out there are StackOverflow, Medium, Dev.to, FreeCodeCamp, Hackernoon, etc. Even then, you are still spending too much time doing research. Unfortunately, just because these websites are reliable, it doesn’t mean they are always going to have the answer you are looking for.

It is common for programmers to develop things they don’t know how to do. In this case, even if you have improved your googling skills, and it still takes a lot of time! In this case, programmers spent a lot of time because they are trying to find good information about something they don’t know. Even if there are good websites out there, even if you know how to search, the reality is you are starting to learn new concepts and you are trying to put the pieces of information together to make your search more and more effective.

Sometimes what you need is experience. The more experience you have, the more knowledge you acquire, the more you know what to look for, the more you know how to recognize the correct answers. It’s crazy how something simple as googling can be complex to master as it is perceived to be already simple to do.

Problems Why New Junior Programmers Struggle Googling
With the rise of technological innovations and the more focus on institutions such as schools, universities, and bootcamps that quickly try to educate new engineers to help them land in their first programming job, it feels there is more and more talent not prepared for what a real job could be like. Bootcamps often do a better job at this as their focus is to train engineers for real-world jobs in the shortest amount of time possible.

Even that being the case, everyone who starts their first programming job, will learn a lot of things that cannot be taught. That’s normal and that’s how things work. There is no secret to that. However, trying to rush the learning process creates some failures in the education system. A couple of them is to read and analyze.

For example, many programmers at some point, including myself when I started, google the answer of a problem, find StackOverflow as the first google search, then look at the first answer with some code, and copy and paste that code in hopes that it will be the answer they’ve been looking for.

There are a lot of problems here:

StackOverflow has become first place to go for almost all programmers. Since answers are upvoted in stackoverflow, the first answer is often “best” answer for a question. The problem is it might be the best answer for the question being asked, not the question you have. Even if both questions are very identical.
Since StackOverflow is the first place to go, programmers don’t even read the question asked.

Programmers are reading the title of the search results, but not the description. Reading the description can save you sometime and prevent you from opening a new tab for you to read at the article later. Sometimes the description can give you enough information to decide whether or not it is worth reading the article.
As you noticed, the main issue is reading. Yes, there is a lot of copy and paste in the programming world. However, that doesn’t mean you don’t know how to read. It’s crazy how something “simple” such as reading is complex. The true issue for many who struggle with their googling skills is failing to read. Don’t confuse skim reading and failing to read. Skim reading allows you to be efficient at finding information, even if you compromise a little on the depth of the information you are looking for.

Senior programmers are good at googling because they read what they are searching for. They have experience googling effectively. If you think about those programmers who started their journey when there was no StackOverflow, or not even internet, the only thing they could be to read books about the programming language, read the logs of the application, debug their code. They were forced to read the documentation and analyze how truly their code worked. No wonder why there were not many programmers before the internet was a thing!

I hope this article gave you insights and reasons why you need to master the art of googling as a programmer. Do you have different opinions? Let me know, I would want to hear your thoughts.

Is it Bad to Commit to Master Branch? Why? Senior Engineer’s Advice

Andres Reales — Sat, 28 Aug 2021 16:12:44 +0000

Looking to improve your skillset as a software engineer is always a good indicator you are passionate about developing software. One common question new developers tend to ask is whether they should commit to master branch their work. I hope this article provides you with meaningful insights into this practice.

Master branch often reflects the code used in production. Hence, it is not a good practice to commit your work to the master branch. It is recommended to branch out or create a copy of the master branch in a different branch where you will commit your work.

Note: Don’t confuse the master branch with the branch called “master”. For the sake of simplicity, the branch named “master” in most of the projects is defined as the master branch. However, based on the project and/or company you are working for, the master branch could be named differently such as “main” or “dev”.

Although committing to a master branch is a bad practice, it doesn’t mean you can’t. However, I’ll explain in depth why this practice is seen with bad eyes in the industry.

Why is it a Bad Practice?

Throughout my experience developing software and working on a variety of projects (solo projects, small company projects, and large enterprise projects), I’ve seen the following issues that happen by committing to a master branch:

Many Developers Working on a Project

When I say “many” developers, I mean more than one developer. If you are working with other developers, you will quickly find yourself in a hell merge. In other words, there will be multiple changes applied to the branch simultaneously which could or not create conflicts with your local changes.

Although you can always merge conflicts, the chances of not correctly merging conflicts correctly will increase, which could lead to the loss of good code. Also, merging conflicts often require communication between the developers who have applied changes to the master branch, which slows down development speed. Every time you commit to master branch will increase the probability of talking to your coworkers to prevent poorly resolving conflicts.

Lost Track of Specific Feature Work

For those who have been developing software for some time, you will know how slim the chances are in getting correct the first version of the code of a feature. Also, the amount of time developing the code will change based on the complexity of the feature. Therefore, making progress on a feature and committing changes is an advisable practice. It is better to have incomplete code rather than no code. This allows keeping track of all the changes made to develop a feature. It also allows other developers to continue or finish your work in case you are away for a few days, whether it is for vacations, sick days, or emergencies.

Automated Deployments Triggered in Master Branch

Depending on what company you are working for, this could apply to you or not. However, companies developing large enterprise projects often have automated deployments in place when new code is in the master branch. Hence, committing and pushing incomplete code will impact the version deployed. The good news is large enterprise companies will have several deployment stages prior to production, such as development, testing, staging, and finally production. Therefore, automated deployments will go only to the immediate lowest environment such as development or staging environment.

When is it Ok to Commit to Master Branch?

If you are working on your first few projects or have projects you like to work on during your free time and you are the only contributor, it is ok.

I Committed to Master Branch, Am I in Trouble?

The short answer is no. You are not in trouble.

There are high chances you are using Git for version control. The good news is Git lets you undo commit or go back to a previous commit. Better yet, if you committed your changes to the master branch, but you haven’t pushed those changes to your hosting repository, such as Github, you can either reset your changes or branch out and push the new branch to your repository. The good part is Git provides plenty of options to make changes in case of accidents.

Can I Prevent Committing Accidentally to a Master Branch?

There are ways to prevent from committing to a master branch. One of them is by configuring pre-commit hooks in case you want to prevent local commits. Another option used in projects with several developers using a Github repository is to set up branch protection rules.

How to Set up Basic Node.js + Express.js Server with TypeScript

Andres Reales — Thu, 01 Jul 2021 14:15:45 +0000

Note: This post is part of Learn How to Use TypeScript With Node.js and Express.js series. Click here to see the first post of the series.

Getting Started

First things first, we need to create the directory for our application:

mkdir express-typescript

Time to set up our package.json file where we can define all our dependencies as well as executable scripts.

npm init

Once this script is run, it will ask you the following questions:

package name: (src) express-typescript
version: (1.0.0)
description:
entry point: index.ts
test command:
git repository:
keywords:
author:
license: (ISC)

Feel free to provide the correct details. For now, the only information we cared to provide is the package name and the entry point set to index.ts.

Installing Dependencies

Since we are going to work with Express.js, we need to install Express.

npm i --save express

We need to install TypeScript as well as Express types to take advantage of TypeScript, but in this case, we will install them as part of the dev dependencies.

npm i --save-dev typescript @types/express

So far, this is how your package.json should look like:

{
  "name": "express-typescript",
  "version": "1.0.0",
  "description": "RESTful API Example of using Express with Typescript",
  "main": "index.ts",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Andrés Reales",
  "license": "ISC",
  "dependencies": {
    "express": "^4.17.1"
  },
  "devDependencies": {
    "@types/express": "^4.17.11",
    "typescript": "^4.2.4"
  }
}

Create Minimal Server with Express.js and TypeScript

Let’s create what could be considered the most basic server using Express.js. Inside the src folder, create an index.ts file and copy the following code:


import express, { Request, Response } from 'express';

const app = express();
const port = 3000;

app.get('/', (req: Request, res: Response) => {
  res.send('Hello World!');
});

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
});

As you notice, it will be a simple GET API endpoint returning a message.

Running TypeScript Files in Node.js: Understanding the Process

First, it is important for you to understand the process that happens to run TypeScript files in node.js. Previously, you created a simple server inside the index.ts. If we were working with plain JavaScript, a similar code could be written in a js file such as index.js. Normally, you will run a js file using the node command.

node src/index.js

If we try to do something similar with index.ts file, the terminal will fail due to syntax errors as we are writing code in TypeScript.

// it will fail
node src/index.ts

What we need to do is to compile our TypeScript code into JavaScript code, and we are going to do that using the tsc command which it is available after installing typescript dependency in the project.

npx tsc src/index.ts

This will generate an index.js file. Now that we have our JavaScript file, we can use node to run our code.

node src/index.js

This will run our server in port 3000. Try opening your browser http://localhost:3000/. You should see a Hello World! message.

We could also set up a tsconfig.json file. This file is used to determine what all TypeScript files will be compiled in a project. This is useful especially when you want to avoid compiling files containing unit or integration tests. Feel free to checkout for more information about the compilation options available in TypeScript.

Running TypeScript Files in Node.js: Quick Process

There is a package available called ts-node which allows executing our TypeScript file in node. Therefore, we are going to install ts-node as part of our development dependencies.

npm i --save-dev ts-node

Once the package is installed, we can run our project with only one command.

npx ts-node src/index.ts

The best thing is that you don’t see any index.js file generated.

Why using `npx` to run ts-node?

At the moment you installed npm, it came with npx. This makes it so we have a command to manage dependencies, and another one to execute dependencies.

npm (package manager)
npx (package eXecutable)

This gives us the opportunity to execute local dependency files, such as, ts-node.

If we were to install ts-nodeglobally like this:

npm i -g ts-node

We could directly execute the ts-node command.

ts-node src/index.ts

However, this can be problematic especially when working with specific versions of dependencies. The npx command is also useful when looking to run packages only once and delete them once they are executed. For example, if you try to create a react application using create-react-app, React’s tutorial recommends using the npx command.

Setting Up Scripts in the package.json

Now that we understand how to run TypeScript files, we can set up a couple of scripts in the package.jsonfor our application. We are going to start by setting the start script in the package.json file.


"scripts": {
    "start": "npx ts-node src/index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Once we save, we can open the terminal and run npm run start and you will notice our project is running again.

However, we constantly make changes during the development phase, and it turns time-consuming to stop and re-run the project after every change we make to the code base. We are going to install nodemon.

npm i --save-dev nodemon

Now we can set up another script such as start:watch to run nodemon.

"scripts": {
    "start:watch": "nodemon src/index.ts",
    "start": "npx ts-node src/index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Prior to running npm run start:watch we need to add an additional configuration. Let’s create another file called nodemon.json in the root of the project, not inside the src folder. Once created, assign the following configuration.

{
  "watch": "src/**/*.ts",
  "execMap": {
    "ts": "ts-node"
  }
}

This file is the configuration setup at the moment of executing nodemon. In this case, it will execute ts-node for any .ts file that is executed using nodemon.

Now it is time to try our script.

npm run start:watch

You should see your application running. Try making changes to the index.ts file such as modifying the log generated inside the callback of the listen function.

console.log(`I just changed this log: http://localhost:${port}`)

Once you save, you should see the updated log in the terminal.

This is the final value for our package.json of our project.

{
  "name": "express-typescript",
  "version": "1.0.0",
  "description": "Example of using Express with Typescript",
  "main": "index.ts",
  "scripts": {
    "start": "npx ts-node src/index.ts",
    "start:watch": "nodemon src/index.ts",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Andrés Reales",
  "license": "ISC",
  "devDependencies": {
    "@types/express": "^4.17.11",
    "nodemon": "^2.0.7",
    "ts-node": "^9.1.1",
    "typescript": "^4.2.4"
  },
  "dependencies": {
    "express": "^4.17.1"
  }
}

Setup TypeScript Configuration

The tsconfig.json file specifies the root files and the compiler options required to compile a TypeScript project. Without it, our TypeScript project would still feel as a JavaScript project because it we are not enforcing the usage of types in our codebase. Therefore, we are going to create a tsconfig.json in the root folder of our project. Once this is done, add the following configuration:

{
  "compilerOptions": {
      "module": "commonjs",
      "esModuleInterop": true,
      "allowSyntheticDefaultImports": true,
      "target": "es6",
      "noImplicitAny": true,
      "moduleResolution": "node",
      "sourceMap": true,
      "outDir": "dist",
      "baseUrl": ".",
      "paths": {
          "*": [
              "node_modules/*",
              "src/types/*"
          ]
      },
  },
  "include": [
      "src/**/*"
  ]
}

Later on, you can make changes to the configuration based on your project needs. For now, this is a good starting point.

What’s Next?

That’s all for this article, and I’m sure you want to get going with more. In the next section, I will explain How to Set up RESTful API Routing using Express.js with TypeScript.

The post How to Set up Basic Node.js + Express.js Server with TypeScript first appeared on Become A Better Programmer.

How to Use Error Handler Middleware with Express.js and TypeScript

Andres Reales — Wed, 30 Jun 2021 13:03:43 +0000

What is an Error Handler in Express.js?

Error handlers in Express.js are in charge of catching and handing errors that happen during runtime. By default, Express.js provides with a built-in by default.

How Does The Error Handler Work in Express.js?

Whenever there is an error occurring in the server, unless you have a custom error handler, Express.js catches the error and sends a response to the client with the error message using its default error handler. The reason Express.js is eager to catch all errors is not only handling properly the errors, but also to correctly empty out unused resources after the application starts running again.

In other words, Express.js is preventing the server from having memory leaks and properly “garbage collects” objects once an API endpoint request is handled by a function.

Let’s explain using an example. Let’s say we have attached a handler function a simple API endpoint.

    app.get('/car/model', function (req: express.Request, res: express.Response) {
      const car = { model: 'Santa Fe', year: 2010, brand: 'Hyundai' };

      res.send(`The car model is ${car.model}`);    });

Besides the fact of returning a message with car model, let’s dig a little deeper of what is going on.

We created a car variable which contains a car object. We are allocating memory space every time we create a variable. As soon as we send a response back to the client, we are no longer needing the car variable. However, in theory car variable still uses memory space.

Does it mean we are loading up the memory every time we send a response to the client?

When incorrectly handled, yes. We reduce the memory space by not correctly freeing up that memory space. In other words, this is what we call memory leaks.

But! Express.js is protecting us from suffering memory leak issues by using a default error handler.

What Does the Error Handler Have to Do with Preventing from Suffering Memory Leaks?

In order to understand how error handlers are helping from Express.js application from crashing, we need to first understand how the Node.js engine works.

If you didn’t know, Node.js uses V8 engine. V8 engines provides with a built-in garbage collector to manage memory space which leads into a better performance and takes away that extra work from developers.

If you want to understand how the garbage collection work using the V8 engine in depth, I recommend you to read the article written on the V8 engine website. In short, the V8 engine determines memory as dead or alive, meaning if a memory spaces is used, then it is alive. If it is not longer used, then it is dead. Those with the dead status are eligible for garbage collection.

If we go back to the example of the API endpoint using a simple handler function, you will notice that the function is scoped. Once we send a response to the client, the function and any scoped variables are no longer used, making them eligible under the V8’s garbage collection engine.

In the case we force an error in the handler function, such as:

    app.get('/car/model', function (req: express.Request, res: express.Response) {
      const car = { model: 'Santa Fe', year: 2010, brand: 'Hyundai' };

      // forcing to trigger an error
      car.model();

      res.send(`The car model is ${car.model}`);
    });

And there were no error handlers, the client would never get a response in first place. Also, the request will “hang” on, meaning that our handler function would be using alive memory. Since this memory is alive, the V8 engine garbage collection would not work, causing memory leaks in the server.

Are There Problems with Using Express.js Default Error Handler?

There are no problems with the default error handler. However, it is important for you to understand some concepts. Let’s say we use our previous code example to manually force to trigger an error. I encourage you to make a request to the endpoint. You should get an error response, which it is expected.

However, this error response is not user friendly. It is rather technical and provides with the stack information about the server, such as the folder structure of the API. This information is beneficial if you are troubleshooting errors during development stages, but dangerous if this were to happen in production environments.

Fortunately, Express.js can prevent displaying any sensitive information from errors in the production stages. To make this work, you should make sure the NODE_ENV var is set to “production” prior to creating the express application.

Why Should I Implement a Custom Error Handler?

There can be different reasons why you would want to implement a custom error handler. For example, there projects that don’t set NODE_ENV as “production” in production stages. This could lead to leaking sensitive information about the system if not properly handled.

There are other projects that require to send a specific error object format whenever some unexpected error occurs.

How to Write a Custom Error Handler in Express.js using TypeScript?

Error handler middleware work very similar to any other middleware. However, there are a few things to take into consideration.

When developing an application-level or a route-level middleware, the handler function expects to receive three arguments: Request , Response , and NextFunction. In the case of developing a custom handler error, the handler function is expected to have four arguments. ErrorRequestHandler , Request , Response , and NextFunction.

Let’s go ahead an create our own custom error handler. In our case, we want to send custom error messages in case we want to provide meaningful information to the client about why the server cannot execute a certain process. One example could be of reading the records of a spreadsheet send by the client containing invalid data type for a specific column. Therefore, our first step is to create a CustomError object.

1. Create CustomError Object

First, create a custom-error.model.ts file in the following folder location: src/api/models. Once it is created, we are going to generate a class and export it.

    export class CustomError {
      message!: string;
      status!: number;
      additionalInfo!: any;

      constructor(message: string, status: number = 500, additionalInfo: any = {}) {
        this.message = message;
        this.status = status;
        this.additionalInfo = additionalInfo
      }
    }

2. Create Custom Error Handler Middleware

Create a file called error-handler.middleware.ts inside the src/api/middlewares folder. Once created, we are going to add the following logic:

    import { Request, Response, NextFunction } from 'express';
    import { CustomError } from './../models/custom-error.model';

    /**
     * Custom error handler to standardize error objects returned to 
     * the client
     * 
     * @param err Error caught by Express.js
     * @param req Request object provided by Express
     * @param res Response object provided by Express
     * @param next NextFunction function provided by Express
     */
    function handleError(
      err: TypeError | CustomError,
      req: Request,
      res: Response,
      next: NextFunction
    ) {
      let customError = err;

      if (!(err instanceof CustomError)) {
        customError = new CustomError(
          'Oh no, this is embarrasing. We are having troubles my friend'
        );
      }

      // we are not using the next function to prvent from triggering 
      // the default error-handler. However, make sure you are sending a 
      // response to client to prevent memory leaks in case you decide to 
      // NOT use, like in this example, the NextFunction .i.e., next(new Error())
      res.status((customError as CustomError).status).send(customError);
    };

    export default handleError;

3. Attach Custom Error Handler as The Last Middleware to Use

Open the index.ts file. Then, import the custom handler and add it to the application as the last middleware. In other words, make sure to use the last app.use for the error handler middleware. If you are following the Learn How to Use TypeScript With Node.js and Express.js series, your index.ts file should look like the following:


import express from 'express';
import compression from 'compression';
import helmet from 'helmet';
import bodyParser from 'body-parser';
import cors from 'cors';
import { generateToken } from './api/utils/jwt.utils';

import routes from './api/routes';

import logger from './api/middlewares/logger.middleware';
import errorHandler from './api/middlewares/error-handler.middleware';

const app = express();
const port = 3000;

// Only generate a token for lower level environments
if (process.env.NODE_ENV !== 'production') {
  console.log('JWT', generateToken());
}

// compresses all the responses
app.use(compression());

// adding set of security middlewares
app.use(helmet());

// parse incoming request body and append data to `req.body`
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// enable all CORS request 
app.use(cors());

// add logger middleware
app.use(logger);

app.use('/api/', routes);

// add custom error handler middleware as the last middleware
app.use(errorHandler);

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
});

4. Test Custom Handler

First, force an error in one of the function handlers for any of your API endpoints. In our case, we are going to modify the getTeams function we have in the teams.controller.ts file.


export const getTeams = (req: Request, res: Response) => {
  const test = {};
  //@ts-ignore
  test.nonExistingMethod();

  res.send(TEAMS);
};

Once, me make a request to PORT/api/teams/ we should get the following error object:


{
    "message": "Oh no, this is embarrasing. We are having troubles my friend",
    "status": 500,
    "additionalInfo": {}
}

Now, let’s use the CustomError object and throw a CustomError instance inside our function handler instead.


import { Request, Response } from 'express';
import { CustomError } from './../models/custom-error.model';

const TEAMS = [
  { id: 1, name: 'Real Madrid', league: 'La Liga' },
  { id: 2, name: 'Barcelona', league: 'La Liga' },
  { id: 3, name: 'Manchester United', league: 'Premier League' },
  { id: 4, name: 'Liverpool', league: 'Premier League' },
  { id: 5, name: 'Arsenal', league: 'Premier League' },
  { id: 6, name: 'Inter', league: 'Serie A' },
  { id: 7, name: 'Milan', league: 'Serie A' },
  { id: 8, name: 'Juventus', league: 'Serie A' },
];

export const getTeams = (req: Request, res: Response) => {
  throw new CustomError('forgot something?', 400, 'you can do better than that');
  res.send(TEAMS);
};

The expected error object result should be the following:


{
    "message": "forgot something?",
    "status": 400,
    "additionalInfo": "you can do better than that"
}