DEV Community: Jannik Wempe

Keep Your Functions Clean & Focused: Context Provision with Node.js AsyncLocalStorage

Jannik Wempe — Mon, 31 Mar 2025 05:37:27 +0000

You have probably heard of the SOLID principles in programming. By applying them to your codebase, you can create a solid (🤡) architecture that is both easy to maintain and extend.

SOLID stands for:

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

In this post, I will demonstrate how to leverage Node.js’s built-in AsyncLocalStorage to implement the Open/Closed principle.

What is the Open/Closed Principle?

The open/closed principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

But what does that mean?

In this post, I will focus on two examples to showcase how you can apply the open/closed principle using Node.js’s AsyncLocalStorage:

Database transactions
Logging

First, I'll show you a violation of the open/closed principle, and then I will demonstrate how to adhere to it using Node.js’s built-in AsyncLocalStorage.

Violation of the Open/Closed Principle

Example 1: Database Transactions

Imagine you have a repository function that creates a user profile in the database.

import { db } from './db';

async function main() {
  await createUserProfile({ id: '1', name: 'John Doe' });
}

async function createUserProfile(profile) {
  await db.insert(userProfileTable).values(profile);
};

Alright, now suppose you want to create the user profile together with a user entity stored in a different table. You should do that in a single transaction because neither should exist without the other. This is what you might do:

import { db } from './db';

async function main() {
  await db.transaction(async (transaction) => {
    await Promise.all([
      createUserProfile({ id: '1', name: 'John Doe' }, transaction),
      createUser({ id: '1', name: 'John Doe' }, transaction),
    ]);
  });
}

// ❌ we have added the transaction argument to the function (= extended the function)
// ❌ this violates the open/closed principle
async function createUserProfile(profile, transaction) {
  await (transaction ?? db).insert(userProfileTable).values(profile);
};

async function createUser(user, transaction) {
  await (transaction ?? db).insert(userTable).values(user);
}

That works, but it is a violation of the open/closed principle ❌ You are modifying the createUserProfile function to accommodate the new requirement. Every time you decide to run a repository function within a transaction, you must modify the function to pass the transaction argument.

Example 2: Logging

Imagine you have a logger with an appendKeys method that appends keys to every subsequent log statement (just like the logger from Powertools for AWS Lambda). This is very useful to find all logs that are related.

Consider a scenario where you have a function that processes an order. You want to easily find all logs related to a specific order. To achieve that, you use logger.appendKeys to append the orderId to every log statement:

import { logger } from './logger';

async function main() {
  await processOrder(order);
}

async function processOrder(order) {
    logger.appendKeys({ orderId: order.id });
  // ...
  const total = calculateOrderTotal(order.lineItems);
  // ...
}

function calculateOrderTotal(lineItems) {
  // calculation...

  // this will also log the orderId since we have appended it to the logger instance
  logger.debug('calculated order total', { total: 100 });
}

Now, suppose you want to process multiple orders concurrently. You cannot simply call appendKeys on the global logger instance because the orderId key would be overwritten, as all processOrder executions share the same logger instance.

One way to deal with this, would be to create a separate logger instance for every processOrder call:

import { logger } from './logger';

async function main() {
  await Promise.all(orders.map(order => {
    const childLogger = logger.createChild();
    return processOrder(order, childLogger);
  }));
}

// ❌ we had to add the logger argument to the function
// ❌ this violates the open/closed principle
async function processOrder(order, logger) {
    logger.appendKeys({ orderId: order.id });
  // ...
}

Another solution is to not use logger.appendKeys altogether and instead pass the orderId to every log statement:

import { logger } from './logger';

async function main() {
  await Promise.all(orders.map(order => processOrder(order, childLogger)));
}

async function processOrder(order) {
  // ...
  const total = calculateOrderTotal(order);
  // ...
}

// ❌ we now pass the whole order because we need access to the orderId for logging
// ❌ this violates the open/closed principle
function calculateOrderTotal(order) {
  // calculation...

  // this will also log the orderId since we have appended it to the logger instance
  logger.debug('calculated order total', { total: 100, orderId: order.id });
}

This approach is not only tedious but also error-prone, since you must consistently use the same orderId key in every log statement to correlate logs associated with a specific order.

You can imagine that both of these approaches quickly become unmanageable—especially when processOrder calls many other functions in a deeply nested manner.

Applying the Open/Closed Principle with AsyncLocalStorage

Now that we know what a violation of the open/closed principle looks like, let's explore how to apply the open/closed principle using Node.js’s built-in AsyncLocalStorage.

Context Sharing with AsyncLocalStorage

We want the createUserProfile and processOrder functions to work in different scenarios without needing to modify them. For instance, createUserProfile shouldn't have to know whether it is running in a transaction or not, and processOrder should not change just because it is executed concurrently.

So how do we solve this?

We can leverage AsyncLocalStorage to create a context that is available to all functions executed within the same scope. This allows us to modify the behavior of functions without actually changing their implementations.

import { AsyncLocalStorage } from 'node:async_hooks';

export function createContext<T>() {
    const context = new AsyncLocalStorage<T>();
    return {
        use() {
            const result = context.getStore();
            if (!result) {
                throw new Error('No context available');
            }
            return result;
        },
        provide<R>(value: T, callback: () => R) {
            return context.run<R>(value, callback);
        },
    };
}

ℹ️ I have learned about the usage of AsyncLocalStorage from the codebase of terminaldotshop/terminal. This is where I took the code for createContext from and also the transaction example (not the logging example though).

createContext creates a private storage context that is only accessible within the createContext function. It returns an object with a use method that returns the current context and a provide method that allows you to provide a context (value) that is available with the callback function.

Example usage:

const userContext = createContext<{ userId: string }>();

userContext.provide({ userId: '123' }, async () => {
  // this can be somewhere deeply nested in your codebase
  const { userId } = userContext.use();
});

ℹ️ This is probably familiar to you if you know React. React also has useContext and createContext to provide data to (potentially deeply nested) components without having to pass props through every component.

How can we leverage the createContext function to solve our examples?

Example 1 Revisited: Database Transactions

Lets use the createContext function to create a context for the database transaction.

type TransactionOrDb = Transaction | typeof db;

const TransactionContext = createContext<{
    transaction: TransactionOrDb;
}>();

async function provideTransaction<T>(
    callback: (transaction: Transaction) => Promise<T>,
    transactionOptions?: TransactionOptions,
): Promise<T> {
    try {
    // if there already is a transaction context, we use that
        const { transaction } = TransactionContext.use();
        return callback(transaction);
    } catch {
    // otherwise we start a new transaction that we provide to the callback
        const result = await db.transaction(
            async (transaction) => {
                return TransactionContext.provide({ transaction }, () => callback(transaction));
            },
            transactionOptions,
        );
        return result as T;
    }
}

async function useTransactionOrDb<T>(callback: (transactionOrDb: TransactionOrDb) => Promise<T>) {
    try {
    // this throws outside of the context (see `createContext().use()`)
        const { transaction } = TransactionContext.use();
        return callback(transaction);
    } catch {
    // if not within a context, we use the db instance
        return callback(db);
    }
}

We have two functions that essentially wrap the use and provide methods of the createContext function:

provideTransaction is used to provide a transaction to the callback function. It either uses an already existing transaction or starts a new one.
useTransactionOrDb returns the transaction if it is within a transaction context or the db instance otherwise.

Now, instead of using the db instance directly in our app, we can just always use useTransactionOrDb.

Back to our example, we have the following code before deciding to use a transaction:

import { db } from './db';

async function main() {
  await createUserProfile({ id: '1', name: 'John Doe' });
}

async function createUserProfile(profile) {
  await useTransactionOrDb().insert(userProfileTable).values(profile);
};

Here, createUserProfile will just use the db instance directly since it is not within a transaction context.

Now, decide that we have to run createUserProfile in a transaction together with createUser. We can do that by providing a transaction to the createUserProfile function:

import { db } from './db';

async function main() {
  await provideTransaction(async () => {
    await Promise.all([
      createUserProfile({ id: '1', name: 'John Doe' }),
      createUser({ id: '1', name: 'John Doe' }),
    ]);
  });
}

// ✅ the arguments are unchanged – no modification needed
async function createUserProfile(profile) {
  await useTransactionOrDb().insert(userProfileTable).values(profile);
};

async function createUser(user) {
  await useTransactionOrDb().insert(userTable).values(user);
}

Now we are following the open/closed principle! We did not have to modify the createUserProfile function to accommodate the new requirement. Only the caller of the function has to know about the context.

Example 2 Revisited: Logging

Now, let's see how we can apply the open/closed principle to the logging example.

Again, we are creating some helper functions that wrap the use and provide methods of the createContext function:

const LoggerContext = createContext<{
  logger: Logger;
}>();

export function createLoggerContext<T>(callback: (logger: Logger) => T): T {
  try {
    // if there is already a LoggerContext, use it
    const { logger } = LoggerContext.use();
    return callback(logger);
  } catch {
    // if there is no LoggerContext, create a new one with a new child logger
    let childLogger = logger.createChild();
    const result = LoggerContext.provide({ logger: childLogger }, () =>
      callback(childLogger),
    );
    return result as T;
  }
}

export function getLogger() {
  try {
    const { logger } = LoggerContext.use();
    return logger;
  } catch {
    return logger;
  }
}

This is essentially the same as in the previous example:

createLoggerContext is used to create a child logger and provide it to the callback function.
getLogger is used to return the logger. If there is no logger in the context, it will return the global logger.

Now we can use that to follow the open/closed principle in our second example. Instead of using the logger instance directly, just always use getLogger. This is how our initial code looks like:

import { getLogger } from './logger';

async function main() {
  await processOrder(order);
}

async function processOrder(order) {
    getLogger().appendKeys({ orderId: order.id });
  // ...
  const total = calculateOrderTotal(order.lineItems);
  // ...
}

function calculateOrderTotal(lineItems) {
  // calculation...

  // this will also log the orderId since we have appended it to the logger instance
  getLogger().debug('calculated order total', { total: 100 });
}

Okay, now we change it to run processOrder in parallel:

import { logger } from './logger';

async function main() {
  await Promise.all(orders.map(order => {
    return createLoggerContext(() => {
      return processOrder(order);
    });
  }));
}

// ✅ the arguments are unchanged – no modification needed
async function processOrder(order) {
    getLogger().appendKeys({ orderId: order.id });
  // ...
  const total = calculateOrderTotal(order.lineItems);
  // ...
}

function calculateOrderTotal(lineItems) {
  // calculation...

  // this will also log the orderId since we have appended it to the logger instance
  getLogger().debug('calculated order total', { total: 100 });
}

We now create a child logger for every processOrder call. processOrder can just call getLogger().appendKeys to append the orderId to the logger as it did before. Now the keys don't overwrite each other because getLogger() returns different a child logger instances.

By using getLogger() everywhere in throughout your codebase instead of the global logger instance, we don't have to modify any functions if they are run differently. We are following the open/closed principle!

Conclusion

In this post, we have seen how to apply the open/closed principle using Node.js’s built-in AsyncLocalStorage. We created a createContext function that allows us to establish a context for any type, which we then leveraged to solve our two examples.

Here are some key takeaways:

Decoupled Context Management: By using AsyncLocalStorage, you can inject contextual data (like transaction handles or logging metadata) without modifying the core business logic.
Adherence to the Open/Closed Principle: Functions remain closed for modification while still being open for extension, minimizing the need to alter function signatures as new requirements arise.
Elimination of Manual Parameter Drag: AsyncLocalStorage prevents the tedious and error-prone process of manually threading context through multiple function calls.
Improved Maintainability: By isolating context handling from your repository and logging logic, your codebase stays cleaner, more modular, and easier to maintain.
Enhanced Debugging and Consistency: Automatically propagated context ensures that logs and database transactions are consistent, making debugging and analytics more straightforward.
Versatile Application: This approach benefits various scenarios, including managing database transactions and setting up consistent logging across parallel asynchronous processes. These takeaways emphasize how leveraging Node.js AsyncLocalStorage can lead to more robust, maintainable, and scalable code while adhering to fundamental design principles.

Create Your Personal, Pay-Per-Use ChatGPT Client in Minutes

Jannik Wempe — Sun, 30 Apr 2023 09:43:44 +0000

I was hesitant to purchase ChatGPT Pro. While I often use ChatGPT, the $20 per month price tag seemed excessive for my needs. However, the slow response time and limited availability were frustrating. I appreciate the serverless, pay-per-use approach, as that's what I was seeking. Thankfully, Chatbot UI offers a solution!

In this article, I'll explain how to host your own ChatGPT UI, allowing you to experience faster response times and pay only for what you use.

About ChatBot UI

Chatbot UI is an open source chat UI for AI models.

– ChatBot UI GitHub Repository
ChatBot UI is a NextJS app and has an interface that is familiar if you have used ChatGPT:

It has features like different chats, saving prompt templates, switching AI models (e.g. gpt-3.5-turbo) and more. You just provide some configs like your Open API key and are good to go.

One feature that is missing though is saving chats and prompts to a database. Data is currently stored in local storage. But the APIs are quite nice and you could easily add a database yourself.

I won't go into details on configuration here. The Readme.md is the single source of truth and will have the up to date instructions.

You could leave the OPENAI_API_KEY environment variable blank and have the user specify the key but I don't want anybody else to use my UI at all. That is why we are now looking into how to protect your ChatBot UI website.

Adding BasicAuth

I am using the most basic way to protect a website: Basic Auth.

Basic auth is a simple HTTP authentication scheme used to protect web resources that require user authentication. It works by sending the combination of a username and password, encoded in base64 format, as plain text over the network (you should use HTTPS). It is good enough for this use case.

I am deploying my version of the ChatBot you to Vercel. There is an example from Vercel on GitHub on how to add Basic Auth. It all comes down to using an edge middleware and an API route. This is my slightly modified version of the middleware using environment variables to provide values for user and pwd:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
export function middleware(req: NextRequest) {
  const basicAuth = req.headers.get('authorization');
  const url = req.nextUrl;
  if (basicAuth) {
    const authValue = basicAuth.split(' ')[1];
    const [user, pwd] = Buffer.from(authValue, 'base64').toString().split(':');
    if (
      user === process.env.BASIC_AUTH_USER &&
      pwd === process.env.BASIC_AUTH_PASSWORD
    ) {
      return NextResponse.next();
    }
  }
  url.pathname = '/api/auth';
  return NextResponse.rewrite(url);
}

It checks the provided user and pwd if the authorization header is provided and allows the requests to pass through if it is correct or otherwise rewrites the response to the /api/auth URL:

// pages/api/auth.ts
import type { NextApiRequest, NextApiResponse } from 'next';
export default function handler(_: NextApiRequest, res: NextApiResponse) {
  res.setHeader('WWW-authenticate', 'Basic realm="Secure Area"');
  res.statusCode = 401;
  res.end(`Auth Required.`);
}

This is just setting a header and a 401 (Unauthorized) status code.The WWW-authenticate field is used to initiate the authentication process, and the value Basic realm="Secure Area" instructs the client to send encoded username and password credentials to access the "Secure Area" of the website.

You just have to add those two files to your ChatBot UI code and provide the BASIC_AUTH_USER and BASIC_AUTH_PASSWORD to add Basic Auth to your own version of ChatGPT.

Conclusion

It is quite straightforward to deploy your own version of ChatGPT with fast response times without paying $20 per month. This can be accomplished in less than 10 minutes, and it also provides a solid starting point for customizing everything to your liking without having to code everything from scratch.

You Have Fucked Up! How to git revert?

Jannik Wempe — Wed, 25 Jan 2023 20:12:27 +0000

You have messed up production. All hell broke loose. What to do now? Fix it as fast as possible and undo the last change that made everything fall apart to unblock further deployments.

Fix Production Fast

First of all, it is a good idea to get back to a working version of the application as fast as possible. Many hosting platforms have some sort of rollback functionality (like Vercel's instant rollback) that you can use to get back to a working application in seconds. Or you deploy the last working commit from your local machine (be careful to not make things worse; you can leverage git bisect to find the last working commit). This is only a temporary solution. The HEAD of your main branch will still point to the broken application version. So how to fix that?

Undo Your Fuckup – Git Revert

This section is about getting your main branch (or trunk or whatever you want to call it) back to a functional state to unblock further deployments (and to prevent yourself from accidentally deploying the broken application again using your CI/CD pipeline).

Remove Last Commit (not `git revert`)

You could just remove your last commit using git reset HEAD^ --hard and git push --force and get rid of that commit (assuming that this has introduced the error). This is rarely a good idea. You don't want to rewrite the git history of a shared remote branch. (Even if you are alone in this project I'd prefer the next solution). It can introduce conflicts with your co-workers' local working version of that branch. But how to do better?

Here is where git revert comes into place.

Git Revert (undo) the Last Commit

git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one).

(Source: Git revert documentation)

