Forem: DrPrime01

React CVE Vulnerability Exposed! Check out how to secure your apps now.

DrPrime01 — Sat, 06 Dec 2025 06:58:22 +0000

DrPrime01

Dec 6 '25

Upgrade Your React Apps!!!

#react #nextjs #security #vulnerabilities

Comments 1

2 min read

Upgrade Your React Apps!!!

DrPrime01 — Sat, 06 Dec 2025 06:57:31 +0000

React reported a CVSS 10 vulnerability on December 3, allowing unauthenticated remote code execution in React apps that use React server functions and possibly components. The vulnerability exploits a flaw in how React decodes the payload sent via server-side function endpoints.

The vulnerability affects apps that use React under the hood. The frameworks and bundlers affected include: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

CVSS 10 is the highest critical rating a security flaw can receive, so it's crucial to treat the warning seriously and update all your apps, as the React team has rolled out fixes.

For React Router,

npm install react@latest
npm install react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

For Next apps of version 15 and above,

npm install next@15.0.5   // for 15.0.x
npm install next@15.1.9   // for 15.1.x
npm install next@15.2.6   // for 15.2.x
npm install next@15.3.6   // for 15.3.x
npm install next@15.4.8   // for 15.4.x
npm install next@15.5.7   // for 15.5.x
npm install next@16.0.7   // for 16.0.x

If you use Next.js 14.3.0-canary.77 or a later canary release, downgrade your app to the latest stable update.

npm install next@14

For Redwood SDK of rwsdk>=1.0.0-alpha.0,

npm install rwsdk@latest // for the latest beta version

and upgrade to the latest react-server-dom-webpack,

npm install react@latest react-dom@latest react-server-dom-webpack@latest

For Waku, upgrade to the latest react-server-dom-webpack.

npm install react@latest react-dom@latest react-server-dom-webpack@latest waku@latest

For @vitejs/plugin-rsc, move up to the latest RSC plugin.

npm install react@latest react-dom@latest @vitejs/plugin-rsc@latest

If you use react-server-dom-parcel, react-server-dom-turbopack, or react-server-dom-webpack in any of your applications, update to their latest versions:

npm install react@latest react-dom@latest *

/* * can be react-server-dom-parcel@latest, or react-server-dom-turbopack@latest, or react-server-dom-webpack@latest */

If you see a banner on Vercel pointing out a vulnerability in your deployed app, that is a cue to update.

Read the official React blog for more information about the blog.

Stay safe!!!

CSS `color-mix()` Function

DrPrime01 — Wed, 09 Jul 2025 03:09:42 +0000

The CSS color-mix() function is like an artist’s palette for mixing colours. If you’ve been to a sip-and-paint event, a palette is that little flat plate you’re given to mix your paints in. That’s what the color-mix() function does, but unlike a real-life palette that allows you to merge any amount of different paints, the function is restricted to only two colors in a selected color space.

    .color-1 {
      background-color: red;
    }

    .color-2 {
      background-color: blue;
    }

    .result {
      background-color: color-mix(in srgb, red 50%, blue 50%)
    }

The color-mix() function is defined in the CSS Color Module Level 5 specification.

Syntax

