DEV Community: Evan Tahler

Bundling and Distributing Next.js Sites via NPM

Evan Tahler — Fri, 04 Jun 2021 19:54:16 +0000

Grouparoo uses Next.js to build our web frontend(s), and we distribute these frontend User Interfaces (UIs) via NPM as packages, e.g. @grouparoo/ui-community. This allows Grouparoo users to choose which UI they want to use (or none) by changing their package.json:

Example package.json for a Grouparoo project:

{
  "author": "Your Name <email@example.com>",
  "name": "grouparoo-application",
  "description": "A Grouparoo Deployment",
  "version": "0.0.1",
  "dependencies": {
    "@grouparoo/core": "0.3.3",
    "@grouparoo/postgres": "0.3.3",
    "@grouparoo/mailchimp": "0.3.3",
    "@grouparoo/ui-community": "0.3.3" // <-- Choose UI Package to install
  },
  "scripts": {
    "start": "cd node_modules/@grouparoo/core && ./bin/start"
  },
  "grouparoo": {
    "plugins": [
      "@grouparoo/postgres",
      "@grouparoo/mailchimp",
      "@grouparoo/ui-community" // <-- Choose UI Package to load
    ]
  }
}

Here is how we bundle up our Next.js applications so that our customers can use them out of the box.

`next build` and `npm run prepare`

The first step in “compiling” your Next.js projects is to use the next build command. We alias this to the “prepare” npm lifecyle command so that this command will be run automatically before npm publish. In this way we can ensure that we always have a freshly built bundle to use when we publish our packages.

This is different from Next’s recommendation to alias next build to npm build because we are not “deploying” our sites - we are publishing them. Many hosting providers look for a build script in your pacakge.json to run when the deploy, hence Next.js’ recommendation.

`.npmignore` vs `.gitignore`

The next step in bundling up a Next.js application for deployment via NPM is to include the build files. In all Next.js projects, you want to ignore the .next folder in your .gitignore. The .next folder is where Next.js keeps all the build artifacts it creates — minified javascript, css chunks, etc. Assuming your “source code” is Typescript and SCSS, everything in the .next folder should be ignored, and rebuilt as needed from the source.

BUT… the content of .next is actually what the visitors to your site really load - that’s the HTML, CSS, and Javascript that ends up in the browser. Since we are trying to package up a usable site, we need to bundle the contents of .next into our NPM bundles. However, we still want to exclude these rapidly changing files from git’s history.

The solution is a .npmignore file! By default, NPM will use a .gitignore file to determine which files it packs up into your packages, and which files it ignores. But, you can override this behavior by placing a .npmignore in your project. For example:

.gitignore

.DS_Store
node_modules
.next

.npmignore

.DS_Store
node_modules
# .next is included

Skip the `.pack` files