This is what we want. We create a new commit (not changing the existing commits and messing with our co-workers' sanity) that applies the changes that the commit to be reverted introduced. We can revert the changes of the last commit by finding its SHA using git log and run git revert SHA:

Commit SHA3 now applies the changes that are required to get back from SHA2 to SHA1. Problem solved and we are good to go, right? Well, in this simple case, yes. But often we work with Pull Requests (PRs) and create merge commits introducing our (shitty) changes to the main branch. Trying the above will result in this error:

git revert SHA2
# error: commit SHA2 is a merge but no -m option was given.
# fatal: revert failed

git revert fails and you start to sweat. Let's explore what this error is about and how to fix it.

Git Revert a Merge Commit

The part "but no -m option was given" of the previous error is already hinting at the solution. What is the -m option of git revert?

-m parent-number

--mainline parent-number

Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.

(Source: Git revert documentation)

Okay, next question: What does "which side of the merge should be considered the mainline" mean?

Let's have a look at this scenario:

As you can see, SHA3 which introduced the issues has two parent branches (SHA1 and SHA2). How should git know which one it should revert to (the mainline)? This is what you have to tell git revert with the -m option.

How to find the "parent number" that you have to pass to git revert -m? You can use git catfile -p SHA3 for that or look at the commit message of the merge commit using git log:

git log tells you that SHA3 is a merge commit of SHA1 and SHA2. git cat-file shows you details for commit SHA3 and tells you that SHA3 has two parents (basically the same info as in the commit message). In both cases the first mentioned SHA is parent-number 1 (the second 2 etc.). In order to revert the changes introduced in commit SHA3 and get back to SHA1 you have to execute git revert -m 1 SHA3. Now you are all set and can push the branch with the new commit.

Now you know to revert merge commits and understand what you are doing instead of copying the command from Stackoverflow over and over again 😜

Conclusion

It can become stressful if you are in the situation of having to fix a production problem that you (or a co-worker) have introduced. Things get really bad if you face a "fatal" error trying to revert a merge commit. Make sure you can deal with these situations before you have to deal with them.

The time to repair a roof is when the sun is shining.

OR -

The time to learn how to deal with a production issue is when production is not broken.

How To Use GitHub Actions for Deployments When Following Trunk-Based Development

Jannik Wempe — Wed, 14 Dec 2022 06:19:01 +0000

Nowadays trunk-based development as a branching model is preferred compared to something like Git Flow. But creating a CI/CD pipeline is more challenging since we deploy to every environment from the same branch. In this post, I create a CI/CD pipeline with GitHub actions that deploys to multiple environments. We will start with a basic implementation and improve it step by step.

This post will not be about the basics of GitHub actions and won't go into details about trunk-based development. We start with a basic introduction to trunk-based development in order to have a shared understanding:

A Brief Introduction to Trunk-Based Development

Trunk-based development involves frequent, small code check-ins to a shared code repository, typically known as the "trunk". This approach contrasts traditional development models (like Git Flow), which often involve long, isolated development cycles followed by large code merges. In trunk-based development, teams are encouraged to commit their code to the trunk frequently, often multiple times per day. This allows for continuous integration and continuous deployment (CI/CD), as well as easier collaboration and code reviews. You also don't have branches per environment like a development branch that is deploying to a development environment. You integrate all code on the "trunk".

Trunk-Based Development is considered the best practice nowadays. You can learn more about it on trunkbaseddevelopment.com.

Creating GitHub Actions Workflows

This is the basic CI/CD pipeline I'd like to create:

At first, we will run some basic checks, then we build the artifact(s) and after that, we deploy it to a staging and a production environment. Yes, we can do a lot more like integration and E2E tests, more environment etc. but this should be sufficient to showcase the main points.

I will be using an AWS CDK deployment as an example but the pipelines will be applicable for everything that creates some kind of a deployable artifact (like a dist folder).

The Basic GitHub Action Workflow

Let us start with a very basic pipeline. We will build upon that and refine it in the following sections.

This is how the code for a basic GitHub Action that deploys to a staging and a production environment could look like:

# .github/workflows/deploy.yaml
on:
  push:
    branches:
      - main # your "trunk" branch
jobs:
  build-and-delopy:
    name: Build & Deploy
    runs-on: ubuntu-latest
    # Required for GH OIDC
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup Node and Cache
        uses: actions/setup-node@v3
        with:
          node-version: 16.18
          cache: npm
      - name: Install dependencies
        run: npm ci
      - name: Type Check
        run: npm run type-check
      - name: Unit Tests
        run: npm run test
      - name: Create Artifact
        run: npm run synth # often 'npm run build'
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: eu-central-1
      - name: Deploy Artifact to Staging
        run: npx cdk deploy --app "./cdk.out/assembly-Staging" --all --concurrency 10 --method=direct --require-approval never
      - name: Deploy Artifact to Production
        run: npx cdk deploy --app "./cdk.out/assembly-Prod" --all --concurrency 10 --method=direct --require-approval never

We trigger the pipeline on pushes to main (our "trunk"). Remember, we don't have different branches per environment. We deploy to all our environments from this branch.

We have one single job build-and-delopy that includes all our steps of the pipeline. The steps are implementing the flow that is shown in the introduction of this chapter. We build the artifacts that should be deployed once and then deploy them to the different environments. We store our secrets in the GitHub secrets of the repository (AWS_DEPLOY_ROLE_ARN in this case).

Sidenote: I am using Open ID Connect to get short-lived credentials for my AWS account. This is a security best practice and safer than using long-lived credentials like a username and password via environment variables.

While this already works, we can do better by leveraging GitHub environments.

Leveraging GitHub Environments

GitHub environments provide some additional features like specifying different secrets per environment (with the same name), having a deployment history per environment, and more. You can learn more about environments and their features in the GitHub documentation.

Environments have to be configured per job in our GitHub Action workflow. Currently, we only have a single job. Now we split it up into three distinct jobs: build, deploy-staging and deploy-production. This is what it looks like:

# .github/workflows/deploy.yaml
on:
  push:
    branches:
      - main # your "trunk" branch
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Setup Node and Cache
        uses: actions/setup-node@v3
        with:
          node-version: 16.18
          cache: npm
      - name: Install dependencies
        run: npm ci
      - name: Type Check
        run: npm run type-check
      - name: Unit Tests
        run: npm run test
      - name: Create Artifact
        run: npm run synth # often 'npm run build'
      - name: Upload Artifact
        uses: actions/upload-artifact@v3
        with:
          name: cdk-out
          path: cdk.out # often 'dist'
  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    environment: staging
    # required to interact with GitHub's OIDC Token endpoint
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Download Artifact
        uses: actions/download-artifact@v3
        with:
          name: cdk-out
          path: cdk.out
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: eu-central-1
      - name: Deploy Artifact
        run: npx cdk deploy --app "./cdk.out/assembly-Staging" --all --concurrency 10 --method=direct --require-approval never
  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: [build, staging] # build - if you want to deploy in parallel with Staging
    environment: production
    # required to interact with GitHub's OIDC Token endpoint
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Download Artifact
        uses: actions/download-artifact@v3
        with:
          name: cdk-out
          path: cdk.out
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: eu-central-1
      - name: Deploy Artifact
        run: npx cdk deploy --app "./cdk.out/assembly-Prod" --all --concurrency 10 --method=direct --require-approval never

The new parts are the uploading and downloading of the artifact that is created in the build job and the environment per environment-specific job.

By uploading and downloading the initially created artifacts we only have to actually build the artifacts once and can be sure that they are stable (and not differ due to different builds).

After running this pipeline for the first to you'll the the "Environments" sections in the sidebar in your GitHub repository:

When clicking on it you will see the deployment history of that environment:

Ideally, your history looks a lot greener 😅

In addition to that, we can now re-run only the failed jobs (and not our whole pipeline). That was not possible with one job.

Okay, this is an improvement, but there is one more thing: Often you don't want to automatically deploy to production but rather have a manual trigger in order to promote the artifact to production in order to have the opportunity to check the staging environment before actually releasing your changes to the user. How to do that with GitHub Actions?

Adding a Manual Trigger for a Production Deployment

You can activate the "Required reviewers" config for your production environment under Settings -> Environments -> production:

That way you don't have to change anything in your pipeline. This is what it looks like:

It will not be deployed to production without a review by an authorized person.

Unfortunately, this simple solution is often not an option. For private repositories, it is only available to GitHub Enterprise customers and it has some other limitations like max. 6 authorized reviewers (teams are also possible). You can learn more about reviewing deployments in the GitHub documentation.

There is an alternative to that using releases.

Using Releases for Manual Steps

Instead of one workflow with all of our jobs, we will now have two. One for building the artifacts, deploying to staging, and creating a release, and a second one for deploying to production if a specific release has been published.

This is how the first workflow now looks like:

# .github/workflows/deploy-staging.yaml
on:
  push:
    branches:
      - main # your "trunk" branch
jobs:
  # 
  # the 'build' and 'deploy-staging' jobs stay exactly the same; omitted
  #
  create-release:
    name: Create Release
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download Artifact
        uses: actions/download-artifact@v3
        with:
          name: cdk-out
          path: cdk.out
      # we can't attack a folder to a release
      - name: Zip Artifact
        run: |
          zip -r cdk.out.zip cdk.out
      - name: Create Release Tag
        id: create-release-tag
        # left pads the run number with zeros to a length of 4; better alphabetical order
        run: echo "tag_name=r-$(printf %04d $GITHUB_RUN_NUMBER)" >> $GITHUB_OUTPUT
      - name: Create Draft Release
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{ steps.create-release-tag.outputs.tag_name }}
          name: Release ${{ steps.create-release-tag.outputs.tag_name }}
          body: |
            ## Info
            Commit ${{ github.sha }} was deployed to `staging`. [See code diff](${{ github.event.compare }}).

            It was initialized by [${{ github.event.sender.login }}](${{ github.event.sender.html_url }}).

            ## How to Promote?
            In order to promote this to prod, edit the draft and press **"Publish release"**.
          draft: true
          files: cdk.out.zip

We download the artifact from the build job, zip it, and create a release as a draft attaching the zipped artifact. The body of the release can be written in markdown. You can add additional information to the release itself. Here you find a reference to the information that is available in a push-triggered workflow.

Releases are always tied to tags. I have created a basic tag name that uses the GITHUB_RUN_NUMBER with a prefix. I also added some left padding to have the releases show up in alphabetical order. If you use semver or any other convention you can change the tag name there.

This is an example release that has been created with the previously shown workflow:

Editing that draft release and clicking on "Publish release" will trigger the next workflow that deploys the artifacts to production:

# .github/workflows/deploy-production.yaml
on:
  release:
    types: [published]

jobs:
  release-production:
    name: Release to Production
    if: startsWith(github.ref_name, 'r-') # the prefix we have added to the tag
    environment: production
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - name: Get Artifact from Release
        uses: dsaltares/fetch-gh-release-asset@master
        with:
          version: ${{ github.event.release.id }}
          file: cdk.out.zip
      - name: Unzip Artifact
        run: unzip cdk.out.zip
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1-node16
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: eu-central-1
      - name: Deploy Artifact
        run: npx cdk deploy --app "./cdk.out/assembly-Prod" --all --concurrency 10 --method=direct --require-approval never

