DEV Community: Aron Schüler

Using BuildKit for Container Image Building in GitLab CI And Pushing To ECR

Aron Schüler — Mon, 15 Sep 2025 15:27:35 +0000

Intro

If you're still using Kaniko for building container images in your GitLab CI pipelines, it's time to make a change. Kaniko has been deprecated, and BuildKit has emerged as the modern, efficient alternative for building container images in CI/CD environments. BuildKit offers superior caching capabilities, better performance, and enhanced security features compared to its predecessor. While Gitlab Docs offer examples, I had to spend some time getting our pipelines authenticated for AWS and allowing ECR pushes to work flawlessly.

In this post, I'll walk you through migrating your GitLab pipelines from Kaniko to BuildKit, specifically focusing on building images, authenticating against AWS, and then pushing them to AWS Elastic Container Registry (ECR). The migration makes sure your pipelines stay up to date with industry standards. It should also bring improvements in build speed and reliability!

Step-by-Step Guide

1. Understanding the BuildKit Setup

BuildKit runs in rootless mode for enhanced security, which means it doesn't require privileged access to build container images. The key components of our setup include:

BuildKit rootless image: moby/buildkit:rootless
ECR credential helper: For seamless authentication with AWS ECR
BuildKit daemon: Running in daemonless mode for GitLab CI compatibility

2. Setting Up the Base Job Configuration

First, let's create a reusable job template that contains all the common configuration.
You can reuse this later for different kind of build, e.g. production vs QA builds, or maybe E2E builds.

.build backend:
  stage: build
  tags:
    - medium-runner
  variables:
    GIT_STRATEGY: fetch
    AWS_DEFAULT_REGION: eu-central-1
    ECR_REPOSITORY: $ECR_REPOSITORY
    ECR_REGISTRY: $ECR_REGISTRY
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
    BUILDKITD_FLAGS: --oci-worker-no-process-sandbox
  image:
    name: moby/buildkit:rootless
    entrypoint: [""]

The BUILDKITD_FLAGS: --oci-worker-no-process-sandbox flag is necessary for running BuildKit in GitLab's shared runners without requiring additional privileges and something I had missing in my first jobs.

3. Installing and Configuring ECR Authentication

The before_script section handles the ECR authentication setup:

before_script:
  # Install ecr login helper
  - mkdir credentials-binaries
  - wget -O credentials-binaries/docker-credential-ecr-login https://amazon-ecr-credential-helper-releases.s3.us-east-2.amazonaws.com/0.10.0/linux-amd64/docker-credential-ecr-login
  - chmod +x credentials-binaries/docker-credential-ecr-login
  - chown 1000:1000 credentials-binaries/docker-credential-*
  - export PATH="${CI_PROJECT_DIR}/credentials-binaries:$PATH"

  # Create docker config for ECR authentication
  - mkdir -p ~/.docker
  - |
    cat << EOF > ~/.docker/config.json
    {
        "credHelpers": {
            "$ECR_REGISTRY": "ecr-login"
        }
    }
    EOF

This setup downloads the ECR credential helper and configures Docker to use it for authentication, using your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for that.
The credential helper also handles token refresh, so you don't need manual docker login commands.

4. Building and Pushing Images with BuildKit

The main build logic uses buildctl-daemonless.sh, which is perfect for CI environments
that don't have the docker service available:

script:
  # Build and push image using BuildKit
  - |
    buildctl-daemonless.sh build \
      --frontend dockerfile.v0 \
      --local context=$CI_PROJECT_DIR/backend \
      --local dockerfile=$CI_PROJECT_DIR/backend \
      --export-cache type=registry,ref=$ECR_REPOSITORY:buildcache \
      --import-cache type=registry,ref=$ECR_REPOSITORY:buildcache \
      --output type=image,name=$ECR_REPOSITORY:$IMAGE_TAG,push=true

The build uses registry-based caching for subsequent builds and builds+pushes to ECR in a single operation,
based on the backend/ folder in this example and the backend/Dockerfile.
Of course, this might need adaption in your usecase.

5. Creating Environment-Specific Jobs

Extend the base job for different environments:

build backend test:
  extends:
    - .build backend
  environment:
    name: test
  variables:
    IMAGE_TAG: backend-latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: on_success
    - when: never

This pattern allows you to create jobs for different environments (staging, production) or usecases by extending the base job and overriding necessary variables.

6. Required GitLab CI Variables

Ensure these variables are configured in your GitLab project settings:

ECR_REGISTRY: ECR registry domain (e.g., 123456789.dkr.ecr.eu-central-1.amazonaws.com)
ECR_REPOSITORY: Full ECR repository URI (e.g., 123456789.dkr.ecr.eu-central-1.amazonaws.com/my-app) (could reuse $ECR_REGISTRY lol)
AWS_ACCESS_KEY_ID: AWS credentials with ECR push permissions
AWS_SECRET_ACCESS_KEY: Corresponding AWS secret key