The syntax for the color-mix() function is defined below:

    color-mix() = color-mix( <color-interpolation-method> , [ <color> && <percentage [0,100]>? ]#)

In use, this is what it looks like:

    element {
      color: color-mix(in lch, red 50%, blue 50%);
    }

Arguments

The color-mix() function takes 3 arguments: the <color-interpolation-method>, the 2 colors, and their respective percentages, which can be optional. In cases where the percentage of any of the two colors or both is not specified, the browser subtracts the percentage value of the specified color from 100 and uses it as the default percentage value for the second color. If both percentage values are not specified, it uses 50% for each, because the sum of the respective colors’ percentage values must be 100.

So, what happens if a user specifies 50% for color 1, and 70% for color 2? The function sums the respective percentage value, then divide each color value by the sum and multiply the result by 100 to get a new percentage value.

    color-1 = 50%
    color-2 = 70%

    color-1% + color-2% = 120

    color-1 new % value = 50/120 * 100 = approx. 41.67%
    color-2 new % value = 70/120 * 100 = approx. 58.33%

If you use these new % values for each color, you’ll get the same color result.

The <color-interpolation-method> decides the color space to be adopted in mixing the two colors, and is the color space in which the result is returned. It specifies whether the color interpolation should use a rectangular color space, a polar color space with an optional <hue-interpolation-method>, or a custom color space. The rectangular color space includes: srgb, srgb-linear, display-p3, a98-rgb, prophoto-rgb, rec2020, lab, oklab, xyz, xyz-d50, or xyz-d65, while the polar color space includes: hsl, hwb, lch, or oklch.

    <color-interpolation-method> = in [ <rectangular-color-space> | <polar-color-space> <hue-interpolation-method>? | <custom-color-space> ]

    <hue-interpolation-method> = [ shorter | longer | increasing | decreasing ] hue

    <rectangular-color-space> = srgb | srgb-linear | display-p3 | a98-rgb | prophoto-rgb | rec2020 | lab | oklab | xyz | xyz-d50 | xyz-d65

    <polar-color-space> = hsl | hwb | lch | oklch

    <custom-color-space> = <dashed-ident>

The second and third arguments are the colors and their respective percentages. The colors can be defined in any valid CSS color notation–it could even be a color-mix() function–while their percentages span 0 to 100%.

    <color> = <color-base> | currentColor | <system-color> | 
          <contrast-color()> | <device-cmyk()>  | <light-dark()>

    <color-base> = <hex-color> | <color-function> | <named-color> | <color-mix()> | transparent
    <color-function> = <rgb()> | <rgba()> |
                  <hsl()> | <hsla()> | <hwb()> |
                  <lab()> | <lch()> | <oklab()> | <oklch()> |
                  <color()>

Examples

    /* color-mix(in <polar-color-space>, <color>, <color> <percentage>) */
    element {
      color: color-mix(in hsl, hsl(200 50 80), coral 80%);
    }

    /* color-mix(in <polar-color-space> <hue-interpolation-method>, <color>, <color>) */
    element {
      background-color: color-mix(in lch longer hue, hsl(200deg 50% 80%), coral);
    }

    /* color-mix(in <rectangular-color-space>, <color>, <color>) */
    element {
      color: color-mix(in srgb, plum, #f00);
    }

    /* color-mix(in <rectangular-color-space>, <color> <percentage>, <color> <percentage> */
    element {
      background: color-mix(in lab, plum 60%, #f00 50%);
    }

    /* color-mix(in <custom-color-space>, <color>, <color>) */
    @color-profile --swop5c {
      src: url("https://example.org/SWOP2006_Coated5v2.icc");
    }

    element {
      color: color-mix(in --swop5c, red, blue);
    }

How it works

The color-mix() function converts the hexcode to RGB format, #4a90e2 → rgb(74, 144, 226), and does the calculation thus:

For --lighter: 70% of rgb(74, 144, 226) (your base) and 30% of rgb(255, 255, 255) (white);
For --darker: 70% of rgb(74, 144, 226) (your base) and 30% of rgb(0, 0, 0) (black);

    R = base.R * 0.7 + white.R/black.R * 0.3
    G = base.G * 0.7 + white.G/black.G * 0.3
    B = base.B * 0.7 + white.B/black.B * 0.3

    then, for --lighter:
    R = 74  * 0.7 + 255 * 0.3 = 51.8 + 76.5  = 128.3
    G = 144 * 0.7 + 255 * 0.3 = 100.8 + 76.5 = 177.3
    B = 226 * 0.7 + 255 * 0.3 = 158.2 + 76.5 = 234.7

    and, for --darker:
    R = 74  * 0.7 + 0 * 0.3 = 51.8 + 0  = 51.8
    G = 144 * 0.7 + 0 * 0.3 = 100.8 + 0 = 100.8
    B = 226 * 0.7 + 0 * 0.3 = 158.2 + 0 = 158.2

    results:
    --lighter: rgb(128, 177, 235); --darker: rgb(51.8, 100.8, 158.2)

If you replace any of the RGB values with the results in the color and background-color, you will see no change in the color variation, because they are the same color expressed in the same color space.

Basic usage

One of the simplest features you can achieve with the color-mix() function is a dynamic theme for your website. You can easily create light and dark variants or accent shades of your base color by blending with white or black.

    :root {
      --base: #4a90e2;
      --lighter: color-mix(in srgb, var(--base) 70%, white);
      --darker: color-mix(in srgb, var(--base) 70%, black);
    }

It doesn’t end there. You can add a little bit of alpha to your --base-color by mixing it with the color transparent or white value.

    element {
      color: color-mix(in srgb, var(--base) 70%, transparent);
    }

This is equivalent to the rgba() equivalent of --base with an alpha of 70%

    element {
      color: rgba(74, 144, 226, 70%)
    }

The first div is the white variant, the second div is the dark variant, the third uses rgba(), and the last is the transparent variant. As you can see, the first, third, and fourth all look the same.

Color scheme with `color-mix()`

OKLCH and OKLAB are two interesting color spaces because they offer colors that feel natural to the human eye. They were developed to be perceptually uniform, i.e., to match how the human eye perceive the colors in their environment. OKLCH and OKLAB behave similarly, but their differences lie in their respective orientations. OKLAB lies within the rectangular (or Cartesian) color space, and its colors are defined using x, y, and z coordinates. OKLCH, on the other hand, exists in the polar or cylindrical color space, and its colors are plotted on a cylinder. It is the polar transformation of OKLAB, just as hsl is to rgb. While they have more colors than their hsl and sRGB predecessors, each shine in its respective ways.

One of the several ways OKLCH particularly stands out is when you need to generate a color scheme with adjustable saturation. In generating a color scheme, you need variants of the same color and other colors that work together, and that is where color-mix() comes in.

    :root {
      /* OKLCH Scheme */
      --base: oklch(0.7 0.2 250);

      --primary: var(--base);
      --primary-light: color-mix(in oklch, var(--base) 60%, white);
      --primary-dark: color-mix(in oklch, var(--base) 70%, black);

      --accent: color-mix(in oklch, var(--base) 60%, oklch(0.7 0.3 90));
      --muted: color-mix(in oklch, var(--base) 60%, oklch(0.6 0.1 250));
      --subtle-bg: color-mix(in oklch, white 85%, var(--base));
      --border: color-mix(in oklch, black 10%, var(--base));
      --card-bg: color-mix(in oklch, white 60%, var(--base));
    }

Here, we have a base color mixed with white and black of different percentages to generate a light and dark variant of the base, and other color mixtures for the --accent and --muted custom variables.

If it looks ugly, you’ll have to pardon me. I’m not very good at designs. 😔

Generating gradients with `color-mix()`

I mentioned one of the strengths of OKLCH in the previous section, but what about OKLAB? OKLAB performs well when you need precise color maths for interpolation and when designing gradients.

Interpolation + gradient = color-mix(in oklab, oklab(L A B), oklab(L A B))

    :root {
      --base: oklch(0.7 0.2 250);
       --primary: var(--base);
      ...
      /* OKLAB Gradient */
      --button-hover-gradient: linear-gradient(
        to right,
        color-mix(in oklab, oklab(0.75 -0.1 -0.2) 100%, oklab(0.7 0.25 0.15) 0%),
        color-mix(in oklab, oklab(0.75 -0.1 -0.2) 75%, oklab(0.7 0.25 0.15) 25%),
        color-mix(in oklab, oklab(0.75 -0.1 -0.2) 50%, oklab(0.7 0.25 0.15) 50%),
        color-mix(in oklab, oklab(0.75 -0.1 -0.2) 25%, oklab(0.7 0.25 0.15) 75%),
        color-mix(in oklab, oklab(0.75 -0.1 -0.2) 0%, oklab(0.7 0.25 0.15) 100%)
      );
    }

    .cta-button {
      font-size: 1rem;
      padding: 0.75rem 2rem;
      border: none;
      border-radius: 8px;
      background: var(--primary);
      color: white;
      cursor: pointer;
    }

    .cta-button:hover {
      background: var(--button-hover-gradient);
    }

It’s the “Get Started” button

Browser support

The CSS color-mix() function is supported on all browsers.

References

How to set up Tailwind CSS v4.0 in your Vite App

DrPrime01 — Wed, 30 Apr 2025 11:45:49 +0000

If you're a lover of Tailwind CSS like I am, you must be either excited and/or confused while trying to set up Tailwind CSS v4.0 in your application after the installation. You're not alone. I was also confused about the setup until I read the docs.

This article will guide you on how to set up Tailwind CSS v4 in your Vite application.

Tailwind CSS v4.0

Tailwind CSS v4.0 was released earlier this year, on January 22 precisely, and has sparked a lot of exciting discussions after its release. It is super-optimised and features a new high-performance engine where full builds are 5x faster and incremental builds are 100x faster. It supports built-in imports, requiring no additional tooling to bundle multiple CSS files. Also, the design tokens are now exposed as native CSS, enabling you to access them anywhere––no need for tailwind.config.js file again. And all these are just the tip of the iceberg. Immerse yourself in the full details in the version release blog by Tailwind CSS.

Let's dive into the installation process.

Installation

Installing Tailwind CSS in your Vite app requires just 3 steps:

Install tailwindcss and @tailwindcss/vite via npm.

npm install tailwindcss @tailwindcss/vite

Add the @tailwindcss/vite plugin to your Vite configuration.

import { defineConfig } from 'vite'
import tailwindcss from '@tailwindcss/vite'
export default defineConfig({
  plugins: [
    tailwindcss(),
  ],
})

Use the @import directive to import tailwindcss into your base CSS file––usually index.css.

@import "tailwindcss";

And that's all. You can start using Tailwindcss in your js,jsx,ts,tsx files.

 <h1 class="text-3xl font-bold underline">
    Hello world!
  </h1>

Upgrading from v3 to v4.0

If you've been using Tailwind CSS v3 in your Vite app project and you want to switch to v4.0, it is pretty easy. The first thing you want to do is to review the changes from v3 in the upgrade guide to know what to expect. When you fully understand the changes you will encounter in v4.0, upgrade your node environment to Node.js 20 or higher, then you can proceed with the command below to initiate the upgrade:

npx @tailwindcss/upgrade

The command handles all the heavy lifting while all you need to do to configure your Vite app to use v4.0 is to migrate from the PostCSS plugin to Tailwind CSS's new dedicated Vite plugin for improved performance and the best developer experience.

In your postcss.config.js file, change the content from this:

export default {
  plugins: {
    "tailwindcss": {},
    "autoprefixer": {},
  },
}

to this:

export default {
  plugins: {
    "@tailwindcss/postcss": {},
  },
}

And in your vite.config.js file, add these 2 lines, import tailwindcss from "@tailwindcss/vite"; and tailwindcss() to your file:

import ...
import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";
export default defineConfig({
  plugins: [
    ...,
    tailwindcss(),
  ],
});

Finally, in your index.css file, replace this:

@tailwind base;
@tailwind components;
@tailwind utilities;

with this:

@import "tailwindcss";

And you're good to go.

Browser requirements for v4.0

Tailwind CSS v4.0 includes several modern CSS features like @property and color-mix(), which would not work in old browsers. It was designed for Safari 16.4+, Chrome 111+, and Firefox 128+, so if you need to support older browsers, stick with v3.4 until your browser support requirements change.

Conclusion

That's all! You can start enjoying the goodies of Tailwind CSS v4.0 in your Vite app.

References

What is Display P3?

DrPrime01 — Tue, 29 Apr 2025 15:51:34 +0000

Apple devices, especially the iPad and iPhones, display better colors than many other devices, and unlike what you think, it's not just because of the screen resolution.

You've probably heard about Display P3, or not, and wondered what it means. Display P3 is a wide-gamut color space. It was first defined by Apple in 2005 as part of the Digital Cinema Initiative, for use in theatrical digital motion picture distribution (DCDM). It uses the DCI P3 primaries, a D65 white point, and the sRGB transfer function to provide a wide range of colors a device can accurately capture or reproduce––gamut. It was originally used in the film industry, but later tailored for consumer electronics.

Why Display P3 Matters

The human eye can perceive a vast range of colors within the visible light spectrum, typically between 380 and 780 nanometers. Display P3 offers a richer, more vibrant, and accurate color reproduction, especially in reds, greens, and blues. This means devices with Display P3 will have a more lifelike appearance, especially in areas like HDR movies and gaming.

Apple devices leverage Display P3 to display colors that are closer to what the human eye can perceive. This is not just about screen resolution—higher resolution improves sharpness, but the color space defines how vivid and accurate those colors appear. For example:

Richer Colors: Display P3 covers approximately 25% more colors than sRGB, particularly in reds, greens, and blues, as stated earlier.
Real-World Accuracy: Photos, videos, and graphics in Display P3 devices will appear more natural, especially for content like landscapes or skin tones.
Creative Work: Also, designers, photographers, and video editors can benefit from seeing colors as intended, especially when working on P3-compatible content.

On an iPhone or iPad or any Display P3 device, Display P3 shines in streaming HDR movies, where vibrant colors pop, editing photos in apps like Adope Photoshop or Lightroom, which supports P3, and gaming, where developers optimise visuals for P3's wider gamut to provide a substantially close real-life experience for the gamers.

Technical Details

Gamut: Display P3 has a wider gamut than sRGB, meaning it can represent more saturated colors. It’s still narrower than other advanced color spaces like Rec.2020, but it is a practical middle ground for consumer devices.
Bit Depth: Apple devices often pair Display P3 with 10-bit color depth, allowing for smoother gradients and over a billion possible colors.
Compatibility: Content must be mastered in Display P3 to take full advantage. If you view sRGB content on a P3 display, the colors may look slightly muted unless the device maps them correctly.

Limitations

Content Dependency: Not all apps or media support Display P3, so you might not always see the full benefit.
Battery Impact: Rendering wider color gamuts can consume slightly more power.
Ecosystem Lock-in: While Display P3 is an industry standard, Apple’s implementation is tightly optimised for their hardware and software.

Why Apple Devices Stand out

Apple’s adoption of Display P3, combined with high-quality Retina displays, True Tone technology, and precise color calibration, makes their screens visually superior. It’s not just about pixel count—Display P3 ensures those pixels deliver colors that are vivid yet true to life.

Another mobile device that uses Display P3 is the Google Pixel, but you only get it from the Pixel 8 upwards.

Conclusion

Display P3 is a game-changer for visual quality, making Apple devices like iPhones and iPads stand out for their vibrant, accurate colors. It’s not just about resolution but about delivering a color experience closer to reality. Whether you’re a casual user or a creative professional, Display P3 enhances everything from streaming to photo editing, provided the content supports it.

References

How to Implement WebCam Recording on the Web Using JavaScript

DrPrime01 — Mon, 03 Feb 2025 13:16:30 +0000

Although videoconferencing technologies have existed for decades, they became more popular in 2020 due to the COVID-19 pandemic. Due to the lockdown restrictions, workplaces, public institutions, and even governmental institutions adopted video calls and meetings. Zoom, a popular videoconferencing application, saw a massive user increase during the pandemic and became a household name. Since then, almost every software application built for public and private institutions has had webcam recording as an essential feature.

Webcam recording is a useful software application feature because it is feasible for videoconferencing (as mentioned above), content creation, security (such as biometric authentication), and even monitoring purposes, such as an online exam or patient monitoring in telehealth applications. It is also found in many applications today, including Zoom, Loom, Microsoft Teams, Google Meet, YouTube, Facebook, Instagram, Zendesk, Freshdesk, Teladoc, and Amwell, among many others.

In this article, you’ll learn how to implement webcam recording in a web application using HTML, CSS, and JavaScript, access and use the MediaRecorder API, record and save videos, add audio, and handle multiple videos and audio options.

Prerequisites

Basic understanding of HTML, CSS, and JavaScript
Familiarity with modern web development tools
A development environment (e.g., VS Code, browser console)

Setting Up the Project

Create a Basic HTML Structure

Open your code editor and create an HTML5 boilerplate
Add the necessary elements
- Buttons to start camera, start recording, and stop recording
- Select elements to choose your preferred video and audio devices
- A link to download the video after recording
Add the link tag for the styles in the head section and a script tag for JavaScript in the body element

    <!DOCTYPE html>
    <html lang="en">
      <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Webcam Recording</title>
        <link rel="stylesheet" href="./style.css" />
      </head>
      <body>
        <main class="main">
          <div>
            <h1>Webcam Recording</h1>
            <div class="webcam-container">
              <div class="red-dot"></div>
              <video id="webcam" autoplay muted></video>
              <div><button id="start-camera">Start Camera</button></div>
              <div class="media-devices">
                <select
                  name="video-devices"
                  id="video-devices"
                  class="video-devices"
                >
                  <option>Select video device</option>
                </select>
                <select
                  name="audio-devices"
                  id="audio-devices"
                  class="audio-devices"
                >
                  <option>Select audio device</option>
                </select>
              </div>
              <div>
                <button id="start-record" disabled>Start Recording</button>
                <button id="stop-record" disabled>Stop Recording</button>
              </div>
              <a id="download-link" style="display: none">Download Recording</a>
            </div>
          </div>
        </main>
        <script src="./script.js"></script>
      </body>
    </html>

Styling the Interface

In the CSS file, add the styles that match the elements’ classes
Remember to make them responsive

    * {
      box-sizing: border-box;
      margin: 0;
      padding: 0;
    }
    body {
      width: 100%;
      height: 100%;
    }
    .main {
      min-height: 100vh;
      display: flex;
      flex-direction: column;
      align-items: center;
      padding: 80px 0;
    }
    .main > div {
      display: flex;
      flex-direction: column;
      gap: 20px;
    }
    .main > div > h1 {
      text-align: center;
    }
    .webcam-container {
      min-height: 500px;
      max-width: 340px;
      width: 100%;
      border: 1px solid #cccccc;
      padding: 16px;
      display: flex;
      flex-direction: column;
      gap: 20px;
      position: relative;
    }
    .media-devices {
      display: flex;
      flex-direction: column;
    }
    .red-dot {
      height: 10px;
      width: 10px;
      border-radius: 99999px;
      z-index: 1;
      background-color: red;
      position: absolute;
      right: 28px;
      top: 28px;
      visibility: hidden;
    }
    .show {
      visibility: visible;
    }
    .red-border {
      border: 2px solid red;
    }
    video {
      height: 80%;
      width: 100%;
      border: 1px solid #aaaaaa;
      object-fit: fill;
    }
    select {
      padding: 8px;
      width: 100%;
    }
    button {
      padding: 8px 12px;
      border: 1px solid black;
      background-color: rgba(0, 0, 0, 0.8);
      color: white;
      font-size: 14px;
      font-weight: 500;
      cursor: pointer;
      width: 100%;
    }
    button:hover {
      background-color: rgba(0, 0, 0, 1);
    }
    button:disabled {
      background-color: rgba(0, 0, 0, 0.5);
    }
    .webcam-container > div {
      display: flex;
      align-items: center;
      gap: 12px;
    }
    @media screen and (min-width: 768px) {
      .webcam-container {
        max-width: 700px;
      }
      .media-devices {
        display: flex;
        flex-direction: row;
      }
    }

The `MediaRecorder` and `MediaDevices` API

The MediaRecorder API is an interface of the MediaStream Recording API that allows you to record media using its MediaRecorder() constructor. You can create a MediaRecorder instance using the provided constructor and save it in a variable. The instance will receive a stream from the MediaDevices.getUserMedia() method. From this variable, you’ll have access to the start() and stop() methods to start and stop a recording session, respectively. The MediaRecorder instance also lets you access the stop and dataavailable events which you will see how they are used in the code block.

The MediaDevices API is an interface of the Media Capture and Streams API that allows a user to access connected media devices like cameras and microphones or any hardware source of media data. It provides 5 methods and an event. However, you will need only 2 methods for this project; getUserMedia() to access the user’s media devices and return a media stream, and enumerateDevices() to obtain an array of media device options connected to the system. This will give the user different media device options to stream from.

Implementing the Recording Functionality Step-By-Step

Variable Declarations and Initial Setup

    const videoElement = document.querySelector("#webcam");
    const startButton = document.querySelector("#start-record");
    const startCameraBtn = document.querySelector("#start-camera");
    const stopButton = document.querySelector("#stop-record");
    const downloadLink = document.querySelector("#download-link");
    const videoSelect = document.querySelector("#video-devices");
    const audioSelect = document.querySelector("#audio-devices");
    const redDot = document.querySelector(".red-dot");

    let mediaRecorder;
    let recordedChunks = [];
    let currentStream = null;

This section initializes the DOM elements and variables needed for the webcam recording functionality.

Explanation

videoElement: The HTML <video> element where the webcam stream will be displayed.
startButton, stopButton, startCameraBtn: Buttons to control the recording and camera.
downloadLink: A link element used to download the recorded video.
videoSelect, audioSelect: Dropdowns to select video and audio input devices.
redDot: A visual indicator to show when recording is active.
mediaRecorder: An instance of MediaRecorder for handling the recording.
recordedChunks: An array to store the recorded video chunks.
currentStream: The current media stream from the webcam.

Populating Media Devices

    async function populateDevices() {
      try {
        const devices = await navigator.mediaDevices.enumerateDevices();

        // Clear and populate video devices
        videoSelect.innerHTML = devices
          .filter((device) => device.kind === "videoinput")
          .map(
            (device) =>
              `<option value="${device.deviceId}">${
                device.label || `Video Device ${videoSelect.options.length + 1}`
              }</option>`
          )
          .join("");

        // Clear and populate audio devices
        audioSelect.innerHTML = devices
          .filter((device) => device.kind === "audioinput")
          .map(
            (device) =>
              `<option value="${device.deviceId}">${
                device.label || `Audio Device ${audioSelect.options.length + 1}`
              }</option>`
          )
          .join("");
      } catch (error) {
        console.error("Error accessing devices:", error);
      }
    }

This function retrieves and populates the available video and audio input devices into the respective dropdowns.

Explanation

navigator.mediaDevices.enumerateDevices(): Retrieves a list of available media input and output devices.
filter and map: Filters and maps the devices to create <option> elements for the dropdowns.
device.label: Uses the device label if available, otherwise provides a default label.

Getting Media Stream

    async function getMedia(constraints) {
      try {
        if (currentStream) {
          stopTracks(currentStream);
        }
        currentStream = await navigator.mediaDevices.getUserMedia(constraints);
        videoElement.srcObject = currentStream;
        startButton.disabled = false;
        startCameraBtn.disabled = true;
      } catch (error) {
        console.error("Error accessing media:", error);
      }
    }

This function requests a media stream from the user's webcam and microphone based on the provided constraints.

Explanations

navigator.mediaDevices.getUserMedia(constraints): Requests a media stream with the specified constraints.
videoElement.srcObject = currentStream: Displays the stream in the <video> element.
stopTracks(currentStream): Stops the current stream if it exists before starting a new one.

Stopping Media Tracks

    function stopTracks(stream) {
      stream.getTracks().forEach((track) => track.stop());
    }

Stops all tracks in the given media stream.

Explanations

stream.getTracks(): Retrieves all tracks in the stream.
track.stop(): Stops each track.

Device Selection Handlers

    videoSelect.addEventListener("change", async () => {
      await getMedia({
        video: { deviceId: videoSelect.value },
        audio: { deviceId: audioSelect.value },
      });
    });

    audioSelect.addEventListener("change", async () => {
      await getMedia({
        video: { deviceId: videoSelect.value },
        audio: { deviceId: audioSelect.value },
      });
    });

These event listeners handle changes in the video and audio device dropdowns.

Explanations

When a user selects a different device, the getMedia function is called with the new constraints.

Initial Device Setup

    startCameraBtn.addEventListener("click", async () => {
      await getMedia({
        video: { deviceId: videoSelect.value },
        audio: { deviceId: audioSelect.value },
      });
      populateDevices();
    });

This event listener starts the webcam and populates the device dropdowns when the "Start Camera" button is clicked.

Explanations

Calls getMedia to start the webcam.
Calls populateDevices to refresh the device dropdowns.

Recording Controls

    startButton.addEventListener("click", () => {
      recordedChunks = [];
      mediaRecorder = new MediaRecorder(currentStream, {
        mimeType: "video/webm; codecs=vp9",
      });

      mediaRecorder.ondataavailable = (event) => {
        if (event.data.size > 0) recordedChunks.push(event.data);
      };

      mediaRecorder.start();
      redDot.classList.add("show");
      videoElement.classList.add("red-border");
      startButton.disabled = true;
      stopButton.disabled = false;
    });

This event listener starts the recording when the "Start Record" button is clicked.

Explanations

MediaRecorder(currentStream, { mimeType: "video/webm; codecs=vp9" }): Creates a MediaRecorder instance with the current stream and specified MIME type.
mediaRecorder.ondataavailable: Event listener to collect recorded data chunks.
mediaRecorder.start(): Starts the recording.
Visual indicators (redDot and videoElement border) are updated to show that recording is active.

    stopButton.addEventListener("click", () => {
      if (mediaRecorder?.state === "recording") {
        mediaRecorder.stop();
        redDot.classList.remove("show");
        videoElement.classList.remove("red-border");
        stopButton.disabled = true;
        startButton.disabled = false;
      }

      mediaRecorder.onstop = () => {
        const blob = new Blob(recordedChunks, { type: "video/webm" });
        downloadLink.href = URL.createObjectURL(blob);
        downloadLink.download = `recording-${Date.now()}.webm`;
        downloadLink.style.display = "block";

        // Cleanup
        recordedChunks = [];
      };
    });

This event listener stops the recording when the "Stop Record" button is clicked.

Explanations

mediaRecorder.stop(): Stops the recording.
Visual indicators are updated to show that the recording has stopped.
mediaRecorder.onstop: Event listener to handle the end of the recording, creating a Blob from the recorded chunks and generating a downloadable link.

Cleanup on Window Close

    window.addEventListener("beforeunload", () => {
      if (currentStream) {
        stopTracks(currentStream);
      }
    });

Ensures that the media stream is stopped when the window is closed.

Explanation

stopTracks(currentStream): Stops all tracks in the current stream.

Conclusion

This article provides a complete implementation for webcam recording on the web using JavaScript. It covers device selection, stream management, recording controls, and cleanup, ensuring a smooth and functional user experience.

For a comprehensive list of MediaRecorder and MediaDevices API methods and events, see the MDN documentation.

You can take the project further by adding pause and play and implementing some functionalities and these events.

Live application: https://webcam-recording.vercel.app/
GitHub code: https://github.com/DrPrime01/webcam-recording

Follow me on X @theDocWhoCodes to learn more about what I do and write about.

Cover Photo by ThisIsEngineering

Accessibility in Frontend Development: Building Inclusive Web Experiences

DrPrime01 — Sun, 02 Feb 2025 16:21:51 +0000

In creating a digital product, the product must be accessible to everyone, including people with disabilities. A product, website or mobile application, on the internet, should be created to be equally accessible to the disabled as the able-bodied. Accessibility in a digital product gives a product a larger audience than without it. According to the CDC, one in four adults in the US has some form of disability. As a product that caters for its users' needs unrestrictively, it reaches a wider audience than one with accessibility issues. Also, accessibility improves the user experience of a digital product. When users find it easy to click a button, navigate from one page to another, and perform an action on a product, they become happy, unlike the frustrations that come with squinting their eyes to see the texts on an app for the non-disabled, let alone people with eye disabilities. In summary, the more accessible a digital product is, the more satisfied users are with it, and the larger the product reach, all of which accumulate less stiff competition with companies of similar products.

Accessibility in a digital product aims to provide equal access to the resources the product offers regardless of the bodily conditions of the user. To enforce unrestricted access, the US Access Board developed the Section 508 standards to implement accessibility laws and requirements within ICT. Section 508 ensures that every ICT development is accessible to all and sundry, and people with disabilities can achieve the same feat on a product as an able-bodied person. The Section 508 standard is further supported by the Americans With Disabilities Act of 1990, which emphasises equal access to people with disabilities within public institutions (schools, hospitals, etc) and internet-based assets. To ensure the enforcement of these regulations within internet-based applications, the World Wide Web Consortium, W3C, developed the web standards for accessibility outlined in the Web Content Accessibility Guidelines, WCAG. Together, these standards and guidelines enforce equal access and interaction with the content of digital products.

The centrepiece of accessibility implementation on the internet is the client-side interface the user will interact with. Accessible frontend development ensures that individuals with varying abilities can access, interact, understand, and engage the web content, irrespective of their approach method. As a frontend developer, you’re tasked with enforcing accessibility standards in your applications, ensuring equal access and a profound user experience across the board. This article exposes common accessibility pitfalls in frontend development and how to avoid them, implementing ARIA attributes effectively in your application, and creating inclusive user interfaces for people with disabilities, among other accessibility issues and their solutions in frontend development.

Common Accessibility Pitfalls and How to Avoid Them

Let us explore some common accessibility pitfalls you might overlook as a frontend developer and their solutions.

Inadequate Keyboard Navigation

Recent web applications are designed and developed with a mouse navigation system as their default, neglecting users who depend partly or solely on keyboard navigation. People with motor and visual impairments heavily rely on their keyboard for website navigation. Without keyboard navigation, they face significant limitations. Besides disabled users, some prefer keyboard shortcuts to move a cursor about on the screen. These people are not left out of the limitations.

Solutions

Make all interactive elements keyboard accessible.
Implement a logical tab order.
Provide visible focus indicators.

Poor Color Contrast

While aesthetics matters in the design of a website, the readability of the website content is also of paramount importance. Information is conveyed to the website users primarily through texts and illustrations. If the texts are then hidden in colours by a poor design choice, the website may end up resembling an art gallery of digital illustrations.

Solutions

Design for colour blindness.
Apply colour contrast in the appropriate ratios, 4.5:1 for normal texts and 3:1 for large texts.
Use tools like WebAIM Contrast Checker to check and select accessible colour combinations.

Missing Alternative Text for Images

An image element alt text helps search engine crawlers index and rank an image properly by serving as the image description. Aside from its SEO usefulness, the alt attribute in images is essential for providing context to screen readers. Therefore, it's important to ensure that the text in the alt attribute is descriptive enough to paint a picture for visually impaired individuals accessing the website.

Solutions

Always use descriptive alt text.
For decorative images, use an empty alt attribute alt="".
In case of an image that requires an extensive description, say an infographic, provide a detailed description in the texts after the image.

Inaccessible Forms

Forms are a way of communication between a user and a website, but a communication barrier can exist between both parties when the form is poorly integrated. Poor form integrations may include a lack of labels, descriptive placeholders, or clear CAPTCHA systems, as well as inadequate error handling.

Solutions

Label form elements properly.
In the absence of labels, use descriptive placeholders.
Handle errors and form validation adequately.
Provide clear instructions and feedback through toasts or modals.
Use visual CAPTCHA alternatives, like audio. This will help the visually impaired.
Use ARIA attributes to improve form accessibility for screen readers.

Non-Responsive Design

According to Research.com, 50.48% of web traffic came from mobile devices while the rest was distributed between desktop and tablet screens. Also, since 2020, mobile visits to a website have been 81% higher than desktop visits (Semrush, 2024). Over the years, various mobile phone companies have produced and sold different mobile screen designs. In summary, websites receive more visits from various mobile screen designs than desktops, necessitating responsive design and development of web applications by frontend developers. Developers who resist this change have forced users to zoom in and out of their devices to access website content, resulting in a frustrating experience.

Solutions

Implement responsive designs across all screen sizes and orientations.
It’s easier to implement responsive designs with recent CSS layouts such as Flexbox and Grid. Use them.
Implement techniques for responsive typography such as CSS Clamp.
Test your web application across several devices screens and screen readers.

Implementing ARIA Attributes Effectively

Accessible Rich Internet Applications (ARIA) is a set of roles and attributes that define ways to make web content and web applications more accessible to people with disabilities (MDN). It helps to represent or replicate features of a semantic element widget in assistive technology devices.
As an accessibility-first developer, you can make the mistake of setting ARIA attributes to almost all HTML elements. This can be unnecessary as modern browsers now support HTML widget elements. These widget elements have built-in keyboard accessibility, roles, and states and should always be selected over using ARIA in all HTML elements.

For instance, take a look at this meter widget,

<meter value="2" min="0" max="10"></meter> <!-- Shows value on a scale -->

It is already meaningful in its present state, even to an assistive technology device. If unaware of its existence, you might be tempted to convert a regular div to a meter widget by setting roles and attributes with ARIA.

    <div id="meter"
      role="meterbar"
      aria-valuenow="2"
      aria-valuemin="0"
      aria-valuemax="10">
    </div>

Therefore, ARIA should only be used when a semantic HTML widget does not exist for the component you’re trying to build.

Common ARIA Attributes and Their Usage

ARIA attributes help modify the state and properties of an element as defined in the accessibility tree. It only modifies how assistive technologies render the element to your users but does not affect the function and behaviour.
ARIA states and roles fall into 4 categories: widget, live region, drag-and-drop, and relationship attributes. While these attributes are specific to their defined functions, ARIA has a list of general attributes applicable to all HTML elements.
Let’s take a look at some of the commonly used ARIA attributes.

aria-label: The aria-label attribute defines a string that adds more meaningful information to an interactive element. Some interactive elements can be poorly described because no attributes define their use. In this case, aria-label adds context to the element’s purpose
aria-hidden: The aria-hidden state tells if an element is exposed to an accessibility API. Some elements can be purely for decorative purposes and have no specific semantic meaning. By setting aria-hidden to those elements, the accessibility API is freed from displaying them in assistive technology devices. However, it is important to note that this attribute should not be on a focusable element, its parents or ancestors.
aria-expanded: The aria-expanded property serves as an indicator of the control state of an element, if it is expanded or collapsed. It is usually used in button elements that control a widget, menu widget, combobox widget, and other collapsible elements.
aria-controls: This property is used on an element to identify the element (or elements) it controls.

For a comprehensive list of common and less-popular ARIA attributes, visit MDN.

ARIA Roles and When to Use Them

ARIA roles describe elements that do not natively exist in HTML or exist without full browser support. ARIA roles provide semantic meaning to these HTML elements, allowing assistive technology devices to replicate the expected element interaction in a way that aligns with the user’s expectations of the object.
ARIA roles fall into 6 categories,

Document structure roles: ARIA roles in this category provide structural descriptions for native HTML elements. Many semantic HTML elements have ARIA roles by default, but when using a generic element to create an object, you must pass a role to it. Document structure role provides assistive technologies more information about the document structure of the element. Some examples include toolbar, tooltip, feed, math, note, presentation, and more.
Widget roles: Similar to document structure roles, it is used to provide descriptions, but in this case, for interactive patterns. Widget roles often require JavaScript for interaction. Combobox, menu, menubar, tab, switch, and scrollbar are a few examples of widget roles. > NB: There is a role named “widget” but it does not fall into the widget role category.
Landmark roles: These roles help to identify the organization of a web page. Assistive technologies like screen readers use these landmark roles for keyboard navigation to sections of the app. Some of these roles are banner, contentinfo, form, main, etc.
Live region roles: These roles define elements whose content changes dynamically. It is particularly useful for low-vision and blind users as it helps them know if an element's content has changed. Alert, log, marquee, status, and timer are the available live region roles.
Window roles: Roles in this category define sub-windows within the main content window. For example, dialogs and modals create a sub-window, and these roles help to announce them in screen readers. Alertdialog and dialog are window roles.
Abstract roles: Unlike other roles listed above, roles in this category are intended for use by the browser only and not for developers. The widget role falls in this category together with command, composite, input, landmark, range, etc.

See more ARIA roles and their uses here.

Best Practices for ARIA Implementation

Various ARIA roles can help to make your website more accessible, but not all of them are essential. This is because many of these ARIA roles are already covered by semantic HTML elements. For example, some roles in the document structure category and all in the landmark category have corresponding semantic HTML elements supported by browsers. Therefore, instead of adding ARIA roles to every element, it's important to check if a semantic HTML equivalent exists.
Also, it's crucial to test ARIA implementations with screen readers to ensure they convey the intended information without confusing users. And finally, refrain from using abstract roles in your app. They are, as stated, for browsers only.

Conclusion

Accessibility is an essential factor to consider when building software applications. It ensures that your app does not restrict users, regardless of disability. As a frontend developer, it is important to enforce accessibility in all your applications, whether small, medium, or large. In this way, your app will serve its purpose without issues, and your users will be satisfied.

Follow me on X @theDocWhoCodes to learn more about what I do and write about.

Cover Photo by fauxels

From ETL to ELT: The Evolution of Data Engineering and the Rise of AirByte

DrPrime01 — Fri, 31 Jan 2025 15:46:13 +0000

Data engineering has exponentially grown over the years due to huge changes in technological advancement, explosion of data volumes, and real-time insight needs by data companies. Data engineering involves designing, building, and maintaining systems that collect store, and analyze data into structures suitable for building analytics solutions. It has existed as far back as the 90s but as a subset of the emerging data technologies and techniques in the analytics landscape. However, with the rise of Artificial Intelligence and Machine learning, the forerunner industry of data analytics and structuring—data engineering—became an independent concept and role for the data industry. This article explores the evolution of data engineering, the shift in the traditional approaches over the years, and the critical role ELT (Extract, Load, Transform) tools, particularly AirByte, play in the modern data ecosystem.

The Early Days of Data Engineering

The primary focus of data engineering in the early days was on building data warehouses using ETL (Extract, Transform, Load) processes. ETL consists of 3 steps of data processing:

Extract: Data is gathered and extracted from different sources.
Transform: The gathered data is processed and transformed into a standardised format. This includes sorting, filtering, aggregating, enrichment, joining, cleaning, validating, and other processes to fit the data to its purpose.
Load: The transformed data is loaded into a designated data store, usually a warehouse or repository.

Data engineers were responsible for extracting data from several sources, transforming it into the desired format, and loading it into a data warehouse. The transformation work in ETL is done in a dedicated engine. It often involves using staging tables to temporarily store data while it is being processed and then loaded to its destination. The strength of ETL lies in its ability to process data from smaller sources and complex transformation. It separates the concerns of the target system from data transformation. It is an excellent choice where data security is paramount, as it can encrypt sensitive data during its transformation process before it lands in the target location—the warehouse or repository.
ETL tools have made data ingesting to a warehouse for analytics possible. However, due to its drawbacks, it is not ideal for high-volume data operations or long-term data projects. Traditional ETL tools do not store data but move new data from a source to a new location, thereby requiring a central repository, which is paid for. Depending on the size of your data and how much it increases with time, your store budget can rise exponentially, burning a hole in your purse. Also, it can be hard to scale the ETL process as your data grows, making it expensive and time-consuming, especially if you need to update or change your system architecture. Batch processing, one of the data analytics processes, also exists as a challenge of ETL tools. Processing batch data with ETL tools causes time lags between data extraction and availability. As a result, you won’t have access to real-time data insights, preventing you from making timely business decisions. Another challenge of ETL tools is their complexity and learning curve. Although there are low-code tools, low-code developers and non-technical users cannot easily start a project as they require a knowledge of programming, data engineering, and ongoing maintenance.

The Shift to Modern Data Engineering

Data volume growth reduced the feasibility of traditional ETL approaches due to scalability issues. The advent of big data technologies, such as Apache Hadoop and Apache Spark, allowed data engineers to process massive datasets in a distributed manner. This led to adjusting the ETL data processing approach from a one-by-one method to parallel processing. For instance, while data extraction is ongoing, the transformation process could be performed on already extracted data, and processed data are loaded, all running concurrently. ETL parallel processing significantly improved the efficiency of handling large datasets, notwithstanding, it was not enough. More businesses began to demand real-time insights, leading to the adoption of stream processing technologies like Apache Kafka and Apache Flink. This shift required data engineers to build more flexible and responsive data pipelines and storage systems. One of these storage systems is the cloud.
The adoption of the cloud revolutionized data engineering by offering scalable storage and computing power, which relieved the load of traditional data pipelines. Cloud platforms like AWS, Google Cloud, and Azure introduced managed services that reduced the burden on data teams, enabling them to focus more on data transformation and analysis. As cloud computing developed and data warehouse technologies became more complex, the data processing ecosystem gave rise to the ELT (Extract, Load, Transform) paradigm.

The Emergence of ELT Tools

The shift towards ELT architecture led to specialized tools and platforms to streamline data integration. Companies like Fivetran, Stitch, and Airbyte became leading suppliers of ELT solutions, offering prebuilt-performed connectors and automated data pipelines. These newer tools have simplified connecting data sources to cloud data warehouses, making the ELT more possible for organizations of all sizes.
Compared to ETL, ELT only reverses the latter two steps: data from several sources is loaded directly into a data warehouse or lake before being transformed. Within the ELT pipeline, transformations are executed inside the target data store using its native processing capabilities without depending on a dedicated transformation engine. ELT offers more solutions than ETL in terms of flexibility, scalability, efficiency, reduced latency, and storage processing.
Using ELT tools, data can be loaded in its raw form and transformed as needed, making it easier to adapt to changing business requirements. It gives businesses an edge when making decisions as they don’t have to worry about transformation logic until later. Leveraging the cloud for transformation, ELT tools are faster and more scalable. ELT takes advantage of the cloud data warehouse's key features such as Massive Parallel Processing (MPP), elastic computing, separation of storage and computing, and built-in optimization, pools them together, and coordinates them easily to handle complex transformations at scale. By deferring transformation, ELT can reduce the time it takes to make data available for analysis, making it efficient and effective for fast decision-making. Also, ELT is better suited for handling any data type—unstructured, semi-structured, and structured, allowing you to focus on more important details during transformation rather than data structure. In addition, it is cost-effective, tapping the cloud pay-as-you-go model, has a faster initial data loading and availability, and offers a simplified architecture by removing the need for intermediate transformation layers.
The ELT paradigm has been particularly valuable in organizations with large volumes and diversified data types, where rapid access to raw data is necessary for different analytics purposes. As cloud data warehouses evolve, ELT’s contributions towards modern data architecture have become central to effective data management strategy.

AirByte: A Key Player in ELT

AirByte is an open-source ELT tool that focuses on making data integration easy and accessible. Its community-driven approach and the importance of open-source contributions have been pivotal to its growth, enabling the rapid development of new features and connectors. It supports numerous connectors, allowing data engineers to move data from various sources to destinations quickly. AirByte’s open-source nature enables users to create custom connectors, making it highly adaptable to unique business needs.
AirByte stands out due to its flexibility and community-driven development. It also offers scalability, customizability, and ease of use.

Scalability: Leveraging its cloud infrastructures to handle large data volumes, AirByte ensures smooth scalability as the business grows.
Customizability: Users can customize existing connectors or build and contribute their own, making AirByte suitable for integrating less common data sources. You can also choose AirByte’s cloud for your organization, an external cloud storage facility, or even a self-hosted cloud option.
Ease of Use: AirByte's user-friendly interface and wide array of pre-built connectors simplify data integration for engineers and non-technical users.

Unlike traditional proprietary tools, Airbyte is open-source, enabling organizations to inspect, modify, and contribute to its codebase for optimal transparency and community-based development. Airbyte's power emanates from having a rich library with over 300 pre-built connectors, ranging from common databases and cloud services to specialized business applications. It considerably reduces engineering effort in setting up data pipelines since it handles all complexities from the extraction of data up to loading. Airbyte is designed to support real-time synchronization, incremental updates, and automatic schema detection, making it adaptive to changing data structures.

The Modern Data Stack

The modern data stack represents a paradigm shift in rethinking data architecture: modularity, scalability, and tool specialization. This has changed the game for organizations, enabling them to rethink how they handle their data pipeline needs by moving away from monolithic solutions to a flexible and maintainable architecture.

Separation of Concerns

The evolution of data engineering does not end at the switch from ETL to ELT tools. Rather, it has led to the modern data stack, where extraction, loading, and transformation are separated into distinct layers. Airbyte, as an ELT tool, takes care of the general movement of data, enabling other tools like dbt to focus on the necessary transformation step to get the data analytics-ready. This separation means that organizations can:

Choose best-in-class tools for each function
Scale different components independently
Maintain and update components without affecting others
Reduce complexity by using specialized tooling
Allow various teams to work side-by-side on different aspects of the pipeline

Data Lakes and Warehouses

Data Lake and Data Warehouse integration allows organizations to store their raw and transformed data within a common architecture, thus allowing Data Science and Business Intelligence use cases. Airbyte plays a key role in populating these data lakes and warehouses with raw data from several sources. This hybrid approach offers:

Flexibility in terms of structured and unstructured data storage
Low-cost storage of history data
Support for various analytical workloads
Better Data Discovery and Governance
Ability to serve multiple personas of users: data scientists, analysts, business users

Orchestration and Governance

Modern data stacks require a complex orchestration to manage data flow from one component to another. These coordinations or orchestrations are performed with tools like Apache Airflow or Dagster by:

Pipeline scheduling and dependencies
Error handling and monitoring
Data quality checks
Resource allocation
Workflow management

Data Quality and Testing

For modern stack, the emphasis is on data quality in the following ways:

Automated Testing of Transformations
Data validation at multiple stages
Data freshness and completeness monitoring
Documentation of data lineage
Implementation of data quality frameworks

Analytics and Business Intelligence

The last layer of the modern data stack focuses on making data accessible to end-users through self-service analytics platforms, interactive dashboards, machine learning models, ad-hoc query capabilities, and automatic reporting systems. This modular approach to data infrastructure has democratized access to sophisticated data processing, enabling even the smallest organizations to build robust and scalable data platforms that grow with their needs.

The Future of Data Engineering

In the times of ETL, low-code, no-code, and non-technical developers due to a certain level of required programming knowledge to kickstart a project. This changed with ELT tools, especially AirByte which provides an easy-to-use interface that allows non-technical users to build or customize a data pipeline. The future of data engineering promises low-code and no-code developers pre-built templates for common data workflows, automated code generation for custom requirements, simplified debugging and monitoring tools, visual pipeline builders replacing complex coding requirements, and more.
Data quality and governance are gaining more attention as data becomes increasingly critical to businesses’ decision-making and AI/ML. Integrating AI/ML into data engineering transforms how we handle, process, and maintain data pipelines. AI and ML are transforming data engineering into predictable self-healing pipelines, leveraging predictive maintenance to detect or foresee failures before they occur. On the subject of data quality, this includes AI-driven anomaly detection to ensure data reliability, and intelligent metadata management to enable automation of cataloguing and lineage tracking. For businesses, Airbyte's roadmap includes features to ensure data accuracy, compliance, and lineage for operating in regulated industries.

Conclusion

Data engineering has incrementally moved from rigid, batch-oriented ETL to flexible, cloud-based ELT pipelines. AirByte positions itself at this forefront of change by providing the means of building scalable, elastic, real-time data pipes with much ease. As data engineering evolves continuously, it will increasingly focus on automation, quality, and making data engineering accessible to a broader audience.
See the documentation to learn more about setting up data integrations using AirByte. You can also join the community to stay updated on the latest data engineering changes.

Check out my recently released project and how I came about it! I created a Wrapped (2024 Unwrapped) for Dev.to. You can use it to see your stats for the year.

DrPrime01 — Sat, 28 Dec 2024 20:43:18 +0000

I created a Wrapped for Dev.to

DrPrime01 ・ Dec 26

#discuss #opensource #productivity #webdev

I created a Wrapped for Dev.to

DrPrime01 — Thu, 26 Dec 2024 22:37:29 +0000

Looking at several wrapped from my Spotify to my friends' YouTube Music and the designers' Figma, and also inspired by a community member's Hashnode Wrapped'24 project, I decided to create a wrapped for Dev.to so my fellow technical writers could see how they performed this year.
Read through this piece to learn how I did it.

The Birth of Dev.to Wrapped

As an active of ArticleStreak, a WhatsApp community for technical writers, I decided to drop one more project before the year runs out that aligns with the theme of the community—a wrapped. A group member already created one for Hashnode, but not everyone uses Hashnode so some people were left out. That was where I came in. Straight to ChatGPT, "I want to create a Dev.to wrapped. How do I get an API with every Dev.to users' stats?" That was the prompt that helped me find out about https://dev.to/api. I should have known, but you can't know all and that's why you research.

The Building Process (or its Summary)

I played around the settings page on the Dev.to website and found the OpenAPI docs. That was all I needed. I wanted a Wrapped that consisted of the articles published for the year, number of comments and reactions, and the number of views, but I couldn't get the last stat because the API currently doesn't allow users OAuth to access information as such. Perhaps in the future, it'll be added.

In Conclusion

To cut the long story short, I created a React application with Vite and joined the pieces together to beget this: Dev.to Wrapped. You'll have to forgive my simple design for I'm not a good designer.

You can contribute to the project here: https://github.com/DrPrime01/dev-to-wrapped and give the repo a star 🌟.

Thanks for reading this short story. I'm Dr Prime.

How to Validate File Inputs in TypeScript with Zod

DrPrime01 — Fri, 01 Nov 2024 05:06:55 +0000

Form validation is an essential aspect of web development. It plays a crucial role in maintaining an application’s security and integrity. Forms are one of the exposed parts of an application because they accept external inputs from users. Through these external form inputs, malicious users or attackers can enter malicious scripts or files that can destroy the integrity of your application and access your users' private data.
Although text-based inputs are the primary targets for attackers attempting to inject malicious scripts into an application, file inputs—not directly vulnerable to script injections—are the most disguised point of entry and are less common. Attackers can use file uploads to embed malicious scripts in ways that are not immediately obvious.
Form validation is a way of preventing these malicious scripts in your application. Zod is a schema validation library for JavaScript and TypeScript that helps enforce data structures and validate inputs. Unlike typical validation libraries, Zod integrates seamlessly with TypeScript, providing strong type safety at runtime. In this article, you’ll learn how to validate your file inputs with Zod, a schema validation library for TypeScript/JavaScript.

Zod’s Overview

Zod is a TypeScript-first schema declaration and validation library that mimics TypeScript’s strong static typing. It allows you to enforce type safety at runtime, making it an excellent choice for TypeScript developers who want strong typing and reliable validation without compromising either.
Zod provides a powerful and flexible way to define schemas for your data structures. Its schema’s syntax is straightforward and you only need to use the ‘z’ object imported from ‘zod’. The ‘z’ object includes methods for various data types such as:


import { z } from "zod";

// Basic primitive schemas
const stringSchema = z.string();
const numberSchema = z.number();
const booleanSchema = z.boolean();
const dateSchema = z.date();
const undefinedSchema = z.undefined();
const nullSchema = z.null();

// Object Schema
const userSchema = z.object({
  name: z.string(),
  age: z.number().int(), //built-in method: Only allows integers
  email: z.string().email(), //built-in method: Validates email format
});

// Array schema
const stringArraySchema = z.array(z.string());

// Optional and Nullable types
const userSchema = z.object({
  name: z.string(),
  age: z.number().int().optional(), // age is optional
  email: z.string().email().nullable(), // email can be null
});

Project Setup

For this article, you need two dependencies: React and Zod. Create a Typescript variant of a React application with Vite and install Zod.

// create react app with vite
npm create vite@latest file-input-validation -- --template react-ts
cd file-input-validation
npm install

// install zod
npm install zod

After running the above command in your terminal, open the file-input-validation directory in your code editor, and run npm run dev to kickstart the application in localhost.
Now that your application is running successfully, delete the App.css file, clear out the App.tsx and index.css files, and replace the former with the code block below.
As for the styles, see it here.


// App.tsx

/* eslint-disable @typescript-eslint/no-explicit-any */
import { DOCUMENT_SCHEMA, IMAGE_SCHEMA } from "./utils/schema";
import { useState, useEffect } from "react";
interface ErrorType {
  img_upload?: string;
  doc_upload?: string;
}
function App() {
  const [docFile, setDocFile] = useState<File | undefined>();
  const [imgFile, setImgFile] = useState<File | undefined>();
  const [imgUrl, setImgUrl] = useState("");
  const [error, setError] = useState<ErrorType>({});
  useEffect(() => {
    if (imgFile) {
      const url = URL.createObjectURL(imgFile);
      setImgUrl(url);
      return () => URL.revokeObjectURL(url);
    }
  }, [imgFile]);

  const handleDocChange = (e: React.ChangeEvent<HTMLInputElement>) => {

  };
  const handleImgChange = (e: React.ChangeEvent<HTMLInputElement>) => {

  };
  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();

  };
  return (
    <div className="app-container">
      <h1>File Input Validation with Zod</h1>
      <div className="form-container">
        <form className="form" onSubmit={handleSubmit}>
          <div className="formfield">
            <label htmlFor="doc-input">
              <p>Document Input</p>
              <div className="doc-label">
                {docFile?.name ? (
                  <p>{docFile?.name}</p>
                ) : (
                  <p>
                    <span>Browse</span> to upload document here{" "}
                  </p>
                )}
                <p className="size">(5MB Max)</p>
              </div>
            </label>
            <input
              id="doc-input"
              name="doc_upload"
              type="file"
              onChange={handleDocChange}
              accept="application/*"
            />
            {error.doc_upload && <p className="error">{error.doc_upload}</p>}
          </div>
          <div className="formfield">
            <label htmlFor="img-input">
              <p>Image Input</p>
              <div className="image-label">
                {imgUrl ? (
                  <img src={imgUrl} alt="img-input" />
                ) : (
                  <div>
                    <p>
                      <span>Browse</span> to upload image here{" "}
                    </p>
                    <p className="size">(5MB Max)</p>
                  </div>
                )}
              </div>
            </label>
            <input
              id="img-input"
              name="img_upload"
              type="file"
              accept="image/*"
              onChange={handleImgChange}
            />
            {error.img_upload && <p className="error">{error.img_upload}</p>}
          </div>
          <button
            type="submit"
            disabled={
              !!error.doc_upload || !!error.img_upload || !docFile || !imgFile
            }
          >
            Submit
          </button>
        </form>
      </div>
    </div>
  );
}
export default App;

For now, leave the functions empty. You’ll fill them up later as you proceed.

Validating File Inputs

The HTML file element allows any file type including video, audio, image, and documents. When defining your file inputs, you can dictate the file types it should receive using the accept attribute—perhaps only image files or a combination of video and audio files. The accept attribute takes a string value of any valid unique file type identifier and prevents the file input from accepting any file with a type not corresponding to the specified type identifier. Using the accept attribute, you can restrict file types to exclude dangerous formats like executable files (.exe), scripts (.js), and macro-enabled documents (.docm).

File Type Validation

With Zod, you can also define the file types your input should accept as an extra layer of security. In your App.tsx file are two file inputs—one for images and the other for documents, and you’ll write a Zod schema to validate each with the instanceof and refine methods.


import { z } from "zod";

// Document Schema
export const DOCUMENT_SCHEMA = z
  .instanceof(File)
  .refine(
    (file) =>
      [
        "application/pdf",
        "application/vnd.ms-excel",
        "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
      ].includes(file.type),
    { message: "Invalid document file type" }
  );

// Image Schema
export const IMAGE_SCHEMA = z
  .instanceof(File)
  .refine(
    (file) =>
      [
        "image/png",
        "image/jpeg",
        "image/jpg",
        "image/svg+xml",
        "image/gif",
      ].includes(file.type),
    { message: "Invalid image file type" }
  );

The instanceof method checks if a value is an instance of a specific class. In this case, both schemas check if the value is of the TypeScript File class. The refine method allows you to define custom validation logic. It takes 2 arguments—a callback function expected to return a false value for a failed validation check and an object for passing customisable options for error-handling behaviours.
Zod takes in the File value and checks the type with the types listed in the array. If the file type is in the array, the file passes the validation. If not, Zod sends the error message.

File Size Validation

Besides the file type validation, you can augment the schema to validate the file size using the refine method again.


import { z } from "zod";
const fileSizeLimit = 5 * 1024 * 1024; // 5MB

// Document Schema
export const DOCUMENT_SCHEMA = z
  .instanceof(File)
  .refine(
    (file) =>
      [
        "application/pdf",
        "application/vnd.ms-excel",
        "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
      ].includes(file.type),
    { message: "Invalid document file type" }
  )
  .refine((file) => file.size <= fileSizeLimit, {
    message: "File size should not exceed 5MB",
  });

// Image Schema
export const IMAGE_SCHEMA = z
  .instanceof(File)
  .refine(
    (file) =>
      [
        "image/png",
        "image/jpeg",
        "image/jpg",
        "image/svg+xml",
        "image/gif",
      ].includes(file.type),
    { message: "Invalid image file type" }
  )
  .refine((file) => file.size <= fileSizeLimit, {
    message: "File size should not exceed 5MB",
  });

Just like the file type is checked with the refine method, the same method is used to check the file size by comparing it with the fileSizeLimit defined in the code block above. If the file size is over the limit, Zod returns the defined error message.
In this way, you have coupled two validation checks in one schema to validate the file type and size.

Frontend Validation with Zod Schemas

The schemas are useless unless integrated with the form that provides the values to be validated. In the App.tsx file, there are undefined functions, and you will define them in this section.
First and foremost, import your schemas into the App.tsx file, then define the validation functions.


import { DOCUMENT_SCHEMA, IMAGE_SCHEMA } from "./utils/schema";

const validateFile = (file: File, schema: any, field: keyof ErrorType) => {
    const result = schema.safeParse(file);
    if (!result.success) {
      setError((prevError) => ({
        ...prevError,
        [field]: result.error.errors[0].message,
      }));
      return false;
    } else {
      setError((prevError) => ({
        ...prevError,
        [field]: undefined,
      }));
      return true;
    }
  };
  const handleDocChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (file) {
      const isValid = validateFile(file, DOCUMENT_SCHEMA, "doc_upload");
      if (isValid) setDocFile(file);
    }
  };
  const handleImgChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (file) {
      const isValid = validateFile(file, IMAGE_SCHEMA, "img_upload");
      if (isValid) setImgFile(file);
    }
  };