The final thing we learned is that while the contents of the .next directory are needed for your visitors, not everything is needed. We saw that we were shipping 300mb packages to NPM for our Next.js UIs. We dug into the .next folder and learned that if you opt-into Webpack v5 for your Next.js site, large .next/cache/*.pack files will be created to speed up how Webpack works. This is normal behavior, but we were inadvertently publishing these large files to NPM! We added the .next/cache/* directory to our .npmignore and our build sizes went down to a more reasonable 20mb.

Our final .npmignore looks like this:

.npmignore

.DS_Store
node_modules
.next/cache/*

Using Typescript to create a Robust API between your frontend and backend

Evan Tahler — Wed, 19 May 2021 17:48:32 +0000

Two of the major components of the @grouparoo/core application are a Node.js API server and a React frontend. We use Actionhero as the API server, and Next.JS for our React site generator. As we develop the Grouparoo application, we are constantly adding new API endpoints and changing existing ones.

One of the great features of Typescript is that it can help not only to share type definitions within a codebase, but also across multiple codebases or services. We share the Typescript types of our API responses with our React Frontend to be sure that we always know what kind of data we are getting back. This helps us ensure that there is a tight coupling between the frontend and backend, and that we will get compile-time warnings if there’s something wrong.

Getting the type of an API Response

In Actionhero, all API responses are defined by Actions, which are classes. The run() method of the Action class is what is finally returned to the API consumer. Here’s a prototypical example of an action that lets us know what time it is:

import { Action } from "actionhero";

export class GetTime extends Action {
  constructor() {
    super();
    this.name = "getTime";
    this.description = "I let you know what time it is";
    this.inputs = {};
    this.outputExample = {};
  }

  async run() {
    const now = new Date();
    return { time: now.getTime() };
  }
}

This action takes no input, and returns the current time as a number (the unix epoch in ms). The action is also listed in our config/routes.ts file as responding to GET /time.

The next step is to extract the run() method’s return type to get the type of the API response

We can use a helper like type-fest’s PromiseValue to get the return value, or we can do it ourselves:

// from https://www.jpwilliams.dev/how-to-unpack-the-return-type-of-a-promise-in-typescript

export type UnwrapPromise<T> = T extends Promise<infer U>
  ? U
  : T extends (...args: any) => Promise<infer U>
  ? U
  : T extends (...args: any) => infer U
  ? U
  : T;

So, the type of the Action’s response is:

type ActionResponse = UnwrapPromise<typeof GetTime.prototype.run>; // = { time: number; }

And in our IDE:

This is excellent because now any changes to our action will result in the type being automatically updated!

Consuming the API Response Type in React

The Grouparoo Application is stored in a monorepo, which means that the frontend and backend code always exist side-by-side. This means that we can reference the API code from our Frontend code, and make a helper to check our response types. We don't need our API code at run-time, but we can import the types from it as we develop and compile the app to Javascript.

The first thing to do is make a utility file which imports our Actions and extracts their types. Grouparoo does this in web/utils/apiData.ts

import { UnwrapPromise } from "./UnwrapPromise";
import { GetTime } from "../../api/src/actions/getTime";

export namespace Actions {
  export type GetTime = UnwrapPromise<typeof GetTime.prototype.run>;
}

This apiData.ts will allow us to more concisely reference Actions.GetTime in the rest of our react application.

Now, to use the Action’s response type, all we have to do is assign it to the response of an API request:

import { useState, useEffect } from "react";
import { Actions } from "../utils/apiData";

export default function TimeComponent() {
  const [time, setTime] = useState(0);

  useEffect(() => {
    load();
  }, []);

  async function load() {
    const response: Actions.GetTime = await fetch("/api/time");
    setTime(response.time);
  }

  if (time === 0) return <div>loading...</div>;

  const formattedTime = new Date(time).toLocaleString();
  return <div>The time is: {formattedTime}</div>;
}

Now we have enforced that the type of response in the load() method above will match the Action, being { time: number; }. We will now get help from Typescript if we don’t use that response value properly as a number. Foe example, assigning it to a string variable creates an error.

Summary

Since Typescript is used at “compile time”, it can be used across application boundaries in surprisingly useful ways. It’s a great way to help your team keep your frontend and backend in sync. You won’t incur any runtime overhead using Typescript like this, and it provides extra certainty in your test suite that your frontend will use the data it gets from your API correctly.

If this type of work is interesting to you, Grouparoo is hiring!

Deferring Side-Effects in Node.js until the End of a Transaction

Evan Tahler — Mon, 17 May 2021 18:05:04 +0000

At Grouparoo, we use Actionhero as our Node.js API server and Sequelize for our Object Relational Mapping (ORM) tool - making it easy to work with complex records from our database. Within our Actions and Tasks, we often want to treat the whole execution as a single database transaction - either all the modifications to the database will succeed or fail as a unit. This is really helpful when a single activity may create or modify many database rows.

Why do we need Transactions?

Take the following example from a prototypical blogging site. When a user is created (POST /api/v1/user), we also create their first post and send them a welcome email. All examples in this post are written in Typescript, but the concepts work the same for Javascript.

import { action } from "actionhero";
import { User, Post } from "../models";

export class UserCreate extends Action {
  constructor() {
    super();
    this.name = "user:create";
    this.description = "create a user and their first post";
    this.inputs = {
      firstName: { required: true },
      lastName: { required: true },
      password: { required: true },
      email: { required: true },
    };
  }

  async run({ params }) {
    const user = await User.create(params);
    await user.updatePassword(params.password);
    await user.sendWelcomeEmail();

    const post = await Post.create({
      userId: user.id,
      title: "My First Post",
      published: false,
    });

    return { userId: user.id, postId: post.id };
  }
}

In this example, we:

Create the user record
Update the user’s password
Send the welcome email
Create the first post for the new user
Return the IDs of the new records created

This works as long as nothing fails mid-action. What if we couldn’t update the user’s password? The new user record would still be in our database, and we would need a try/catch to clean up the data. If not, when the user tries to sign up again, they would have trouble as there would already be a record in the database for their email address.

To solve this cleanup problem, you could use transactions. Using Sequelize’s Managed Transactions, the run method of the Action could be:

async run({ params }) {
  return sequelize.transaction(async (t) => {
    const user = await User.create(params, {transaction: t});
    await user.updatePassword(params.password, {transaction: t} );
    await user.sendWelcomeEmail();

    const post = await Post.create({
      userId: user.id,
      title: 'My First Post',
      published: false,
    }, {transaction: t})

    return { userId: user.id, postId: post.id };
  })
}

Managed Transactions in Sequelize are very helpful - you don’t need to worry about rolling back the transaction if something goes wrong! If there’s an error throw-n, it will rollback the whole transaction automatically.

While this is safer than the first attempt, there are still some problems:

We have to remember to pass the transaction object to every Sequelize call
We need to ensure that every method we call which could read or write to the database needs to use the transaction as well, and take it as an argument (like user.updatePassword()... that probably needs to write to the database, right?)
Sending the welcome email is not transaction safe.

Sending the email as-written will happen even if we roll back the transaction because of an error when creating the new post… which isn’t great if the user record wasn’t committed! So what do we do?

Automatically Pass Transactions to all Queries: CLS-Hooked

The solution to our problem comes from a wonderful package called cls-hooked. Using the magic of AsyncHooks, this package can tell when certain code is within a callback chain or promise. In this way, you can say: "for all methods invoked within this async function, I want to keep this variable in scope". This is pretty wild! If you opt into using Sequelize with CLS-Hooked, every SQL statement will check to see if there is already a transaction in scope... You don't need to manually supply it as an argument!

From the cls-hooked readme:

CLS: "Continuation-Local Storage"

Continuation-local storage works like thread-local storage in threaded programming, but is based on chains of Node-style callbacks instead of threads.

There is a performance penalty for using cls-hooked, but in our testing, it isn’t meaningful when compared to await-ing SQL results from a remote database.

Using cls-hooked, our Action's run method now can look like this:

// Elsewhere in the Project

const cls = require('cls-hooked');
const namespace = cls.createNamespace('actionhero')
const Sequelize = require('sequelize');
Sequelize.useCLS(namespace);
new Sequelize(....);

// Our Run Method

async run({ params }) {
  return sequelize.transaction(async (t) => {
    const user = await User.create(params);
    await user.updatePassword(params.password);
    await user.sendWelcomeEmail();

    const post = await Post.create({
      userId: user.id,
      title: 'My First Post',
      published: false,
    })

    return { userId: user.id, postId: post.id };
  })
}

Ok! We have removed the need to pass transaction to all queries and sub-methods! All that remains now is the user.sendWelcomeEmail() side-effect. How can we delay this method until the end of the transaction?

CLS and Deferred Execution

Looking deeper into how cls-hooked works, we can see that it is possible to tell if you are currently in a namespace, and to set and get values from the namespace. Think of this like a session... but for the callback or promise your code is within! With this in mind, we can write our run method to be transaction-aware. This means that we can use a pattern that knows to run a function in-line if we aren’t within a transaction, but if we are, defer it until the end. We’ve wrapped utilities to do this within Grouparoo’s CLS module.

With the CLS module you can write code like this:

// from the Grouparoo Test Suite: Within Transaction

test("in a transaction, deferred jobs will be run afterwords", async () => {
  const results = [];
  const runner = async () => {
    await CLS.afterCommit(() => results.push("side-effect-1"));
    await CLS.afterCommit(() => results.push("side-effect-2"));
    results.push("in-line");
  };

  await CLS.wrap(() => runner());
  expect(results).toEqual(["in-line", "side-effect-1", "side-effect-2"]);
});

You can see here that once you CLS.wrap() an async function, you can defer the execution of anything wrapped with CLS.afterCommit() until the transaction is complete. The order of the afterCommit side-effects is deterministic, and in-line happens first.

You can also take the same code and choose not apply CLS.wrap() to it to see that it still works, but the order of the side-effects has changed:

// from the Grouparoo Test Suite: Without Transaction

test("without a transaction, deferred jobs will be run in-line", async () => {
  const results = [];
  const runner = async () => {
    await CLS.afterCommit(() => results.push("side-effect-1"));
    await CLS.afterCommit(() => results.push("side-effect-2"));
    results.push("in-line");
  };

  await runner();
  expect(results).toEqual(["side-effect-1", "side-effect-2", "in-line"]);
});

CLSAction and CLSTask

Now that it is possible to take arbitrary functions and delay their execution until the transaction is complete, we can use these techniques to make a new type of Action and Task that has this functionality built in. We call these CLSAction and CLSTask. These new classes extend the regular Actionhero Action and Task classes, but provide a new runWithinTransaction method to replace run, which helpfully already uses CLS.wrap(). This makes it very easy for us to opt-into an Action in which automatically runs within a Sequelize transaction, and can defer it's own side-effects!

Putting everything together, our new transaction-safe Action looks like this:

// *** Define the CLSAction Class ***

import { Action } from "actionhero";
import { CLS } from "../modules/cls";

export abstract class CLSAction extends Action {
  constructor() {
    super();
  }

  async run(data) {
    return CLS.wrap(async () => await this.runWithinTransaction(data));
  }

  abstract runWithinTransaction(data): Promise<any>;
}

// *** Use the CLSAction Class ***

import { CLSAction } from "../classes";
import { User, Post } from "../models";

export class UserCreate extends CLSAction {
  constructor() {
    super();
    this.name = "user:create";
    this.description = "create a user and their first post";
    this.inputs = {
      firstName: { required: true },
      lastName: { required: true },
      password: { required: true },
      email: { required: true },
    };
  }

  async runWithinTransaction({ params }) {
    const user = await User.create(params);
    await user.updatePassword(params.password);
    await CLS.afterCommit(user.sendWelcomeEmail);

    const post = await Post.create({
      userId: user.id,
      title: "My First Post",
      published: false,
    });

    return { userId: user.id, postId: post.id };
  }
}

If the transaction fails, the email won’t be sent, and all the models will rolled back. There won't be any mess to clean up 🧹!

Summary

The cls-hooked module is a very powerful tool. If applied globally, it unlocks the ability to produce side-effects throughout your application worry-free. Perhaps your models need to enqueue a Task every time they are created... now you can if you cls.wrap() it! You can be sure that task won’t be enqueued unless the model was really saved and committed. This unlocks powerful tools that you can use with confidence.

Why do database columns have a character length of 191?

Evan Tahler — Mon, 17 May 2021 18:00:46 +0000

Sometimes, when you are looking at a database’s schema, you see that there are text fields defined like this:

email_address varchar(191) NOT NULL

This means that the column supports strings with a maximum length of 191 characters, and can’t be null. 191 is such an odd number - where did it come from? In this post, we’ll look at the historical reasons for the 191 character limit as a default in most relational databases.

Why `varchar` and not `text`?

The first question you might ask is why limit the length of the strings you can store in a database at all? All modern popular relational database support (almost) unlimited sized strings with a text or blob-type column, so why not use that? The reason is indexes.

If you are going to search by a column, say email_address, you probably want to add an index to it to speed things up when you do the following:

select id from users where email = 'foo@example.com';

As your table gets bigger, searches get slower because your database has to check every row to find a match. However, if you add a search index, you are telling your database to essentially "pre-compute" popular search patterns with a tree so the next search is much faster. In essence, indexes spend computation time (and a little bit of disk space) making writes to the database slower, to speed up reads later. For most applications this is a great tradeoff, since they are "read heavy" and "write lite".

So, why use varchar? Indexes can be made to perform better when assumptions can be made about the type of data they store. Knowing how long the strings in the index are is one of the best ways speed things up. For some databases, you aren’t allowed to add a search index to columns of type text because this optimization can't be done, while in others, the index just won’t perform as well. In fact, historically, databases were constructed with limits on how big an index could be to optimize search and how they stored data on disk.

It’s MySQL’s fault

Ok, so indexes are good. But, generically, it seems that an index of any size should work, and while that’s true today, it wasn't always possible. The next stop on our journey is to look at what the default column size was far in the past, and that was 255 characters, e.g.:

email_address varchar(255) NOT NULL

MySQL, the most popular open source database of the early 2000s had a limit of 255 characters in indexed fields. The history is fuzzy as to why MySQL chose a 255 character limit (see the articles linked below), but the most popular theories include:

256 is the largest number you can represent with an 8-bit integer. MySQL being very concerned with speed and memory usage, wanted to store things with the smallest possible data types.
MySQL was itself trying to be compatible with even older databases (sybase/SAP), and they had a 255 character limit.
MySQL wanted to ensure that its index files could fit within a single page block on older file systems.

With a 256 character limit in mind, the MySQL developers felt comfortable further optimizing many parts of the database against that 255-character limit (more on this later). Since many popular open source application frameworks launched in that time period (Wordpress, Django, and Rails to name a few), they all followed MySQL’s defaults, even when they could run on multiple database types, like postgres. This formed a common default for most ORMs (Object–relational mapping - Wikipedia) to use varchar(255), regardless of the database in use.

It’s 🐟’s fault

255 makes a lot more sense than 191. How did we get to 191? I’m going to blame emoji 😜. Seriously. Well, utf8mb4 at least, the charter set that allows for "international" ¹ characters, and included the first emoji. MySQL in the early 2000s was happy supporting 255 characters in varchar columns and indexing them. However, the the most popular text encoding (Latin1 or utf8 ) on the most popular MySQL database engine (innodb) assumed that 3 bytes was enough to store every character ², and once utf8mb4 came along with characters like 𠼭³ and 🐟, 4 bytes were needed to store each character. There were more character to choose from, so referencing them took more bytes.

The way innodb MySQL databases worked was that you can only have 767 bytes for an index - enough to store 255 3-byte characters (767/3 = 255). This is an extreme example of index optimization based on knowing the size of the data you are indexing! So if the characters took more space to store, then the number of characters you could index had to get smaller. Specifically, 767/4 = 191 characters! As more software supported an international audience, varchar(191) replaced varchar(255) as the default. For those software applications that didn't need to support international users, they also needed to upgrade once users started expecting emoji support (often linked to the rise of smartphones) in the early 2010s.

Today

These days, with modern databases, character encodings like utf8mb4 and others which can support "all" characters are the default, and the fixed-length index is a thing of the past. However, we still have these 191-character defaults in many applications to ensure compatibility. Regardless, indexes still work best when they know the size of the the strings they are comparing, so we still want to have some limit on our column length for speed reasons, and thanks to history and inertia, the 191 limit is still with us.

Thank you

Thanks to all the reference articles I checked when putting together this history, specifically:

"International" is an odd way to talk about the languages that most of the world uses, specifically those using non-Latin characters. However, operating systems and databases had thoroughly english-centric origins, and the legacy of those early choices is still rippling though our code today. ↩
Throughout this post, I've use the word "character" rather than "letter", and this is why - depending on your language, each character in a string might be a letter, a whole word, or even a pictogram like an emoji. ↩
"To Honk" (like from a car) - https://words.hk/zidin/%F0%A0%BC%AD ↩

Gifit: Convert Screen Recordings to easy-to-share Animated gifs

Evan Tahler — Wed, 12 May 2021 15:40:04 +0000

When building Grouparoo, the team often shares screen recordings of our work with each other. In many cases, the tools we are using (like Github, until recently anyway) could only embed image content into READMEs and Pull Requests. That meant that the humble animated gif was often the best way to share a video. Here is my personal script called gifit which uses the open source ffmpeg and gifsicle tools to make it super easy to convert any video file into an easy-to-share gif!

#!/bin/bash

# This script required ffmpeg and gifsicle
# On OSX: `brew install ffmpeg gifsicle`

SECONDS=0
INPUT_FILE=$1
BASENAME="${INPUT_FILE%.*}"
OUTPUT_FILE="$BASENAME.gif"

echo "🎥 Converting $INPUT_FILE to $OUTPUT_FILE"

# Convert the video to a gif
ffmpeg -i $INPUT_FILE -pix_fmt rgb8 -r 10 $OUTPUT_FILE -loglevel warning -stats

# Compress the Gif
# Reduce the size to 1/2 the original (because we are recording a retina screen)
# Tweak the "lossy" argument to add more colors, but increase filesize
gifsicle -O3 $OUTPUT_FILE -o $OUTPUT_FILE --lossy=80 --scale=0.5

# How lng did it take?
ELAPSED="$(($SECONDS / 3600))hrs $((($SECONDS / 60) % 60))min $(($SECONDS % 60))sec"

echo "🎉 Complete in $ELAPSED"

Note that on OS X you will need to brew install ffmpeg gifsicle first.

So, to make the video above, I:

Used Quicktime to record my screen
Saved the video as screenshot.mov
Ran gifit screenshot.mov and I got screenshot.gif!

Dialect differences between SQLite and Postgres in Sequelize

Evan Tahler — Mon, 10 May 2021 17:14:38 +0000

Like many applications, Grouparoo stores data in a relational database. Unlike most applications, Grouparoo works with 2 different types of databases - Postgres and SQLite. We enable our customers to run Grouparoo in a number of different ways - on their laptop with no external decencies, and as part of a large cluster with many servers processing data in parallel. When running Grouparoo locally, you can use SQLite so no other dependencies are needed, and in the production cluster, you can use a hosted version of Postgres provided by your hosting provider.

Grouparoo uses the Sequelize Object Relational Mapper, or ORM, along with sequelize-typescript so we can work with the same Objects in our codebase, regardless of the database providing persistence. Sequelize does a great job of abstracting away the differences between the database types... most of the time. In this blog post, I’ll be sharing the times when the differences in the SQL implementations of Postgres and SQLite matter.

Case Insensitive Sting Comparisons

Postgres supports both the like and iLike operators for comparing strings, with the i indicating case-insensitive matching (Postgres Docs). That means you can choose, per query, if you are ignoring case or not:

-- Postgres --
-- assuming you have `email = person@example.com` (lowercase) in your `users` table

-- match
SELECT * FROM users WHERE email ILIKE '%@EXAMPLE.COM';

-- no match
SELECT * FROM users WHERE email LIKE '%@EXAMPLE.COM';

However, in SQLite, all string comparisons are case-insensitive (and there is no iLike function (SQLite Docs). Instead, if you really want your like function to be made case-sensitive, you would use the case_sensitive_like PRAGMA (SQLite Docs)... but that’s a database-wide change that you likely don’t want to use.

-- SQLite --
-- assuming you have `email = person@example.com` (lowercase) in your `users` table

-- match
SELECT * FROM users WHERE email LIKE '%@EXAMPLE.COM';

-- no match
PRAGMA case_sensitive_like=ON;
SELECT * FROM users WHERE email LIKE '%@EXAMPLE.COM';

In the Grouparoo application, this distinction shows up in a number of places, with the most interesting being that we need to provide different rules that can be used to calculate Group membership. If you visit the groups config page and check out the options for string or email comparisons between Postgres and SQLite, you’ll see the difference.

Date and Time Part Functions

Postgres ships with a number of handy date and time functions with a consistent API, like date_trunc. (Postgres Docs) SQLite instead chose to rely on the C-like strftime function (SQLite Docs). Both are popular ways to deal with time, but very different ways of approaches.

For example, if we want to count up how many events occurred per hour:

-- Postgres ---
SELECT COUNT(*) as total, date_trunc('hour', "occurredAt") as time FROM events GROUP BY 2

-- SQLite ---
SELECT COUNT(*) as total, strftime('%Y-%m-%d %H:00:00', "occurredAt") as time FROM events GROUP BY 2

While not necessarily a user-facing problem, there are quite a few places in the Grouparoo codebase were we calculate rollups like these, and need to make different queries depending on the database in use.

Min and Max typecasting

Sequelize helps you to write rather complex queries in a database-agnostic way. Consider the following query that asks for all the types of events that exist, and returns the count, first occurrence and most recent occurrence. e.g.: we might learn that there have been 100 pageview events, with the first one on Jan 1 and the most recent one today. This Sequelize query works for both Postgres and SQLite!

const types = await Event.findAll({
  attributes: [
    "type",
    [api.sequelize.fn("COUNT", "id"), "count"],
    [api.sequelize.fn("MIN", api.sequelize.col("occurredAt")), "min"],
    [api.sequelize.fn("MAX", api.sequelize.col("occurredAt")), "max"],
  ],
  group: ["type"],
  order: [[api.sequelize.literal("count"), "desc"]],
});

However, the resulting objects differ slightly types[0].min will be a JS Date object from Postgres and a string from SQLite. They will need to be converted to the same type in your application code.

Boolean Column typecasting

SQLite does not have Boolean columns, and uses integers instead. When using an ORM that supports the boolean type, most of the time it knows to covert the database’s 1 to true and 0 to false, but when accessing properties directly it may not. This appears regularly with Sequelize’s instance.getDataValue() method. Conversely, Postgres boolean values are always properly cast.

Transaction Limits

SQLite can only handle one transaction at a time. This makes sense, as it’s quite literally reading and writing a file on disk. Postgres, on the other hand, can handle many transactions at once and does a great job of merging the results and avoiding deadlocks. If you using Node.JS like Grouparoo is, even a single process can generate many transactions - you might be processing many API requests in parallel, or in the case of Grouparoo, running many background tasks at once.

To help avoid SQLite deadlocks (which look like SequelizeTimeoutError: SQLITE_BUSY: database is locked), we limit the number of workers we run against a SQLite database to 1.

Compound Indexes with Unique Columns

Sequelize has a bug in which a migration against a table that has an index against 2 columns will make those columns unique, even if they wen’t before the migration. To mitigate this, we do not use compound indexes in the Grouparoo application.

While this list may seem long, the vast majority of the Grouparoo codebase works exactly the same regardless of if you are backing the application with SQLite or Postgres. The Sequelize team did a great job abstracting most of the dialect nuances away.

Don’t use underscores in your HTTP Headers

Evan Tahler — Mon, 10 May 2021 15:12:56 +0000

Don’t use underscores in your HTTP Headers... at least according to AWS and Nginx!

curl --HEADER "AUTH_TOKEN: abc" example.com # is bad
curl --HEADER "AUTH-TOKEN: abc" example.com # is OK

Grouparoo is a self-hosted application, and we are always helping folks run and deploy our service in new ways. Recently, we’ve been working an example application for Amazon Web Service’s (AWS) Elastic Beanstalk service. Elastic Beanstalk is AWS’s original Platform as a Service (PaaS) which means you can deploy your application without having to directly manage the servers yourself. Also, Elastic Beanstalk servers are within you Virtual Private Cloud (VPC), so they are good choice if you want to integrate with any of AWS’ other services, like a database or cache.

The app-example-aws app deployed just fine, but we were running into a strange bug: users of our web UI would be logged out on every subsequent page load! We weren’t seeing this behavior on any of the other hosting platforms we’ve used, including other AWS deployments hosting options. What could be wrong?

Eventually we narrowed down the problem to communication between our website UI and the API server. The Grouparoo UI server uses a special header, X-GROUPAROO-SERVER_TOKEN , along with the users’s session cookie, to authenticate against the API to pre-hydrate our pages on behalf of the user making the request. This page hydration request was the only type of request failing. Eventually we got into the weeds of the network request, and saw that the API was never receiving the X-GROUPAROO-SERVER_TOKEN header, but everything else was coming though OK:

{
  "headers": {
    "connection": "upgrade",
    "host": "app-example-aws.example.com",
    "x-real-ip": "172.31.xxx.xxx",
    "x-forwarded-for": "54.157.xxx.xxx, 172.31.xxx.xxx",
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "x-amzn-trace-id": "Root=1-60517ca4-xxxxx",
    "accept": "application/json",
    "content-type": "application/json",
    "cookie": "grouparooSessionId=xxxxxxxxxx",
    "user-agent": "axios/0.21.1"
  }
}

After some digging, we learned that Elastic Beanstalk fronts its applications with Nginx acting as a reverse proxy, which by default, considers headers with underscores CGI commands of yore and ignores them. By default the Nginx option underscores_in_headers is off , and you can learn more here. Please note that using underscores in headers is perfectly valid per the HTTP spec, but Nginx, by default, will ignore them.

(photo of a lost header, the football kind)

It was a matter of preference whether or not right thing to do was to change the header we use and not use underscores (X-GROUPAROO-SERVER-TOKEN) , or to modify the Nginx reverse proxy configuration on our Elastic Beanstalk servers (which is possible - see here). At the end of the day we want Grouparoo to work out-of-the box on as many platforms as possible without needing custom configuration. Nginx is a wildly popular web server, load balancer, and reverse proxy - and we should to be compatible with its defaults. To that end, we opted to change our headers not to use underscores. I recommend that everyone else developing a web application do the same and follow Nginx's defaults to avoid problems like this down the road.

Production Node Applications with Docker - 3 DevOps Tips for Shutting Down Properly

Evan Tahler — Wed, 19 Feb 2020 04:16:11 +0000

Recently, I’ve been noticing that a high number of folks using Node Resque have been reporting similar problems relating to the topics of shutting down your node application and property handling uncaught exceptions and unix signals. These problems are exacerbated with deployments involving Docker or a platform like Heroku, which uses Docker under-the-hood. However, if you keep these tips in mind, it’s easy to have your app work exactly like you want it too… even when things are going wrong!

I’ve added a Docker-specific example to Node Rescue which you can check out here https://github.com/actionhero/node-resque/tree/master/examples/docker, and this blog post will dive deeper into the 3 areas the the example focuses on. Node Resque is a background-job processing framework for Node & Typescript which stores jobs in Redis. It support delayed and recurring jobs, plugins, and more. Node Rescue is a core component of the Actionhero framework.

1. Ensure Your Application Receives Signals, AKA Don’t use a Process Manager

You shouldn’t be using NPM, YARN, PM2 or any other tool to “run” your application inside of your Docker images. You should be calling only the node executable and the file you want to run. This is important so that the signals Docker wants to pass to your application actually get to your app!

There are lots of Unix signals that all mean different things, but in a nutshell it’s a way for the Operating System (OS) to tell your application to do something, usually implying that it should change its lifecycle state (stop, reboot, etc). For web servers, the most common signals will be SIGTERM (terminate,) , SIGKILL (kill, aka: “no really stop right now I don’t care what you are working on”) and SIGUSR2 (reboot). Docker, assuming your base OS is a *NIX operating system like Ubuntu, Red Hat, Debian, Alpine, etc, uses these signals too. For example, when you tell a running Docker instance to stop (docker stop), it will send SIGERM to your application, wait some amount of time for it to shut down, and then do a hard stop with SIGKILL. That’s the same thing that would happen with docker kill - it sends SIGKILL too. What are the differences between stop and kill? That depends on how you write your application! We’ll cover that more in section #2.

So how to you start your node application directly? Assuming you can run your application on your development machine with node ./dist/server.js, your docker file might look like this:

FROM alpine:latest
MAINTAINER admin@actionherojs.com
WORKDIR /app
RUN apk add —update nodejs nodejs-npm
COPY . .
RUN npm install
CMD [“node”, “/dist/server.js”]
EXPOSE 8080

And, be sure you don’t copy your local node_modules with a .dockerignore file

node_modules
*.log

We are using the CMD directive, not ENTRYPOINT because we don’t want Docker to use a subshell. Entrypoint and Cmd without 2 arguments works by calling /bin/sh -c and then your command… which can trap the signals it gets itself and not pass them on to your application. If you used a process runner like npm start, the same thing could happen.

You can learn more about docker signals & node here https://hynek.me/articles/docker-signals/

2. Gracefully Shut Down your Applications by Listening for Signals

Ok, so we are sure we will get the signals from the OS and Docker… how do we handle them? Node makes it really easy to listen for these signals in your app via:

process.on(“SIGTERM”,() => {
  console.log(`[ SIGNAL ] - SIGTERM`);
});

This will prevent Node.JS from stopping your application outright, and will give you an event so you can do something about it.

… but what should you do? If you application is a web server, you might:

Stop accepting new HTTP requests
Toggle all health checks (ie: GET /status) to return false so the load balancer will stop sending traffic to this instance
Wait to finish any existing HTTP requests in progress.
And finally… exit the process when all of that is complete.

If your application uses Node Resque, you should call await worker.end(), await scheduler.end() etc. This will tell the rest of the cluster that this worker is:

About to go away
Lets it finish the job it was working on
Remove the record of this instance from Redis If you don’t do this, the cluster will think your worker should be there and (for a while anyway) the worker will still be displayed as a possible candidate for working jobs.

In Actionhero we manage this at the application level (await actionhero.process.stop()) and allow all of the sub-systems (initializers) to gracefully shut down - servers, task workers, cache, chat rooms, etc. It’s important to hand off work to other members in the cluster and/or let connected clients know what to do.

A robust collection of process events for your node app might look like:

async function shutdown() {
  // the shutdown code for your application
  await app.end();
  console.log(`processes gracefully stopped`);
}

function awaitHardStop() {
  const timeout = process.env.SHUTDOWN_TIMEOUT
    ? parseInt(process.env.SHUTDOWN_TIMEOUT)
    : 1000 * 30;

  return setTimeout(() => {
    console.error(
      `Process did not terminate within ${timeout}ms. Stopping now!`
    );
    process.nextTick(process.exit(1));
  }, timeout);
}

// handle errors & rejections
process.on(“uncaughtException”, error => {
  console.error(error.stack);
  process.nextTick(process.exit(1));
});

process.on(“unhandledRejection”, rejection => {
  console.error(rejection.stack);
  process.nextTick(process.exit(1));
});

// handle signals
process.on(“SIGINT”, async () => {
  console.log(`[ SIGNAL ] - SIGINT`);
  let timer = awaitHardStop();
  await shutdown();
  clearTimeout(timer);
});

process.on(“SIGTERM”, async () => {
  console.log(`[ SIGNAL ] - SIGTERM`);
  let timer = awaitHardStop();
  await shutdown();
  clearTimeout(timer);
});

process.on(“SIGUSR2”, async () => {
  console.log(`[ SIGNAL ] - SIGUSR2`);
  let timer = awaitHardStop();
  await shutdown();
  clearTimeout(timer);
});

Let’s walk though this:

We create a method to call when we should shutdown our application, shutdown, which contains our application-specific shutdown logic.
We create a “hard stop” fallback method that will kill the process if the shutdown behavior doesn’t complete fast enough, awaitHardStop. This is to help with situations where an exception might happen during your shutdown behavior, a background task is taking too long, a timer doesn’t resolve, you can’t close your database connection… there are lots of things that could go wrong. We also use an Environment Variable to customize how long we wait (process.env.SHUTDOWN_TIMEOUT) which you can configure via Docker. If the app doesn’t exist in in this time, we forcibly exit the program with 1, indicating a crash or error
We listen for signals, and (1) start the “hard stop timer”, and then (2) call await shutdown()
If we successfully shutdown we stop timer, and exit the process with 0, indicating an exit with no problems

Note:
We can listen for any unix signal we want, but we should never listen for SIGKILL. If we try to catch it with a process listener, and we don’t immediately exit the application, we’ve broken our promise to the operating system that SIGKILL will immediately end any process… and bad things could happen.

3. Log Everything

Finally, log the heck out of signaling behavior in your application. It’s innately hard to debug this type of thing, as you are telling your app to stop… but you haven’t yet stopped. Even after docker stop, logs are still generated and stored…. And you might need them!

In the Node Rescue examples, we log all the stop events and when the application finally exists:

docker logs -f {your image ID}

… (snip)

scheduler polling
scheduler working timestamp 1581912881
scheduler enqueuing job 1581912881 >> {“class”:”subtract”,”queue”:”math”,”args”:[2,1]}
scheduler polling
[ SIGNAL ] - SIGTERM
scheduler ended
worker ended
processes gracefully stopped

So, if you:

Ensure Your Application Receives Signals, AKA Don’t use a Process Manager
Gracefully Shut Down your Applications by Listening for Signals
Log Everything

You should have no problem creating robust node applications that are deployed via Docker, and are a pleasure to monitor and debug.

Proxying free Heroku Dynos though Cloudflare to a Custom Domain

Evan Tahler — Mon, 30 Dec 2019 17:04:44 +0000

The Actionhero project runs a number of websites for the community - documentation, sample apps, etc. We often rely on Heroku’s free hosting to run these applications. Heroku makes it very easy to deploy your apps in a 12-factor way, attach databases, and deploy with a simple git push. It’s a great, free option to deploy your applications.

The Actionhero project uses Cloudflare as our DNS provider, as they provide a simple interface to enforce HTTPS, add caching, and a whole other host of features… and it’s also free!

One of the Cloudflare features we have enabled is full HTTPS encryption across the whole domain, meaning that traffic remains HTTPS’d between you and the Cloudflare proxy (which provides caching), and remains HTTPS’d from Cloudflare to our servers at Heroku.

Heroku doesn’t provide HTTPS certificates for free dynos/apps like the ones we are using, except on their own domain, *.herokuapp.com. By default your app will be visible on a domain like my-app.herokuapp.comHowever, you can opt to add custom domain to your app, like my-cool-app.com but… you can’t add HTTPS on the free Heroku tier. Your custom CNAME won’t support it.

If you point your CNAME to this new custom Heroku DNS target, Cloudflare will keep directing the client to HTTPS, which Heroku won’t like… and you’ll end up with a Too many redirects error.

The way to solve this is to use the original CNAME target Heroku gave you even though it’s no longer listed in the interface. Point the CNAME in Cloudflare at *.herokuapp.com even though Heroku will tell you to use a new DNS target in the interface, and you will have encrypted traffic flowing in no time!

CNAME     chat.actionherojs.com     chat-actionhero.herokuapp.com

As an interesting notes, older Heroku apps keep showing the original *.herokuapp.com CNAME target in the dashboard, and not a new custom one, even with a custom URL added. This behavior confirms that the above is a good path to get things working!

Markdown in React and Custom Page Elements

Evan Tahler — Mon, 02 Dec 2019 00:45:35 +0000

I recently moved the Actionhero tutorials from the Actionhero Docs site docs.actionherojs.com to the main Actionhero website www.actionherojs.com. We are switching Actionhero from Javascript to Typescript, and as such we’ve changed from using JSDoc to TypeDoc to generate our documentation site. Previously, we had a custom “theme” for JSdoc which included our Tutorials within the docs, but that was a bit of a hack. To me, there’s a distinction between tutorials and docs, and having both in the same place could lead to confusion. This was a great time to make the switch.

Why Separate Docs from Tutorials?

I think to have a well-documented project you need both of these components - Docs and Tutorials, but they aren’t consumed by the same audience in the same way.

Tutorials/Guides - These are narrative descriptions of how you might use a feature. It walks through the steps linearly form A to B to C, and when you are done, you have a working thing. These are often geared towards new users to the product or tool.
Docs - Docs are API reference guides, method signatures, and generally other hints to how to implement something technically once you understand how & why you might use it.

I often reference this wonderful guide by Divio talking about the different types of documentation: https://www.divio.com/blog/documentation/. You should read it if you aren’t familiar with the “Cooking” metaphor for documentation.

Markdown in your HTML

It was very pleasant to write Actionhero’s tutorials in Markdown. It makes focusing on the content rather than the style very simple, while abstracting away all the DIVs and TAGs of HTML. It also makes it easy to Diff changes when updating the site (i.e. when looking at a Pull Request). With the goal of keeping this part of the site in Markdown, we needed to find a way to render it React.

The React Markdown package is wonderful at this step. You can load in a Markdown file and React Markdown with generate the HTML.

A few tips:

We use Next.js. The way that Next.js handles hydration of pages from the server to the client wants to pass DATA and not HTML. This means that if were to render the markdown content on the server when doing a hot-reload of the page (i.e. navigation form another page to this page), the markdown HTML would not properly render. That’s why we parse the markdown at the componentDidMount stage of the lifecycle. This may have adverse effects on the SEO of those pages.
You can load the markdown file into your app as a Prop derived via getInitialProps! This means that the markdown content will be passed down from the server on initial page load.

export default class ToutorialPage extends Component<Props, State> {
  static async getInitialProps(ctx) {
    const name = ctx.query.name;
    const markdown = await require(`./../../tutorials/${name}.md`);
    return {
      markdown: markdown.default,
      name
    };
  }

  render () {
      return (
      <ReactMarkdown
        source={this.props.markdown}
        escapeHtml={false}
        renderers={{}}
      />
    ) 
  }
}

Hooking into Rendering to modify State

In the example above you can see that react-markdown lets us provide special renderers for each HTML element. 2 things that were important to this project were rendering code properly, and adding sub-navigation to each page.

Adding code was easy, as we already had a component for rendering code based on react-syntax-highlighter.

import { Component } from "react";
import SyntaxHighlighter from "react-syntax-highlighter";
import { docco } from "react-syntax-highlighter/dist/cjs/styles/hljs";

interface Props {
  language?: string;
  showLineNumbers?: boolean;
  value?: string;
}

export default class extends Component<Props> {
  render() {
    const language = this.props.language || "typescript";
    const showLineNumbers = this.props.showLineNumbers || false;

    return (
      <SyntaxHighlighter
        language={language}
        style={docco}
        showLineNumbers={showLineNumbers}
      >
        {this.props.value ? this.props.value : this.props.children}
      </SyntaxHighlighter>
    );
  }
}

We just pass that component into our example above:

import Code from "./../../components/code";

export default class ToutorialPage extends Component<Props, State> {
  static async getInitialProps(ctx) {
    const name = ctx.query.name;
    const markdown = await require(`./../../tutorials/${name}.md`);
    return {
      markdown: markdown.default,
      name
    };
  }

  render () {
      return (
      <ReactMarkdown
        source={this.props.markdown}
        escapeHtml={false}
        renderers={{
          code: Code // <-- HERE
        }}
      />
    ) 
  }
}

Adding navigation was a bit tricker. We accomplished this by creating a custom renderer for Headers that also built up a list of all the section headers into the page’s state with this new parseHeading method:

parseHeading({ children }) {
    const { sectionHeadings } = this.state;

    return (
      <div>
        {children.map(child => {
          const stringValue = child.props.value;
          if (sectionHeadings.indexOf(stringValue) < 0) {
            sectionHeadings.push(stringValue); // <-- Build our list of headings
            this.setState({ sectionHeadings });
          }

          const style = Theme.typeography.h2;

          return (
              <div>
                <br />
                <h2 id={stringValue} style={style}>
                  <span style={{ fontWeight: 300, fontSize: 36 }}>{child}</span>
                </h2>
                <RedLine />
              </div>
          );
        })}
      </div>
    );
  }

this.state.sectionHeadings is built in our render as we parse the headers. We then have this available to the rest of the page to draw our side navigation!

Notes:

Since we are changing state within the render method, it’s easy to get into an infinite loop. That’s why we need to only modify the list of headers (sectionHeadings) if the header isn’t present.
Since we have access to the header’s render method now, we add more style! Here we are adding our custom RedLine component to draw a line under the header of each section

In the final version of the page’s source (which you can see here https://github.com/actionhero/www.actionherojs.com/blob/master/pages/tutorials/%5Bname%5D.tsx) you can see that we do even more in the header’s render message, link changing colors if the section is in view, highlighting things, etc. It’s very powerful!

You can read more about Actionhero’s move to Typescript in the new Typescript Tutorial here -> https://www.actionherojs.com/tutorials/typescript (yes, it’s written in markdown)!

Testing javascript applications with Selenium, Async/Await, and Jest

Evan Tahler — Sun, 03 Nov 2019 18:18:31 +0000

Originally posted Mar 27, 2018

The last time I used Selenium, in 2015, I hated it. It was slow, brittle, and difficult to get working. These days, it can actually be pleasant!

Recently, in the ActionHero project, we found that we really needed a “full browser” integration test… something that we couldn’t mock or accomplish with even a robust tool like request. We needed to ensure that our HTTP and WebSocket libraries properly shared session & fingerprint information, which required cookies, headers, and 2 “full” protocols in the test… so we needed a real browser :/

We recently switched ActionHero’s test suite from mocha to Jest. Jest is an awesome test framework for javascript projects (and react, and other things that compile to javascript). It supports parallel testing, watching & retrying, mocking, snapshotting… all the tools I was missing coming from Rails, the gold-standard for TDD frameworks. It turns out that some wonderful person has already done the heavy lifting to make a full-featured integration between Selenium and Jest… and it’s actually simple to use!

What follows is a step-by-step guide to writing a “full-browser” test in Jest on OSX, complete with saving off photos of the page.

First, you’ll need to install a few things into your node.js project:

npm install --save-dev jest jest-environment-webdriver

# if you don't have homebrew: https://brew.sh/
brew install chromedriver

chromedriver is a version of the Chrome browser which is able to be “machine controlled” by selenium in our tests. Note that we do not need to install anything else like the selenium server.

Jest already has support for multiple “renderers”. This is how it handles testing compiled-to-javascript files, like JSX. This means that we can signal to Jest in a given test file that it should use selenium. Jest uses magic comments for this:

/**
 * @jest-environment jest-environment-webdriver
 */

