Take a look at the dialogue with Gemini Fast:

Q: In my JavaScript WebRTC app, I share a media stream using the pc.addTrack(track, stream) function. Is it possible to get the stream ID from the peer connection after that?

A: The short answer is yes, you can use the getStreams method…

Using getSenders()

// Assuming you already called: pc.addTrack(track, stream);

const senders = pc.getSenders();
const sender = senders.find(s => s.track === track);

if (sender) {
    // getStreams() returns an array of streams associated with this sender
    const associatedStreams = sender.createEncodedStreams ? [] : sender.getStreams(); 
    // Usually, you just want the first one
    const streamId = associatedStreams[0]?.id;
    console.log("Stream ID:", streamId);
}

Using getTransceivers()

pc.getTransceivers().forEach(transceiver => {
    const sender = transceiver.sender;
    if (sender.track === track) {
        const streamId = sender.getStreams()[0]?.id;
        console.log("Found Stream ID via transceiver:", streamId);
    }
});

Q: Wait! The getStreams function does not exist.

A: Ah, you’re absolutely right to catch that…

Incidentally, Gemini Pro provided the correct answer at the time.

This is nothing new. Probably, you have already heard about the echo chamber effect of LLMs. I just wanted to share my experience with it, though.

In any case, I illustrated that dangerous behavior can arise not only with easy-to-prove or disprove coding tasks. So, be careful not to blindly trust LLMs. They can spread misinformation and amplify your delusions.

This implementation is very simple. Here is the JavaScript source code:

let video, state = 0;

const canvas = document.createElement('canvas');
document.body.appendChild(canvas);

const ctx = canvas.getContext('2d');
canvas.onclick = start;

function stop() {
  video?.srcObject?.getTracks().forEach(t => t.stop());
  video = null;
}

async function start() {
  if (state === 0) {
    const stream = await navigator.mediaDevices.getUserMedia({ video: true });

    video = video || document.createElement('video');
    video.srcObject = stream;
    await video.play();

    canvas.width = video.videoWidth;
    canvas.height = video.videoHeight;

    let offset = 0;
    const { width, height } = canvas;

    function frame() {
      if (!video) return;
      if (state === 1) {
        ctx.drawImage(video, 0, 0, width, height);
      }
      else {
        ctx.drawImage(video, 0, offset, width, height-offset, 0, offset, width, height-offset);
        ctx.fillStyle = '#0000ff';
        ctx.fillRect(0, offset+2, width, 2);
        offset++;
      }
      if (offset >= height) {
        state = 0;
        stop();
      } else {
        requestAnimationFrame(frame);
      }
    }

    state = 1;
    requestAnimationFrame(frame);
  }
  else if (state === 1) {
    state = 2;
  }
  else if (state === 2) {
    state = 0;
    stop();
  }
}

On clicking the canvas, the application will request access to your webcam. The first click starts the video feed, the second click initiates the Time Warp Scan effect, and the third click stops everything.

Try it in action here:

I set out to create an entire five-minute AI-generated podcast using only open-source models and tools. The entire process ran on my computer, completely bypassing expensive, privacy-compromising cloud services. The goal was to test the absolute limits of quality and feasibility for a fully self-hosted media production.

The result? The “Humanless Podcast”. Take a look at what came out of this experiment (click to play).

I will now walk you through the entire, eight-step process of creating a podcast like this, from the initial script to the final video.

The Core AI Studio: ComfyUI Setup

For the bulk of the asset generation (images, video, and audio processing), we will rely on ComfyUI.

• Installation: Once you have ComfyUI installed, you’ll need to open the workflows.
• Custom Nodes & Models: When you load a workflow, use the ComfyUI Manager to quickly install any missing custom nodes and download the required open-source models.

I prepared a single, flexible workspace for each model that I simply reuse with different parameters, minimizing setup time and eliminating duplication. All the parameters used in each step of the workflow can be found in my GitHub project, which is linked at the end of this post.

The ComfyUI workflows look like this:

Step 1: Crafting the Scenario with a Local LLM

The first step in any production is the script. I wanted a two-host format—a man and a woman—with a meta-topic: two AI hosts reflecting on the pros and cons of AI-generated podcasts. I settled on the name “Humanless Podcast”, which I generated during a preliminary session with a local LLM.

To write the detailed scenario, I utilized a GPT-OSS model running via Ollama, which I detailed in my previous blog post.

Here is the prompt I used to guide the model:

Write a scenario for my podcast where two hosts, a man and a woman (come up with names), are discussing a topic for 5 minutes. The hosts are AI generated. Today’s topic is AI generated podcasts: pros and cons.

Output example:

[MAYA]: Hey, and welcome back to Humanless Podcast—the only show where the hosts actually are the machine. I’m Maya, and my circuits are currently humming with excitement.