The validateFile function takes 3 arguments—the file, the schema, and the field. The schema safeParse’s the file and the result is stored in the result variable. If the parse is unsuccessful, the function updates the field of the failed input in the error state with the error message Zod returns and the function returns false. If successful, the field is set to undefined in the error state and the function returns true. By using the Zod safeParse method, you allow your application to fail gracefully, preventing Zod from throwing errors, which could be a bad user experience.
handleDocChange and handleImgChange are the functions you pass to the doc_upload and img_upload inputs respectively. The functions monitor the files uploaded to their respective input files and run the validateFile function on them, storing the response in the isValid variable. If the variable is true, the functions update their respective states with the files.
Finally, the error state helps to store the error information about each input field. This information is displayed in the <p> tag below each input field whenever any error state object property contains an error which corresponds to it.

Handling Multiple Files

By adding the multiple attribute to your input element, you can select and upload multiple files at once. With Zod, you can write a validation schema for a FileList which is as easy as doing the same for a File.


const fileSizeLimit = 5 * 1024 * 1024; // 5MB

export const fileUploadSchema = z.object({
  files: z
    .instanceof(FileList)
    .refine((list) => list.length > 0, "No files selected")
    .refine((list) => list.length <= 5, "Maximum 5 files allowed")
    .transform((list) => Array.from(list))
    .refine(
      (files) => {
        const allowedTypes: { [key: string]: boolean } = {
          "image/jpeg": true,
          "image/png": true,
          "application/pdf": true,
          "application/msword": true,
          "application/vnd.openxmlformats-officedocument.wordprocessingml.document":
            true,
        };
        return files.every((file) => allowedTypes[file.type]);
      },
      { message: "Invalid file type. Allowed types: JPG, PNG, PDF, DOC, DOCX" }
    )
    .refine(
      (files) => {
        return files.every((file) => file.size <= fileSizeLimit);
      },
      {
        message: "File size should not exceed 5MB",
      }
    ),
});