The default is to use chromedriver, which is what we’ll be using, but you can also test with Firefox, Safari, and other browsers. Using jest-environment-webdriver means that we get a few new global variables we can use in our tests, specifically browser, until, and by (full list here), which we will use in our test.

From here on out, you can use normal Jest commands to start your server in before blocks, configure whatever you need… and control your browser in the test. We can continue to use the normal Jest/Jasmine assertions. In this example, we’ll be testing www.actionherojs.com for a few things, but you’ll probably be testing localhost.

File Location: tests/integration/test.js

/**
 * @jest-environment jest-environment-webdriver
 */

const url = 'https://www.actionherojs.com'

describe('www.actionherojs.com#index', () => {
  test('it renders', async () => {
    await browser.get(url)
    const title = await browser.findElement(by.tagName('h2')).getText()
    expect(title).toContain('reusable, scalable, and quick')
  })

  test('loads the latest version number from GitHub', async () => {
    const foundAndLoadedCheck = async () => {
      await until.elementLocated(by.id('latestRelease'))
      const value = await browser.findElement(by.id('latestRelease')).getText()
      return value !== '~'
    }

    await browser.wait(foundAndLoadedCheck, 3000)
    const latestRelease = await browser.findElement(by.id('latestRelease')).getText()
    expect(latestRelease).toEqual('v18.1.3')
  })

  describe('save a screenshot from the browser', () => {
    test('save a picture', async () => {
      // files saved in ./reports/screenshots by default
      await browser.get(url)
      await browser.takeScreenshot()
    })
  })
})