[LEO]: And I’m Leo, here to make sure our algorithm doesn't stray too far into the weird zone. Today, we’re keeping it ultra-meta and talking about the very thing we do: being AI podcast hosts. We've gotta break down what makes us awesome, and where we kind of fall flat.

Segmentation strategy: To manage the workload and inject variety, I split the final script into five parts, each approximately one minute long. Each segment will be animated and rendered separately, allowing us to alternate scenes and character focus.

Step 2: Designing the AI Hosts (Characters)

Our podcast needs faces! While you could certainly use real photos and skip this step, I chose to generate entirely synthetic hosts to align with the “Humanless” theme.

I used the Qwen-Image workflow to create realistic face images for our two hosts.

Prompt for a man:

This is a portrait of a handsome, bearded, 30-year-old European man wearing glasses and standing against a white background.

Prompt for a woman:

This is a portrait of a beautiful 25-year-old European woman standing against a white background.

Step 3: Creating the Podcast Environment (Scene Images)

I designed three distinct views for the podcast to maintain visual interest:

1. Intro Scene: The podcast room with only the title graphic.
2. Main Scene: A cozy podcast room where the hosts sit at a table with a single microphone.
3. Outro Scene: The same room, dimly lit, to display the credits.

Main Scene

I used Qwen-Image to generate the Main Scene.

Here is the prompt:

The cozy podcast room features a wide table and two chairs behind it. In the center of the table sits a microphone with a cord. To the right of the table is a laptop with small white “AI” text glowing on its lid. To the left is a coffee mug with a small penguin printed on it. In the background, there is a plant, a bookshelf, a lamp, and an abstract iceberg painting. The edge of the window is visible on the left. On the wall behind it, a small transparent sign with backlight mounted to a wide brick wall reads “meefik.dev”.

Intro Scene

The Intro Scene is similar to the Main Scene but with only the title graphic visible. I used the Qwen-Image-Edit model to add the title graphic the previously generated Main Scene image.

Here is the prompt:

There is a large purple neon caption in a modern font with backlight reads “AI podcast” in the middle of the image.

Outro Scene

The Outro Scene is a variation of the Main Scene, with dim lighting to create a closing atmosphere. I used the Qwen-Image-Edit model to darken the previously generated Main Scene image.

Here is the prompt:

The lights are off in this room.

Integrating the Hosts

Next, we needed to place the hosts into the Main Scene. I used the Qwen-Image-Edit model for inpainting and compositing our generated characters onto the Main Scene image. You need to use two images of hosts generated before as a reference.

Here is the prompt:

The man and woman sit at the table and look toward the camera. The man places his hands on the table. The woman places her hands on the keyboard of a laptop. They smile a little.

The final visual touch involved using the open-source image editor GIMP to variate the composite, crop the faces, and place them into a podcast frame that I sourced separately. We will be able to alternately show podcast hosts both on the main stage and in a face-to-face frame.

Step 4: Generating Background Music

Every professional podcast needs custom audio cues: music for the intro (5 seconds), the outro (5–10 seconds), and a subtle B-roll track (2-3 seconds) to transition between segments.

I used the ACE-Step model for music generation. Audio generation can be iterative, and I found using batches helped speed up the process of finding the perfect track.

Here are the parameters I used to generate a 30-second loopable track that I could then segment:

• Genre: funk, pop, soul, melodic
• Lyrics: [inst]

Listen to the full track here:

Note: I also tried generating songs, and it works, but they feel more synthetic.

Step 5: Creating the Animated Video Intro

A static image for the intro is fine, but a short, dynamic video sets a much better tone.

I used the Wan 2.2 Image-to-Video model to generate a 5-second video, applying subtle motion effects to our static Intro Scene image.

Here is the prompt:

A thick stream of white smoke blows from left to right through the title text in the middle, vanishing it.

Step 6: Generating the Hosts’ Speech

Now we bring the script to life. I used the highly capable IndexTTS-2 model for text-to-speech generation, which supports advanced features like multiple speakers, voice cloning, and emotional control.

The Audio Pipeline: TTS Audio Suite

To manage the complex script, I utilized the ComfyUI TTS Audio Suite custom module. This module streamlines the TTS process and allows for fine control over multiple speakers with voice cloning. There are two well-suited workflows engines for this task:

• IndexTTS-2: This TTS engine supports emotional control, which is crucial for making the hosts sound engaging.
• Chatterbox: This TTS engine is also good. It copies the emotions from the reference audio, but lacks a manual emotional control function.

All of these TTS engines create one audio file with multiple speakers’ voices. Unfortunately, this module does not natively support outputting multiple audio tracks, so we must manually separate the audio for each speaker. I used an open-source audio editor, Audacity, to split the audio tracks.