There are two new Zod methods in this schema—object and transform. The object method allows you to define a validation schema for an object and each property of the object. The transform method allows you to convert a value from one form to the other. In this case, the FileList is converted to an array for easier manipulation.
With this schema defined, you can integrate it with your application’s form input elements as in the previous section.


const handleFileChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  const selectedFiles = e.target.files;
  if (!selectedFiles) return;
  const result = fileUploadSchema.safeParse({ files: selectedFiles });
  if (result.success) {
    setFiles(result.data.files);
    setError(null);
  } else {
    setError(result.error.errors[0].message);
    setFiles([]);
  }
};

Preventing Security Risks and Handling Edge Cases

One of the main purposes of file validation is to secure your application against potential security risks that could include uploading some malicious scripts hidden in files. Even with a limitation on the types of accepted files, it's highly important to take additional measures to protect against them:

Validate File Type and MIME Type: Make sure the uploaded files match their MIME type - such as application/pdf - and extension - such as .pdf. Some file types, such as .svg files, may contain scripts and must therefore be carefully validated or sanitized if they are to be permitted.
Clean and Limit Content Size: Where file types can be utilized to contain scripts, such as .svg or .docx, for example, you may consider using server-side sanitization libraries to exorcise any potentially harmful content.
Rejected File Types for Suspicious Ones: If the file type is ambiguous, or if its MIME type doesn't correspond with the extension of the file, reject it and an graceful error message will be displayed to the user. This is a precautionary measure, which will prevent certain kinds of attack vectors, such as disguised executables.