Conclusion

The setup shown here provides a solid foundation that you can customize for your specific needs. Migrating from Kaniko is pretty straightforward with this.
BuildKit brings your CI/CD pipeline up to date with current best practices. It also brings benefits like improved build speeds through better caching, enhanced security with rootless builds, and more reliable image building.
The ECR integration step is something that I needed to pierce together from different sources, but I'm very happy with the setup and the speed.
As you implement this in your own projects, you might want to explore additional BuildKit features like multi-platform builds or custom frontend implementations.

As always, feel free to share your experiences or ask questions about this migration approach down below :-)

Implementing Stripe Subscriptions with Firebase Cloud Functions and Firestore

Aron Schüler — Mon, 24 Mar 2025 07:37:29 +0000

Intro

Adding a subscription to your web application is probably the easiest way to generate a MRR with your new shiny startup idea. And Firebase is probably the fastest way of integrating a lot of functionality like Authentication, a NoSQL database and Cloud Functions into your system. I have done this a couple of times and just did it again for https://shotmetrics-ai.com, I can recommend Stripe. Integrating Stripe with Firebase means that we will create several Cloud Functions to provide all functionality, including a webhook for accepting incoming Stripe data and using these functions in your frontend.

Let's go through all steps required to implement stripe subscriptions in Firebase applications, using Firebase Firestore, Firebase Cloud Functions and of course Stripe it self.

Step-by-Step Guide

Step 1: Set Up Your Stripe Account

Before we dive into the necessary code, ensure you have a properly configured Stripe account:

Create a Stripe account if you don't have one already
Add your products in the Stripe dashboard
Create pricing plans for all products in Stripe's test mode
Write down your product and price IDs for later use

Remember to use Stripe's test mode during development so that you don't have to pay for your own services.

Step 2: Create a Cloud Function that returns Stripe Products and Prices

The first function we are going to create is a centralized information endpoint about your subscriptions, so that you don't have to redefine this in the frontend too.

Create a Cloud Function that serves as a central repository for your product and pricing information and add all your products and their prices:

export const getSubscriptionPlans = {
  basic: {
    id: "basic",
    name: "Basic Plan",
    description: "Access to core features",
    prices: {
      monthly: {
        id: "price_monthly_basic_id_from_stripe",
        amount: 9.99,
        interval: "month",
      },
      yearly: {
        id: "price_yearly_basic_id_from_stripe",
        amount: 99.99,
        interval: "year",
      },
    },
  },
  pro: {
    id: "pro",
    name: "Pro Plan",
    description: "Full access to all features",
    prices: {
      monthly: {
        id: "price_monthly_pro_id_from_stripe",
        amount: 19.99,
        interval: "month",
      },
      yearly: {
        id: "price_yearly_pro_id_from_stripe",
        amount: 199.99,
        interval: "year",
      },
    },
  },
};

Step 3: Expose your Stripe Products and Prices to Your Frontend

Create a Cloud Function that your frontend can call to retrieve product information:

import { onRequest } from "firebase-functions/v2";
import { getSubscriptionPlans } from "./constants";

export const getStripeProducts = onRequest((_request, response) => {
  response.json({
    products: getSubscriptionPlans,
  });
});

Step 4: Create a Stripe Checkout Session Cloud Function

Next, we want users to be able to start a Checkout Session where they enter payment informations. To do so, create a .env file in your functions folder where you add the stripe secret key like this:

STRIPE_SECRET_KEY=stripe-sk-foobar12345

Then, implement a Cloud Function that creates a Stripe checkout session when a user wants to subscribe:

import { getAuth } from "firebase-admin/auth";
import { onCall, HttpsError } from "firebase-functions/v2/https";
import Stripe from "stripe";

export const createSubscriptionCheckout = onCall(async (request) => {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || "", {
    apiVersion: "2025-01-27.acacia",
  });
  try {
    const { priceId, successUrl, cancelUrl } =
      request.data as CreateCheckoutSessionRequest;
    const auth = getAuth();
    const user = await auth.getUser(request.auth?.uid || "");

    if (!user.email) {
      throw new HttpsError(
        "failed-precondition",
        "User must have an email to create a subscription",
      );
    }

    // Get or create Stripe customer
    const customerId = await getOrCreateStripeCustomer(
      stripe,
      user.uid,
      user.email,
    );

    // Create checkout session
    const checkoutUrl = await createCheckoutSession(
      stripe,
      customerId,
      priceId,
      successUrl,
      cancelUrl,
    );

    return { url: checkoutUrl };
  } catch (error: unknown) {
    logger.error("Error creating subscription checkout:", error);
    throw new HttpsError(
      "internal",
      error instanceof Error
        ? error.message
        : "An error occurred while creating the checkout session",
    );
  }
});

Step 5: Connect Your Frontend to Stripe

In our frontend, we want to display the products and create a checkout session when users click to subscribe. For this, you could create a React component that looks something like this (not checked if this runs, if it does not, comment below please):