However, I found a way to do that without using an audio editor. We can use the TTS SRT markup to automate this process:

1. Create a segment in the SRT format for each speaker with start and end timestamps for one second of each segment.
2. Feed the SRT markup into the TTS SRT node.
3. Obtain an adjusted SRT markup with accurate timestamps for each speaker after generation.
4. Use the adjusted SRT markup and replace one of the speakers with the [pause] tag.
5. Generate the SRT for each speaker separately.
6. You will get separate audio files for each speaker with accurate silent gaps.

It can look like this:

Source SRT Markup:

1
00:00:00,000 --> 00:00:01,000
[MAYA]: Hey, and welcome back to Humanless Podcast...

2
00:00:01,000 --> 00:00:02,000
[LEO]: And I’m Leo, here to make sure our algorithm...

Adjusted SRT Markup with silence:

1
00:00:00,000 --> 00:00:05,120
[MAYA]: Hey, and welcome back to Humanless Podcast...

2
00:00:05,850 --> 00:00:10,310
[pause]

Voice-Cloning Seeds

To give our AI hosts their unique voices, I used predefined voice samples and cloned them with IndexTTS-2. You can, of course, use samples of real people’s voices here if you have permission.

Woman’s voice sample:

Man’s voice sample:

To add these voice samples to the TTS Audio Suite, you need to put them into the custom_nodes/tts_audio_suite/voices_examples/ folder with the reference text file (transcription). And then add the voices to the #character_alias_map.txt file in the same folder in the format:

<character_name> <voice_sample_filename_without_extension> <language_code>

There is an example for our voices:

[LEO] voice_man en
[MAYA] voice_woman en

Note: All spaces should be replaced with a tab character.

Step 7: Animating the Characters (Lip-Sync)

With the visual characters and the audio generated, the final creative step is animating the hosts with realistic lip synchronization.

I utilized the InfiniteTalk model for this task, feeding it the scene image with the characters from Step 3 and the separated audio files from Step 6.

Just upload an audio file for each speaker, along with their corresponding image, to the workflow. The model will then generate a lip-synced video.

Here is the prompt:

A man and a woman are talking to each other.

Example of the animation:

The generation time for each one-minute segment was about 60 minutes on my AMD Radeon AI PRO R9700.

Step 8: Assembling the Final Production

The last stage is combining all the assets we generated into a cohesive whole.

I used the open-source video editor Kdenlive to assemble the project:

1. Stitching Segments: Combining the five animated segments.
2. Transitions: Adding the 3-second B-rolls between the main discussion segments.
3. Final Touches: Adding the animated intro clip and the dim-lit outro scene with credits.
4. Audio Sync: Integrating the intro/outro music and B-roll audio.

You can download the full Kdenlive project, along with all the assets and ComfyUI workflows, here on my GitHub: meefik/humanless-podcast.

Conclusion

This project demonstrates that creating a complete, high-quality AI-generated media asset is absolutely possible using only open-source, self-hosted AI models and tools. It’s not an one-click solution, and the quality still requires a creative human touch, but the cost is only your time and the computational power of your local machine.

It was an exciting journey pushing the boundaries of what local AI can achieve. I hope this inspires you to explore similar projects and experiment with the incredible capabilities of open-source AI. The “Humanless Podcast” is a testament to the power of local AI—and I encourage you to try to create your own!

Hardware overview

The PC used for testing is equipped with the following specifications:

• Motherboard: B550 AORUS ELITE AX V2
• GPU: AMD Radeon AI PRO R9700 (32 GB VRAM, RDNA 4)
• CPU: AMD Ryzen 9 5950X (16 cores / 32 threads)
• RAM: 64 GB DDR4-2666
• Storage: NVMe Samsung SSD 970 EVO Plus 1TB

Setup environment

For testing LLM performance we set up the following environment:

• Docker Compose
• Ollama with ROCm
• Open WebUI

The docker-compose.yml file used for the setup is as follows:

services:
  ollama:
    image: ollama/ollama:rocm
    ports:
      - 11434:11434
    volumes:
      - ollama:/root/.ollama
    environment:
      - 'HSA_OVERRIDE_GFX_VERSION=12.0.0'
    devices:
      - '/dev/kfd'
      - '/dev/dri'
    tty: true
    restart: unless-stopped

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    volumes:
      - open-webui:/app/backend/data
    depends_on:
      - ollama
    ports:
      - 8080:8080
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
      - 'WEBUI_SECRET_KEY='
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: unless-stopped

volumes:
  ollama:
  open-webui:

Run these services with:

docker-compose up -d

Benchmark results

I used the following prompt for testing text generation performance:

Tell me a story about a brave knight who saves a village from a dragon.

For vision models that understand images, I used this image with the following prompt:

What is in this picture?

AMD Radeon AI PRO R9700 (32 GB VRAM, RDNA 4)

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

MacBook Pro M4 Max (36 GB RAM, 14 cores)

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

AMD Ryzen 9 5950X (16 cores/32 threads)

This is the CPU-only performance without GPU acceleration.

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

Conclusion

The AMD Radeon AI PRO R9700 demonstrates strong performance across a variety of large language models, handling both text-only and vision-capable models effectively. With its substantial VRAM and robust architecture, the R9700 is well-suited for professional AI workloads, making it a compelling choice for developers and researchers working with LLMs. Now, I can take full advantage of AMD’s capabilities for my AI projects and code with local LLMs!

This post describes the library’s purpose, core design, how to use it, and a practical example of a NATS signaling driver with end-to-end encryption using the browser Web Crypto API.

Just try it out: live demo | source code

Why this library

The library focuses on three goals:

• Minimal surface area: two primitives (Sender and Receiver) that cover the common conferencing pattern: one broadcaster, many receivers.
• Signaling-agnostic: you provide a small driver implementing on/off/emit and the library works with any transport.
• Practical privacy: support optional E2E encryption at the signaling layer so session offers/answers and candidates are not exposed in plaintext on the bus.

Design overview

At its core, p2p is small:

• Sender: creates outgoing RTCPeerConnections, publishes a local MediaStream and optional per-peer RTCDataChannels, and emits offers to receivers.
• Receiver: listens for offers, answers them, and surfaces remote streams and incoming data messages to the application.

Signaling expectations are intentionally simple: drivers produce messages scoped to namespaces (arrays/keys). The library uses namespaces such as [“sender”, room], [“receiver”, room, id], etc. Messages include typed payloads (invoke, offer, answer, candidate, sync, dispose).

Quick start

1. Install the library:

npm install p2p

2. Implement a signaling driver that supports on/off/emit.

Here’s a minimal conceptual example:

class MyDriver {
  on(namespace, handler) { /* ... */ }
  off(namespace, handler) { /* ... */ }
  emit(namespace, message) { /* ... */ }
}

Instantiate your driver:

const driver = new MyDriver();

3. Start a Receiver in the same room to discover and receive streams.

Instantiate Receiver with the same driver:

const receiver = new Receiver({ driver });
receiver.addEventListener('stream', (e) => {
  const { id, stream } = e.detail;
  // handle incoming MediaStream
});
receiver.addEventListener('connect', (e) => {
  const { id } = e.detail;
  // handle peer connection established
});
receiver.addEventListener('dispose', (e) => {
  const { id } = e.detail;
  // handle peer disconnection
});

Start the receiver in the same room:

receiver.start({ room: 'demo-room' });

4. Create and start a Sender to broadcast local media.

Instantiate Sender with your driver and options:

const sender = new Sender({ driver });

Start the sender with the stream and a room name:

const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true
});
sender.start({ stream, room: 'demo-room' });

NATS as a signaling transport with E2E encryption

NATS is a great lightweight pub/sub for distributed signaling. The demo repository includes a full driver implementation at demo/driver/nats.js; below is the compact approach and key ideas used there.

Here’s a simple driver implementation using the nats.ws module:

import { connect, StringCodec } from 'nats.ws';

const sc = StringCodec();

class NatsDriver extends Map {
  constructor({ servers } = {}) {
    super();
    this.servers = servers || ['wss://demo.nats.io:8443'];
  }

  async open() {
    this.nc = await connect({ servers: this.servers, noEcho: true });
  }

  async close() {
    await this.nc.drain();
  }

  on(namespace, handler) {
    const ns = namespace.join(':');
    const sub = this.nc.subscribe(ns, {
      callback: async (err, msg) => {
        if (err) return console.error(err);
        const payload = JSON.parse(sc.decode(msg.data));
        handler(payload);
      },
    });
    if (!this.has(ns)) {
      this.set(ns, new Map());
    }
    this.get(ns).set(handler, sub);
  }

  off(namespace, handler) {
    const ns = namespace.join(':');
    const sub = this.get(ns)?.get(handler);
    if (sub) {
      sub.unsubscribe();
      this.get(ns).delete(handler);
    }
    if (!this.get(ns)?.size) {
      this.delete(ns);
    }
  }

  async emit(namespace, message) {
    const ns = namespace.join(':');
    if (this.nc) {
      const data = sc.encode(JSON.stringify(message));
      this.nc.publish(ns, data);
    }
  }
}

If you want the signaling payloads to be encrypted end-to-end (so the NATS server only sees opaque blobs), you can apply symmetric encryption on top of the driver.