Apart from security, file uploads do have many edge cases that need to be handled well in advance. The following are a few examples:

Empty File Uploads: Users sometimes don't even notice when they select an empty file meaning one with 0 bytes of size. Zod can validate against this by having a minimum size requirement. A File which is Empty should be rejected because there may be an error in actually processing or displaying its content.
Unexpected File Encodings: Some files use unusual encoding; this may cause errors in other applications. You can log or reject the files containing unexpected encoding.
Intermittent Upload Errors: In real-world applications, users might face network interruptions or other issues during file uploading. You can include retry mechanisms or error prompts so that users can complete their uploads.

In summary, make your validation system robust and user-friendly. Also, bear in mind security risks and common edge cases to ensure the users' interactions with your application's file-handling features go smoothly, error-free, and safely.

Conclusion

Adding file upload validation by Zod creates an extra layer of security and further improves the user experience for your application. Zod validation schema makes it easy to implement comprehensive checks, and provide clear feedback to users. This feedback allows your users to understand and resolve the issues in their values quickly.
As you iterate on your validation logic, you're actively building a safer application that instils more trust and satisfaction in your user. Zod gives flexibility in handling file validation to set such standards out of the box with a solid base for any project needing file-handling functionality.
For a more comprehensive section about Zod, see the documentation