This workflow gets triggered on the release published event which gets triggered after a release, pre-release, or draft of a release was published. You can look up the details on the release published event in the GitHub documentation. In addition to that, we only run the release-production job if the reference of the release that triggered the workflow starts with the prefix for the tag we have created earlier.

That is it. You can see the published releases in the sidebar on the GitHub UI:

I like this approach since you have GitHub releases for your actual production releases. That releases have the deployed artifacts attached. That way you can re-deploy any previously deployed artifact easily. This enables rollbacks to previous releases.

Conclusion

GitHub Actions provide us with a lot of opportunities. I myself haven't used features like up-/downloading artifacts, environments, creating releases etc. Knowing about them opens up new doors. I now prefer having multiple jobs that I can re-run independently instead of a single job that is doing everything. (I was actually wondering for a long time what the difference between "Re-run all jobs" vs. "Re-run failed jobs" is. There were none for me.)

Hopefully, you learned a thing and maybe can use it in your own GitHub Action workflows.

My thoughts after trying to port a Shopify store from NextJS to Shopify Hydrogen

Jannik Wempe — Sun, 30 Oct 2022 10:43:42 +0000

A while ago I created a Shopify shop for my little brother who is selling handmade, unique furniture: glückweiser.de (all German; currently mainly selling on Etsy). It is written in NextJS 12 and uses Shopify's GraphQL Storefront API. The Developer Experience (DX) is okay. Everything is nice and typesafe with Typescript, graphql-codegen and react-query. BUT it is quite some manual work. Especially dealing with the cart. Initializing it, storing the id, updating etc.

I like trying out new things and this is why I thought I'll give Shopify Hydrogen a shot and recreate the shop using it. In this article, I want to share my experiences and thoughts after a few days of coding in Hydrogen.

What is Shopify Hydrogen?

Before I go ahead and share my experiences, I want to give a quick intro to Hydrogen:

These are the main features as per the Hydrogen website:

I would say its main selling point is obviously the integration with Shopify. It comes with hooks, components and types to make it really easy to interact with the Shopify API. (They also use an XState state machine for the cart.)

From an architectural perspective, it heavily relies on React server components and Vite. React server components allow for fetching data right in the React component. It is run on the server and streamed to the client. You can safely use secrets there since only the resulting HTML gets streamed to the client. (React server components were just released in NextJS 13 a few days ago.). React server components require quite some mind shift because previously components were primarily run on the client (neither a pro nor a con of Hydrogen for me since it's related to React).

In addition to that, Hydrogen comes with out-of-the-box support for Tailwind and Typescript.

What I like about Hydrogen

Let us start with the pros of using Hydrogen first:

Shopify integration

As mentioned previously, this is the main selling point in my eyes. You configure your Shopify integration in hydrogen.config.ts and can start using hooks like useShopQuery that let you fetch data from the Storefront API. The types are also shipped with Hydrogen.

Besides that, it comes with handy components that are required for almost any shop: Money, AddToCartButton, Image and many more.

This nice integration lets you get started pretty quickly.

Components provide primitives

Hydrogen components are primitives. Hydrogen doesn't provide components like Cart or ProductPage. They are different for most shops anyway. Instead, Hydrogen provides small building blocks. These can be styled and customized easily with Tailwind (and most likely CSS). They are focused on functionality rather than design (which makes sense).

Up-to-date tech stack

I think Hydrogen was the first framework heavily betting on React server components. Now that NextJS 13 is also defaulting to server components for routes (in the /app folder), it is probably safe to say that server components are the future of React. Mastering Hydrogen will improve your overall React skills and will be transferable to other frameworks that are also relying on React server components.

In addition to that, Vite is also probably one of the most modern dev- and build tools out there. (At least until Turbopack will eventually takes over 🤪)

What I don't like about Hydrogen

Besides the pros, there are also some cons:

Development and production environments behave differently

It is always painful if a development environment is very different from the production environment. This opens the doors for bugs in production that you were not able to catch during development.

Unfortunately, this is exactly my experience: In production, I started seeing errors that my client components could not be found. That crashed the whole app. I was able to fix this be adding { optimizeBoundaries: false } to the hydrogen Vite plugin – but I have honestly no idea what this is doing and what other implications it might have.

Another issue: I created an API route for sending emails. I was using nodemailer for that. Everything works fine in dev, but I saw various errors when trying to build the app. It took me a while to find out that Hydrogen is creating edge functions for API routes. Edge functions only provide a limited feature set and therefore some node internals were not working.

I made it work by ditching nodemailer and using the Mailgun API with fetch directly. It worked on dev, and the bundling also succeeded but it failed after deployment (on Vercel) because the environment variables could not be found anymore (yes, I have added them to Vercel).

The DX is lacking and I was encountering multiple such issues... A huge bummer for me.

Docs leave room for improvement

You can imagine that I was reading the docs and API references a lot. The API routes are explained in a few sentences. Potential limitations or something were not covered, edge functions or worker environments were not mentioned. I had to figure out a lot of stuff myself...

Additional thoughts

I think Hydrogen has a high potential and I would probably default to it for creating custom Shopify shops. But the DX is not there yet. I encountered too many roadblocks that took me a while to resolve.

I would prefer to have the primitives and nice Shopify integration without having to adapt a whole new framework. I think this is exactly what Hydrogen UI is about (not in beta yet and I am not sure which features are Hydrogen and which are Hydrogen UI). I would really like to have Hydrogen features be easily usable in NextJS. I wonder if it would have been a better idea for Shopify to focus on something like Hydrogen UI rather than creating a full framework. All the Vite SSR stuff is the most complicated of Hydrogen for sure. Maybe that has something to do with Shopify's Oxygen – the recommended deployment target for Hydrogen? I don't know...

Most likely Hydrogen will improve a lot in the future but I currently have a bad gut feeling about fully committing to it after my initial experiences...

How to Securely Use Secrets in AWS Lambda?

Jannik Wempe — Mon, 10 Oct 2022 04:47:40 +0000

It is quite common to need a secret value of some kind in a Lambda function. Either for a database connection, a 3-rd party service, or whatever else. But how to securely use secrets in your Lambda?

In this post, I am going to tell you why environment variables are not the tool for the job and what the preferred way looks like.

I will also provide you with an example implementation showing you how to do better using AWS CDK and TypeScript.

Why Environment Variables Are Not the Best Solution for Accessing Secrets

I am sure I don't have to tell you why it is a bad idea to put secrets in plain text into your code base. But why aren't environment variables very secure either? AWS suggests to better not using environment variables for your secrets:

To increase database security, we recommend that you use AWS Secrets Manager instead of environment variables to store database credentials.

(from Securing environment variables)

This tweet from Yan Cui (@theburningmonk) sums up the reasons pretty well:

Yan Cui

@theburningmonk

Depends on if you put them as plaintext in env vars - if a function is compromised then env vars is the 1st place attackers would look. There have been multiple instances of compromised NPM packages that steal env vars when initialized. This affects lambda too.

09:35 AM - 02 Jun 2021

There are malicious packages out there sending your environment variables somewhere else. Just google something like "npm package malicious environment variables" and you will find lists of malicious packages. Often they create packages with almost identical names than widely used packages. If you do a typo while installing a package you could end up sending your secrets to a bad actor. This is not an issue that is specific to AWS Lambda – but the solution I am going to show you is.

In addition to that, secrets stored in environment variables will be visible to everyone having access to that Lambda in the AWS console. With other services (I will get to them in the next section) you can restrict who is able to see the secrets.

How to Securely Access Secrets in AWS Lambda?

Now that we know why using environment variables for secrets is a bad idea, how can we do better?

Retrieving Secrets at Runtime

One solution has already been mentioned in the quote in the previous chapter: AWS Secrets Manager. Another popular solution is AWS Systems Manager Parameter Store. Both of them allow you to securely store secrets and retrieve them using the aws-sdk. They provide a different set of features but this is out of scope for this article – both of them are doing the job for the use case I will be showing you. There are other solutions out there as well, but AWS Secrets Manager and AWS Systems Manager Parameter Store (SSM Parameter Store) are the most common ones. I will go ahead and use SSM Parameter Store for further examples.

You have different options on how to retrieve and use secrets from SSM – as always, all of them have different trade-offs:

Retrieve secrets inside of the Lambda handler
Retrieve secrets during Lambda init phase (outside of handler) & cache them forever (= for the time of the Lambda execution context)
Retrieve secrets during Lambda init phase & cache them for a certain period, e.g. 5min

The trade-off you have to make is between performance & price (less API calls are cheaper and faster) and flexibility (you can change secrets immediately if you don't cache them).

Retrieving Secrets in AWS Lambda using AWS CDK

Now that we know the theory, let's go ahead and implement it. I will be using AWS CDK and TypeScript for this.

Before we go ahead with writing actual code, let's create a secret we want to retrieve. We can create it via the AWS console or via the awscli like this:

aws ssm put-parameter --name "/dev/service-a/secret-key" --type "SecureString" --value "my-super-secret-secret"

Note: I like to use a naming convention like /[stage]/[service]/[parameter] in order to keep everything nice and organized and to be able to easily construct and access parameters for different environments.

You can find the code in my JannikWempe/lambda-retrieve-secrets repository.

This is how you get access to that previously created secret in CDK:

export class LambdaRetrieveSecretsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const serviceASecretKeyParameter =
    StringParameter.fromSecureStringParameterAttributes(
      this,
      "ServiceASecretKey",
      { parameterName: "/dev/service-a/secret-key" } // replace with your parameter name
    );
  }
}

