DEV Community: Maxim Orlov

One or Two-Column Resumes: Best Choice for Aspiring Web Developers

Maxim Orlov — Wed, 22 Nov 2023 04:00:00 +0000

This article was originally published at https://maximorlov.com/one-or-two-column-resumes/

The design of your resume can make or break your job search.

A well-designed resume stays out of the way and effectively conveys your qualifications to the recruiter's scanning eye.

In contrast, a poorly designed resume is confusing, obscures important information, and fails to convince the recruiter to invite you for an interview.

With hundreds of applications per position, you want to do everything possible to pass the initial selection phase, where most applicants are eliminated.

Resume layouts typically come in two types: one-column and two-column. Which layout is more likely to increase your chances of securing an interview?

You might assume that a two-column layout is better, as it allows you to include more information and stand out. However, this is a misunderstanding.

These are the top three reasons why a two-column layout is likely hindering your job search.

Harder to read

Recruiters have to go through dozens or even hundreds of resumes for a single position. It's said that a recruiter spends at most 10 seconds reviewing a resume.

10 seconds! That's nothing.

In those 10 seconds, your resume must convince the recruiter to consider you for the position. That's not a small feat!

Your resume should be as easy to scan as possible, with minimal friction to the recruiter's eyes. A two-column layout complicates this by breaking up the visual field, requiring more focus and time to read — time you can't afford to lose.

Moreover, recruiters are more accustomed to scanning one-column layouts. This familiarity works in your favor, as the easier your resume is to scan, the more likely a recruiter will learn about your qualifications and consider you for the next round.

Formatting issues

Two-column layouts are challenging to format correctly. Managing whitespace and ensuring a cohesive flow is more complex than in a one-column layout.

Furthermore, a two-column layout is not update-friendly. Tailoring your resume for each job application (which you should!) can disrupt the balance between the columns. You're then left juggling the symmetry between the left and right column.

A two-column layout also is more prone to being distorted when saved in different file formats. The last thing you want is to send a jumbled mess to recruiters.

Formatting a one-column resume is already a challenge; going for a two-column layout adds unnecessary complexity.

Not ATS friendly

Many companies use Applicant Tracking Systems (ATS) to streamline their hiring process. An ATS parses resumes to simplify the recruiter's review. Some systems even score resumes on their match potential.

An ATS typically reads a resume from left to right, top to bottom. A two-column layout disrupts this logical flow, making correct parsing more challenging.

If the ATS can't fully interpret your resume, it may overlook key keywords, resulting in a lower score.

In a competitive job market, where hundreds of candidates apply for a single position, many applications are automatically rejected by these systems. You want to avoid automatic rejection and ensure your efforts are seen.

While ATS technology has improved and some have gotten better at parsing two-column layouts, you can't be certain which system will process your resume. Why take the risk?

Want to impress? Focus on content

Impress recruiters with your qualifications, not a fancy resume design.

Emphasize the impact of your work. Describe how your efforts benefited your team and led to measurable achievements. Use numbers to reinforce these points.

Highlight projects, even unfinished ones, that demonstrate your skills.

Ensure your resume clearly communicates why you are suited for the specific job you're applying for, including technologies and skills mentioned in the job description.

In conclusion, a one-column layout is the best choice for your resume. It's easier to read, update, and more likely to pass the ATS, giving you a real chance at the job.

Craft a resume that's impossible to ignore

Take the next step towards securing your dream job with a comprehensive resume checklist. Made specifically for aspiring software engineers, this FREE checklist (featuring 35+ points) ensures you not only stand out but also effectively showcase your skills.

By following these guidelines, you'll craft a resume that grabs recruiters' attention, highlights your unique talents, and increases your chances of breaking into tech. I guarantee that if your resume ticks all the boxes on this checklist, you'll start receiving more interview invitations.

Simply enter your email below the original article, and I'll send the checklist straight to your inbox.

ESLint Setup in Node.js: A Detailed Guide

Maxim Orlov — Tue, 10 Oct 2023 07:48:05 +0000

This article was originally published at https://maximorlov.com/eslint-setup-nodejs-detailed-guide-beginners/

A code linter can simplify your developer life by a lot. I couldn't imagine coding without one.

It immediately catches many syntax errors and potential bugs as I type. There's no need to wait until deploying to production to find out my code isn't working properly.

This rapid feedback loop empowers me to develop faster and with more confidence, knowing that I have a trustworthy tool watching my back.

Wondering how to start using a code linter with Node.js?

In this tutorial, I'll walk you through the step-by-step process of adding ESLint, the most popular JavaScript linter, into your project so you can start benefiting from it right away.

Requirements
This tutorial assumes no prior knowledge of ESLint and starts from the basics.

I assume you already have a Node.js project and consequently, an existing package.json file (set up with npm init).

Goals
By the end of this tutorial, you'll have a basic ESLint setup up and running. I'll also give you additional resources so you can delve deeper and further customize the linter if you want to.

Overview
Here's what we're going to do:

Install & configure ESLint in your Node.js project
Integrate ESLint with VSCode for real-time feedback within your editor

Without further ado, let's dive in.

Step 1 – Install & configure ESLint in a Node.js project

ESLint offers an interactive CLI package that simplifies installation and configuration. It prompts a series of questions about your project and preferences.

At the root of your project folder, open the terminal and type:

npm init @eslint/config

Here are the questions you'll face:

How would you like to use ESLint? - Select the second option: "To check syntax and find problems". ESLint can also enforce a coding style but for that, I recommend using Prettier instead.
What type of modules does your project use? - Choose the option that matches your project: ES Modules (option 1) with import or CommonJS (option 2) with require.
Which framework does your project use? - Since we're working with a Node.js project, select "None of these".
Does your project use TypeScript? - Pick "Yes" if applicable. Otherwise, opt for "No". If you're unsure, it's likely "No".
Where does your code run? - This is a multiple-choice question and "Browser" will be pre-selected. Deselect "Browser" and select "Node".
What format do you want your config file to be in? - Pick "JavaScript". JSON configurations lack comment functionality, and YAML demands familiarity with its syntax.
Would you like to install them now? - Depending on your earlier choices the dependencies will vary. At a minimum, the setup wizard will introduce eslint@latest to your project. Click "Yes".
Which package manager do you want to use? - Choose "npm".

Upon completion, the wizard will install dependencies and generate a .eslintrc.js file.

File structure highlighting `.eslintrc.js` and the corresponding version of `eslint` in the `package.json` file

Inspect your package.json file. You'll find the latest version of eslint listed under devDependencies. ESLint is a development dependency since you only need it during development to enhance your workflow. Production environments often omit development dependencies to speed up deployments.

If you opted for TypeScript, the wizard would also have added the @typescript-eslint/eslint-plugin and @typescript-eslint/parser packages. The former is an ESLint plugin with additional linting rules made possible by strict typing. The latter enables ESLint to comprehend TypeScript syntax.

Another addition to your project is the .eslintrc.js file. Inside, you'll find configurations that may differ based on your responses.

ESLint configuration specifying environment settings, extending recommended rules, and parser options