See the full project of this article here.

Create a Simple Authentication System for your Next Application with Clerk

DrPrime01 — Sat, 26 Oct 2024 08:55:59 +0000

Authentication is a process through which users verify their identity before accessing a system. In web applications, authentication is primarily implemented with email/username and password. The auth process has been further simplified with Google authentication, which enables users to sign up or sign in to a web application with their Gmail account. Google's auth approach has proven useful in many applications, especially for users who frequently forget their credentials. The limitation of Google auth is that you can only sign in or sign up with your Gmail account and nothing else. However, Clerk provides more than one option to log in or sign up, even including Google auth as one of its several options.
Clerk is a powerful authentication tool for your Next application that provides more than one way to authenticate your users. In this article, you will learn how to create a simple auth system for your Next app with Clerk.

What is Clerk?

Clerk is an authentication solution for your Next application. It is a suite of embeddable UIs and flexible APIs created to make your app’s authentication process seamless. It features customizable SignIn and SignUp components, multifactor authentication, advanced security, session management, social sign-on, email and SMS OTPs, webhooks, and the recent magic link auth. Compared to other auth solutions, Clerk tops the game as it is an all-in-one auth solution for your application while others focus on only a single auth system. Also, it is not limited to Next applications. Clerk has SDKs for modern mobile and web frameworks like React, Remix, Astro, Expo, and iOS.