Your test can now be run via the normal jest command. That’s it!

jest __tests__/integration/simple.js
 PASS  __tests__/integration/simple.js
  www.actionherojs.com#index
    ✓ it renders (770ms)
    ✓ loads the latest version number from GitHub (267ms)
    save a screenshot from the browser
      ✓ save a picture (784ms)
Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total
Snapshots:   0 total
Time:        3.204s, estimated 6s

Note that there is no need to start or stop the chromedriver or selenium server (this handled for you).

Selenium is very powerful (full api docs here). You can type input, scroll the page, get and set cookies, etc. If you do find that you need a “full” integration test, this is a very painless way to do it!

Why Choose Actionhero

Evan Tahler — Sat, 02 Nov 2019 00:03:20 +0000

or: Actionhero is the Node.js server for when your project grows up

It’s been over 7 years since I started on Actionhero, a Node.js server, and I’m very proud of how far we’ve come. We’ve got over 2,000 stars on GitHub and an active Slack community. We are used by many large companies in production, and are often cited by many publications as one of the better Node.JS frameworks. We are even approved by the US Department of Veteran’s Affairs for use in critical health-care systems.

Until now, I’ve taken a very soft stance on “why” Actionhero might be better than any other server framework/tool for your project, as every project is different. Maybe all of your project’s goals really would be met using only Express, and all you need is a JSON-speaking REST API server. That said, every project I’ve worked on always needed… more.