import React, { useState, useEffect } from 'react';
import { httpsCallable } from 'firebase/functions';
import { functions } from './firebaseConfig';

const SubscriptionPage = () => {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Fetch products from your Cloud Function
    fetch('/api/getStripeProducts')
      .then(response => response.json())
      .then(data => {
        setProducts(data.products);
        setLoading(false);
      });
  }, []);

  const handleSubscribe = async (priceId) => {
    try {
      const createCheckoutSession = httpsCallable(functions, 'createSubscriptionCheckout');
      const { data } = await createCheckoutSession({
        priceId,
        successUrl: `${window.location.origin}/subscription/success`,
        cancelUrl: `${window.location.origin}/subscription/canceled`,
      });

      // Redirect to Stripe Checkout
      window.location.href = data.url;
    } catch (error) {
      console.error('Error creating checkout session:', error);
    }
  };

  if (loading) return <div>Loading subscription plans...</div>;

  return (
    <div className="subscription-container">
      <h1>Choose your plan</h1>
      <div className="plans-grid">
        {Object.values(products).map(product => (
          <div key={product.id} className="plan-card">
            <h2>{product.name}</h2>
            <p>{product.description}</p>
            <div className="pricing-options">
              {Object.values(product.prices).map(price => (
                <button
                  key={price.id}
                  onClick={() => handleSubscribe(price.id)}
                  className="subscribe-button"
                >
                  Subscribe ${price.amount}/{price.interval}
                </button>
              ))}
            </div>
          </div>
        ))}
      </div>
    </div>
  );
};

export default SubscriptionPage;

Step 6: Create a Webhook Handler for Stripe Events

After a user has successfully completed their purchase, we need to update our Firestore database to reflect the new subscription status. We also need to verify the stripe-signature header to make sure that the request actually comes from stripe.

For this, we should create a webhook to process subscription events from Stripe and update your Firestore database accordingly:

import * as logger from "firebase-functions/logger";
import { onRequest } from "firebase-functions/v2/https";
import Stripe from "stripe";
import { handleSubscriptionUpdated } from "./handleSubscriptionUpdated";

export const stripeWebhook = onRequest(async (request, response) => {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || "", {
    apiVersion: "2025-01-27.acacia",
  });

  const sig = request.headers["stripe-signature"];

  if (!sig) {
    response.status(400).send("Missing stripe-signature header");
    return;
  }

  try {
    const event = stripe.webhooks.constructEvent(
      request.rawBody,
      sig,
      process.env.STRIPE_WEBHOOK_SECRET || "",
    );

    // Handle the event
    switch (event.type) {
      case "customer.subscription.created":
      case "customer.subscription.updated":
      case "customer.subscription.deleted":
      case "customer.subscription.paused":
      case "customer.subscription.resumed":
        await handleSubscriptionUpdated(event);
        break;
      default:
        logger.info(`Unhandled event type ${event.type}`);
    }

    response.json({ received: true });
  } catch (err: unknown) {
    logger.error("Error processing webhook:", err);
    response
      .status(400)
      .send(
        `Webhook Error: ${err instanceof Error ? err.message : "Unknown error"}`,
      );
  }
});

You can either test this webhook locally with the Stripe CLI or deploy it to Firebase and add the webhook URL to your Stripe account.
Documentation on how to test this locally can be found here.

And here's the implementation of the handleSubscriptionUpdated function:

import type Stripe from "stripe";
import { getFirestore } from "firebase-admin/firestore";
import * as logger from "firebase-functions/logger";
import { getSubscriptionPlans } from "../config/constants";

const db = getFirestore();

export async function handleSubscriptionUpdated(event: Stripe.Event) {
  const subscription = event.data.object as Stripe.Subscription;
  const customerId = subscription.customer as string;

  // Get the Firebase user ID from Stripe metadata
  const customerData = await stripe.customers.retrieve(customerId);
  const userId = customerData.metadata.firebaseUID;

  if (!userId) {
    logger.error("No Firebase UID found in customer metadata");
    return;
  }

  const db = getFirestore();

  // Update user subscription data in Firestore
  await db
    .collection("users")
    .doc(userId)
    .update({
      subscription: {
        id: subscription.id,
        status: subscription.status,
        priceId: subscription.items.data[0].price.id,
        productId: subscription.items.data[0].price.product,
        currentPeriodEnd: new Date(subscription.current_period_end * 1000),
        cancelAtPeriodEnd: subscription.cancel_at_period_end,
        createdAt: new Date(subscription.created * 1000),
        updatedAt: new Date(),
      },
    });

  logger.info(`Updated subscription for user ${userId}`);
}

Step 7: Create a Customer Portal Function

Even if your service is amazing, some users will inevitably cancel their subscriptions. Or maybe just update their payment method. But we need some kind of subscription management. For this, we have to create a links so they can manage their subscription through Stripe. Stripe calls this a "Customer Portal session".