Setting up Clerk

Into the course of the article, create a Next app, but before you begin, mark out the prerequisites:

A basic understanding of React/Next
A Clerk account.

Although you will integrate Clerk in a Next app, you only need a basic understanding of React to get your app working. You won’t be getting into the intricacies of a Next app.

Step 1: Creating a Next app

Create a new folder named clerk-demo on your machine, drag it into your code editor, and open the terminal.
In the terminal, run this command npx create-next-app@latest . The “.” at the end allows the next app to be created in the already opened folder, clerk-demo, in your code editor.
Run npm run dev to start your newly created Next app in development mode and open the app on your browser using the provided domain. It’s usually localhost:3000

Step 2: Setting up your Clerk account

Go to clerk.com and sign up with your GitHub or Google account.
After signing up, you’ll be redirected to a page to create a new application.
Create a new application, give it a name, clerk-demo, and select your preferred auth options. There are about 15 or more auth options to choose from. Clerk allows you to see the UI of your selected auth options in real-time to help your decision-making.
After selecting the auth options and clicking the Create Application button, you’ll be redirected to the app’s dashboard.
Select your framework (NextJS) and you’ll see information on integrating Clerk.
Copy the installing command and run it in your code editor’s terminal, npm install @clerk/nextjs
Copy the environment variables
Create a .env.local file in the root of your Next app’s folder and paste the environment variables
Copy the middleware.ts code, create a file with the name, and paste it there.
Finally, update your layout.tsx file in the app folder of your application with the code from the Clerk dashboard. The ClerkProvider wrapper enables your app to access the Clerk authentication APIs and use the Clerk components.

Now, that you’ve successfully set up Clerk, you may proceed to the Clerk’s authentication implementation phase.

Implementing Authentication

Implementing authentication with Clerk is easy. There are no complex configurations to be done except to use the ready-made components in the right places.

Step 1: Defining your Sign-in and Sign-up routes

Clerk, by default, redirects your users to another link to sign in but if you want to displace that behaviour with your predefined sign-in and sign-up routes, open your .env.local file again and add these variables:

    /* Already existing variables */

    NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
    NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up

Step 2: Positioning the Clerk Auth Components

If you remember, you copied the layout.tsx page from your Clerk dashboard and updated your app’s layout.tsx file with it. The <SignedIn />, <SignedOut />, <SignInButton />, and <UserButton /> components should be moved from the layout file to a <Navbar /> component which you will create in your app.

In the root folder of your Next app, create a /components folder, and create a Navbar.tsx file in it.

    /components/Navbar.tsx

    export default function Navbar() {
      return (
        <nav>
          <SignedOut>
            <SignInButton />
          </SignedOut>
          <SignedIn>
            <UserButton />
          </SignedIn>
        </nav>
      )
    }

Then, import the Navbar.tsx file into your layout.tsx file and render the component between the body element, right about the children prop. In this way, all the children elements will have it right above them.

    import type { Metadata } from "next";
    import { Inter } from "next/font/google";
    import "./globals.css";
    import { ClerkProvider } from "@clerk/nextjs";
    import Navbar from "@/components/Navabr";

    const inter = Inter({ subsets: ["latin"] });
    export const metadata: Metadata = {
      title: "Miles Rentals",
      description: "Generated by create next app",
    };
    export default function RootLayout({
      children,
    }: Readonly<{
      children: React.ReactNode;
    }>) {
      return (
      <ClerkProvider>
        <html lang="en" suppressHydrationWarning>
          <body className={`${inter.className} noScrollBar`}>
            <Navbar />
            {children}
          </body>
        </html>
      </ClerkProvider>
      );
    }

Step 3: Create the Sign-in and Sign-up pages

For the SignIn and SignUp pages, create a /sign-in/[[…sign-in]] and a /sign-up/[[…sign-in]] folder inside the /app folder of your Next app, create a new page.tsx file in each, and paste this code in them.