Along with the other Actionhero core-contributors, I’ve decided to publish this list of why you might choose to use Actionhero in a mature, enterprise environment.

Actionhero understands that modern applications speak more than HTTP.

Of course Actionhero features a robust RESTful router and HTTP server. But that is not enough any more is it? You probably also want websocket support, right? You also want to share session across HTTP and WS connections, and you want to be able to reuse your code across both. The Actions in ActionHero are agnostic of the communications protocol your clients are speaking, and you can reuse them. Support for all of this is included, right out-of-the-box.

Actionhero can coordinate with its peers when deployed.

Actionhero is “Cluster Aware”. This means that ActionHero is built from the ground-up to run in parallel across multiple machines at once. Nodes can speak to each other both passively (via a shared cache and job-queues; included) and actively with direct RPC communication.
Actionhero knows that background tasks are always required.
Sending your client a “welcome” email doesn’t belong in your web thread. Neither does processing anything else in the background. Actionhero treats background jobs as first class citizens, and any part of your API can enqueue them. Actionhero runs job workers in the proper Node.js way: event-based and many at a time.

Actionhero provides all the help you need, then gets out of the way.

Actionhero proposes a standard project layout, including testing and initializers. Actionhero has a REPL and generators to get you up-and-running quickly. Actionhero supports localization and test-driven development. After that… you can do anything you want!