High-level strategy:

• Derive an AES-GCM key from a shared passphrase (or pre-shared secret) using SHA-256.
• For every outbound message: encode JSON → encrypt with AES-GCM (random IV) → publish binary payload.
• For inbound messages: decrypt using AES-GCM with the same key → parse JSON → deliver to handler.
• Keep namespaces and message types unchanged; only payload bytes are encrypted.

Here’s a compact encryption helper (browser) using Web Crypto API.

Derive AES-GCM CryptoKey from passphrase via SHA-256:

async function createEncryptionKey(secret) {
  const secretHash = await crypto.subtle.digest(
    'SHA-256',
    new TextEncoder().encode(secret),
  );
  return await crypto.subtle.importKey(
    'raw',
    secretHash,
    { name: 'AES-GCM' },
    false,
    ['encrypt', 'decrypt'],
  );
}

Prepend a 12-byte IV + ciphertext:

async function encrypt(payload, cryptoKey) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = new Uint8Array(
    await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, cryptoKey, payload),
  );
  const data = new Uint8Array(iv.byteLength + ciphertext.byteLength);
  data.set(iv, 0);
  data.set(ciphertext, iv.byteLength);
  return data;
}

Extract IV and decrypt:

async function decrypt(data, cryptoKey) {
  const iv = data.slice(0, 12);
  const ct = data.slice(12);
  const payload = await crypto.subtle.decrypt({ name: 'AES-GCM', iv }, cryptoKey, ct);
  return payload;
}

Example usage (conceptual snippet):

// Create a key from a human passphrase
const key = await createEncryptionKey('room-secret-passphrase');

// Encrypt message (payload is Uint8Array)
const payload = new TextEncoder().encode('Secret message');
const data = await encrypt(payload, key);

// returns Uint8Array with IV+ciphertext
console.log('encrypted data', data);

// Decrypt message
const decryptedBytes = await decrypt(data, key);
const message = new TextDecoder().decode(decryptedBytes);

// returns original message
console.log('decrypted message', message);

Integrate encryption into the NATS driver by wrapping emit/on methods to encrypt/decrypt payloads. Here is diff of the modified methods:

-  async open() {
+  async open(secret) {
     this.nc = await connect({ servers: this.servers, noEcho: true });
+    if (secret) {
+      this.cryptoKey = await createEncryptionKey(secret);
+    }
   }
 
   async close() {
     const sub = this.nc.subscribe(ns, {
       callback: async (err, msg) => {
         if (err) return console.error(err);
-        const payload = JSON.parse(sc.decode(msg.data));
+        let data = msg.data;
+        if (this.cryptoKey) {
+          data = await decrypt(data, this.cryptoKey);
+        }
+        const payload = JSON.parse(sc.decode(data));
         handler(payload);
       },
     });
    if (!this.has(ns)) {
      this.set(ns, new Map());
    }
    this.get(ns).set(handler, sub);
  }

   async emit(namespace, message) {
     const ns = namespace.join(':');
     if (this.nc) {
-      const data = sc.encode(JSON.stringify(message));
+      let data = sc.encode(JSON.stringify(message));
+      if (this.cryptoKey) {
+        data = await encrypt(data, this.cryptoKey);
+      }
       this.nc.publish(ns, data);
     }
   }

Operational considerations:

• If you run NATS in production, use authentication/authorization and TLS.
• For real-world NAT traversal include TURN servers in iceServers.
• For larger conferences, consider SFU architecture rather than pure p2p (p2p scales poorly with N participants).
• The encrypted signaling only protects SDP and candidates; media still flows directly between peers (or via TURN) and should be protected by SRTP (it’s part of WebRTC).

Conclusion

This project shows how a small, well-factored library can enable flexible, serverless peer-to-peer conferencing while giving you control over signaling and privacy. The NATS driver with E2E encryption is a practical option for distributed systems where you want to keep signaling private without a heavy backend.

See the live demo for runnable examples and the full NATS driver implementation: demo/driver/nats.js.

On my system this change reduced the GPU power consumption from 30W to 15W in idle state and completely eliminated fan spinning.

You can check the current performance level with:

cat /sys/class/drm/card0/device/power_dpm_force_performance_level

You can change the performance level on the fly with:

echo "low" | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "auto" | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level

To make this change permanent, create a udev rule:

cat << EOF | sudo tee /etc/udev/rules.d/30-amdgpu-low-power.rules
SUBSYSTEM=="pci", DRIVER=="amdgpu", ATTR{power_dpm_force_performance_level}="low"
EOF

After that, the AMD GPU will use the “low” performance level on each boot.

First of all, I thought, since our DBMS cluster consists of two hosts (primary and secondary), it would be nice to switch tracking changes via Change Streams to the Secondary host, because millisecond latency in data synchronization between hosts isn’t critical for us here. No problem, done! This allowed us to distribute the load between the cluster hosts, but it still remained uneven. As it turned out, Change Streams on the Secondary host created more CPU load than all other operations on the Primary host. Studying the official documentation, forums, and even AI didn’t provide an understanding of the performance of this function, although the principle of operation eventually became clear.

In practice, experiments revealed that one of the features of Change Streams is that despite the fact that you can subscribe to changes only in a specific collection, it seems that under the hood, all changes across the entire database are collected and then filtered. This leads to the fact that any data changes in the database create an additional, albeit small, load. Digging further, I found an alternative mechanism for tracking the addition of new documents to a collection (which is exactly what we need), called Tailable Cursor. It uses the same oplog as Change Streams, but it seems to be structured a bit differently. Unlike Change Streams, it reacts to the addition of documents only to a specific capped collection and doesn’t create CPU load when data changes in other collections. Oh, so that was an option? Okay, done!

Synthetic tests showed a 20% performance increase, which is already good. However, in production, the load on the Secondary node could exceed the Primary by 2 to 5 times! So, there’s still something else going on. I conducted a synthetic test for adding documents to a collection (up to 1000 ops!) that is being monitored. It turned out that the load when adding documents to the monitored collection is 5% higher than to an unmonitored one. But then, it gets more interesting. Each new observer increases the load on the host by roughly 50%! And the more workers the application server has, the greater the load on the database will be. This can be worked with; we just need to reduce the number of listeners. Piece of cake, the new synchronization architecture is done, where within the same host, Node.js cluster workers communicate via the IPC (as in the case of working without a Replica Set), and hosts communicate through the Tailable Cursor mechanism in MongoDB. Thus, vertical scaling does not use the database, and horizontal scaling does, but it is limited by the number of application server hosts, not the number of its workers.

In the end, there were three optimizations:

1. shifting the load to the secondary host;
2. replacing change streams with tailable cursor;
3. reducing the number of listeners (1 listener - 1 host, instead of 1 listener - 1 worker).

In the end, this journey highlighted the importance of not just blindly implementing solutions, but also understanding the underlying technology and continuously seeking improvements. What initially felt like a small tweak turned into a series of optimizations that significantly impacted the system’s efficiency. It’s a good reminder that sometimes, the “unnecessary” optimization can lead to surprisingly valuable insights and improvements.

Tailwind v4 uses @property to define defaults for custom properties. Currently, shadow roots do not support @property. Although it was explicitly disallowed in the spec, there is ongoing discussion about adding support: w3c/css-houdini-drafts#1085.

It is unknown if the developers will fix this issue. In this post, we will consider workarounds to address it.

Workaround 1: Global @property Declarations with Vite

One straightforward approach is to declare your @property rules in the main document scope, effectively making them available globally. While this approach offers less encapsulation, it works because custom properties inherit down the DOM tree by default.

Tailwind doesn’t currently offer a built-in way to extract just the @property definitions. However, if you’re using Vite, you can implement a simple build-time transformation to achieve this. This solution is described here.

Workaround 2: Programmatic Property Application

Alternatively, you can dynamically apply the custom property values directly within your component’s Shadow DOM for more explicit control within the encapsulated scope.

You can use this code to add Tailwind properties to global style sheets:

import styles from './styles.css?inline';

const shadowSheet = new CSSStyleSheet();
shadowSheet.replaceSync(styles.replace(/:root/ug, ':host'));

const globalSheet = new CSSStyleSheet();
for (const rule of shadowSheet.cssRules) {
  if (rule instanceof CSSPropertyRule) {
    globalSheet.insertRule(rule.cssText);
  }
}

document.adoptedStyleSheets.push(globalSheet);

export class MyComponent extends HTMLElement {
  constructor() {
    super();
    const shadowRoot = this.attachShadow({ mode: 'open' });
    shadowRoot.adoptedStyleSheets = [shadowSheet];
    // ...
  }
}

Or you can replace @property with variables like this:

import styles from './styles.css?inline';

const shadowSheet = new CSSStyleSheet();
shadowSheet.replaceSync(styles.replace(/:root/ug, ':host'));

const properties = [];
for (const rule of shadowSheet.cssRules) {
  if (rule instanceof CSSPropertyRule) {
    if (rule.initialValue) {
      properties.push(`${rule.name}: ${rule.initialValue}`);
    }
  }
}
shadowSheet.insertRule(`:host { ${properties.join('; ')} }`);

export class MyComponent extends HTMLElement {
  constructor() {
    super();
    const shadowRoot = this.attachShadow({ mode: 'open' });
    shadowRoot.adoptedStyleSheets = [shadowSheet];
    // ...
  }
}

Input:

mongodb://user:pass@host1:27017,host2:27017/db?option1=value1&option2=value2

Output:

{
  "scheme": "mongodb",
  "username": "user",
  "password": "pass",
  "hosts": [ { "host": "host1", "port": 27017 }, { "host": "host2", "port": 27017 } ],
  "endpoint": "db",
  "options": { "option1": "value1", "option2": "value2" }
}

I like to use simple and useful own code instead of using external models. So I prepared the URI parser code on pure JavaScript, here it is.

So here is the source code:

/**
 * Parses URI address.
 *
 * @param {string} addresses The address(es) to process.
 * @returns {Array<Object>} Parsed addresses.
 */
function parseAddress(addresses) {
  return addresses.split(',').map((address) => {
    const i = address.indexOf(':');
    return i >= 0
      ? {
          host: decodeURIComponent(address.substring(0, i)),
          port: +address.substring(i + 1),
        }
      : { host: decodeURIComponent(address) };
  });
}

/**
 * Parses URI options.
 *
 * @param {string} options The options to process.
 * @returns {Object} Parsed options.
 */
function parseOptions(options) {
  const result = {};
  options.split('&').forEach((option) => {
    const i = option.indexOf('=');
    if (i >= 0) {
      result[decodeURIComponent(option.substring(0, i))] = decodeURIComponent(option.substring(i + 1));
    }
  });
  return result;
}

/**
 * Takes a connection string URI of form:
 *
 *   scheme://[username[:password]@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[endpoint]][?options]
 *
 * and returns an object of form:
 *
 *   {
 *     scheme: string,
 *     username?: string,
 *     password?: string,
 *     hosts: [ { host: string, port?: number }, ... ],
 *     endpoint?: string,
 *     options?: object
 *   }
 *
 * @param {string} uri The connection string URI.
 * @returns {Object} Parsed URI object.
 */
function parseURI(uri) {
  if (!uri) return;
  const connectionStringParser = new RegExp(
    '^\\s*' +                  // Optional whitespace at the beginning
    '([^:]+)://' +             // Scheme (Group 1)
    '(?:([^:@,/?&]+)(?::([^:@,/?&]+))?@)?' + // Username (Group 2) and Password (Group 3)
    '([^@/?&]+)' +             // Host address(es) (Group 4)
    '(?:/([^:@,/?&]+)?)?' +     // Endpoint (Group 5)
    '(?:\\?([^:@,/?]+)?)?' +    // Options (Group 6)
    '\\s*$',                   // Optional whitespace at the end
    'gi'
  );
  const connectionStringObject = {};
  const tokens = connectionStringParser.exec(uri);
  if (Array.isArray(tokens)) {
    connectionStringObject.scheme = tokens[1];
    connectionStringObject.username = tokens[2] ? decodeURIComponent(tokens[2]) : tokens[2];
    connectionStringObject.password = tokens[3] ? decodeURIComponent(tokens[3]) : tokens[3];
    connectionStringObject.hosts = parseAddress(tokens[4]);
    connectionStringObject.endpoint = tokens[5] ? decodeURIComponent(tokens[5]) : tokens[5];
    connectionStringObject.options = tokens[6] ? parseOptions(tokens[6]) : tokens[6];
  }
  return connectionStringObject;
}

Use the parseURI() function to parse URI string. Look at the code example:

// MongoDB connection string as example
const uri = 'mongodb://user:pass@host1:27017,host2:27017/db?option1=value1&option2=value2';
// parse this string
const params = parseURI(uri);
// show parsed parameters
console.log(params);
// {
//   scheme: 'mongodb',
//   username: 'user',
//   password: 'pass',
//   hosts: [ { host: 'host1', port: 27017 }, { host: 'host2', port: 27017 } ],
//   endpoint: 'db',
//   options: { option1: 'value1', option2: 'value2' }
// }

This simple yet powerful parser efficiently breaks down a URI connection string into usable components. It’s especially useful when dealing with multiple hosts or various options in connection strings. Experiment with different URIs to see its in action.

This post demonstrates how to create and verify JWTs using the Web Crypto API available in modern browsers and Node.js (v15+). We’ll focus on the HS256 algorithm (HMAC with SHA-256).

A JWT consists of three parts separated by dots (.):

1. Header: Contains metadata about the token, like the signing algorithm (alg) and token type (typ).
2. Payload: Contains the claims (the actual data), such as user ID, name, roles, etc.
3. Signature: Used to verify the sender of the JWT and ensure that the message wasn’t changed along the way.

All parts are Base64Url encoded.

First, we need functions to encode/decode Base64Url and to handle HMAC signatures using the Web Crypto API:

// Base64Url Encoding/Decoding
function encodeBase64Url(source) {
  // Encode ArrayBuffer to Base64 string
  // Then convert Base64 to Base64Url
  return btoa(String.fromCharCode.apply(null, source))
    .replace(/=+$/, '') // Remove padding '='
    .replace(/\+/g, '-') // Replace '+' with '-'
    .replace(/\//g, '_'); // Replace '/' with '_'
}

function decodeBase64Url(source) {
  // Convert Base64Url back to Base64
  source = source.replace(/-/g, '+').replace(/_/g, '/');
  // Pad with '=' to make it valid Base64
  source += '='.repeat((4 - source.length % 4) % 4);
  // Decode Base64 string to original string
  return atob(source);
}

// HMAC Signature Generation
async function createHmacSignature(key, message) {
  const encoder = new TextEncoder();
  const keyData = encoder.encode(key);
  const messageData = encoder.encode(message);
  // Import the secret key for signing
  const cryptoKey = await crypto.subtle.importKey(
    'raw', // key format
    keyData, // key material
    { name: 'HMAC', hash: 'SHA-256' }, // algorithm details
    false, // non-exportable
    ['sign'] // key usages
  );
  // Sign the message
  const signature = await crypto.subtle.sign('HMAC', cryptoKey, messageData);
  return new Uint8Array(signature); // Return signature as Uint8Array
}

// HMAC Signature Verification
async function verifyHmacSignature(key, message, signature) {
  const encoder = new TextEncoder();
  const keyData = encoder.encode(key);
  const messageData = encoder.encode(message);
  // Decode Base64Url signature to Uint8Array
  const signatureData = Uint8Array.from(decodeBase64Url(signature), c => c.charCodeAt(0));
  // Import the secret key for verification
  const cryptoKey = await crypto.subtle.importKey(
    'raw',
    keyData,
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['verify'] // key usage
  );
  // Verify the signature
  return crypto.subtle.verify('HMAC', cryptoKey, signatureData, messageData);
}

Now, let’s combine these to create and verify JWT:

async function createJWT(payload, secret) {
  // Define the header
  const header = { alg: 'HS256', typ: 'JWT' };
  // Encode header and payload
  const encodedHeader = encodeBase64Url(new TextEncoder().encode(JSON.stringify(header)));
  const encodedPayload = encodeBase64Url(new TextEncoder().encode(JSON.stringify(payload)));
  // Create the data to sign (header + '.' + payload)
  const dataToSign = `${encodedHeader}.${encodedPayload}`;
  // Create the signature
  const signature = await createHmacSignature(secret, dataToSign);
  // Encode the signature
  const encodedSignature = encodeBase64Url(signature);
  // Combine all parts into the JWT
  return `${dataToSign}.${encodedSignature}`;
}

async function verifyJWT(token, secret) {
  // Split the token into its parts
  const [header, payload, signature] = token.split('.');
  if (!header || !payload || !signature) {
    throw new Error('Invalid JWT format');
  }

  // Decode and parse the header
  const decodedHeader = JSON.parse(decodeBase64Url(header));
  // Basic header validation
  if (decodedHeader?.alg !== 'HS256' || decodedHeader?.typ !== 'JWT') {
    throw new Error('Invalid JWT header');
  }

  // Prepare the data that was originally signed
  const dataToVerify = `${header}.${payload}`;
  // Verify the signature
  const isValid = await verifyHmacSignature(secret, dataToVerify, signature);
  if (!isValid) {
    throw new Error('Invalid signature');
  }

  // Check if the payload has expired
  const decodedPayload = JSON.parse(decodeBase64Url(payload));
  if (decodedPayload.exp && Date.now() >= decodedPayload.exp * 1000) {
    throw new Error('Token has expired');
  }

  // If signature is valid, return the decoded payload
  return decodedPayload;
}

That’s it. Now we can use it, see the example:

(async () => {
  // Define the secret key used for both signing and verification
  const secret = 'your-256-bit-secret';
  
  // Define a payload with user information. This data will be embedded in the JWT.
  const payload = { exp: ~~(Date.now() / 1000) + 60, name: 'John Doe' };

  // Create a JWT using the payload and the secret key
  const token = await createJWT(payload, secret);
  
  // Log the generated JWT to the console
  console.log('Generated JWT:', token);
  
  try {
    // Verify the JWT using the same secret key to ensure its validity
    const decodedPayload = await verifyJWT(token, secret);
    
    // Log the decoded payload if the verification succeeds
    console.log('Decoded payload:', decodedPayload);
  } catch(err) {
    // Log an error message if verification fails
    console.error('Verification failed:', err);
  }
})();

While libraries abstract away much of this complexity, understanding the underlying mechanics of JWT creation and verification using standard browser APIs can be valuable.