Implement a function that creates a Stripe Customer Portal session to allow users to manage their subscriptions:

export const createCustomerPortal = onCall(async (request) => {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || "", {
    apiVersion: "2025-01-27.acacia",
  });
  try {
    const { returnUrl } = request.data as ManageSubscriptionRequest;
    const auth = getAuth();
    const user = await auth.getUser(request.auth?.uid || "");

    if (!user.email) {
      throw new HttpsError(
        "failed-precondition",
        "User must have an email to access the customer portal",
      );
    }

    // Get or create Stripe customer
    const customerId = await getOrCreateStripeCustomer(
      stripe,
      user.uid,
      user.email,
    );

    // Create portal session
    const portalUrl = await createPortalSession(stripe, customerId, returnUrl);
    return { url: portalUrl };
  } catch (error: unknown) {
    logger.error("Error creating customer portal session:", error);
    throw new HttpsError(
      "internal",
      error instanceof Error
        ? error.message
        : "An error occurred while creating the portal session",
    );
  }
});

Step 8: Retrieve Stripe Subscription Data via Cloud Function

Create a function that allows users to check their current subscription status:

export const getSubscription = onCall(async (request) => {
  const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || "", {
    apiVersion: "2025-01-27.acacia",
  });

  const auth = getAuth();
  const user = await auth.getUser(request.auth?.uid || "");

  if (!user.email) {
    throw new HttpsError(
      "failed-precondition",
      "User must have an email to get subscription details",
    );
  }

  // Get or create Stripe customer
  const customerId = await getOrCreateStripeCustomer(
    stripe,
    user.uid,
    user.email,
  );

  // Get subscription details
  const subscription = await getCustomerSubscription(stripe, customerId);

  return { subscription };
});

Step 9: Frontend Integration of Stripe Subscription Data and Management

You should now integrate both the createCustomerPortal and getSubscription functions into your frontend and show this information to your user and offer the option to manage their subscription, if they have an active subscription.

Step 10: Update Firestore Rules

Of course, we need to make sure that no users with ill intent can just tell your system that they have a valid subscription. For this, we need to restrict the access to the subscription attribute of our /user/{userId} document. This can be done by Firestore rules, which I hope you have configured properly already! If you did not, I have a tutorial available on basic Firestore rules.

Extend your Firestore rules with this:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth.uid == userId;
      allow update: if request.auth.uid == userId && request.resource.data.keys().hasOnly(['name', 'email', 'preferences']);
    }
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

This will only allow update operations on the name, email and preferences attributes of your user document - this is what I use to hold various informations, but you get the idea.

Step 11: Test everything and enable live mode

After deploying your functions and your frontend, test everything carefully. Everything! Subscription cancel cases, payment updates, aborted checkout sessions etc. If everything works and you're happy with it, disable Stripe test mode and you are ready to process your first subscriptions!

Conclusion

As you can see, you really only need a handful of new Firebase Cloud Functions to integrate Stripe with Firebase applications.
We have created functions to retrieve product and pricing information, create a checkout session, handle Stripe webhooks, create a customer portal session, and retrieve subscription data. We also updated Firestore rules to secure the subscription data.
I hope this guide was helpful to you and your products and that your launch is a great success! Feel free to share whatever you are building down below, I am interested to see your projects!

Publish Playwright Test Reports with GitLab CI/CD Artifacts

Aron Schüler — Wed, 11 Dec 2024 08:42:46 +0000

Introduction

Testing is a critical part of web development, and tools like Playwright make it easier to automate end-to-end testing for web applications.
Especially with their codegen feature, I enjoy writing tests with Playwright and prefer it over tools like Cypress or Selenium.

However, debugging e2e tests can be a hassle. If you run them in a pipeline, it can be quite hard to debug failing tests without proper reports.
Sharing test results with your team to collaborate on fixing issues can also be a challenge.

Luckily, Gitlab CI/CD allows us to easily publish HTML output as artifacts, making it easy to share test results with your peers.

In this guide, I'll walk you through configuring Playwright and GitLab CI/CD to generate and publish HTML test reports, making debugging and team collaboration much smoother.

Step-by-Step Guide

Configure Playwright to Generate HTML Reports

Playwright supports various reporters for its test results.
To generate an HTML report, you'll need to configure the playwright.config.ts or playwright.config.js file to use the html reporter.

Here’s how your configuration should look:

// playwright.config.js or playwright.config.ts
const config = {
  // Other configurations...
  reporter: [["html", { outputFolder: "out/report", open: "never" }]],
};
export default config;

This will generate an HTML report in the out/report directory after running the Playwright tests. The open: "never" option prevents the report from opening in the browser automatically, which would block the CI/CD pipeline and cause timeouts.

Set Up GitLab CI/CD Pipeline

Next, configure your .gitlab-ci.yml file to run the Playwright tests and provide the generated report as an artifact.
Here’s a sample pipeline configuration:

Code Block for Gitlab CI