Now we can reference that secret and use CDKs utilities in order to grant access to that secret. Let us add a Lambda function, pass the parameterName to it as an environment variable, and grant access to read that secret:

export class LambdaRetrieveSecretsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const serviceASecretKeyParameter =
    StringParameter.fromSecureStringParameterAttributes(
      this,
      "ServiceASecretKey",
      { parameterName: "/dev/service-a/secret-key" }  // replace with your parameter name
    );

    const secretsExampleLambda = new NodejsFunction(this, 'SecretsExampleLambda', {
      entry: path.join(__dirname, 'lambda', 'index.ts'),
      runtime: Runtime.NODEJS_16_X,
      environment: {
        SERVICE_A_SECRET_KEY_PARAMETER_NAME: serviceASecretKeyParameter.parameterName,
      }
    });

    serviceASecretKeyParameter.grantRead(secretsExampleLambda);
  }
}

That is it from the CDK side. Now let us create the handler and retrieve that secret. I like to use middy which describes itself as "stylish Node.js middleware engine for AWS Lambda". It offers some helpful middlewares like ssm which will help us retrieve and cache values from SSM Parameter Store. (Middy provides various other official middlewares including one for Secrets Manager.) I prefer a middleware for this because it keeps the code for retrieving the secret out of your handler which should deal with actual business logic.

The handler could look like this:

import middy from "@middy/core";
import ssm from "@middy/ssm";

const { SERVICE_A_SECRET_KEY_PARAMETER_NAME } = process.env;

if (!SERVICE_A_SECRET_KEY_PARAMETER_NAME) {
  throw new Error("SERVICE_A_SECRET_KEY_PARAMETER_NAME environment variable is not set");
}

export const handler = middy((_, context) => {
  // ⚠️⚠️⚠️ you should never log secrets; just for demo purposes ⚠️⚠️⚠️
  console.log(context.SERVICE_A_SECRET_KEY);
}).use(ssm({
  fetchData: {
    SERVICE_A_SECRET_KEY: SERVICE_A_SECRET_KEY_PARAMETER_NAME
  },
  cacheKey: SERVICE_A_SECRET_KEY_PARAMETER_NAME,
  cacheExpiry: 60 * 5, // 5min
  setToContext: true
}));

We are wrapping the handler with middy in order to be able to use the ssm middleware which will retrieve the decrypted secret for us.

fetchData lets us define the name we want to use for the retrieved parameter as a key and the parameterName as the value.

Make sure to set setToContext: true. That way the secret is accessible via the Lambda context. It will not end up in the environment variables.

Also, I am setting a cacheExpiry of 5min here. That way the Lambda will retrieve the secret in the init phase and will reuse that value for 5min in subsequent requests in that execution environment. If the execution environment is still running after 5min, the secret will again be fetched during the next invocation. This is somewhere in the middle of the trade-off spectrum between cost & performance and flexibility.

Conclusion

There are safer ways to use secrets in your AWS Lambda than by using environment variables. It is not much harder to use AWS services like Secrets Manager or SSM to retrieve secrets at runtime. In fact, it will become easier to manage the secrets from a central place. You can easily rotate secrets in a central place and configure permissions only showing the secrets to authorized people. From now on, you should not use environment variables for secrets.

Mastering AWS CDK Aspects

Jannik Wempe — Thu, 29 Sep 2022 06:33:25 +0000

CDK Aspects Introduction

CDK Aspects are a powerful tool provided by the AWS Cloud Development Kit (CDK). They are utilizing the Visitor Pattern. By applying a CDK Aspect to a specific scope, you get access to every child node within it. You can inspect them or alter them. That scope can be any IConstruct which includes App and Stack as they extend Construct. Therefore an Aspect can be applied at various levels.

CDK Aspects are a way to apply an operation to every construct in a given scope.

This should be enough on a high level about what CDK Aspects are for this post. I have written a post on the Learn AWS hashnode blog about The Power of AWS CDK Aspects. Read that post if you are interested in some more theory.

In this post, I will show you a few possible implementations of custom CDK Aspects on how you can leverage third-party Aspects. We will create Aspects that alter your infrastructure, that show errors, that take arguments and that don't take arguments.

The goal is that you should be able to write your own Aspects and have a better idea of possible use cases for CDK Aspects.

You can find all the code in a CDK app that you can play around with in my GitHub repository JannikWempe/cdk-aspects-examples.

Implementing Custom CDK Aspects

Aspects have a small interface. This is what we have to implement creating our own custom Aspects:

interface IAspect {
    visit(node: IConstruct): void;
}

This terms visit (based on Visitor Pattern), node, and IConstruct should already be familiar to you after the introduction. The visit method will be called for every node within the scope you are applying the Aspect to.

Example 1: Applying Tags

The standard way of applying tags in a CDK app is by using Tags.of(scope).add(key, value). You know what? That is already using an Aspect.

But maybe you want something more custom and make certain tags required.

This is how a custom ApplyTags Aspect could look like:

type Tags = { [key: string]: string } & {
  stage: 'dev' | 'staging' | 'prod';
  project: string;
  owner: string;
}; 

class ApplyTags implements IAspect {
  #tags: Tags;

  constructor(tags: Tags) {
    this.#tags = tags;
  }

  visit(node: IConstruct) {
    if (TagManager.isTaggable(node)) {
      Object.entries(this.#tags).forEach(([key, value]) => {
        this.applyTag(node, key, value);
      });
    }
  }

  applyTag(resource: ITaggable, key: string, value: string) {
    resource.tags.setTag(
      key,
      value
    );
  }
}

In visit we narrow down the node to a construct that is taggable by checking if TagManager.isTaggable(node) is truthy. After that, we go ahead and add the desired tags.

TypeScript helps here because you won't be able to just call setTag on any IConstruct. You have to filter out the resources that are not taggable. This is a common pattern for Aspects: You narrow down all the nodes to the resources you want to act upon.

This is how you apply ApplyTags on the App-level:

const app = new cdk.App();
const myStack = new MyStack(app, 'MyStack');

const appAspects = Aspects.of(app);

appAspects.add(new ApplyTags({
  stage: 'dev',
  project: 'CDK Aspects',
  owner: 'Jannik Wempe'
}));

You first call Aspects.of(scope) to get access to the Aspects within scope and add your own Aspect to it.

This will add three tags to all taggable resources that are within your app.

Example 2: Enabling S3 Bucket Versioning

This example will show you how to alter constructs within the scope. Use this power responsively as you will end up in a mess if you overuse this.

You want to enable bucket versioning for all of your buckets? You could create your own VersionedBucket by extending Bucket. But that is probably not the best idea. You would end up maintaining your own L2 construct and the requirements for that bucket will increase. You will end up with a custom bucket construct that would have tons of props in order to be suitable for all sorts of scenarios. Using an Aspect for that is more maintainable – and it requires fewer lines of code.

class EnableBucketVersioning implements IAspect {

  visit(node: IConstruct) {
    if (node instanceof CfnBucket) {
      node.versioningConfiguration = {
        status: 'Enabled'
      };
    }
  }
}

That's it. All of your CfnBuckets within scope will be versioned.

Note that all Buckets (L2 construct) are a CfnBucket (L1 construct) but CfnBuckets are not necessarily a Bucket. Double check that you are narrowing down to the desired ones by adding some console.logs – as a real developer does 😅

Example 3: Enforcing Minimum Lambda Node Runtime Version

As mentioned in the previous example, altering all kinds of constructs through Aspects can end up in a mess that is hard to debug. Displaying an error and letting the developer intentionally change the code might be the better option. This is what we will do in this example.

Let us create an Aspect that checks all Lambda functions runtime versions and enforces a minimum NodeJS version being used. We pass a minimumNodeRuntimeVersion: Runtime into the constructor of our EnforceMinimumLambdaNodeRuntimeVersion Aspect (Yes, I know, it is a creative name 😅). The Aspect would check every Lambda functions runtime and adds an error to the functions Annotations if the check fails:

class EnforceMinimumLambdaNodeRuntimeVersion implements IAspect {
  #minimumNodeRuntimeVersion: Runtime;

  constructor(minimumNodeRuntimeVersion: Runtime) {
    if (minimumNodeRuntimeVersion.family !== RuntimeFamily.NODEJS) {
      throw new Error('Minimum NodeJS runtime version must be a NodeJS runtime');
    }
    this.#minimumNodeRuntimeVersion = minimumNodeRuntimeVersion;
  }