Let's delve deeper into each configuration so you understand what's going on. Regardless of your responses to the setup questions, these are the configurations you'll encounter:

env.es2021 - Introduces language-specific global variables from ECMAScript 2021. Recent additions to the language include BigInt, Atomics, and AggregateError. Why not 2022 or 2023? Because those ECMAScript versions haven't introduced new global variables. You could add es2023 to your config, but it wouldn't make any difference. Source
env.node - Includes global variables specific to Node.js, such as process and AbortController. Source
extends - Enables additional rules recommended by ESLint under eslint:recommended. ESLint Rules documentation & Source
overrides - Allows configurations from this file to be overridden for specific files. Essentially, this is to ensure the configuration file itself (.eslintrc.js) is linted properly. ESLint Overrides documentation
overrides[0].env.node - Similar to the main env.node configuration, it adds Node.js-specific global variables.
overrides[0].files - Specifies the files for which the configuration should be overridden.
overrides[0].parserOptions.sourceType - Directs the parser to interpret the file as a script (CommonJS).
parserOptions.ecmaVersion - Instructs ESLint to parse the codebase using the latest ECMAScript version.
rules - Initially, this is an empty object. Later on, as you expand your linting preferences, this is where you'll define custom rules. ESLint Rules Documentation

If you opted for ES Modules, you'll see this additional configuration:

parserOptions.sourceType - Informs the parser to interpret all files as module (ES Modules).

If you chose CommonJS:

env.commonjs - Includes CommonJS global variables, such as require and module. Source

If your project uses TypeScript, you'll see these configurations:

extends - In addition to the recommended rules from ESLint, rules tailored for TypeScript are enabled with plugin:@typescript-eslint/recommended. TypeScript ESLint Rules documentation
parser - Uses the TypeScript parser to convert TypeScript code so ESLint can understand it. ESLint Parser documentation
plugins - Imports the @typescript-eslint plugin which gives you access to TypeScript-specific rules and its custom parser. TypeScript ESLint documentation

Now, you're all set!

In your terminal, you can run npx eslint . to lint your project. If there are issues, they'll be displayed in your console.

ESLint error messages in the console

ESLint can even automatically fix certain types of errors. Add the --fix flag to the command: npx eslint --fix ..

To learn more about ESLint, the ESLint documentation is an excellent resource.

Step 2 – Integrate ESLint with VSCode

To get continuous feedback from ESLint as you code, rather than running the command repeatedly, you can integrate ESLint into your editor. I'll cover integration with VSCode, given its popularity.

Simply download the ESLint extension for VSCode.

Once the extension is installed, ESLint errors will be directly highlighted in your editor.

ESLint integration in VSCode highlighting errors in the editor

And that's a wrap!

From now on you'll always have ESLint watching your back and preventing you from making silly mistakes. After all, we're all human and make mistakes :).

Continue reading to discover 14 ESLint rules for improving your asynchronous JavaScript code.

Happy coding! 🎭

Write clean code. Stay ahead of the curve.

Every other Tuesday, I share tips on how to build robust Node.js applications. Join a community of developers committed to advancing their careers and gain the knowledge & skills you need to succeed.

Subscribe for success!

Understanding "Property of Undefined" TypeError in JavaScript

Maxim Orlov — Fri, 15 Sep 2023 03:53:04 +0000

This article was originally published at https://maximorlov.com/understanding-property-of-undefined-typeerror-in-javascript/

You're likely here because you've run across this all-too-familiar JavaScript error message:

TypeError: can't access property "value" of undefined

While the message seems clear, its wording can be misleading and leave you confused.

You're not alone, even seasoned developers occasionally trip up when they encounter this.

This is a common error in JavaScript, and you'll see it frequently in your web development career. The sooner you understand it, the less time you'll waste chasing the bug in the wrong places.

Let's examine this error message and reveal what it's really trying to tell us.

Decoding the error message

To better understand this error, or its equivalent, cannot read properties of undefined (reading "value"), it's crucial to analyze the error message in detail.

The irony is that the message contains all the information you need—it's just that, more often than not, developers gloss over it.

Suppose you have a user variable that's supposed to be an object and you're trying to access the name property:

console.log(user.name); // TypeError: can't access property "name" of undefined

At first glance, you might suspect that name is undefined.

However, if that were the case, JavaScript would simply return undefined. Nothing wrong with that:

const user = {};
console.log(user.name); // undefined

In reality, the issue lies one level higher—it's the parent user object that's undefined:

let user; // undefined
console.log(user.name); // TypeError: can't access property "name" of undefined

When you attempt to access a property on undefined type in JavaScript, the program throws a TypeError.

MDN describes a TypeError as:

The TypeError object represents an error when an operation could not be performed, typically (but not exclusively) when a value is not of the expected type.

So we end up doing undefined.name which doesn't make sense because undefined is not of type Object.

Understanding the hidden message

When the error says can't access property "name" of undefined, it's really saying: "Hey, the object you're trying to read name from? Yeah, that one's undefined."

You shouldn't focus on name, but on its parent object. It's about where you're pulling name from.

What confuses many developers is that the error message doesn't show the name of the parent object which is causing the issue. Most developers tend to skim through the error, catch sight of the variable name, and wrongly assume that's where the problem lies.

Line and column numbers are your friends

Error messages come with a stack trace that does us a favor by displaying the line and column number where the error originated. The key to tracing any bug is to read the line and column numbers in the stack trace and navigate to that location in your project.

Note: This information is generally reliable unless you're dealing with minified or transpiled code without source maps.

For example, when I run this code:

let x;
console.log(x.value);

I get the following output:

TypeError: Cannot read properties of undefined (reading 'value')
    at file:///Users/maxim/Code/playground/test.js:2:15

The error message tells me the problem lies in the test.js file on line 2, column 15. This points directly to the dot notation, offering a clue about where the problem is:

let x;
console.log(x.value);
          // ^ line 2, column 15

Question your assumptions

Ultimately, effective debugging involves questioning your initial assumptions.

Within that questioning, we often find that we've made a wrong assumption that led us to reason about the code in the wrong way.

A bug is a difference between what we expect the program to do and what it actually does.

So the next time this confusing error pops up, you'll know exactly what to look for. It's this level of understanding that sets you apart as a developer.

Remember, we all make mistakes, but it's how we learn from them that defines us as developers. Happy debugging! 🐞 🚫

Write clean code. Stay ahead of the curve.

Every other Tuesday, I share tips on how to build robust Node.js applications. Join a community of developers committed to advancing their careers and gain the knowledge & skills you need to succeed.

Subscribe for success!

Navigate New Codebases Like a Seasoned Pro

Maxim Orlov — Mon, 04 Sep 2023 05:08:49 +0000

This article was originally published at https://maximorlov.com/navigating-new-codebases/

You've landed your first web development job or internship, and you're excited to get your hands dirty in the codebase. Congratulations! 🎉

But wait... You're dropped into a colossal project and told to "just mess around with it"? How are you supposed to make sense of thousands of lines of code?

