Use async / await and avoid UnhandledPromiseRejection and crashes
Overview
You should be using the async and await keywords in your Node.js Express APIs. But did you know that Express handles error handling differently for fully synchronous code vs. asynchronous code?
Express does some magic to route errors to you error handling middleware, but you can run into issues with any asynchronous calls. Do you ever see the dreaded UnhandledPromiseRejection Error? Read on to learn the distinction and see a simple solution to avoid these.
Note: Express has solid docs on error handling here — in this article we’ll focus on the async / await keywords, which is the exact…
Recently, I’ve been working on a project called sapling.dev, which generates full stack JavaScript (node + React) apps, including full CRUD APIs, Auth0 and Stripe integrations, and more. Sapling is the first developer tool I’ve built, and I quickly realized that the following items would be critical as we begin marketing:
- Top-Notch Documentation — our Docs need to describe how users can generate a new codebase, how the new frontend and backend are structured, how to get up and running (npm scripts, nvm versioning, dockerized database, etc.), and how to configure the integrated services like Auth0 and Stripe
- A Nice…
Overview
When your Express API receives HTTP requests, how do you check whether the request is valid? Especially for POST and PUT requests, where you expect the request body to contain an entire object to process, how do you know whether it has the right fields and valid values?
In some of my early APIs, it seemed natural enough to either write my own validation code in my routes to check for fields and types, or to even have some code in the model layer that would check an object for various conditions before it got put into the database, for…
ESLint, Prettier + VSCode
This is Part 2/2 in my series on setting up a minimal Node.js & Express project using Babel. Check out Part 1 here:
In Part 1, I set up Babel in a fresh Node / Express project, talked about Node versioning, set up scripts to use Babel for development and production, and considered whether Babel is still worth it (tldr; I think either direction is fair).
In this post, we’ll work through setting up ESLint and Prettier in our Node project, and then look specifically at a couple setup options I use in VS Code. Why is this setup in…
Let’s set up a basic Node.js / Express.js API that uses Babel. Babel will ‘transpile’ our ES2015+ code and module syntax to older-style code for compatibility purposes. I’ll use a basic Express API as the example, add in absolute imports via Babel, and briefly discuss whether we even need Babel in 2020 for our Node setup.
In Part 2 of this minimal setup, I’ll add in setup for eslint and prettier, and show you how to get them to play nicely together. Then we’ll update some settings in VS Code to finish the process.
The final repository can be found…
Part 2
In my last post I reviewed some of the basics on Client Side Rendering (CSR) vs. Server Side Rendering (SSR). Check that out here if you’re unfamiliar:
Create React App was the example of a CSR app, and Next.js was the lead-in to the world of SSR. As noted, Next.js takes all of this rendering on the server to the next level with lots of options, so this post will explain some of its power with use cases.
🗒 quick note: you can google “CRA SSR” and there’s plenty to do. …
Part 1
Recently, I’ve been working more with Next.js. Its ability to help you pre-render your site on the server is really powerful. Before diving into any of the specifics on Next.js and its methodologies on pre-rendering, let’s take a step back and discuss basic Client Side Rendering vs. Server Side Rendering generically.
Afterwards, check out Part 2 here, where we’ll take a deeper dive into Next.js pre-rendering strategies with examples.
I’ve built several Create React App (CRA) apps over the past few years, and the mental model goes like this:
- When you run
npm run build, your React code, styling, etc…