  visit(node: IConstruct) {
    if (node instanceof CfnFunction) {

      // runtime is optional for functions not being deployed from a package
      if (!node.runtime) {
        throw new Error(`Runtime not specified for ${node.node.path}`);
      }

      if (!node.runtime.includes('nodejs')) return;

      const actualNodeJsRuntimeVersion = this.parseNodeRuntimeVersion(node.runtime);
      const minimumNodeJsRuntimeVersion = this.parseNodeRuntimeVersion(this.#minimumNodeRuntimeVersion.name);

      if (actualNodeJsRuntimeVersion < minimumNodeJsRuntimeVersion) {
        Annotations
          .of(node)
          .addError(`Node.js runtime version ${node.runtime} is less than the minimum version ${this.#minimumNodeRuntimeVersion.name}.`);
      }
    }
}

  private parseNodeRuntimeVersion(runtimeName: string): number {
    const runtimeVersion = runtimeName.replace('nodejs', '').split('.')[0];
    return +runtimeVersion;
  }
}

This one is slightly more complex but it follows the same principles as the previous example. The main difference is the Annotations.of(node).addError() part. We don't throw an error that would abort the synthesis and show an ugly, unhelpful stack tract, but we are adding an error annotation to the construct itself. This is what error annotations would look like:

[Error at /MyStack/MyLambda1/Resource] Node.js runtime version nodejs12.x is less than the minimum version nodejs16.x.
[Error at /MyStack/MyLambda2/Resource] Node.js runtime version nodejs12.x is less than the minimum version nodejs16.x.

Note that it shows two errors. The synthesis doesn't stop after the first one.

Example 4: Configure Lambda Log Groups

This one is also different from the previous ones. We now want to add an actual resource. Lambda functions are creating their CloudWatch log groups implicitly. You won't be able to see the log groups in the synthesized CloudFormation template but they will be created for you. That is why we can't just narrow the node in visit down to CfnLogGroup. The log group won't be there.

In order to customize a log group of a Lambda we have to explicitly create it with the logGroupName being /aws/lambda/[REPLACE_WITH_LAMBDA_FN_NAME]. We can pass configurations to that explicitly created log group.

This is what it looks like:

class LambdaLogGroupConfig implements IAspect {
  #logGroupProps?: Omit<LogGroupProps, "logGroupName">;

  constructor(logGroupProps?: Omit<LogGroupProps, "logGroupName">) {
    this.#logGroupProps = logGroupProps;
  }

  visit(construct: IConstruct) {
    if (construct instanceof CfnFunction) {
      this.createLambdaLogGroup(construct);
    }
  }