You're probably lost and scared that you won't be able to pull it off, especially if you're working remotely. It's not like you can have someone pop by your shoulder and give you friendly advice.

No worries, though. This feeling is natural and it will pass.

Follow these 4 tips while you navigate a new codebase and you will ace your new job! 💪

Tip 1: Create a map

The first time looking at a massive codebase can be daunting. You might feel like you're in the middle of a labyrinth with no escape.

This is why mapping is crucial.

Grab a pen and paper, or go digital if you prefer. Create a flowchart that outlines how different modules and components interact with one another. This could be as simple as "User Input → Form Validation → Database" or as complicated as a multi-layer API structure. The goal is to give yourself a roadmap, or a cheat sheet if you will, to refer back to.

Think of it as mapping out your favorite video game. It helps you understand where you are and where you need to go.

After creating the initial flowchart, keep refining it. Whenever you understand a new aspect of the code, update your map. The process is ongoing, and your understanding of the codebase will evolve.

The map will become an indispensable resource as you dive deeper. And you know what? Your future self and potential teammates will thank you for it.

Tip 2: Add small features

You might be wondering, "Why should I add features to a project I don't understand yet?".

Well, the beauty is in the doing.

When you take the bold step to insert a small widget or perhaps modify a piece of existing code, you engage with the system in a very practical way. This is where the rubber meets the road. As you succeed in adding small features, you'll gain confidence.

Plus, by doing so, you'll inevitably encounter various parts of the codebase, which helps your understanding of it.

Don't worry if the feature you're adding doesn't bring about world peace. The goal is learning, not perfection. Over time, these little additions will empower you to understand larger structures and even refactor code.

Tip 3: Read and comment

Code isn't just a set of instructions for a computer. It's a language that developers communicate in.

So treat the codebase like a book — read it, ponder it, question it.

Try to understand the developer's intentions. Why did they use a for-loop here instead of a while-loop? What's the reason for caching this specific data? These are the types of questions that will help you dig deeper into the code's logic and purpose.

Don't underestimate the power of commenting. Write your thoughts and questions directly in the code as comments. If you're wondering why a particular function is structured a certain way, write it down. These comments act like sticky notes that you or another developer can refer back to. They're the questions you'll ask in your next team meeting or during a pair programming session.

By annotating the codebase, you make it interactive — a living, breathing document that helps everyone involved.

Tip 4: Ask (many) questions

It's not only okay to ask questions, it's encouraged!

Think you don't even know what to ask? Well, you do! Write down anything you don't understand and can't find in documentation (if there's any). There's no such thing as a stupid question when you're learning. The only stupid thing is not asking and remaining in the dark.

If you're working remotely it can feel isolating, and the lack of in-person interactions can leave you second-guessing your every move. But remember, remote work doesn't mean less communication. It means more.

Got questions? Jot 'em down. Not sure how to extend a form or why a piece of code is doing what it's doing? Mark it and discuss it with a colleague.

Don't let fear get the best of you

The project might be as complex as a full-fledged slot game or a robust e-commerce site, but don't let that intimidate you. Seasoned developers also get this overwhelmed feeling. The difference? They know it'll pass because they've been through it before.

You too will navigate through the maze of code, functions, and algorithms.

So map out the code, add small features, comment generously, and communicate! Don't bottle up your questions, ask them.

You're not an imposter. You're an explorer charting new territories, and like any great explorer, it's okay to ask for directions.

So go on, roll up your sleeves, and dig in! 🚀

Write clean code. Stay ahead of the curve.

Every other Tuesday, I share tips on how to build robust Node.js applications. Join a community of developers committed to advancing their careers and gain the knowledge & skills you need to succeed.

Subscribe for success!

Unfinished Projects on Resume: Wise or Not?

Maxim Orlov — Thu, 27 Jul 2023 05:05:00 +0000

This article was originally published at https://maximorlov.com/unfinished-projects-on-resume/

Sometimes, you're working on a project or app and itching to showcase it on your resume, but there's a catch – the project isn't finished yet.

So you might ask yourself, "At what stage in the development of an app is it appropriate to feature it on my resume? Should I include an incomplete project at all?"

To answer these questions, you'll need to consider two things:

The project's contribution to your knowledge and growth as a web developer.
The opportunity cost of including the project on your resume (i.e., what else didn't make the cut).

Let's discuss each of these points in more detail.

What have you learned from the project?

In an ideal world, only fully completed projects should make the cut for your resume.

However, if you're feeling the need to bolster your resume a little bit, especially if you're applying for jobs, it's acceptable to include projects that are still under development.

The key lies in their ability to demonstrate your competencies and expertise.

A good time to include an unfinished project is when you've learned enough from it that you could confidently talk about it in a job interview.

Keep in mind that anything on your resume is fair game for interview discussions. Be prepared to talk about your project and the challenges you've encountered along the way, as well as the solutions you've implemented.

This means the project will most likely have some noteworthy completed features.

What else are you excluding?

Furthermore, it's important to weigh the opportunity cost of adding an unfinished project to your resume.

A typical resume is limited to one page. Your education, skills, and work history have already staked their claim to that precious space.

If squeezing in this project implies omitting something else, ensure the project offers a much better representation of your skills.

Your resume is all about putting your best foot forward. You want to highlight your most impressive achievements. Think of it as cherry-picking your standout accomplishments to make a strong impression on potential employers.

So, if you consider the project to be a significant achievement, given everything else on your resume, then it's likely a good addition.

However, if your project is still in its infancy and lacks substantial features or progress, it's best to hold off on adding it to your resume.

Conclusion

Circling back to the initial question, "At what stage of an app's development is it suitable to include on a resume?" consider these two points:

Has your progress with the app reached a stage where you can discuss challenges you've faced and solutions you've implemented? Could you have an insightful conversation about the project in an interview?
If adding this project to your resume means sacrificing something else, does the app offer a stronger representation of your skills than what you're leaving out?

By answering these questions for yourself, you'll be able to make an informed decision about whether or not to feature an unfinished project on your resume.

Do you want to have an attractive portfolio? Would you rather focus on the back end instead of fiddling with CSS?

I'm releasing a collection of portfolio projects that include a beautiful and complete front end. Learn more →

Should You Use char, varchar, or text in PostgreSQL?

Maxim Orlov — Wed, 08 Feb 2023 18:30:00 +0000

This article was originally published at https://maximorlov.com/char-varchar-text-postgresql/

When designing a database schema, you have to choose the correct data types for the data you're expecting to store.

When it comes to strings, PostgreSQL has not just one, but three data types to choose from: char(n), varchar(n), and text.

What's the difference between them, and which one should you choose?

By the end of this article, you will know exactly how the three data types differ, and which one you should use.

The 3 data types for strings in PostgreSQL

PostgreSQL gives you three data types to store strings: char(n), varchar(n), and text. These are the defining characteristics of each data type:

char(n) (or character(n)) has a fixed length of N, where N is the number of characters. When you store a string with less than N characters, the string will be space-padded on the right. Attempting to store a string with more than N characters will result in an error.

varchar(n) (or character varying(n)), like the name implies, has a varying character length not exceeding N. Unlike char(n), varchar(n) doesn't add padding to strings with less than N characters. Similar to char(n), the N character length is enforced on inserts and updates.

text can store strings of any length. There is no maximum limit on the number of characters, and padding is never applied.

Note: PostgreSQL allows you to use varchar (without length n), in which case it's equivalent to text.

When should you use `char(n)`, `varchar(n)`, or `text`?

There are two reasons why you might consider using char(n) or varchar(n) instead of text: better performance and enforcing a maximum length. Let's examine both.

Performance
PostgreSQL documentation says the following about the performance difference between the three data types:

There is no performance difference among these three types, ... . While char(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL;

Moreover, PostgresSQL Wiki says storing the same string into the three data types will use the same amount of space:

If you insert the same string into the three field types they will take up exactly the same amount of space.

Therefore, using char(n) or varchar(n) over text has no performance benefit.

In fact, char(n) will use up more storage compared to the other two for strings with less than N characters because of padding. Both char(n) and varchar(n) incur an additional CPU cost to check the length, which might be unnecessary if you don't need it.

Enforcing a maximum length
If you want to enforce a maximum length, it's better to use a check constraint instead of relying on char(n) or varchar(n).

Not only is a check constraint more specific, but it will also save you from future trouble when you decide to change the length limit.

Changing the char(n) or varchar(n) length limit practically means changing the column's data type and therefore it impacts dependent objects (views, functions, foreign keys, etc.). It could result in an expensive query due to a potential rewrite of the table during which other queries are put on hold.

Modifying or dropping a check constraint is a quick operation that only involves reading the table's data. It's also more powerful and allows you to enforce other requirements such as a minimum (or exact) length and a limited set of characters.

/*
  Add a check constraint to the `id` column to enforce
  alphanumeric strings of exactly 5 characters long
*/
ALTER TABLE short_urls ADD CONSTRAINT id CHECK (id ~ '^[a-zA-Z0-9]{5}$');

Conclusion

Always use the text data type when storing strings in PostgreSQL. There is no performance benefit of using char(n) or varchar(n).

If you want to enforce a maximum length, use a check constraint which is more specific and easier to change.

With this knowledge in hand, you can confidently move forward with designing and deploying your database.

Write clean code. Stay ahead of the curve.

Every other Tuesday, I share tips on how to build robust Node.js applications. Join a community of developers committed to advancing their careers and gain the knowledge & skills you need to succeed.

Subscribe for success!

7 Awesome Free APIs for Your Next Node.js Project

Maxim Orlov — Mon, 30 Jan 2023 05:48:09 +0000

This article was originally published at https://maximorlov.com/awesome-apis-for-nodejs-projects/

Coming up with an idea for your next portfolio project is not easy. The project should be: fun, not too difficult, and not too easy, impress recruiters, look nice on your portfolio, cover every aspect of Node.js you want to practice, etc., etc.

You can't come up with something that fits all the criteria and you keep going in circles. You're stuck in analysis paralysis.

Truth is, you're way overthinking this.

The type of project you decide to build doesn't matter as much as you think it does. Whether it's a chatbot, a time tracker, or a fitness app, these are all solid choices.

What truly matters is getting practice under your belt, and every hour you spend fretting about making the right choice is a lost hour you could've spent coding instead!

To help you finally make a decision and start coding today, I've put together a list of awesome free APIs. You can use any of these APIs to build some really cool portfolio projects with Node.js, and for each API I'll give you some project ideas to get you inspired.

Spoonacular API 🥘

Documentation: https://spoonacular.com/food-api/docs

The Spoonacular API is an API for all things related to food. It's a database for recipes, ingredients, nutritional data, wines, and more. With this vast amount of data, the project ideas are endless.

What can you build with it?

Wine purchase recommendation based on what the user is having for dinner
A recipe suggestion app based on the user's food preferences and dietary requirements
Image classification app for food (Improved version of the Not Hotdog App 😄)

Do you want to have an attractive portfolio? Would you rather focus on the back end instead of fiddling with CSS? Learn more →

Words API 💬

Documentation: https://www.wordsapi.com/docs/

Words API has over 350,000 English words in its database. The API has endpoints for word definitions, synonyms, and sentence examples. There is also a search endpoint that accepts regular expressions and min/max letter counts.

What can you build with it?

A word finder app for Scrabble. The user inputs the available tiles, including any wildcards, and the app suggests a list of possible words sorted by longest (and highest scoring) first
Dictionary app that allows users to look up word definitions along with their pronunciation and class (noun, verb, adjective, etc.)
A better writing app that lets the user paste some text and it suggests synonyms for frequently used words in the English language

AirLabs API ✈️

Documentation: https://airlabs.co/docs/flights

The AirLabs API provides you with real-time flight tracking data similar to flight radar sites. It gives you access to the live coordinates of any flight in the world.

You can also give it a bounding box of coordinates and it will return all flights in a specific area. Pretty sweet!

What can you build with it?

An app where users can track the flight of a friend or a loved one. Users can choose to get notified (push, sms, or email) when the airplane crosses borders, along with ETA, and when it lands
A flight radar clone where users can see all airplanes in a specific area on the map. Users can click on an airplane to get more info about the flight (origin, destination, speed, etc.)

Bionic Reading API 📖

Documentation: https://rapidapi.com/bionic-reading-bionic-reading-default/api/bionic-reading1

This API is different from the others in this list. Instead of giving you some data, you give the Bionic Reading API a text piece and it returns it with the beginning of the words highlighted.

The idea is that if your eyes focus on the beginning of the words, your brain will automatically fill in the rest. Because we read faster with our minds than with our eyes, it improves reading speed and understanding of written content.

What can you build with it?

A blog with a toggle button where readers can choose to view blog posts with or without highlighted initial letters

Open Library API 📚

Documentation: https://openlibrary.org/developers/api

The Open Library API has pretty much every book ever released in its catalog. You can search for books or get detailed information on a particular book. The API has links to cover images and an array of genres for each book.

What can you build with it?

A GoodReads clone where users can keep track of the books they've read, and the ones they wish to read. Additionally, users can review books they've read
A Book Club app where users can vote and pick what books to read. The app can recommend new books based on previously read books. Users can update their reading status and other users can see how far in the book everyone is

The Movie Database API 🍿

Documentation: https://developers.themoviedb.org/3/getting-started/introduction

There's a good reason every project ideas list like this one mentions a movie API. Everyone watches movies or TV shows and therefore it's likely to be an interesting project idea.

The Movie Database has most of the movies and TV shows that have ever been released. The API gives you access to a variety of useful information for each movie/TV show such as genre, rating, and actors. It also provides you with cover images so you can make your project visually attractive.

The API has a trending, a discovery, and a recommendation endpoint which opens the door for some interesting projects.

What can you build with it?

A "Where Can I Stream It?" app that lets the user know on which streaming service to watch a particular movie or TV show based on their country
A movie library where users can keep track of the movies and TV shows they've watched, and the ones they wish to watch. Users can rate movies and a recommendation engine will take that into account to suggest other movies to watch

API Ninjas' Exercises API 🏋️‍♂️

Documentation: https://api-ninjas.com/api/exercises

The Exercises API is a collection of thousands of exercises. You can filter exercises by the muscle group targeted, type and difficulty. Each exercise includes an instruction text on how to perform the exercise and the necessary equipment for it if any.

What can you build with it?

A fitness inspiration app where users can search for and browse exercises with filters for targeted muscles, difficulty, and type. The app can also suggest a weekly training program based on the user's level, muscle focus preference, and available training equipment

You should now have plenty of inspiration for your next Node.js portfolio project. You have no excuse to procrastinate any longer. Choose one of these APIs and an idea that seems fun to you and go build something awesome. 🌟

Remember, choosing something is better than not choosing at all!

Do you want to have an attractive portfolio? Would you rather focus on the back end instead of fiddling with CSS?

I'm releasing a collection of portfolio projects that include a beautiful and complete front end. Learn more →

Backend Portfolio Projects for Developers Who Dread CSS

Maxim Orlov — Fri, 20 Jan 2023 06:01:19 +0000

This article was originally published at https://maximorlov.com/backend-portfolio-projects-no-css/

Having a portfolio is essential to landing a web development job. As a back-end developer, how do you showcase your skills when most of it happens, well, in the back end?!

You might use Postman to send requests to your server, but you can't expect recruiters to do that. They need an easy and quick way to see what you've built. You need a front end to accompany your back end.

You need HTML and CSS.

But writing CSS isn't your forte. In fact, you could easily spend hours fiddling with CSS only to end up with a page that looks like it was built in the 90s.

Imagine showing one of your projects to a recruiter while trying to convince them the back end is really well done and they should ignore the design..

That's awkward.

Despite having the design skills of a 5-year-old, your projects don't have to reflect that.

What if you had a portfolio you were truly proud of? A portfolio of beautifully designed projects that are worthy of your intelligently written back ends.

A portfolio worthy of YOU.

This portfolio would make you stand out from all other candidates. It would get you past the screening stage and sitting at a table in front of your future employer.

Best of all, what if you accomplished all of that without writing even a single line of CSS? Wouldn't it be great if you spent your time writing back-end logic instead — the type of coding you're actually good at.

Well, now you can!

Introducing back-end projects packaged with a front-end application

I'm releasing a collection of portfolio projects that come with an already built front-end application so you can focus entirely on the back end.

These projects will cover a wide range of back-end topics such as authentication, caching, sockets and security, making them an ideal choice for learning and practicing Node.js.

By the time you complete several of these projects, you'll have a strong portfolio showcasing your web development skills.

Want to use Express, Fastify, Nest.js, or any other back-end framework? Not a problem! SQL or NoSQL? Up to you! There are absolutely no restrictions on how you should build these projects.

You're free to choose any frameworks and libraries you want. This is an excellent opportunity to try out a new library or learn a technology that will give you an edge on the job market.

URL Shortener project

The first project in the series is a URL Shortener service.

Your task is to implement a back-end that enables users to shorten a long URL. The short URL should redirect visitors to the original URL when visited. Additionally, users should be able to view the number of times an URL has been visited.

I'm giving the first project away for FREE. Learn more →

What's inside

Front-end application

Screenshots of the Home, Short URL and Analytics mobile pages

Each project comes with a fully designed and implemented front-end application. It's a plug-and-play application ready to connect to a back end. Just give it a URL and you're good to go.

API Documentation

API documentation for the endpoint to create a short URL

Back-end developers often use the API documentation to coordinate with front-end developers. API documentation is a formalized document of how the client and server will communicate.

Typical API documentation will describe how the client should authenticate with the server, what the available endpoints are, and what the data returned by the back end looks like.

As a back-end developer, you should be comfortable with implementing a back end that closely matches the documentation. API documentation is to back-end developers, what design files are to front-end developers.

User stories

Essential features of the URL Shortener project

User stories provide an overview of the features you will be implementing. They give you a good idea of what the project is about.

These are a collection of essential features written from the user's perspective. User stories encourage backward planning by starting with the end result first. Use them to work your way backward and decompose the project into many small tasks.

Together with the API documentation, user stories are a great starting point for integration tests.

Bonus tasks

Bonus tasks add an extra level of difficulty

For ambitious developers who like an extra challenge, each project comes with additional bonus tasks. These tasks go beyond the initial scope of the project and challenge your problem-solving skills.

If the user stories are the Minimum Viable Product (MVP), bonus tasks are the polished version of a product. Completing the bonus tasks shows you're capable of analyzing, researching, and solving real-world problems.

Don't feel the pressure to finish all, or any, bonus tasks. If you implement just the essential features that's already a big accomplishment.

Resources

Resources are various links to tutorials, Stack Overflow questions, Wikipedia pages, or blog posts that can help you with the project. If you get stuck building the project, these resources can help you get unstuck and learn a different problem-solving approach.

These resources work best when used as inspiration. Try not to copy-paste code from them and if you absolutely have to, make sure you fully understand what each line of code does.

Additional support

A workflow for building the project. This is a step-by-step workflow on how I would build the project. From initializing a GitHub repository to implementing a mock server to connecting a database. These are a sequence of steps. Feel free to adapt it to your liking or use your own workflow.

Deployment tips. How you deploy the back end will largely depend on whether you want to host it on a server (VPS) or a managed server (PaaS). With the plethora of cloud providers today, I lay out the options available to you along with some recommendations that have free tiers.

For a limited time only, I'm offering FREE professional code reviews for anyone who completes a project! Don't miss this unique opportunity to get actionable personalized feedback on your code.

Go build something awesome!

Visit the original article and download the project files to get started.

I'm super excited to see the awesome stuff you'll make and I'm curious to see what approach you'll take to solve these projects.

I'd love to have a look at your solution. Shoot me an email with a link or mention me on Twitter. I'll help spread the word!

Have fun building! ⚒️

3 Reasons Why Async/Await Is Better Than Chaining Promises

Maxim Orlov — Wed, 02 Nov 2022 14:00:00 +0000

This article was originally published at https://maximorlov.com/async-await-better-than-chaining-promises/

If you're already familiar with promises and chaining them you might be wondering — why learn a new syntax? Why use async/await when you can use promises to accomplish the same thing? 🤨

And yet developers love async/await and are saying how it has helped them write better code. Makes you wonder if they know something you don't...

Only if you had someone to show you where promises fall short. It could give you the insight you've been missing all this time! 💡

Well, you do!

Grab a seat and read on as I point out the shortcomings of Promise.then() syntax and how async/await helps you write better asynchronous JavaScript code. 🎯

Reason #1 - Confusing order of execution

One of the first things we're taught in programming is that code is executed from top to bottom. We tell machines what to do by writing code as a sequence of chronological steps — first do this, then do that, and finally run that.

By definition, asynchronous code doesn't run linearly and it contradicts how we've learned to read and reason about code.

While promises are a vast improvement over callbacks (and they power async/await under the hood), they can give you the impression that code runs in a weird order.

Here is an example with print statements before, inside, and after the promise chain:

console.log('Start'); // 1
insertComment(comment)
  .then((commentId) => {
    console.log('Comment ID is', commentId); // 3
  });

console.log('End'); // 2

This prints the following:

Start
End
Comment ID is e03c2055-2309-494f-b37e-f153bc673445

This is unintuitive because it looks like the program is jumping from end to middle, when in fact code always executes from top to bottom. What happens is that the execution of asynchronous code is deferred to a future point in time with the help of the event loop.

When we take the same code and refactor it to async/await, it not only runs from top to bottom but also reads from top to bottom.

console.log('Start'); // 1
const commentId = await insertComment(comment);
console.log('Comment ID is', commentId); // 2
console.log('End'); // 3

Which unsurprisingly prints:

Start
Comment ID is e03c2055-2309-494f-b37e-f153bc673445
End

Async/await allows you to write asynchronous code that reads like synchronous code.

And that's powerful.

Reason #2 - Reusing values inside promise chains

Another issue with promise chains is when you want to reuse values at later steps in the chain. Each .then() method creates a separate function scope and, therefore, prevents accessing its variables from later steps in the chain.

insertComment(comment)
  .then((commentId) => {
    return insertHashtag(hashtag, commentId);
  })
  .then((hashtagId) => {
    // how do we use commentId in here?
    console.log('Comment ID is', commentId);
  });

In practice, this issue is often worse because you have longer promise chains and you want to access several values at different steps in the chain.

Promise.then() solutions and their shortcomings

You could solve this in a few different ways with Promise.then() syntax, but let me show you why they're not ideal.

A solution would be to initialize the variables you need outside of the promise chain. This allows you to reference them at later steps in the chain because the variables are declared in a shared outer scope.

// Initialize variable in outer scope so we can reference it
// from a later step in the promise chain
let commentId;
insertComment(comment)
  .then((newCommentId) => {
    // Need to come up with a new name to avoid name clash 🙅‍♂️
    commentId = newCommentId;
    return insertHashtag(hashtag, commentId);
  })
  .then((hashtagId) => {
    console.log('Comment ID is', commentId);
  });

The problem with this is that you have to come up with different names for each variable to avoid name clashes, and we all know that naming things is hard in programming.

Moreover, with longer promise chains it's hard to keep track of where the variables were assigned and what values they hold. I've had to debug some long promise chains in production that were using this solution and I can tell you it was not fun.

Another solution is to add a nested promise chain and resolve with the value needed in the next step.

insertComment(comment)
  .then((commentId) => {
    return insertHashtag(hashtag, commentId)
      // Add a nested promise chain and resolve with the value
      // needed in the next step
      .then((hashtagId) => {
        return commentId; // this nesting though 😵
      });
  })
  .then((commentId) => {
    console.log('Comment ID is', commentId);
  });

However, nesting promise chains goes against why you would chain promises in the first place — which is to create a flat async structure. Everyone hated callback hell (a.k.a. pyramid of doom) from earlier days of asynchronous JavaScript, and nobody wants to work with that mess again.

You also need to make sure to return nested promises otherwise rejections won't bubble up and your Node.js server will quit unexpectedly.

Lastly, you could use Promise.all to pass an array of values to subsequent steps in the chain.

insertComment(comment)
  .then((commentId) => {
    // Need to make sure to keep this array in sync with..
    return Promise.all([
      commentId,
      insertHashtag(hashtag, commentId)
    ]);
  })
  .then(([commentId, hashtagId]) => { // <-- ..this array
    console.log('Comment ID is', commentId);
  });

This is in my opinion the "least worse" solution, as it avoids name clashes or nesting promises. Before async/await was a thing, this would be my go-to approach.

The downside is that you have to keep both arrays in sync. When you change something in one array it's easy to forget about the other. Adding Promise.all in your promise chains quickly becomes tedious and it affects the readability of your code.

Using async/await

Let's look at how you'd write this with async/await.

// ✨
const commentId = await insertComment(comment);
await insertHashtag(hashtag, commentId);
console.log('Comment ID is', commentId);

There's not much to explain really, it's concise and clear. No separate function scopes to worry about and no weird workarounds. Amazing!

Reason #3 - Conditional asynchronous tasks

Another reason to use async/await over Promise.then() syntax is when you have async tasks inside an if statement. It's tricky to handle this nicely with Promise.then() and you'll soon find yourself in a "promise hell".

insertComment(comment)
  .then((commentId) => {
    if (hashtag) {
      // Ugh this nesting starts to look like callback hell...
      return insertHashtag(hashtag, commentId)
        .then((hashtagId) => {
          // If we don't resolve with commentId the next value
          // in the chain might be hashtagId and we'll have
          // to add a check for that
          return commentId;
        });
    }

    return commentId;
  })
  .then((commentId) => {
    console.log('Comment ID is', commentId);
  });

You can't get around the nesting problem because if you resolve with a different value (hashtagId) you won't know what value you're getting in the next step (hashtagId or commentId?). In some situations you can programmatically check which value you're working with, but often you can't.

With async/await this is a non-issue. You just put the entire logic inside an if statement and that's it.

// 🚀
const commentId = await insertComment(comment);
if (hashtag) {
  await insertHashtag(hashtag, commentId);
}

console.log('Comment ID is', commentId);

This code is straightforward and runs as expected.

By now you're familiar with the scenarios where Promise.then() syntax falls short and how async/await empowers you to write clean asynchronous code. Use this knowledge to write better JavaScript code and progress in your development career.

Transform Callbacks into Clean Async Code! 🚀

Tired of messy callback code? Download this FREE 5-step guide to master async/await and simplify your asynchronous code.

In just a few steps, you'll transform complex logic into readable, modern JavaScript that's easy to maintain. With clear visuals, each step breaks down the process so you can follow along effortlessly.

Get the FREE guide

Using Callbacks With Async/Await

Maxim Orlov — Mon, 24 Oct 2022 10:24:20 +0000

This article was originally published at https://maximorlov.com/using-callbacks-with-async-await/

Let's face it. Sometimes you have to use an asynchronous function that uses the old callback-based approach. It might be part of a legacy codebase, or it could come from a library that hasn't had an update in over 5 years. 🤷‍♂️

Nevertheless, there's no way around it and you have to deal with it somehow.

So what do you do? Do you add messy callbacks to your code? 🙅‍♂️

What if I told you there is a way to make callback-based asynchronous functions work nicely with async/await? Not only that, but you won't have to make any changes to existing code.

I'll teach you how to change a function's signature, even when you don't have control over its implementation.

Transforming callback-based asynchronous functions

Suppose we have a getUserAddress function that's written using modern async/await. Inside this function, we're calling fetchUser which uses a callback-based approach.

When fetchUser completes, it calls the callback with the user object. Our goal is to have getUserAddress return the user's address.

async function getUserAddress(userId) {
  fetchUser(userId, (err, user) => {
    if (err) {
      console.log(err);
      return;
    }

    user.address; // we want this value
  });
}

const address = await getUserAddress(8); // to be returned here
console.log(address); // undefined

How do we accomplish that?

We can't simply return user.address inside the callback function because the return value would go to the parent function that calls the callback, which is the fetchUser function and not getUserAddress.

async function getUserAddress(userId) {
  fetchUser(userId, (err, user) => {
    if (err) {
      console.log(err);
      return;
    }

    // 🚫 doesn't work, value is returned to fetchUser function
    return user.address;
  });
}

const address = await getUserAddress(8);
console.log(address); // undefined

And returning fetchUser doesn't work either because by design the function doesn't return anything. In fact, all callback-based asynchronous functions return undefined.

async function getUserAddress(userId) {
  // 🚫 doesn't work, fetchUser doesn't return anything
  return fetchUser(userId, (err, user) => {
    if (err) {
      console.log(err);
      return;
    }

    user.address;
  });
}

const address = await getUserAddress(8);
console.log(address); // undefined

Well then, the only way to use fetchUser with async/await is if the function returns a Promise. Callback-based functions are incompatible with promises & async/await because they are different approaches to writing asynchronous code.

But how do we make fetchUser return a Promise when we don't have control over its implementation?

We wrap it! 🌯

If we wrap fetchUser inside a promise that resolves with the user value and rejects with the error object, we can await the promise and return the user's address inside getUserAddress.

async function getUserAddress(userId) {
  // Create and await a promise that rejects and resolves
  // with the callback's `err` and `user` arguments, respectively
  try {
    const user = await new Promise((resolve, reject) => {
      fetchUser(userId, (err, user) => {
        if (err) {
          reject(err);
          return;
        }

        resolve(user);
      });
    });
    return user.address;
  } catch (error) {
    console.log(error);
  }
}

const address = await getUserAddress(8);
console.log(address); // '729 Ellsworth Summit, Aliyaview'

What this does is it creates a bridge between the asynchronous callback and async/await. It translates the success and error paths inside the callback to the resolve and rejection states of the promise.

When the callback is called with an err argument the promise will reject with the error object which is then caught and logged in the catch block. If there is no error, the promise resolves with the user which is assigned to a variable.

Finally, we call getUserAddress which returns a promise, because all async functions return a promise, and await it to get the user's address.

Using a utility function

It quickly becomes tedious if you have to manually wrap all callback-based functions in your project. Luckily, Node.js comes with a utility function that does this for you.

The promisify method from the built-in util module takes a callback-based asynchronous function and returns a promise-based version. You call the promise-based function with the same parameters as you would call the callback-based function, except instead of passing in a callback you await the promise for the resolved value.

import util from "node:util";
import { fetchUser } from "../utils/api.js";

// util.promisify transforms a callback-based function
// into a promise-based equivalent
const fetchUserAsync = util.promisify(fetchUser);

async function getUserAddress(userId) {
  try {
    const user = await fetchUserAsync(userId);
    return user.address;
  } catch (error) {
    console.log(error);
  }
}

const address = await getUserAddress(8);
console.log(address); // '729 Ellsworth Summit, Aliyaview'

This is much better than what we've started with, and it works! 🎉

You've learned how to transform a callback-based asynchronous function into a function that returns a promise despite not having control over its internal implementation. There's no need to write asynchronous JavaScript code using a callback-based approach anymore.

Transform Callbacks into Clean Async Code! 🚀

Tired of messy callback code? Download this FREE 5-step guide to master async/await and simplify your asynchronous code.

Get the FREE guide

Avoid This Mistake When Caching Asynchronous Results

Maxim Orlov — Mon, 17 Oct 2022 11:55:32 +0000

This article was originally published at https://maximorlov.com/caching-asynchronous-results/

Implementing a robust cache is a challenging task. Some of the things you'll need to consider are — What will you cache? When will you invalidate? And, what strategy will you implement? 🤔

The primary job of a cache is to reduce load on upstream services. Therefore, last thing you want is an ineffective and useless cache. 😤

Unfortunately, this is something that happens all too often when caching asynchronous results.

Here's what you should watch out for, and how you can implement a cache that guarantees no cache misses.

Cache stampede

In the context of web applications, a cache stampede occurs when several requests are fetching the same resource in parallel. If the resource is missing from the cache, each request ends up initiating a separate database query.

To illustrate, suppose a query takes 3 seconds to complete and the incoming traffic is 10 requests per second (for the same resource). On a cache miss, we'll end up with 30 identical database queries before we start serving the resource from the cache!

The longer it takes for a query to complete and the higher the incoming traffic, the larger the load on the database. This can result in slow response times or even a complete outage. (looking at you, Facebook)

The core of the problem is that requests aren't aware of each other. They act independently which leads to duplicate work. Ideally, requests should know about one another and reuse pending work.

One way to solve a cache stampede is to introduce a locking mechanism. On a cache miss, a request tries to acquire a lock for a particular resource and recompute it only if it has acquired a lock.

Implement locks using promises

An ingenious way of implementing a locking mechanism is to use promises. Instead of storing the value in the cache, we store the corresponding promise.

We can make use of the fact that promises are created synchronously, whereas query results are returned asynchronously. This ensures that with multiple concurrent requests, only the first request will propagate a query to the database. Subsequent requests will reuse the same promise and wait until it fulfills.

Let's look at some code.

Below, we have a getUser function that takes a user ID and returns a promise that fulfills with the user object. The function first checks if there is a promise for that particular user ID in the cache. If there is, return the promise. If there isn't, initiate a query to get the user from the database and store the resulting promise in the cache before returning it.

const userPromiseCache = new Map();

function getUser(userId) {
  // If the promise is not stored in the cache, fetch the user from DB
  // and store the resulting promise in the cache
  if (!userPromiseCache.has(userId)) {
    const userPromise = db.findUserById(userId)
      .catch((error) => {
        // Have the promise remove itself from the cache if it rejects
        userPromiseCache.delete(userId);
        return Promise.reject(error);
      });

    // Store promise in the cache
    userPromiseCache.set(userId, userPromise);
  }

  // Return the promise from cache
  return userPromiseCache.get(userId);
}

Notice the error handler attached to the promise. It ensures the promise will remove itself from the cache if it rejects. Otherwise, we'll end up caching the rejection and future requests will return an error. It's ok to use the .catch() method here since there's no other way. Generally though, you want to avoid mixing Promise.then() with async/await syntax.

Because the promise is created and returned synchronously, subsequent calls with the same user ID are guaranteed to reuse the same promise.

Usually, a locking mechanism involves complex logic for lock acquisition. This technique gives you simple and straightforward locks.

Note: Promises are a language-specific construct and this technique works only for in-memory cache inside JavaScript code. For external cache storages like Redis, you'll need to manually implement locking using a Pub/Sub pattern.

Memoizing promises

Seen from another angle, this cache implementation is just memoizing the getUser function. When we call the function with the same userId, we get the same cached result (a promise).

Note: Memoization is an optimization technique that stores the results of expensive function calls and returns the cached result when the same inputs occur again.

There are several libraries in the JavaScript ecosystem that help with memoization, including memoizee. We can simplify the above implementation to just:

import memoizee from "memoizee";

const getUser = memoizee(
  (userId) => db.findUserById(userId),
  { promise: true }
);

With promise: true we let the library know that the function returns a promise. It will then make sure to remove promise rejections like we manually did earlier.

Looks clean, doesn't it?! ✨

Note: Make sure you have a cache eviction policy in place to avoid outgrowing your application's memory limits. In memoizee, you can limit the cache size with the max property.

You have now learned the peril of caching asynchronous values and how to avoid it. With this knowledge in hand, you're ready to implement a robust cache with more cache hits!

Transform Callbacks into Clean Async Code! 🚀

Tired of messy callback code? Download this FREE 5-step guide to master async/await and simplify your asynchronous code.

Get the FREE guide

Understanding Async & Await

Maxim Orlov — Fri, 07 Oct 2022 12:28:25 +0000

This article was originally published at https://maximorlov.com/understanding-async-await/

Learning async/await can be daunting. It's something you've been procrastinating on for weeks, if not months!

You might know the difference between synchronous and asynchronous code, but you're completely lost in the application of it.

At this rate, it's hard to imagine how you'll ever wrap your head around asynchronous JavaScript. 😫

But learning async/await doesn't have to be scary!

With a little guidance and the right approach, you can write modern asynchronous code that just works. Not next month, or next week, but today.

It's true, async/await is unintuitive at first.. but only because you haven't built a mental model for it, yet!

To understand async/await we have to talk a little bit about promises first. Since async/await is built on top of promises, when you're writing async/await you're in fact dealing with promises under the hood.

What's a `Promise`?

Put simply, a Promise is a JavaScript object that represents a future value. It holds two pieces of information: the promise state, and a value or error (depending on the state).

A promise can be in one of these states:

pending — initial state, the operation is in progress
fulfilled — the operation completed successfully
rejected — the operation failed

A promise is settled when the promise has either fulfilled or rejected, but not pending. A promise eventually fulfills with a value or rejects with an error (or reason).

A function that returns a promise is by definition an asynchronous function. (remember this, we'll come back to it later)

Even though the promise is returned synchronously, the value inside the promise is asynchronous and can only be accessed after the promise has fulfilled.

What does `await` actually do?

When you add the await keyword in front of a promise you instruct the JavaScript runtime to pause execution inside the current function, wait until the promise settles, and only after the promise has settled, continue executing the rest of the code inside that function.

Await guarantees that you have access to an asynchronous value past a certain point. The runtime won't execute any further code inside the function until the promise fulfills with the value (or rejects with an error).

One thing to keep in mind is that starting an asynchronous operation and awaiting its result are two separate actions. This becomes clear when you write them on different lines.

Therefore, await is solely responsible for pausing further execution until the asynchronous operation has completed. It is not what starts the asynchronous operation.

How about `async`?

The async keyword grants a special ability to a function.

A function marked as async can pause execution anywhere inside its body. In other words, the function is allowed to use the await keyword. Await can only be used inside async functions. (you'll understand why in a bit)

An async function has two important properties:

It always returns a Promise
You can use the await keyword inside its scope

When you return a non-Promise value inside an async function, the value is wrapped inside a Promise before being returned.

async function getFive() {
  return 5;
}

console.log(getFive()); // Promise { ... }

Remember what I said earlier about functions that return a promise — they're by definition asynchronous. Therefore, a function marked as async is always asynchronous.

A non-async function that returns a promise is also asynchronous. The following code is practically the same as the one above:

function getFive() {
  return Promise.resolve(5);
}

console.log(getFive()); // Promise { ... }

All other functions are considered synchronous functions.

Why `async` & `await` are inseparable

Knowing that await pauses execution inside a function and that a non-async function is synchronous if it doesn't return a promise, you can start to see why the following code doesn't work:

function getFive() { // function is not async
  const five = await fetchFive(); // 🚫 doesn't work, can't use await
  return five;
}

How can getFive() synchronously return five if it needs to wait for fetchFive() first?

Put differently, how can you wait for an asynchronous value and then proceed to return it synchronously?

You simply can't.

That's why await can only be used inside a function declared with the async keyword. An async function wraps the return value in a promise which makes the value asynchronous.

Hopefully you have a better understanding of async/await by now. Go ahead and use it in your projects!

Transform Callbacks into Clean Async Code! 🚀

Tired of messy callback code? Download this FREE 5-step guide to master async/await and simplify your asynchronous code.

Get the FREE guide

DEV Community: Maxim Orlov

One or Two-Column Resumes: Best Choice for Aspiring Web Developers

Harder to read

Formatting issues

Not ATS friendly

Want to impress? Focus on content

Craft a resume that's impossible to ignore

ESLint Setup in Node.js: A Detailed Guide

Step 1 – Install & configure ESLint in a Node.js project

Step 2 – Integrate ESLint with VSCode

Write clean code. Stay ahead of the curve.

Understanding "Property of Undefined" TypeError in JavaScript

Decoding the error message

Understanding the hidden message

Line and column numbers are your friends

Question your assumptions

Write clean code. Stay ahead of the curve.

Navigate New Codebases Like a Seasoned Pro

Tip 1: Create a map

Tip 2: Add small features

Tip 3: Read and comment

Tip 4: Ask (many) questions

Don't let fear get the best of you

Write clean code. Stay ahead of the curve.

Unfinished Projects on Resume: Wise or Not?

What have you learned from the project?

What else are you excluding?

Conclusion

Should You Use char, varchar, or text in PostgreSQL?

The 3 data types for strings in PostgreSQL

When should you use char(n), varchar(n), or text?

Conclusion

Write clean code. Stay ahead of the curve.

7 Awesome Free APIs for Your Next Node.js Project

Spoonacular API 🥘

Words API 💬

AirLabs API ✈️

Bionic Reading API 📖

Open Library API 📚

The Movie Database API 🍿

API Ninjas' Exercises API 🏋️‍♂️

Backend Portfolio Projects for Developers Who Dread CSS

Introducing back-end projects packaged with a front-end application

URL Shortener project

What's inside

Front-end application

API Documentation

User stories

Bonus tasks

Resources

Additional support

Go build something awesome!

3 Reasons Why Async/Await Is Better Than Chaining Promises

Reason #1 - Confusing order of execution

Reason #2 - Reusing values inside promise chains

Promise.then() solutions and their shortcomings

Using async/await

Reason #3 - Conditional asynchronous tasks

Transform Callbacks into Clean Async Code! 🚀

Using Callbacks With Async/Await

Transforming callback-based asynchronous functions

Using a utility function

Transform Callbacks into Clean Async Code! 🚀

Avoid This Mistake When Caching Asynchronous Results

Cache stampede

Implement locks using promises

Memoizing promises

Transform Callbacks into Clean Async Code! 🚀

Understanding Async & Await

What's a Promise?

What does await actually do?

How about async?

Why async & await are inseparable

Transform Callbacks into Clean Async Code! 🚀

When should you use `char(n)`, `varchar(n)`, or `text`?

What's a `Promise`?

What does `await` actually do?

How about `async`?

Why `async` & `await` are inseparable