Mature Operations for a Mature business.

Actionhero supports 0-downtime deployments, process signaling, and more. You can be sure that your DevOps team will find running Actionhero pleasant and clear.

DEV Community: Evan Tahler

Bundling and Distributing Next.js Sites via NPM

next build and npm run prepare

.npmignore vs .gitignore

Skip the .pack files

Using Typescript to create a Robust API between your frontend and backend

Getting the type of an API Response

Consuming the API Response Type in React

Summary

Deferring Side-Effects in Node.js until the End of a Transaction

Why do we need Transactions?

Automatically Pass Transactions to all Queries: CLS-Hooked

CLS and Deferred Execution

CLSAction and CLSTask

Summary

Why do database columns have a character length of 191?

Why varchar and not text?

It’s MySQL’s fault

It’s 🐟’s fault

Today

Thank you

Gifit: Convert Screen Recordings to easy-to-share Animated gifs

Dialect differences between SQLite and Postgres in Sequelize

Case Insensitive Sting Comparisons

Date and Time Part Functions

Min and Max typecasting

Boolean Column typecasting

Transaction Limits

Compound Indexes with Unique Columns

Don’t use underscores in your HTTP Headers

Production Node Applications with Docker - 3 DevOps Tips for Shutting Down Properly

1. Ensure Your Application Receives Signals, AKA Don’t use a Process Manager

2. Gracefully Shut Down your Applications by Listening for Signals

3. Log Everything

Proxying free Heroku Dynos though Cloudflare to a Custom Domain

Markdown in React and Custom Page Elements

Why Separate Docs from Tutorials?

Markdown in your HTML

Hooking into Rendering to modify State

Testing javascript applications with Selenium, Async/Await, and Jest

Why Choose Actionhero

or: Actionhero is the Node.js server for when your project grows up

Actionhero understands that modern applications speak more than HTTP.

Actionhero can coordinate with its peers when deployed.

Actionhero provides all the help you need, then gets out of the way.

Mature Operations for a Mature business.

`next build` and `npm run prepare`

`.npmignore` vs `.gitignore`

Skip the `.pack` files

Why `varchar` and not `text`?