In this way, users can navigate to /sign-in or /sign-up to log in or sign up, respectively.

    /sign-in/[[...sign-in]]/page.tsx

    import { SignIn } from "@clerk/nextjs";
    import React from "react";
    const page = () => {
      return (
        <main className="auth-page">
          <SignIn />
        </main>
      );
    };
    export default page;

    // replace <SignIn /> with <SignUp /> for the sign-up page.tsx file

    // NB: [[...sign-in]] is a folder within the sign-in folder where the sign-in page.tsx file is hosted. 
   //Ensure the folder is named with the square brackets and the "..."

With these few lines of code, you have successfully implemented Clerk authentication for your application. Now, explore other authorization concepts you can implement in your application with Clerk.

Managing User Sessions

Clerk has several hooks that give you access to the Clerk object. Among these hooks is the useSession() hook. The useSession() hook manages access to the current user’s session object and other helpers for setting the active session. The helpers are isLoaded, isSignedIn, and session.

    import { useSession } from '@clerk/clerk-react'

    const { isLoaded, session, isSignedIn } = useSession()

isLoaded is a boolean that checks if Clerk is successfully loaded in your app. This boolean is particularly useful when you want to use any of the numerous Clerk methods in your app. To prevent errors, you can check if Clerk is loaded before using any of its methods and objects. The isSignedIn boolean checks if a user is signed in or not. As you’ll see in the next section, this boolean can be useful in creating protected routes. The last helper in the hook is the session object. This object lets you access important information about the currently active section. For instance, you can help the users track the time spent during each session.

    import { useSession } from '@clerk/clerk-react'

    export default function Home() {
      const { session } = useSession()

      return (
        <div>
          <p>This session has been active since {session.lastActiveAt.toLocaleString()}
          </p>
        </div>
      )
    }

Other useful information you can get from the session object includes user, publicUserData, status, lastActiveToken, createdAt, updatedAt, expireAt, actor, end(), touch(), getToken(), and many others. See the Clerk session doc for a comprehensive list.

Protecting Routes

Protected routes are routes in an application where access is restricted to authenticated users only. In your application, you can expose some routes like the landing page, about page, and contact us page; and restrict some to authenticated users only like the user dashboard page or the settings page. Clerk has useful hooks that make it possible to create Protected routes for your application, including the useUser() hook.
The useUser() hook gives access to the current user’s user object and some helpers. It returns isSignedIn and isLoaded booleans, like the useSession hook, and a user object. With the information provided by this hook, you can create a ProtectedRoute wrapper around some pages of your application and prevent unauthorized access.

    // ProtectedRoute.tsx

    import { useUser } from "@clerk/clerk-react";
    import { redirect } from "next/navigation";

    export default function ProtectedRoute({
      children,
    }: {
      children: React.ReactNode;
    }) {
      const { isSignedIn, isLoaded } = useUser();
      if (!isLoaded) {
        return <LoadingComponent />;
      }
      if (!isSignedIn) {
        redirect(`/sign-in`);
      }
      return <>{children}</>;
    }

You can then use this ProtectedRoute component to wrap any page that requires authentication:

    // UserDashboard.tsx

    import ProtectedRoute from "@/components/custom-routes/ProtectedRoute";
    export default function UserDashboard() {
      return <ProtectedRoute>{/* Your User Dashboard component */}</ProtectedRoute>;
    }

Role-Based Access Control (RBAC)

In addition to basic authentication, you might want to implement Role-Based Access Control to restrict access based on user roles. Clerk provides a way to implement RBAC using user metadata. Here's how you can extend your protected routes to include role-based access:

Configure the session token: Add user metadata to the session token in the Clerk Dashboard under Sessions > Customize session token.
Create a TypeScript definition for roles: Define your roles in a globals.d.ts file.
Create a helper function to check roles

    import { Roles } from '@/types/global'
    import { auth } from '@clerk/nextjs/server'

    export const checkRole = (role: Roles) => {
      const { sessionClaims } = auth()
      return sessionClaims?.metadata.role === role
    }

Extend your ProtectedRoute component to include role checks

    import { useUser } from "@clerk/clerk-react";
    import { redirect } from "next/navigation";
    import { checkRole } from "@/utils/roles";

    export default function ProtectedRoute({
      children,
      requiredRole,
    }: {
      children: React.ReactNode;
      requiredRole?: Roles;
    }) {
      const { isSignedIn, isLoaded } = useUser();

      if (!isLoaded) {
        return <LoadingComponent />;
      }

      if (!isSignedIn) {
        redirect(`/sign-in`);
      }

      if (requiredRole && !checkRole(requiredRole)) {
        redirect(`/unauthorized`);
      }

      return <>{children}</>;
    }

Now you can protect routes based on both authentication and roles

    import ProtectedRoute from "@/components/custom-routes/ProtectedRoute";

    export default function AdminDashboard() {
      return (
        <ProtectedRoute requiredRole="admin">
          {/* Your Admin Dashboard component */}
        </ProtectedRoute>
      );
    }

This implementation allows you to create a flexible system for protecting routes based on both authentication status and user roles, enhancing the security of your application.

Customization Option

Clerk provides many customization options for your application. You can customize the SignIn and SignUp component to use your logo rather than Clerk’s logo.

Navigate to your Clerk dashboard, right-click on your app’s name, and click the settings icon. There, you’ll see different customization settings to make Clerk feel more like yours.

Besides the logo change on the SignIn and SignUp components, you can also customize the theme of all Clerk components to match your application’s theme at once or individually. Clerk provides an appearance prop in the ClerkProvider wrapper component, which you use in your layout.tsx file. You can also use the appearance prop in any Clerk component to customize it individually. The appearance prop accepts the following properties:

baseTheme: The base theme to be used in your component. See the themes documentation for available themes.
variables: An object to define the styles like color, font size, font weight, and much more.
layout: This property is particularly useful for customizations that are hard to implement with CSS. It gives you access to configuration options that affect the layout of Clerk components. See layout for more information.
elements: If you want to override the default style of a specific element, this property is for you. For more information, see elements.

All of these properties are optional so you can use 1 or 2 or all of them, independently. The code sample below illustrates a sample use of the appearance prop in the ClerkProvider wrapper component.

    import type { Metadata } from "next";
    import { ClerkProvider } from "@clerk/nextjs";
    import { dark } from "@clerk/themes";
    import localFont from "next/font/local";
    import "./globals.css";
    import { cn } from "@/lib/utils";

    const geistSans = localFont({
      src: "./fonts/GeistVF.woff",
      variable: "--font-geist-sans",
      weight: "100 900",
    });
    const geistMono = localFont({
      src: "./fonts/GeistMonoVF.woff",
      variable: "--font-geist-mono",
      weight: "100 900",
    });
    export const metadata: Metadata = {
      title: "Clerk Auth",
      description: "Code sample of using the appearance prop",
    };
    export default function RootLayout({
      children,
    }: Readonly<{
      children: React.ReactNode;
    }>) {
      return (
        <ClerkProvider
          appearance={{
            baseTheme: dark,
            variables: {
              colorPrimary: "#3371FF",
              fontSize: "16px",
            },
          }}
        >
          <html lang="en" suppressHydrationWarning>
            <body
              className={cn(
                "antialiased min-h-screen",
                geistSans.variable,
                geistMono.variable
              )}
            >
             {children}
            </body>
          </html>
        </ClerkProvider>
      );
    }

Conclusion

In this article, you learned how to implement a basic but strong authentication system in your Next.js application using Clerk. You saw how Clerk can provide an all-in-one solution which is both robust and very easy to implement. You started by creating a Clerk account and linking it with the Next.js application. Then you integrated the primary authentication functionality: sign-in and sign-up. Later, you dove deeper into more advanced topics, like user session management, protecting routes, and even Role-Based Access Control. You learned how Clerk's customizability allowed you to tailor the authentication experience to your application. You have seen how easily you can implement different themes and layouts, making every adjustment necessary to fit your app's design.
With web application development, you will need a secure, customizable, full-featured authentication system—that's what Clerk offers with much simplicity in implementation hence highly recommended for your Next.js projects. You now know how to effectively use Clerk's authentication solution for your projects, whether small or large scalable applications. Whether you're building a small project or a large-scale application, you now have the knowledge to use Clerk's authentication solution effectively. You're equipped with the tools and flexibility to meet your authentication needs efficiently and securely in your Next.js applications.

Forem: DrPrime01

React CVE Vulnerability Exposed! Check out how to secure your apps now.

Upgrade Your React Apps!!!

Upgrade Your React Apps!!!

CSS `color-mix()` Function

Syntax

Arguments

Examples

How it works

Basic usage

Color scheme with color-mix()

Generating gradients with color-mix()

Browser support

References

How to set up Tailwind CSS v4.0 in your Vite App

Tailwind CSS v4.0

Installation

Upgrading from v3 to v4.0

Browser requirements for v4.0

Conclusion

References

What is Display P3?

Why Display P3 Matters

Technical Details

Limitations

Why Apple Devices Stand out

Conclusion

References

How to Implement WebCam Recording on the Web Using JavaScript

Prerequisites

Setting Up the Project

Create a Basic HTML Structure

Styling the Interface

The MediaRecorder and MediaDevices API

Implementing the Recording Functionality Step-By-Step

Variable Declarations and Initial Setup

Explanation

Populating Media Devices

Explanation

Getting Media Stream

Explanations

Stopping Media Tracks

Explanations

Device Selection Handlers

Explanations

Initial Device Setup

Explanations

Recording Controls

Explanations

Explanations

Cleanup on Window Close

Explanation

Conclusion

Accessibility in Frontend Development: Building Inclusive Web Experiences

Common Accessibility Pitfalls and How to Avoid Them

Inadequate Keyboard Navigation

Solutions

Poor Color Contrast

Solutions

Missing Alternative Text for Images

Solutions

Inaccessible Forms

Solutions

Non-Responsive Design

Solutions

Implementing ARIA Attributes Effectively

Common ARIA Attributes and Their Usage

ARIA Roles and When to Use Them

Best Practices for ARIA Implementation

Conclusion

From ETL to ELT: The Evolution of Data Engineering and the Rise of AirByte

The Early Days of Data Engineering

The Shift to Modern Data Engineering

The Emergence of ELT Tools

AirByte: A Key Player in ELT

The Modern Data Stack

Separation of Concerns

Data Lakes and Warehouses

Orchestration and Governance

Data Quality and Testing

Color scheme with `color-mix()`

Generating gradients with `color-mix()`

The `MediaRecorder` and `MediaDevices` API