stages:
  - e2e

playwright:
  stage: e2e
  image: mcr.microsoft.com/playwright:v1.49.0-noble
  script:
    - npx playwright test
  except:
    - release
  after_script:
    - echo "Report will be available at https://$CI_PROJECT_ROOT_NAMESPACE.$CI_PAGES_DOMAIN/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/out/report/index.html"
  artifacts:
    paths:
      - out/report/
    when: on_failure

Explanation of Gitlab CI configuration

image: Specifies the container image with Playwright pre-installed.
script: Runs the Playwright tests using npx.
except: Excludes the pipeline stage for specific branches like release.
after_script: Outputs a clickable URL to the report in the job logs.
artifacts: Stores the out/report directory with the playwright content as a pipeline artifact, making it available as Gitlab Pages content.

The pipeline will generate the HTML report and make it accessible as an artifact link in the GitLab job interface.

View the Report

Once the pipeline completes (successful or failed), you’ll find a link to the report in the pipeline job’s logs. The output you will look for looks something like this:

Report will be available at "https://<namespace>.<domain>/-/<project_name>/-/jobs/<job_id>/artifacts/out/report/index.html"

Clicking the link will open the Playwright HTML report, allowing you to inspect test results, trace failures, and debug issues effectively. I also like the playwright's Visual Comparison features, as it's great to use paired with these test reports.

Optional: Publish Report with GitLab Pages

If you’d like to make the report persistently accessible via GitLab Pages, extend the .gitlab-ci.yml configuration like this:

pages:
  stage: deploy
  script:
    - mkdir -p public
    - cp -r out/report/* public/
  artifacts:
    paths:
      - public

This step deploys the report to GitLab Pages under your project’s domain, making it publicly or privately accessible depending on your repository settings.
But this is probably something that you'd rather use for feature branches or other test deployments of e. g. your SPA.
If you'd like to know more about this, leave a comment down below, and I'll happily provide a tutorial for that, too!

Conclusion

By following these steps, you can integrate Playwright’s reporting features with GitLab CI/CD, making it easy to debug failing pipelines. Especially when combined with Playwrights screenshot matching, you'll end up with a nice way of debugging your end-to-end tests.

If you have questions or want to share your experience setting this up, feel free to drop a comment below. Happy testing 😸!

Using Cloudflare Workers as a Proxy for Firebase Authentication

Aron Schüler — Sun, 02 Apr 2023 10:43:38 +0000

Setting Up Cloudflare Workers

Firebase is a popular platform for building web and mobile applications. One of the most commonly used authentication methods in Firebase is signInWithRedirect. However, there is a known issue with this function on Safari browsers where cross-domain cookies do not work. This means that the authentication cannot be done in the Firebase project's URL, which will be something like myapp-123asdf.firebaseapp.com/, and we have to serve the authentication handlers ourselves.

To resolve this issue, we can use Cloudflare Workers as a proxy for Firebase authentication, so we can serve the authentication on the same domain as our application. This way, we can set the cookies for e.g. app.example.com and use it in the application after the redirect. This will allow any user to authenticate with the signInWithRedirect function. In this blog post, I will guide you through the process of setting up Cloudflare Workers for Firebase authentication.

Note that this guide requires that you maintain your DNS records with Cloudflare already. As we will register a serverless function running on the same domain as your application, Cloudflare needs to be able to register a new record pointing to your function.

Register a Cloudflare Worker

The first step is to register a Cloudflare Worker. If you don't already have a Cloudflare account, you will need to create one and add your domain to it, so that we can register a route for the domain later on. Once you have logged in to your Cloudflare account, click on the Workers section in the sidebar.

Next, you should give the worker a good name so that it is easy recognizable. You can pick any of the code examples.

Confirm the Creation and you will be greeted with an overview of the just created service. By clicking "Quick Edit" we can jump straight into a code editor for the Worker and start implementing necessary logic to proxy the requests to Firebase Authentication.

Implementing the Worker to proxy requests to Firebase Authentication

To implement the actual code that proxies requests from our app.example.com domain (where your application is running) to the external Firebase Authentication system, we will define some logic for our Worker using JavaScript. The first step is to define the project URL of your Firebase project. It is in the format https://project-id.firebaseapp.com. Your project ID can be found in the Firebase console under Project settings > General > Project ID.

If your project ID would be myapp-1dg8y9, your project URL would be https://myapp-1dg8y9.firebaseapp.com

Define your project URL as firebaseProjectUrl:

const firebaseProjectUrl = 'https://myapp-1dg8y9.firebaseapp.com';

We can then define the Cloudflare Worker to listen for requests on /__/auth/ and proxy them to the Firebase authentication URL.

const firebaseProjectUrl = 'https://myapp-1dg8y9.firebaseapp.com';

export default {
  async fetch(request) {
    const requestUrl = new URL(request.url);
    if (requestUrl.pathname.startsWith("/__/auth/")) {
      const transformedUrl = new URL(
        firebaseProjectUrl + requestUrl.pathname + requestUrl.search
      );
      const newRequest = new Request(transformedUrl.toString(), {
        method: request.method,
        headers: request.headers,
      });
      return fetch(newRequest);
    }
    return new Response("Not found", { status: 404 });
  },
};

This code listens for requests on /__/auth/ and rewrites the request to be directed to your Firebase project URL. Then, it creates a new request object with the rewritten URL and forwards the original request's headers and method. Finally, it returns the response from Firebase.

With this code, we have successfully set up a Cloudflare Worker to proxy our app's Firebase authentication requests. In the next section, we will guide you through the process of setting up the routing for this Worker.

Configure the Cloudflare Worker

Now that we have created a new Worker, we need to configure it to be reachable under our app's domain, so that it can rewrite requests to Firebase Authentication for us.

First, go to your Cloudflare dashboard and navigate to the Workers section. Click on the worker you just created to open its settings page. There, select Triggers to configure the Worker's triggers.

Under the "Routes" section, click "Add route" to add a new route with the Route app.example.com/__/auth/*, where you . This tells Cloudflare to use the Cloudflare Worker for any requests that start with /__/auth/.
Then select the fitting Zone / Domain for your worker.

That was the Cloudflare part, nice!

Setting Up Your App

Registering the new authorized domain in Firebase Authentication

Next, we need to add the app's domain (app.example.com) to our Firebase project's Authorized domains. Go to the Firebase console and navigate to Authentication > Settings. Under Authorized domains, add your app's domain + /__/auth/handle, so for our app.example.com application you would add https://app.example.com/__/auth/handle. The Firebase Settings UI does not show the pathname entered here, but it matters, so be sure to add it this way.

Changing your firebase configuration

Finally, we need to update our Firebase configuration to use the new authentication domain. In your app's Firebase configuration, update the authDomain property to use your Cloudflare worker domain.

const firebaseConfig = {
  // [...]
  authDomain: 'app.example.com'
};

With these configurations, we have successfully set up our Cloudflare Worker to proxy Firebase authentication requests and configured our Firebase project to use the new authentication domain. In the next section, we will guide you through the process of testing this setup.

Testing

To test if your setup is working as expected, you can navigate to https://app.example.com/__/auth/handle. If you see a "Site Not Found" Firebase error, your project was configured correctly, as the default action for GET requests to the auth handle is what's currently displayed. You can deploy your change now, the sign in will work under Safari now!

Conclusion

By using Cloudflare Workers as a proxy for Firebase authentication, we can ensure that any user can authenticate with the signInWithRedirect function. The process involves registering a Cloudflare Worker and configuring it to resolve the requests as a proxy, configuring your Firebase project to allow the authentication domain, configuring your application, and then testing the Cloudflare Worker and Firebase authentication to ensure this works before deploying.

Fix slow ZSH startup due to NVM

Aron Schüler — Thu, 02 Feb 2023 11:04:23 +0000

NVM can really be helpful when dealing with older projects. But there’s a problem, still. The nvm installation adds a portion of code to your .zshrc to enable autocompletion. This, in turn, slows the startup of your shell quite a lot.

But we can easily fix this slow zsh startup! Instead of always loading your nvm autocompletion, we can command oh-my-zsh to just load nvm ressources on-demand, also known as lazy-loading.

How do I check if just NVM slows my ZSH startup?

That’s easy. In your ~/.zshrc you can simply add zmodload zsh/zprof as first line and zprof as last line. This will prove you a nice output on which plugin caused what delay.

So go ahead, add these both lines to your shell startup script and time your shell startup with time zsh -i -c exit. This will start your ZSH and execute the exit command.
Scroll a bit up and your zsh output should blame nvm:

Bad, right? That’s almost 90% startup time caused by a single tool I
don’t use that much. So let’s fix this!

How do I fix the slow zsh startup?

As the average ZSH user, you probably already have different plugins provided by oh-my-zsh. If not, really, go ahead and get yourself some nice plugins! It’s a community driven aggregator of many many great plugins.

The plugin we need now is the nvm plugin. It’s already included in oh-my-zsh and should be activated in your plugins array somewhere in your .zshrc.

But you also want to add the line zstyle ':omz:plugins:nvm' lazy yes, which enables the
lazy-loading mode. This mode defers the load of the nvm plugin and activates the script when using it.
To further optimize your startup you can replace that line with zstyle ':omz:plugins:nvm' autoload yes.
This will only source the plugin in directories that contain a .nvmrc file. So, in conclusion,
add/modify the following in your zsh startup script:

zstyle ':omz:plugins:nvm' lazy yes
# Alternative:
# zstyle ':omz:plugins:nvm' autoload yes
plugins=(
  nvm
  // [...]
)
// [...]

Also, be sure to remove the lines added by nvm, they should be somewhere at the bottom of your script, mine looked like:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Checking fixed startup times

Now, go to any directory that shouldn’t autostart nvm and check your timings again. Mine looked like this:

As you can see above, nvm support takes now much less time to start, while still being available “on-call”.

Done!

Now you can safely remove the debugging lines we introduced to our .zshrc earlier.

Hopefully I could help you a bit with this short post, see you around for the
next one 🙂

Serve your React build locally with nginx through docker

Aron Schüler — Thu, 02 Feb 2023 10:55:03 +0000

Sometimes, there are build differences between your development server and your build outcome. To debug this, you have to somehow host your build outcome locally. This can be done really easy, just mount your build into a nginx container!

Creating the build

As a first step, you have to build and bundle your JavaScript / TypeScript by running the build command. You can find that command in your package.json. For a React App, created with create-react-app this would be react-scripts build, accessible in the most projects over the script build. This script can be executed through e.g. npm run build, depending on your node package manager.

This provides us our static files in /build. We will have to start a container and mount that directory next.

Creating the container

The second step starts a container and mounts the built files as the default served directory. For the default nginx image, this is the path /usr/share/nginx/html, which provides the famous Welcome to nginx! default page.

Mounting our build output into this folder makes nginx serve the build instead of its default pages.

Start the container with the following command from your project root:

docker run -p 8082:80 -v $(pwd)/build:/usr/share/nginx/html nginx

Your built files will be available under port 8082.

Done!

Really easy, wasn’t it? If there’s any feedback, problems, or just a quick “Thanks, works” – be sure to comment below.

Meaningful Sentry issues with react-query + axios

Aron Schüler — Thu, 02 Feb 2023 10:39:26 +0000

One of our products just went live, wohoo! But we are using external backend servers, which are not monitored by us, the frontend development team. To gain more insight into application behaviour, we are monitoring the web app through Sentry. This works well and already provided a lot of informations on legacy issues, such as missing ResizeObserver, clients that use browsers without window.matchMedia and so on.

But one issue really stood out. We were not able to gather anything useful for errors produced by axios. And as we are not able to debug this backend-side, this was a big no-no.

So I went to optimize the way how our errors are handled with react-query, axios and Sentry. Let's have a look!

The initial problem

Like any sane web app, we catch exceptions for requests on a query level using onError and display errors in a toast, so the user knows something went wrong and what they can do about it. Then we pass the exception into Sentry.
Often, we enrich the exception further with informations that might be useful for debugging later, for example, a selected product or what payment provider the user tried to use.

An example would look like:

const { isLoading, error, data } = useQuery({
    queryKey: ['repoData'],
    queryFn: () => myQueryFn(),
    onError: (err) => {
        showAlert({
            text: t("Error.repoData.failed"),
            type: AlertTypes.error,
        });
        withScope((scope) => {
            scope.setTag("section", "repoData");
            captureException(err);
        });
    }

But what if we don't want to do this with every component, what if we have a lot of queries and mutations that should just display a general error and capture the exception afterwards?

Well, that's definitely possible in the defaultOptions while setting up your QueryClient:

  const queryClient = useMemo(
    () =>
      new QueryClient({
        defaultOptions: {
          queries: {
            onError: (err) => {
              captureException(err);
              showAlert();
            },
          },
          mutations: {
            onError: (err) => {
              captureException(err);
              showAlert();
            },
          },
        },
      }),
    [showAlert]
  );

Cool, right? Yeah, well, not really. There are three big issues with this.

Missing information

Both usages of captureException above just brings us the stack trace and the error.response.message in Sentry, so all information we would have on a response with a 500 status would be:

AxiosError: Request failed with status code 500
  at AxiosError(../node_modules/axios/lib/core/AxiosError.js:22:23)
  at settle(../node_modules/axios/lib/core/settle.js:19:16)
  at onloadend(../node_modules/axios/lib/adapters/xhr.js:103:7)

To be fair, in the breadcrumbs you can see what the requests were before that.
But this is not much info either, you can just say what URL the user tried to reach, not what exception occurred or what the request and response looked like.

Missing grouping of issues

Handling exceptions this way will cause the same queries and exceptions to raise new issues. This is because Sentry groups issues by their stack trace and the point in your app where these exceptions were found. This is called "Fingerprinting" in Sentry. You can read more about this here: Fingerprinting Rules in Sentry.

Totally not DRY when using query-level `onError`

If you want to handle certain errors on a query level as well, you will have many places with custom logic that looks like the first example. Using defaultOptions, you cannot configure your queries to share a common onError behaviour and then implement e.g. a custom alert themselves. It is just the default option if no onError callback was defined.

The solution

Now, we are really searching for two things:

Setting up a global captureException, which works even with query-level onError handlers defined
Enriching issues with more informations about the exception

Step 1: Global `captureException` handlers

Instead of capturing exceptions on a query-based level, I discovered the ability to configure error handling on a more global level. This is done by configuring the MutationCache and QueryCache used by your QueryClient. You can set onError handlers for these, which will then trigger always, even when query-level onError handlers are present.
As you have access to the muation or query object there, you can even extract more informations and send them with the exception!

Let's have a look at the new queryClient I came up with:

const queryClient = useMemo(
  () =>
    new QueryClient({
      mutationCache: new MutationCache({
        onError: (err, _variables, _context, mutation) => {
          withScope((scope) => {
            scope.setContext("mutation", {
              mutationId: mutation.mutationId,
              variables: mutation.state.variables,
            });
            if (mutation.options.mutationKey) {
              scope.setFingerprint(
                // Duplicate to prevent modification
                Array.from(mutation.options.mutationKey) as string[]
              );
            }
            captureException(err);
          });
        },
      }),
      queryCache: new QueryCache({
        onError: (err, query) => {
          withScope((scope) => {
            scope.setContext("query", { queryHash: query.queryHash });
            scope.setFingerprint([query.queryHash.replaceAll(/[0-9]/g, "0")]);
            captureException(err);
          });
        },
      }),
      defaultOptions: {
        queries: {
          onError: (err) => {
            showAlert(err);
          },
        },
        mutations: {
          onError: (err) => {
            showAlert(err);
          },
        },
      },
    }),
  [showAlert]
);

We capture exceptions for every query and mutation now and we use scope.setFingerprint to define, what fingerprint the scope has and therefore what the exception will be grouped by. For now, I use the mutationKey or the queryHash for this. Before using the queryHash I strip away all numbers, so that I don't get one issue per query parameter combination.

Step 2: Automatically enriching issues with informations

Sentry provides a really helpful pluggable Integration, ExtraErrorData. This integration automatically extracts data from the given error object in an event and even checks if this error object has a .toJSON() method, which it will call and display all information in the issue page on Sentry.

To set this integration up, you have to install the @sentry/integrations package and add your wanted integration into your Sentry.init call, like so:

import * as Sentry from "@sentry/browser";
import { ExtraErrorData as ExtraErrorDataIntegration } from "@sentry/integrations";

Sentry.init({
  dsn: "https://examplePublicKey@o0.ingest.sentry.io/0",
  integrations: [
    new ExtraErrorDataIntegration(),
  ],
});

This will then display all additional data from your axios error in sentry. Nice!

Done!

Instead of just getting a stack trace and the error message, we now get grouped issues per query/mutation, all data from the axios error and global handling of all errors when using react-query.

I hope this was helpful to you! If not, be sure to leave a comment below, I am happy to investigate your issue as well! 😊

DEV Community: Aron Schüler

Using BuildKit for Container Image Building in GitLab CI And Pushing To ECR

Intro

Step-by-Step Guide

1. Understanding the BuildKit Setup

2. Setting Up the Base Job Configuration

3. Installing and Configuring ECR Authentication

4. Building and Pushing Images with BuildKit

5. Creating Environment-Specific Jobs

6. Required GitLab CI Variables

Conclusion

Implementing Stripe Subscriptions with Firebase Cloud Functions and Firestore

Intro

Step-by-Step Guide

Step 1: Set Up Your Stripe Account

Step 2: Create a Cloud Function that returns Stripe Products and Prices

Step 3: Expose your Stripe Products and Prices to Your Frontend

Step 4: Create a Stripe Checkout Session Cloud Function

Step 5: Connect Your Frontend to Stripe

Step 6: Create a Webhook Handler for Stripe Events

Step 7: Create a Customer Portal Function

Step 8: Retrieve Stripe Subscription Data via Cloud Function

Step 9: Frontend Integration of Stripe Subscription Data and Management

Step 10: Update Firestore Rules

Step 11: Test everything and enable live mode

Conclusion

Publish Playwright Test Reports with GitLab CI/CD Artifacts

Introduction

Step-by-Step Guide

Configure Playwright to Generate HTML Reports

Set Up GitLab CI/CD Pipeline

Code Block for Gitlab CI

Explanation of Gitlab CI configuration

View the Report

Optional: Publish Report with GitLab Pages

Conclusion

Using Cloudflare Workers as a Proxy for Firebase Authentication

Setting Up Cloudflare Workers

Register a Cloudflare Worker

Implementing the Worker to proxy requests to Firebase Authentication

Configure the Cloudflare Worker

Setting Up Your App

Registering the new authorized domain in Firebase Authentication

Changing your firebase configuration

Testing

Conclusion

Fix slow ZSH startup due to NVM

How do I check if just NVM slows my ZSH startup?

How do I fix the slow zsh startup?

Checking fixed startup times

Done!

Serve your React build locally with nginx through docker

Creating the build

Creating the container

Done!

Meaningful Sentry issues with react-query + axios

The initial problem

Missing information

Missing grouping of issues

Totally not DRY when using query-level onError

The solution

Step 1: Global captureException handlers

Step 2: Automatically enriching issues with informations

Done!

Totally not DRY when using query-level `onError`

Step 1: Global `captureException` handlers