  private createLambdaLogGroup(lambda: CfnFunction) {
    new LogGroup(lambda, "LogGroup", {
      ...this.#logGroupProps,
      logGroupName: `/aws/lambda/${lambda.ref}`,
    });
  }
}

To be honest, this one was hard for me as it has some caveats. Thanks, Glib Shpychka for helping me out on the cdk.dev Slack channel.

We can pass all LogGroupProps to the Aspect excluding the logGroupName as this is the prop that connects the LogGroup to the CfnFunction. We again narrow down the node to the construct we are interested in: CfnFunction. Now we create a LogGroup and are using the CfnFunction construct itself as the scope for that LogGroup. This helps us to avoid conflicts in the CDK-generated logical IDs as the scope will be used to generate a prefix.

Now you might wonder what the lambda.ref is about and why it's not just lambda.functionName. This is the tricky part.

It is best practice to not assign specific resource names to your constructs but rather let CDK generate them for you. If you log lambda.functionName to the console you would see something like this: ${Token[TOKEN.246]}. It is a Token. What is a Token?

Tokens represent values that can only be resolved at a later time in the lifecycle of an app.

(from CDK docs - Tokens)

I tried different kinds of things to resolve the Token (e.g. checking Token.isUnresolved) but nothing was working. The solution was to use CfnRefElement.ref which lets you access the CloudFormation { Ref } element – the physical name.

With LambdaLogGroupConfig you could configure all Lambda functions log groups based on the environment like this:

appAspects.add(new LambdaLogGroupConfig({
  retention: config.stage.name === "prod" ? RetentionDays.ONE_MONTH : RetentionDays.ONE_WEEK
}));

// OR

const myProdStackAspects = Aspects.of(myProdStack);
myProdStackAspects.add(new LambdaLogGroupConfig({
  retention: RetentionDays.ONE_MONTH
}));

const myDevStackAspects = Aspects.of(myDevStack);
myDevStackAspects.add(new LambdaLogGroupConfig({
  retention: RetentionDays.ONE_WEEK
}));

Using 3rd-Party CDK Aspects

There are already useful CDK Aspects out there that are ready to be used in your CDK application. In this section I want to give you an example for one of them: One of them is cdk-nag.

cdk-nag contains several Aspects to check your applications for best practices. It is especially useful if you need to be HIPAA-compliant or have other compliance requirements. It is inspired by cfn_nag which is a a tool checking for patterns in your CloudFormation templates.

After installing cdk-nag with your favorite package manager (e.g. npm install cdk-nag) you can use one of the Aspects just like the others above:

const app = new cdk.App();
new MyStack(app, 'MyStack');

const appAspects = Aspects.of(app);
appAspects.add(new AwsSolutionsChecks());

The AwsSolutionChecks includes a lot of rules which is why you initial output after trying to synthesize your app could look something like this:

[Error at /MyStack/CdkAssertionsQueue/Resource] AwsSolutions-SQS2: The SQS Queue does not have server-side encryption enabled.
[Error at /MyStack/CdkAssertionsQueue/Resource] AwsSolutions-SQS3: The SQS queue does not have a dead-letter queue (DLQ) enabled or have a cdk-nag rule suppression indicating it is a DLQ.
[Error at /MyStack/CdkAssertionsQueue/Resource] AwsSolutions-SQS4: The SQS queue does not require requests to use SSL.
[Error at /MyStack/MyBucket/Resource] AwsSolutions-S1: The S3 Bucket has server access logs disabled.
[Error at /MyStack/MyBucket/Resource] AwsSolutions-S2: The S3 Bucket does not have public access restricted and blocked.
[Error at /MyStack/MyBucket/Resource] AwsSolutions-S10: The S3 Bucket or bucket policy does not require requests to use SSL.

Each rule has an identifier like AwsSolutions-S2. You can turn off rules individually.

Conclusion

We had a look at different possibilities you have when creating your own CDK Aspects and have used a 3rd-party Aspect as well. By now you should have a good idea of how to work with CDK Aspects. Maybe you even have some use cases in mind in which Aspects could be helpful.

There is also one other useful use case that I haven't explicitly shown above: You can alter constructs that you don't have direct access to. Imagine using a 3rd party L3 construct that does not expose ways to customize one of the underlying resources. You can create a CDK Aspect and apply it to that 3rd party construct.

All the code is on GitHub JannikWempe/cdk-aspects-examples.

Thanks for reading this article ✌🏼

AWS Beginner: AWS is different. What are AWS Accounts, IAM Users and Root User?

Jannik Wempe — Wed, 17 Aug 2022 20:00:54 +0000

Things are confusing when you are just starting to use AWS. You don't just create an account and get started as you do with other services. You come across terms like "Account", "User" and "Root User" and maybe ask yourself how they differ. This post should help understand these terms.

When You Sign Up for an AWS Account

If you sign up for an AWS account you will be asked to enter a "Root user email address" and an "AWS account name":

After you finish the signup process, you will end up with an account (identified by a 12-digit account ID and an account name, also known as account alias) and some credentials (email and password of your root user) to enter that account.

This is what the AWS docs say about the root user in a red warning callout:

We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user.

Okay, so you should create an IAM user (often just referred to as user; this is how you can create an IAM user) but what is the difference between an IAM user and the root user? And usually, if you sign up for a service you create an account with credentials and end up with one thing: an account. Why do you have (at least) three account-related things in AWS? How are they different? Before we will get to the definitions we will have a look at how to sign in using either the root user or an IAM user.

Sign In to your account

This is how the sign-in screen looks like when you click on the "Sign In" button on https://aws.amazon.com/console/:

You can either go ahead and sign in as a root user by just providing the root user email address and the password or you can sign in as an IAM user by providing the account ID or account alias first and the IAM user name and password in the second step:

Note how you don't have to provide the account ID for the root user as that user has to be unique globally.

Also, you can use your account name in a URL like https://myaccountname.signin.aws.amazon.com/console to populate the account id input with myaccountname (that account alias must exist, otherwise you will land on a 404 page).

Definitions

Now let's get to the definitions.

Account

Think of an account as just a container. A container containing your resources, users and account settings.

You can create multiple of these containers. In fact, it is best practice to separate your different workloads (for example test and production) into different accounts.

Root User

The root user is the master of your account. It is the central key (this is why you should activate Multi-Factor Authentication (MFA) for it) and provides unrestricted access to the account. There is always exactly one root user per account.

There are some tasks that only a root user can do, e.g. changing the account settings (including the account name) and billing information.

Again: use MFA for your root user and only use that user if you have to, don't use it for everyday work.

IAM User

An IAM User is an entity representing a person or an application (it is not necessarily a person, this can be confusing because the word "user" implies a person). You create the IAM users after the initial creation of your root user. An account can have several users (think of people or applications being able to access the container of resources).

There are various ways how you can grant IAM users permissions in order to be able to do something. One of them is attaching policies to the IAM user (learn more about IAM permissions). An IAM user with the AdministratorAccess policy attached is not the same as the root user.

Conclusion

The concept of accounts and users in AWS is different from what we are used to (Google, Spotify, etc.). This can lead to confusion. Hopefully this post has cleared up that confusion for you.

If you need help getting going, feel free to ask questions.

When to (Not) Use React Context API for State?

Jannik Wempe — Fri, 24 Jun 2022 05:30:00 +0000

React's Context API is a popular choice for global state (my definition: state that is shared amongst components). It is easy to use and we are used to it because a lot of libraries leverage them. There are characteristics of React Context that you should be aware of. They make context not always the best choice for global state.

Why Does React Context Exist?

Technically we could just place our whole state at our top-level component and pass it down the React element tree to the components that need access to the state. But in any application but a very simple one that would require us to pass down the state several levels down the tree and through components that are not using the state themselves at all. It would pollute the code and ruin the Developer Experience (DX). That problem is known as prop-drilling. React's Context API was created to mitigate this issue. This is an excerpt from the React Context API docs:

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

By combining React's state-related hooks (useState and useReducer) with React context you can provide a shared state to all components nested within the contexts Provider. Problem solved, right? Well, no. The context API has a major issue:

The Issue With Using React Context API for State

Consumers of a context always re-render if the state provided by the context changes. It does not matter if a component actually uses the piece of the state that has changed. Example: ContextA provides the state { a: 1, b: 1 } and ComponentA reads only a. Even if only b changes ComponentA will re-render – for no reason, it will render the same content. This is called an extra or unnecessary re-render.

For that reason, it is bad practice to have a single, huge state provided by a context. Instead, you should split the state up and create separate contexts like AuthContext, ThemeContextetc. Ask yourself if consumers mostly consume the majority of the state. Only in that case, you don't end up with a lot of extra re-renders. (A few extra renders are not an issues at all but it can get out of control if a lot of components and their children re-render.)

Besides the extra re-renders it can become hard to keep track of the data flow in your application. You won't be able to easily see which data is being used where, as it's the case with props. The React docs include a section Before You Use Context for a reason. One highlighted excerpt:

If you only want to avoid passing some props through many levels, component composition is often a simpler solution than context.

Don't get me wrong, the React Context API is a great tool. But don't see everything as a nail global state just because you have a hammer React's Context API.

When to Use React's Context API?

Now you may ask yourself when it is a good idea to use context for global state? I am glad you asked, this chart is my answer:

As you can see, there are a lot of scenarios where other tools are preferable. I will explore a few of the alternatives in future posts.

Creating Reusable React Components with TypeScript

Jannik Wempe — Sun, 06 Mar 2022 09:49:51 +0000

Often we write React components that get bigger and bigger and at some point, we extract parts of it into separate components. Either because the component is getting too big or because we need parts of it somewhere else.

This is generally a good approach but after a while, we can up with several components that are similar (e.g. some kind of list, card, or whatever). Often they have some similarities. Wouldn't it be nice to have some basic building blocks that can be reused in order to encapsulate such similarities?

In this post, I'll show you how to use the React techniques "render props" and "as-prop" and how to use them with TypeScript.

You can find the finished code on GitHub.

Starting Point: Non-Generic JS Component

This is the component we are starting with:

import React from "react";
import { Pokemon } from "../api/pokemon";

type Props = {
  pokemons: Pokemon[]; // Pokemon is { name: string; url: string; }
};

export function PokemonList({ pokemons }: Props) {
  return (
    <ul>
      {pokemons.map((pokemon) => (
        <li key={pokemon.name}>
          <a href={pokemon.url} target="_blank" rel="noreferrer">
            {pokemon.name}
          </a>
        </li>
      ))}
    </ul>
  );
};

Note: I know that "Pokemons" isn't the plural, but I use the "s" to distinguish it from the singular.

It is just a list of Pokemon which is rendering some links – nothing special here. But imagine at another place we are either creating a similar list with trainers or a list which is containing more information about the Pokemon.

We could come with a <LinkList /> which is also usable for trainers or add an optional prop to this component indicating that it should also render more details. But these solutions aren't really reusable either.

💡 Boolean flags like showDetails are often a code smell. It indicates that the component is doing more than one thing – it is violating the Single Responsibility Principle (SRP). That is not only true for React components, but for functions in general.

Okay, let us create a truly reusable <List /> component.

React Render Props

First of all, what is the React Render Props technique? It is even mentioned in the official React docs:

The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.

A component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.

Render props are a way to achieve Inversion of Control (IaC). Instead of having the child component control the rendering of the list items, we reverse control and have the parent component control the rendering of the items.

This is what a generic <List /> component could look like:

import React from "react";

type Props<Item> = {
  items: Item[];
  renderItem: (item: Item) => React.ReactNode;
}

export function List<Item>({ items, renderItem }: Props<Item>) {
  return <ul>{items.map(renderItem)}</ul>;
};

Note that the component now has no reference to Pokemon anymore. It could render anything, no matter if Pokemon, trainers, or something else.

It not only is a generic component not, but it also uses a TypeScript generic for the component props. We use the generic Item type for the list of itemsand for the single item. When we pass one of the props to this component, if we use it somewhere, React (or rather TypeScript) knows that the other prop has the same type.

This is how we would use it to achieve the same output as in our initial example:

import React from "react";
import { List } from "./components/List";
import { getPokemons } from "./api/pokemon";

function App() {
  const pokemons = getPokemons(); // returns some fix dummy data

  return (
    <List
      items={pokemons}
      renderItem={(pokemon) => (
        <li key={pokemon.name}>
          <a href={pokemon.url} target="_blank" rel="noreferrer">
            {pokemon.name}
          </a>
        </li>
      )}
    />
  );
}

export default App;

If we pass items, which is of type Pokemon[] first, then the single item in renderItem is inferred to be Pokemon. We could also pass the single item in renderItem first, but in that case, we have to explicitly type it like renderItem={(pokemon: Pokemon) => (. Now, items must be of type Pokemon[].

Now the parent controls how the items of the list are rendered. That is nice, but it has a major flaw: <List /> renders an outer <ul> and therefore we must return an <li> from renderItem in order to end up with valid HTML. We would have to remember that and we can't use it for more generic lists where we don't want to use an <ul> at all. This is where the as-prop comes into play.

React As Prop

Our goal: We not only want to reverse control over how a single item is rendered but also for the HTML tag used by <List />. We can achieve that with the as-prop:

import React from "react";

type Props<Item, As extends React.ElementType> = {
  items: Item[];
  renderItem: (item: Item) => React.ReactNode;
  as?: As;
}

export function List<Item, As extends React.ElementType>({
  items,
  renderItem,
  as
}: Props<Item, As>) {
  const Component = as ?? "ul";
  return <Component>{items.map(renderItem)}</Component>;
}

Now the parent component can decide what HTML tag <List /> renders. It could also make it not render an outer tag at all by passing as like this <List as={React.Fragment} />. Per default <List /> renders an <ul> tag. Therefore our current usage in the parent doesn't have to change at all.

Note: We can't just use the as prop like <as>content</as> because that would not be valid JSX. Non-native HTML tags have to be uppercased. You could uppercase the As prop in the first place but I personally find it quite awkward.

There is still one caveat. If we decide to render an outer a or img tag (which we probably won't in our example, but it is very relevant when dealing with the as-prop in general), then we can't pass required props like href or src to <List />. Not only TypeScript would complain, but also the props would not be forwarded to the <Component />within <List />. This is how we can deal with that (this is the final version):

import React from "react";

type Props<Item, As extends React.ElementType> = {
  items: Item[];
  renderItem: (item: Item) => React.ReactNode;
  as?: As;
}

export function List<Item, As extends React.ElementType>({
  items,
  renderItem,
  as,
  ...rest
}: Props<Item, As> & Omit<React.ComponentPropsWithoutRef<As>, keyof Props<Item, As>>) {
  const Component = as ?? "ul";
  return <Component {...rest}>{items.map(renderItem)}</Component>;
}

We now pass all props besides items, renderItem and as to Component by using the spread operator for rest. Now we technically could pass an href from the parent component, but TypeScript would still complain. We can solve this with React.ComponentPropsWithoutRef<As>, which results – as the name already implies – in all prop types of the As component excluding the ref prop. If we would now pass as={"a"}, TypeScript autocomplete would suggest props from an <a> tag, like href to us.

What is Omit<React.ComponentPropsWithoutRef<As>, keyof Props<Item, As>> doing here? If we would include something like href: MyHrefType in our Props type and use as="a", then we would end up with an error when trying to pass any href: Type 'string' is not assignable to type 'never'.. Omit excludes all prop types that we explicitly defined in our Props type from the result of React.ComponentPropsWithoutRef<As>. In our case – passing as="a" – Omit<React.ComponentPropsWithoutRef<As>, keyof Props<Item, As>> would not include the href type anymore. We now can pass the href prop of type MyHrefType again. TLDR; it deduplicates types.

The Result

Now our <List /> is truly generic and reusable for a lot of cases. I often still prefer creating something like a <PokemonList /> which uses the <List /> as a building block:

import React from "react";
import { Pokemon } from "../api/pokemon";
import { List } from "./List";


type Props = {
  pokemons: Pokemon[];
};

export function PokemonList({ pokemons }: Props) {
  return (
    <List
      items={pokemons}
      renderItem={(pokemon) => (
        <li key={pokemon.name}>
          <a href={pokemon.url} target="_blank" rel="noreferrer">
            {pokemon.name}
          </a>
        </li>
      )}
    />
  );
}

Now we can easily create something like <PokemonDetailsList />, <TrainersList /> or whatever – or use the <List /> directly.

Conclusion

React techniques like render props and the as prop enable us to build our own reusable, generic building blocks. Typing those generic components isn't that easy (at least this is how I feel about it). Therefore we also learned how to type those generic components using TypeScript.

I admit that this <List /> component is a contrived example as it seems to offer not that many benefits compared to our initial solution. But the techniques that I have shown here are very relevant and the simple example allowed me to focus on the techniques. These techniques are widely used in libraries like Chakra UI and headless UI which I really enjoy using.

There are many other techniques for creating reusable React components. Some of them utilize React context and composition (rather than inheritance). These techniques might be the topics for future articles.

My Favorite Tech Stack for 2022

Jannik Wempe — Thu, 23 Dec 2021 19:31:51 +0000

I just recently tweeted my favorite tech stack for 2022 (inspired by @jonmeyers_io tweet). I'd like to share some more thoughts about my choices in this post.

// Detect dark theme var iframe = document.getElementById('tweet-1473935933447839748-733'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1473935933447839748&theme=dark" }

Frontend

First of all: I love frontend development. It is the direct touchpoint to the user for websites / -apps. It is the first impression for the user.

There is so much out there. It can be paralyzing. I already used a variety of frontend frameworks: React (CRA, Gatsby, NextJS), Vue, Angular, Svelte (SvelteKit). And as far as styling goes, I've tried a lot of things too: CSS (modules), SASS, CSS-in-JS, Material, Bootstrap, Bulma, Quasar, Tailwind, Chakra UI, and more. Therefore you can assume I've tried quite a lot and my choices are not the only ones I know. (Not saying that other tools don't do the job and are inferior. It also comes down to personal preference.)

Svelte / SvelteKit

This blog post goes into detail Why Svelte is different - and awesome. I just really enjoy using Svelte. It is more concise than React and more performant. Stores and animations are also great features. There is a reason why Svelte was the most loved web framework in the Stack Overflow Developer Survey 2021.

I think Svelte will make a jump in popularity with the release of SvelteKit version 1.0 which is my default for every Svelte app. In addition to that, Rich Harris (the creator of Svelte) was hired by Vercel and is now working full-time on Svelte / SvelteKit.

Svelte will rise and shine ✨

Learn more about Svelte

Learn more about SvelteKit

NextJS

Currently, I am still often using NextJS. It is great! Just like SvelteKit is my default for every Svelte project, NextJS is my default for any React project. Mostly for the same reasons: Static Site Generation (SSG), Server-Side Rendering (SSR), built-in file-based routing based, and more.

The ecosystem for React is way larger than the Svelte one and more people are familiar with React. Therefore NextJS is my choice for working together with other React-devs and when relying on a certain library that is not (yet) available in Svelte (can't think of any out of my head). In addition, the demand and job market for React / NextJS are much larger than for Svelte / SvelteKit.

Learn more about NextJS

TailwindCSS

I love styling with utilities based on a predefined and easily customizable theme. If you have read my post Debunking Tailwind Counterarguments you already know that I am a big fan. Most often I use Headless UI as an addition to get some functionality like a select or a modal. I've also bought Tailwind UI in order to move faster and also for some inspiration — and I don't regret it.

I just can't go back to UI libraries like Material UI or Bootstrap anymore 🤷🏼‍♂️

Learn more about TailwindCSS

Chakra UI

Chakra UI is inspired by Tailwind. It is also based on a theme that uses very similar design tokens. The difference to TailwindCSS is that it comes with a lot of components (therefore it is framework-specific; originally created for React but also available for Vue). The components are created with accessibility in mind. Chakra UI feels like a headstart compared to Tailwind when initially getting started but it also is a little less flexible (framework-specific, peer dependencies, etc.) I love both!

Learn more about Chakra UI

Backend

No frontend without backend (at least if you also consider static site hosting as backend). I do not only love frontend but I love backend as well — yes, I know, focusing is not one of my strengths, but I just can't go with just one of them.

Vercel

Vercel is my go-to for hosting my projects. It just provides a great Developer Experience (DX). Luckily they are not only the creators of NextJS but now also have Rich Harris and therefore SvelteKit expertise on board.

For some of my projects, Vercel alone is sufficient as it also provides also server-side functions. If it is not sufficient and I just need a little more, like auth, a DB or some storage, I go with Supabase next.

Learn more about Vercel

Supabase

Supabase ("The Open SourceFirebase Alternative") is great. It has a great DX, is very easy to use while also being quite powerful, and has a generous free tier (and is also quite cheap beyond that).

Supabase will be sufficient for a lot of use cases as it provides auth, a DB with a good API through their SDK and storage. If it is not sufficient, I go with AWS.

Learn more about Supabase

AWS CDK / Serverless Framework

There is literally nothing you can't do with AWS. In addition, AWS skills make you very attractive on the job market (my LinkedIn inbox is pretty full since I earned the AWS Associate Developer certificate).

I've used Cloudformation, SAM, CDK and the Serverless Framework so far. I can't really decide between CDK and Serverless. I like writing my infrastructure in TypeScript but I also appreciate the ease of use and plugin system of Serverless. Both of them are well suited for serverless architectures which is what I personally almost exclusively use.

Learn more about AWS CDK

Learn more about Serverless Framework

Conclusion

That's it. Nothing highly sophisticated. It is mostly the tech I enjoy and I think is valuable in the future. There are also other libraries I really enjoy, like XState and React Query (there is also Svelte Query). Just to mention a few.

How does your go-to stack in 2021 look like?

Authentication: Cookie- vs. Token-based

Jannik Wempe — Sun, 28 Nov 2021 18:27:41 +0000

Authentication is about confirming that users are who they say they are. Whereas authorization is about permissions of a given user (e.g. admin vs. user). Authentication is an integral part of most apps.

The two main methods for authentication are cookies and tokens. But what are the differences between the cookie- and the token-based approaches?

Cookie-based Authentication

The cookie-based approach is also often referred to as session authentication. When using session authentication, a cookie with the session id is created on the server and is sent to the client. The browser automatically stores the cookie and sends it alongside every subsequent request to the server. The server then looks up the session id and verifies its validity. The client doesn't have to deal with storing session-related information at all.

Sidenote: Dealing with sessions by using a cookie is not the same as a session cookie. A session cookie is a cookie without the Max-Age or Expires attribute being set. Therefore a session cookie gets deleted when a user closes the browser window or tab (= a user is ending the session). The term session cookie provides no information about what content a cookie stores.

Token-based Authentication

Tokens use a different approach. The token containing the session information is created on the server. It is encoded and signed by the server and sent to the client. The client can use the session information in that token. In this case, the client has to store the token (usually in localStorage or sessionStorage) and has to actively send the token along with every request (usually in the Authorization header). The server doesn't have to keep track of the sessions. The token contains all information the server needs to verify the session. (EDIT: Except the secret key, which is used for signing.) The signing of the token prevents the client from manipulating it.

The most popular way of using tokens for authentication is JSON web tokens (JWTs). You can learn more about JWTs specifically at jwt.io.

Summary

The main difference between the cookie and token-based approach is where the session information is stored. In the cookie-based approach, the burden of storing the session is on the server-side in contrast to the token-based approach where the client is responsible for storing the session information.

DEV Community: Jannik Wempe

Keep Your Functions Clean & Focused: Context Provision with Node.js AsyncLocalStorage

What is the Open/Closed Principle?

Violation of the Open/Closed Principle

Example 1: Database Transactions

Example 2: Logging

Applying the Open/Closed Principle with AsyncLocalStorage

Context Sharing with AsyncLocalStorage

Example 1 Revisited: Database Transactions

Example 2 Revisited: Logging

Conclusion

Further Reading

Create Your Personal, Pay-Per-Use ChatGPT Client in Minutes

About ChatBot UI

Adding BasicAuth

Conclusion

You Have Fucked Up! How to git revert?

Fix Production Fast

Undo Your Fuckup – Git Revert

Remove Last Commit (not git revert)

Git Revert (undo) the Last Commit

Git Revert a Merge Commit

Conclusion

How To Use GitHub Actions for Deployments When Following Trunk-Based Development

A Brief Introduction to Trunk-Based Development

Creating GitHub Actions Workflows

The Basic GitHub Action Workflow

Leveraging GitHub Environments

Adding a Manual Trigger for a Production Deployment

Conclusion

My thoughts after trying to port a Shopify store from NextJS to Shopify Hydrogen

What is Shopify Hydrogen?

What I like about Hydrogen

Shopify integration

Components provide primitives

Up-to-date tech stack

What I don't like about Hydrogen

Development and production environments behave differently

Docs leave room for improvement

Additional thoughts

How to Securely Use Secrets in AWS Lambda?

Why Environment Variables Are Not the Best Solution for Accessing Secrets

How to Securely Access Secrets in AWS Lambda?

Retrieving Secrets at Runtime

Retrieving Secrets in AWS Lambda using AWS CDK

Conclusion

Mastering AWS CDK Aspects

CDK Aspects Introduction

Implementing Custom CDK Aspects

Example 1: Applying Tags

Example 2: Enabling S3 Bucket Versioning

Example 3: Enforcing Minimum Lambda Node Runtime Version

Example 4: Configure Lambda Log Groups

Using 3rd-Party CDK Aspects

Conclusion

AWS Beginner: AWS is different. What are AWS Accounts, IAM Users and Root User?

When You Sign Up for an AWS Account

Sign In to your account

Definitions

Account

Root User

IAM User

Conclusion

When to (Not) Use React Context API for State?

Why Does React Context Exist?

The Issue With Using React Context API for State

When to Use React's Context API?

Creating Reusable React Components with TypeScript

Starting Point: Non-Generic JS Component

React Render Props

React As Prop

The Result

Conclusion

My Favorite Tech Stack for 2022

Frontend

Svelte / SvelteKit

NextJS

TailwindCSS

Chakra UI

Backend

Remove Last Commit (not `git revert`)