DEV Community: Francesco Di Donato

How to Use a Reverse Trie for Fast Disposable Email Domain Detection

Francesco Di Donato — Fri, 06 Dec 2024 11:25:36 +0000

Learn how to use a reverse Trie to efficiently detect disposable email domains. Optimize your domain lookups with a scalable, memory-efficient solution tailored for fast and precise results.

Read the article on my website
Use the Free Disposable Email Domain Detector

Disposable emails can cause issues like fake signups and spam. The user grabs an address from one of thousands of temporary email generators and hands it over. Not even the GOAT of email regex can save you here.

Personally, I find having a big list of all disposable email domains is the easiest yet most effective solution. But before you assemble that list and start a for ... of loop to check against it, think of the O(n) complexity!

A great way to identify them is by using a reverse Trie, an efficient data structure for fast lookups.

What Is a Reverse Trie?

First, let's grasp what a Trie is. It is a data structure where strings are:

chopped up, char per char
assembled in a tree structure

example, if we feed boa, bro, brie, it would assemble them using Map as:

b
 ├── o ── a
 └── r ── o  
     └─── i ── e

This approach allows direct lookups without cycling through the entire list. Each character guides the search deeper.

It trades memory for efficiency. The time it takes to find the string does not depend on the size of the list, but on the length of the string!

A reverse Trie stores strings in reverse order, ideal for domains:

mailinator.com becomes moc.rotanliam
trashmail.com becomes moc.liambhsart

Note on This Implementatin

By reversing domains, searches start at the TLD (e.g., .com), which is shared across many domains. To optimize further, it stores TLDs as a single key (com), rather than splitting them into characters. The rest of the domain follows a standard Trie structure.

Reverse Trie Domains Implementation

Since this is a tree structure, each node will reference its children:

type TrieNode = Map<string, TrieNode>;

First, a utility function to split the TLD from the rest of the domain:

private splitTLDFromRest(input: string) {
    const dot = input.lastIndexOf('.');
    const TLD = input.substring(dot + 1);
    const rest = input.substring(0, dot);
    return [TLD, rest];
}

Using lastIndexOf ensures subdomains like foo.bar.baz.com are handled correctly.

Next, the constructor will assemble the Trie:

export class ReverseTrieDomains {
    private root: TrieNode = new Map();

    // ...

    constructor(...domains: string[]) {
        for (const domain of domains) {
            // For "didof.dev"
            const [TLD, rest] = this.splitTLDFromRest(domain);
            // dev, didof

            // Keep the refence to the TLD node for final set
            let node = this.root.get(TLD);
            if (!node) node = new Map();

            // Start from TLD node, walk along the string in reverse
            let currentNode: TrieNode = node;
            for (let i = rest.length - 1; i >= 0; i--) {
                const char = rest[i];
                let childNode = currentNode.get(char);
                if (!childNode) {
                    childNode = new Map();
                    currentNode.set(char, childNode);
                }
                currentNode = childNode;
            }

            this.root.set(TLD, node);
        }
    }
}

To check if a domain is disposable, traverse the Trie:

export class ReverseTrieDomains {
    // ...

    public has(domain: string) {
        const [TLD, rest] = this.splitTLDFromRest(domain)

        const node = this.root.get(TLD)
        if (!node) return false

        let currentNode: TrieNode = node
        let isFullDomainFound = false
        for (let i = rest.length - 1; i >= 0; i--) {
            const char = rest[i]
            const childNode = currentNode.get(char)
            if (!childNode) return false
            currentNode = childNode
            if (i === 0) {
                isFullDomainFound = currentNode.size === 0;
            }
        }

        return isFullDomainFound
    }
}

Conclusion

Using a reverse Trie offers several benefits:

Fast Lookups: Traverse characters step-by-step for quick results.
Memory Efficiency: Common suffixes like .com are stored only once.
Scalability: Handles large domain lists effortlessly.

If you’re dealing with disposable emails, this is a smart, scalable solution to implement.

Throttling Explained: A Guide to Managing API Request Limits

Francesco Di Donato — Wed, 04 Dec 2024 18:15:00 +0000

When Should You Implement Throttling in Your Code?

For big projects, it’s usually best to use tools like Cloudflare Rate Limiting or HAProxy. These are powerful, reliable, and take care of the heavy lifting for you.

But for smaller projects—or if you want to learn how things work—you can create your own rate limiter right in your code. Why?

It’s Simple: You’ll build something straightforward that’s easy to understand.
It’s Budget-Friendly: No extra costs beyond hosting your server.
It Works for Small Projects: As long as traffic is low, it keeps things fast and efficient.
It’s Reusable: You can copy it into other projects without setting up new tools or services.

What You Will Learn

By the end of this guide, you’ll know how to build a basic throttler in TypeScript to protect your APIs from being overwhelmed. Here’s what we’ll cover:

Configurable Time Limits: Each blocked attempt increases the lockout duration to prevent abuse.
Request Caps: Set a maximum number of allowed requests. This is especially useful for APIs that involve paid services, like OpenAI.
In-Memory Storage: A simple solution that works without external tools like Redis—ideal for small projects or prototypes.
Per-User Limits: Track requests on a per-user basis using their IPv4 address. We’ll leverage SvelteKit to easily retrieve the client IP with its built-in method.

This guide is designed to be a practical starting point, perfect for developers who want to learn the basics without unnecessary complexity. But it is not production-ready.

Before starting, I want to give the right credits to Lucia's Rate Limiting section.

Throttler Implementation

Let’s define the Throttler class:

export class Throttler {
    private storage = new Map<string, ThrottlingCounter>();

    constructor(private timeoutSeconds: number[]) {}
}

The Throttler constructor accepts a list of timeout durations (timeoutSeconds). Each time a user is blocked, the duration increases progressively based on this list. Eventually, when the final timeout is reached, you could even trigger a callback to permanently ban the user’s IP—though that’s beyond the scope of this guide.

Here’s an example of creating a throttler instance that blocks users for increasing intervals:

const throttler = new Throttler([1, 2, 4, 8, 16]);

This instance will block users the first time for one second. The second time for two, and so on.

We use a Map to store IP addresses and their corresponding data. A Map is ideal because it handles frequent additions and deletions efficiently.

Pro Tip: Use a Map for dynamic data that changes frequently. For static, unchanging data, an object is better. (Rabbit hole ¹)

When your endpoint receives a request, it extracts the user's IP address and consults the Throttler to determine whether the request should be allowed.

How it Works

Case A: New or Inactive User

If the IP is not found in the Throttler, it’s either the user’s first request or they’ve been inactive long enough. In this case:
- Allow the action.
- Track the user by storing their IP with an initial timeout.
Case B: Active User

If the IP is found, it means the user has made previous requests. Here:
- Check if the required wait time (based on the timeoutSeconds array) has passed since their last block.
- If enough time has passed:
- Update the timestamp.
- Increment the timeout index (capped to the last index to prevent overflow).
- If not, deny the request.

In this latter case, we need to check if enough time is passed since last block. We know which of the timeoutSeconds we should refer thank to an index. If not, simply bounce back. Otherwise update the timestamp.

export class Throttler {
    // ...

    public consume(key: string): boolean {
        const counter = this.storage.get(key) ?? null;
        const now = Date.now();

        // Case A
        if (counter === null) {
            // At next request, will be found.
            // The index 0 of [1, 2, 4, 8, 16] returns 1.
            // That's the amount of seconds it will have to wait.
            this.storage.set(key, {
                index: 0,
                updatedAt: now
            });
            return true; // allowed
        }

        // Case B
        const timeoutMs = this.timeoutSeconds[counter.index] * 1000;
        const allowed = now - counter.updatedAt >= timeoutMs;
        if (!allowed) {
            return false; // denied
        }

        // Allow the call, but increment timeout for following requests.
        counter.updatedAt = now;
        counter.index = Math.min(counter.index + 1, this.timeoutSeconds.length - 1);
        this.storage.set(key, counter);

        return true; // allowed
    }
}

When updating the index, it caps to the last index of timeoutSeconds. Without it, counter.index + 1 would overflow it and next this.timeoutSeconds[counter.index] access would result in a runtime error.

Endpoint example

This example shows how to use the Throttler to limit how often a user can call your API. If the user makes too many requests, they’ll get an error instead of running the main logic.

const throttler = new Throttler([1, 2, 4, 8, 16, 30, 60, 300]);

export async function GET({ getClientAddress }) {
    const IP = getClientAddress();

    if (!throttler.consume(IP)) {
        throw error(429, { message: 'Too Many Requests' });
    }

    // Read from DB, call OpenAI - do the thing.

    return new Response(null, { status: 200 });
}

Note for Authentication

When using rate limiting with login systems, you might face this issue:

A user logs in, triggering the Throttler to associate a timeout with their IP.
The user logs out or their session ends (e.g., logs out immediately, cookie expires with session and browsers crashes, etc.).
When they try to log in again shortly after, the Throttler may still block them, returning a 429 Too Many Requests error.

To prevent this, use the user’s unique userID instead of their IP for rate limiting. Also, you must reset the throttler state after a successful login to avoid unnecessary blocks.

Add a reset method to the Throttler class:

export class Throttler {
    // ...

    public reset(key: string): void {
        this.storage.delete(key);
    }
}

And use it after a successful login:

const user = db.get(email);

if (!throttler.consume(user.ID)) {
    throw error(429);
}

const validPassword = verifyPassword(user.password, providedPassword);
if (!validPassword) {
    throw error(401);
}

throttler.reset(user.id); // Clear throttling for the user

Managing Stale IP Records with Periodic Cleanup

As your throttler tracks IPs and rate limits, it's important to think about how and when to remove IP records that are no longer needed. Without a cleanup mechanism, your throttler will continue to store records in memory, potentially leading to performance issues over time as the data grows.

To prevent this, you can implement a cleanup function that periodically removes old records after a certain period of inactivity. Here's an example of how to add a simple cleanup method to remove stale entries from the throttler.

export class Throttler {
    // ...

    public cleanup(): void {
        const now = Date.now()

        // Capture the keys first to avoid issues during iteration (we use .delete)
        const keys = Array.from(this.storage.keys())

        for (const key of keys) {
            const counter = this.storage.get(key)
            if (!counter) {
                // Skip if the counter is already deleted (handles concurrency issues)
                return
            }

            // If the IP is at the first timeout, remove it from storage
            if (counter.index == 0) {
                this.storage.delete(key)
                continue
            }

            // Otherwise, reduce the timeout index and update the timestamp
            counter.index -= 1
            counter.updatedAt = now
            this.storage.set(key, counter)
        }
    }
}

A very simple way (but probably not the best) way to schedule the cleanup is with setInterval:

const throttler = new Throttler([1, 2, 4, 8, 16, 30, 60, 300])
const oneMinute = 60_000
setInterval(() => throttler.cleanup(), oneMinute)

This cleanup mechanism helps ensure that your throttler doesn't hold onto old records indefinitely, keeping your application efficient. While this approach is simple and easy to implement, it may need further refinement for more complex use cases (e.g., using more advanced scheduling or handling high concurrency).

With periodic cleanup, you prevent memory bloat and ensure that users who haven’t attempted to make requests in a while are no longer tracked - this is a first step toward making your rate-limiting system both scalable and resource-efficient.

If you’re feeling adventurous, you may be interested into reading how properties are allocared and how it changes. Also, why not, about VMs optmizations like inline caches, which is particularly favored by monomorphism. Enjoy. ↩

Optimizing Three.js: 4 Key Techniques

Francesco Di Donato — Fri, 29 Nov 2024 13:50:56 +0000

Code can be art. Whether it's in clever syntax, elegant data structures, or refined interactions, there’s beauty only programmers see—and that’s fine.

But code can also create something visually stunning, something everyone can appreciate. This is where tools like Three.js shine. However, Three.js can be heavy, especially when used in a dynamic web page accessed by devices with varying computational power.

If you’re like me, adding multiple Three.js scenes to your site (as I do on didof.dev), you’ll need optimizations. Here are three practical techniques to keep performance in check.

Originally posted on my blog.

Load Scenes Only When Needed

Don’t load a scene if it’s not visible. This applies to any heavy graphical component. The best tool for this is IntersectionObserver, which detects when an element enters the viewport. Here's how I handle it in SvelteKit:

<script lang="ts">
    import { browser } from '$app/environment';
    import { onMount } from 'svelte';

    let ref: HTMLDivElement;
    let download = $state(false);
    if (browser)
        onMount(() => {
            const observer = new IntersectionObserver(([entry]) => {
                if (entry.isIntersecting) {
                    download = true;

                    // we need this once only
                    observer.disconnect();
                }
            });
            // ref has been bound by Svelte since we are in onMount
            observer.observe(ref);

            return () => observer.disconnect();
        });
</script>

<div bind:this={ref}>
    {#if download}
        <!-- let SvelteKit handle the code splitting -->
        {#await import('./three-scene.svelte')}
            Loading
        {:then module}
            <module.default />
        {:catch error}
            <div>{error}</div>
        {/await}
    {/if}
</div>

Pause Scenes Out of View

If a scene isn’t visible, stop rendering it. Most tutorials focus on a single fullscreen scene, but for sites with multiple scenes, pausing hidden ones saves resources.

Here’s a snippet using IntersectionObserver to control a scene’s animation loop:

function tick() {
    const elapsedTime = clock.getElapsedTime();

    // Update your scene (e.g. set uniforms, move/rotate geometries...)

    renderer.render(scene, camera);
}

// Start the rendering
renderer.setAnimationLoop(tick);

Once again, our friend IntersectionObserver comes to our aid.

let clock: THREE.Clock;
let renderer: THREE.WebGLRenderer;

if (browser)
    onMount(() => {
        const observer = new IntersectionObserver(([entry]) => {
            if (entry.isIntersecting) {
                clock.start();
                renderer.setAnimationLoop(tick); // resume
            } else {
                clock.stop();
                renderer.setAnimationLoop(null); // pause
            }
        });
        observer.observe(canvas);

        // Scene setup...

        return () => {
            observer.disconnect();

            // Other cleanup...
        };
    });

Adjust Shader Workload for Viewport Size

Devices with smaller screens are often less powerful. Adapt your shader’s computational workload accordingly. For example, reduce the number of octaves used in a fractal shader based on the viewport width:

from the browser...

<script lang="ts">
    import ThreeScene from "./three-scene.svelte";
    import { browser } from '$app/environment';

    const octaves = browser ? (window.innerWidth <= 680 ? 2 : 4) : 1
</script>

<ThreeScene {octaves} />

...through three.js...

const material = new THREE.ShaderMaterial({
    vertexShader,
    fragmentShader,
    uniforms: {
        uOctaves: new Three.Uniform(octaves) // coming as $prop
    }
});

...finally, in the shader.

uniform float uOctaves;

for(float i = 0.0; i <= uOctaves; i++)
{
    elevation += simplexNoise2d(warpedPosition * uPositionFrequency * pow(2.0, i)) /  pow(2.0, i + 1.0);
}

This approach dynamically balances performance and visual quality.

Let the Browser Handle Clean up

Here’s where things get tricky. Three.js doesn’t automatically clean up memory, and you need to manually track and dispose of objects like geometries, textures, and materials. If you skip this, memory usage grows every time you navigate away and back, eventually crashing the browser.

Let me share what I observed on my homepage:

Initial memory usage: 22.4MB

After soft-navigation to another page: 28.6MB (even though that page was static HTML).

After repeated navigation back and forth: Memory usage kept climbing until the browser crashed.

Why? Because Three.js objects weren’t being disposed of properly. And despite extensive research, I couldn’t find a reliable way to fully clean up memory in modern frameworks.

Here’s the simplest solution I found: force a hard-reload when leaving pages with Three.js scenes. A hard-reload lets the browser:

Create a new page context.
Perform garbage collection on the old page (leaving cleanup to the browser).

In SvelteKit, this is easy with data-sveltekit-reload. Just enable it for pages with scenes:

homepage's +server.page.ts

export function load() {
    return {
        sveltekitReload: true
    }
}

For navigation links, pass this value dynamically:

<script lang="ts">
    import { page } from '$app/stores';
</script>

<a href="/docs" data-sveltekit-reload={$page.data.sveltekitReload}>Docs</a>

If you use a generic <Link> component, you only need to implement this once.

This approach isn’t perfect—it disables smooth client-side routing for specific pages—but it keeps memory in check and prevents crashes. For me, that trade-off is worth it.

Final Thoughts

These optimizations have worked well for me, but the question remains: how do we properly clean up Three.js objects in modern frameworks? If you’ve found a reliable solution, I’d love to hear from you!

Radial Gradient Generator

Francesco Di Donato — Thu, 28 Nov 2024 12:37:09 +0000

After over five years in the IT industry, I've accumulated a wealth of internal tools and resources that I believe could benefit others. To share this knowledge, I've decided to launch a dedicated section on my personal website.

Today, I'm excited to introduce the Radial Gradient Generator—a simple, web-based tool that allows you to create stunning radial gradients effortlessly.

Go to Radial Gradient Generator

What it offers

Stackable Shades

Add as many shades as you like to create complex gradients.

Customizable Options

Define the color, position, and blur for each shade to achieve your desired look.

Easy Integration

With just one click, you can copy your gradient and paste it directly into your website. There are no dependencies of course.

Examples

These gradients serve as perfect placeholders or can be used to enhance your designs. I left some examples on my website.

Feel free to use the Radial Gradient Generator and let me know your thoughts! Your feedback is invaluable as I continue to improve this tool and share more resources in the future.

How to have Perfect Contrast of Text Color on Any Background in TailwindCSS

Francesco Di Donato — Fri, 17 May 2024 10:11:40 +0000

You can read the interactive version of this blog post!

The Problem

In recent years I have developed a good number of websites. The basic structure is usually similar among them, but there are some tasks that always require a lot of effort. And, coincidentally, they are precisely the most tedious and complicated ones. Especially styling and choosing the colors of the website.

There are quite a few palette generators around the web, but all of them leave you with just a bunch of hexs and rgbs — it’s up to you to join those into your system.

As if managing a theme was not enough, you were perhaps required to add the dark mode! The TailwindCSS team proposes to do this by wandering around the template, adding classes prefixed with dark: to instruct each element about its appearance when the selected theme is dark.

This is imho not optimal since, in addition to bloating the template even more, it would require manual work should I be asked to change some colors. And what if I want a third or even fourth theme?

The Real Problem

I’ve been living with this problem peacefully until, after spending too many days hunting for html tags to slightly change their shades, I realized that, alas, the text was no longer readable - it lacked contrast.

Lighthouse accessibility check, unconcerned about my emotional state, lowered the score.

I don’t want to have to think about this problem anymore.

The Solution

I have come up with a system that allows for an unlimited number of themes, each with an unlimited amount of colors. Most importantly, that ensures that the text is always readable on any color.

Basic usage involves configuring at least two themes, light mode and dark mode.

Each theme requires at least five colors. They are background, neutral (useful for card backgrounds), primary, secondary and accent.

No one is stopping you from adding others like success, warning, error… you name it — it is completely configurable!

For each of them, the TailwindCSS utilities and components are produced and available. It means you can not only add a bg-secondary-300 here and a border-t-neutral-500 there, but you get fancy stuff for free — IDE autocomplete included:



<div class="bg-gradient-to-br
  from-primary-300 via-accent-500 to-secondary-700
  shadow-accent-500"
/>

Text perfect contrast

Thanks to a simple plugin (no need to install anything), some contrast dedicated classes are generated (and available in the IDE autocomplete). They follow the pattern text-wacg-<color>-<shade>.

You can try real-time widgets on my blog post!



<div class="bg-primary-500 text-wacg-primary-500">
    This text will always be readable
</div>

This is easily obtainable with my free online tool.

Benefits

Read more about the other convenient benefits:

Framework agnostic

It is adoptable in any framework: React, Next.js, Vue, Nuxt, Angular, Svelte, SvelteKit, Sapper, Laravel, Spring, Rails, Django, Express, Hugo, Solid.js, Astro.js, Preact, Ember.js, Alpine.js, LitElement, JQuery and any other I may have omitted.

Zero dependencies

I have opted for a dependency-free solution. As a developer, I do not like to install packages unless it is strictly necessary. Mainly because I know how dangerous it can be — supply chain attack gettin’ real!

This solution is not a black box, and a few paragraph below you can appreciate how simple yet powerful it is.

CSS Only

This solution minimizes JavaScript usage at runtime, leveraging CSS for the majority of heavy lifting.

IDE autocomplete

All the palette colors are utilized to generate all the TailwindCSS utilities (bg-primary-500, border-l-neutral-300, etc…), complete with IDE autocompletion. Additionally, any unused elements are purged by TailwindCSS, ensuring they are not present in the final CSS output.

Browser support

The system is based on two CSS features:

var, which allows the declaration and usage of cascading variables in stylesheets, has support on 97.32% of browsers.
calc, which allows to calculate values directly into CSS, is supported in 98.19% of all browsers. Stay tuned to learn how it works — otherwise you can already use the free online tool.

FaQ

Q: Why do I have to explicitly set the text-wacg class? Couldn’t it be implicit in the background one?

A: It could, but I learned to appreciate explicitness.

Web Perf - Large Files

Francesco Di Donato — Tue, 28 Nov 2023 16:30:00 +0000

When you have a lot of information to show on the screen, there are two common choices:

pagination
streaming

But you know what? You can also just send the whole thing to the user. Let's explore this straightforward approach together.

Headers

We'll explore three crucial headers - Content-Length, Content-Encoding, and Transfer-Encoding - and see how different combinations of these headers can influence the rendering on the browser.

`Content-Length`

It specifies the size of the payload in bytes. It helps the recipient (in our case, the browser) know how much data to expect. It's like a heads-up, ensuring everyone is on the same page about the amount of content coming their way.

`Content-Encoding`

It tells the browser how the content is encoded or compressed. It's like a secret code that both the server and the browser understand. Common encodings include gzip and deflate. When the browser sees this header, it knows how to decode the content for a smooth display.

`Transfer-Encoding`

This less-known header handles the encoding of the message itself during transmission. It can be sent all at once (like a single big parcel) or in smaller pieces (like breaking it into multiple smaller packages).

Server

To see how the browser reacts to different combinations of these headers, let's set up a basic Node.js HTTP server.

The server is designed to handle incoming requests for any path, offering flexibility through optional query parameters:

content-length: If set to true, this parameter adds the Content-Length header to the response.
transfer: This parameter sets the Transfer-Encoding header, with options for:
- identity: Instruct the server to send the document as a whole.
- chunked: Directs the server to send the document in chunks.
gzip: If set to true, the server retrieves the zipped version of the file. In this case, the Content-Length (if set) reflects the size of the zipped version.

Support Code

index.mjs

import { createServer } from "http";
import { getView, combinations } from "./src/utils.mjs";

createServer(async (req, res) => {
  const { searchParams: sp } = new URL(req.url, "http://127.0.0.1:8000");

  // Ready query params
  const length = sp.get("content-length") === "true" || false;
  const gzip = sp.get("gzip") === "true" || false;
  const identity = sp.get("identity") === "true" || false;

  // Either index.html or index.html.gz
  let view = "index.html";
  if (gzip) view += ".gz";

  const [data, stats, _] = await getView(view);

  res.setHeader("Content-Type", "text/html");

  if (length) res.setHeader("Content-Length", stats.size);

  if (gzip) res.setHeader("Content-Encoding", "gzip");

  if (identity) res.setHeader("Transfer-Encoding", "identity")

  return res.writeHead(200).end(data);
}).listen(8000, "127.0.0.1", () => {
  console.info(combinations().join("\n"));
});

src/utils.mjs

import { resolve } from "path";
import { readFile, stat } from "fs/promises";

const root = resolve(new URL(".", import.meta.url).pathname, "..");

export async function getView(name, encoding) {
  const filepath = resolve(root, "src", "views", name);

  const [data, stats] = await Promise.allSettled([
    readFile(filepath, encoding),
    stat(filepath),
  ]);
  if (data.status === "rejected")
    return [null, null, new Error("could not retrieve data")];
  if (stats.status === "rejected")
    return [null, null, new Error("could not retrieve stats")];

  return [data.value, stats.value, null];
}

// Ignore if not running on your machine.
export function createURL(
  { gzip, length, identity } = {
    gzip: false,
    length: false,
    identity: false,
  }
) {
  // Use pathname so that in Developer Tools you can filter out the favicon.
  const url = new URL("big", "http://127.0.0.1:8000");
  if (gzip) url.searchParams.set("gzip", "true");
  if (length) url.searchParams.set("content-length", "true");
  if (identity) url.searchParams.set("identity", "true");
  return url.toString();
}

// Ignore if not running on your machine.
export function combinations() {
  const urls = [createURL()];
  for (const gzip of [false, true]) {
    for (const length of [false, true]) {
      for (const identity of [false, true]) {
        urls.push(
          createURL({
            gzip,
            length,
            identity,
          })
        );
      }
    }
  }
  return urls;
}

The content within the HTML files is not the focus; their substantial size is (AKA they're LARGE).

These files are maintained in two versions: plain and gzipped. While it's generally not a recommended practice for real servers to adopt dual storage, here the intent is to avoid introducing additional overhead in the case of zipping.

Testing

I'll now test the server using Firefox, monitoring how response times vary with changes in the headers. If you're following along on your machine, make sure to disable the cache and consider checking the 'Preserve logs' checkbox for a more accurate observation.

Initially, we make a request without query parameters, letting the Node.js HTTP server handle it by default. The default Transfer-Encoding observed is chunked, aligning with the behavior of passing ?transfer=chunked. Node.js aims to be non-blocking, and this choice ensures smoother processing.

Now, let's spice things up by passing the query parameter ?transfer=identity. This time, the request takes notably longer to complete.

To remedy this, we introduce the Content-Length header with ?content-length=true&identity=true, resulting in a significant reduction in duration. It's like mailing a package in one piece. Including the Content-Length header is the friendly note that says, 'Hey, your package is this big!'. Without it, the client might fumble guessing the size, leading to some awkward data processing moments.

🔑 message
In 'identity' mode, be a good server and always attach that Content-Length header.

As a final observation, we note that the presence of the Content-Length has no impact when the transfer method is set to chunked.

🔑 message
Not only there's no need for the Content-Length header`, but using both is actually contradictory.
In 'chunked' encoding, the size of each chunk is self-contained, and a final zero-size chunk does the job of marking the end of the response.

Compression

When using the gzip-compressed resource, the behavior aligns with what we've just explored. In the identity transfer mode, it remains crucial to provide information about the content length, regardless of the content encoding.

Now, let's talk about compression benefits and a trade-off. Opting for gzip compression offers two wins:

it conserves disk storage on your server.
it trims down on bandwidth usage.

However, there's a catch - the browser has to roll up its sleeves and put in a bit more effort to decompress.

If you are interested in Web Performance you definitely need to know about Web Caching (posts series).

Web Caching - Cache-Control max-age, stale-while-revalidate

Francesco Di Donato — Thu, 23 Nov 2023 17:00:00 +0000

Until now, thanks to Last-Modified/If-Modified-Since or ETag/If-None-Match we mainly saved on bandwidth. However, the server always had to process each request.

The server can instruct the client about using the stored resources for a certain duration, deciding if and when the client should revalidate the content and whether or not to do so in the background.

Support code

Real-world endpoints are not as instantaneous as those in this tutorial. The response may take milliseconds to generate, without even considering the location of the server relative to the requester!

Let's exacerbate the asynchronicity between server and client to highlight the need for the Cache-Control Header.



// src/utils.mjs
export async function sleep(duration) {
  return new Promise((resolve) => setTimeout(resolve, duration));
}

Based on the previously implemented /only-etag endpoint, register /cache-control-with-etag. For the time being, it's identical, except that it waits three seconds before responding.
Also, add some log before dispatching the response



export default async (req, res) => {
  console.info("Load on the server!");

  work; // computation;

  await sleep(3000) // simulate async.

  const etag = createETag(html);
  res.setHeader("ETag", etag);
  const ifNoneMatch = new Headers(req.headers).get("If-None-Match");
  if (ifNoneMatch === etag) {
    res.writeHead(304).end();
    return;
  }

  res.writeHead(200).end(html);
};

Let's visualize the problem. When you request a page from the browser, it enters a loading state for three seconds. Even if you refresh within that time, the browser makes the request anew, regardless of the ETag or the Last-Modified mechanisms. The page content persists because you're essentially staying on the same page. To observe the behavior more clearly, try reopening the page from a new tab or starting from a different site.

Most importantly, the server is hit on every request!

max-age

It is possible to instruct the browser to use the cached version for a certain duration. The server will set the Response Header Cache-Control with a value of max-age=<seconds>.



export default async (req, res) => {
  console.info("Load on the server!");

  work; // db retrieval and templating;

  await sleep(3000) // simulate async.

  // Instruct the browser to use the cached resource
  // for 60 * 60 seconds = 1 hour
  res.setHeader("Cache-Control", "max-age: 3600");

  etag; // as seen before
  // 200 or 304
};

Give it another try now, and request the page. The first request makes the browser load for three seconds. If you open the same page in another tab, you'll notice it's already there, and the server wasn't contacted.

This behavior persists for the specified seconds. If, after the cache expires, a new request returns a 304 Not Modified (thanks to the If-None-Match header), the resource will be newly cached for that amount of time.

➕ Better UX
➕ Less load on the server
❔ If the resource changes, the client remains unaware until the cache expires. After expiration, with a different Etag, a new version will be displayed and cached.

When attempting a refresh while staying on the page, you might observe the loading delay, indicating that the server is being contacted. Make sure you're not doing a hard refresh, as it overrides the described behavior.

stale-while-revalidate

If your application needs resource validation but you still want to show the cached version for a better user experience when available, you can use the stale-while-revalidate=<seconds> directive.



res.setHeader("Cache-Control",
   "max-age=120, stale-while-revalidate=300"
);

In this case, the browser is instructed to cache the response for 2 minutes. Once this period elapses, if the resource is requested within the next 5 minutes, the browser will use the cached resource (even if it's stale) but will perform a background validation call.

I want to emphasize the "even if stale" by playing around with the endpoint configured as above. Only soft refreshes are performed.

ℹ️ Info
Tap/click the next items to show the related graph.

1. On the initial page request, it takes 3 seconds to load, and the response is cached for 2 minutes with an associated ETag. The client will include this ETag in the If-None-Match header for subsequent requests.

2. Close and reopen the browser (or request from another page) within the 2-minute window: the page is instantly shown without hitting the server.

3. After the 2-minute cache expires, the server is contacted. The resource has not changed, the client receives 304 Not Modified. The cache expiry date is extended with the provided max-age value. No need to update what the user is seeing.

4. Now that the 2-minute window is open again, let's update the content of the resource using the db endpoint implemented in the previous blog post. Basically, next time the ETag will not match.



curl -X POST http://127.0.0.1:8000/db \
-d '{ "title": "ETag", "tag": "code" }'

5. Still within the 2-minute window, request the page again. Thanks to max-age, the browser shows it immediately. It proceeds with background validation as already seen in step 3. But this time the ETag does not match; the server responds with a 200 OK and provides a new ETag (which overrides the previous entry in the cache).

🔑 message
Although the displayed content is stale, the browser updates its cache silently, preserving the user experience.

Request the page anew; this time, it finally displays the latest stored version. If within the newly restarted 2-minute window, the server won't be contacted.

🔑 message
Any request outside the time window indicated by stale-while-revalidate (which I recall, starts from the expiration of that of max-age), will behave like step 1 - blank state.

Web Caching - ETag/If-None-Match

Francesco Di Donato — Tue, 21 Nov 2023 15:40:00 +0000

Support code

In the previous post, we explored the usefulness of the Last-Modified Response Header and If-Modified-Since Request Header. They work really well when dealing with an endpoint returning a file.

What about data retrieved from a database or assembled from different sources?

Request	Response	Value example
`Last-Modified`	`If-Modified-Since`	`Thu, 15 Nov 2023 19:18:46 GMT`
`ETag`	`If-None-Match`	`75e7b6f64078bb53b7aaab5c457de56f`

Also here, we have a tuple of headers. One must be provided by the requester (ETag), while the other is returned by the sender (If-None-Match). The value is a hash generated on the content of the response.

If you want to go directly to using headers, go to the endpoint. Otherwise, observe (but don't spend too much time on) the implementation.

Preparation

For simplicity, we use an in-memory DB. It is exposed via the endpoint /db. It contains a list of posts. Each post contains a title and a tag. Posts can be added via POST, and modified via PATCH.

Retrieval is via a GET function, which optionally filters by tag.

src/db.mjs



import { getJSONBody } from "./utils.mjs";

const POSTS = [
  { title: "Caching", tag: "code" },
  { title: "Headers", tag: "code" },
  { title: "Dogs", tag: "animals" },
];

export function GET(tag) {
  let posts = POSTS;
  if (tag) posts = posts.filter((post) => post.tag === tag);
  return posts;
}

export default async function db(req, res) {
  switch (req.method) {
    case "POST": {
      const [body, err] = await getJSONBody(req);
      if (err) {
        res.writeHead(500).end("Something went wrong");
        return;
      }

      POSTS.push(body);
      res.writeHead(201).end();
      return;
    }
    case "PATCH":
      const [body, err] = await getJSONBody(req);
      if (err) {
        res.writeHead(500).end("Something went wrong");
        return;
      }

      POSTS.at(body.index).title = body.title;
      res.writeHead(200).end();
      return;
  }
}

src/utils.mjs



export function getURL(req) {
  return new URL(req.url, `http://${req.headers.host}`);
}

export async function getJSONBody(req) {
  return new Promise((resolve) => {
    let body = "";
    req.on("data", (chunk) => (body += chunk));
    req.on("error", (err) => resolve([null, err]));
    req.on("end", () => resolve([JSON.parse(body), null]));
  });
}

Endpoint

By registering the db, we will be able to modify the content of the responses in real-time, appreciating the usefulness of ETag.
Also, let's register and create the /only-etag endpoint.



// src/index.mjs
import { createServer } from "http";
import db from ".src/db.mjs";
import onlyETag from "./src/only-etag.mjs";
import { getURL } from "./src/utils.mjs";

createServer(async (req, res) => {
  switch (getURL(req).pathname) {
    case "/only-etag":
      return await onlyETag(req, res);
    case "/db":
      return await db(req, res);
  }
}).listen(8000, "127.0.0.1", () =>
  console.info("Exposed on http://127.0.0.1:8000")
);

The onlyETag endpoint accepts an optional query parameter tag. If present, it is used to filter the retrieved posts.
Thus, the template is loaded in memory.

src/views/posts.html



<html>
  <body>
    <h1>Tag: %TAG%</h1>
    <ul>%POSTS%</ul>
    <form method="GET">
      <input type="text" name="tag" id="tag" autofocus />
      <input type="submit" value="filter" />
    </form>
  </body>
</html>

When submitted, the form uses as action the current route (/only-etag) appending as query parameter the name attribute. For example, typing code in the input and submitting the form would result in GET /only-etag?name=code), No JavaScript required!

And the posts are injected into it.



import * as db from "./db.mjs";
import { getURL, getView, createETag } from "./utils.mjs";

export default async (req, res) => {
  res.setHeader("Content-Type", "text/html");

  const tag = getURL(req).searchParams.get("tag");
  const posts = await db.GET(tag);

  let [html, errView] = await getView("posts");
  if (errView) {
    res.writeHead(500).end("Internal Server Error");
    return;
  }

  html = html.replace("%TAG%", tag ?? "all");
  html = html.replace(
    "%POSTS%",
    posts.map((post) => `<li>${post.title}</li>`).join("\n")
  );

  res.setHeader("ETag", createETag(html));

  res.writeHead(200).end(html);
};

As you notice, before dispatching the response, the ETag is generated and included under the ETag Response header.



// src/utils.mjs
import { createHash } from "crypto";

export function createETag(resource) {
  return createHash("md5").update(resource).digest("hex");
}

Changing the content of the resource changes the Entity Tag.

Performing the request from the browser you can inspect the Response Headers via the Network tab of the Developer Tools.



HTTP/1.1 200 OK
Content-Type: text/html
ETag: 4775245bd90ebbda2a81ccdd84da72b3

If you refresh the page, you'll notice the browser adding the If-None-Match header to the request. The value corresponds of course to the one it received before.



GET /only-etag HTTP/1.1
If-None-Match: 4775245bd90ebbda2a81ccdd84da72b3

As seen in the previous posts per Last-Modified and If-Modified-Since, let's instruct the endpoint to deal with If-None-Match.



export default async (req, res) => {
  res.setHeader("Content-Type", "text/html");

  retrieve (filtered) posts; // as seen before
  load html; // as seen before
  fill template; // as seen before

  const etag = createETag(html);
  res.setHeader("ETag", etag);
  const ifNoneMatch = new Headers(req.headers).get("If-None-Match");
  if (ifNoneMatch === etag) {
    res.writeHead(304).end();
    return;
  }

  res.writeHead(200).end(html);
};

Indeed, subsequent requests on the same resource return 304 Not Modified, instructing the browser to use previously stored resources. Let's request:

/only-etag three times in a row;
/only-etag?tag=code twice;
/only-etag?tag=animals twice;
/only-etag, without tag, once again;

The presence of the query parameter determines a change in response, thus in ETag.

Notice the last one. It does not matter that there have been other requests in the meantime; the browser keeps a map of requests (including the query parameters) and ETags.

Detect entity change

To further underscore the significance of this feature, let's add a new post to the DB from another process.



curl -X POST http://127.0.0.1:8000/db \
-d '{ "title": "ETag", "tag": "code" }'

And request again /only-etag?tag=code.

After the db has been updated, the same request generated a different ETag. Thus, the server sent the client a new version of the resource, with a newly generated ETag. Subsequent requests will fall back to the expected behavior.

The same happens if we modify an element of the response.



curl -X PATCH http://127.0.0.1:8000/db \
-d '{ "title": "Amazing Caching", "index": 0 }'

While ETag is a more versatile solution, applicable regardless of the data type since it is content-based, it should be considered that the server must still retrieve and assemble the response, then pass it into the hashing function and compare it with the received value.

Thanks to another header, Cache-Control, it is possible to optimize the number of requests the server has to process.

Web Caching - Last-Modified/If-Modified-Since

Francesco Di Donato — Thu, 16 Nov 2023 13:12:15 +0000

Less load on the server and less bandwidth usage for the same result? Where should I sign up? Nowhere, you just need to know the right headers.

Support code

Let's keep it simple - NodeJS, no dependencies. Build with me some endpoints, each using different headers, and find out how the browser behaves based on the headers received.

Go directly to the /no-headers endpoint or take a (very quick) look at the easiest server there is.

index.mj

import { createServer } from "http";
import noHeaders from "./src/index.mjs";

createServer((req, res) => {
  switch (req.url) {
    case "/no-headers":
      return noHeaders(req, res);
  }
}).listen(8000, "127.0.0.1", () =>
  console.info("Exposed on http://127.0.0.1:8000")
);

src/utils.mjs

import fs from "fs/promises";
import path from "path";

export function to(promise) {
  return promise.then((res) => [res, null]).catch((err) => [null, err]);
}

export async function getView(name) {
  const filepath = path.resolve(
    process.cwd(),
    "src",
    "views",
    name + ".html"
  );
  return await to(fs.readFile(filepath, "utf-8"));
}

export async function getViewStats(name) {
  const filepath = path.resolve(process.cwd(), "src", "views", name + ".html");
  return await to(fs.stat(filepath));
}

Add an HTML file at src/views/index.html. Its content is irrelevant.

No Headers - Endpoint

It simply reads the file and sends it to the requester. Apart from the Content-Type, no caching-related header is added.

// src/no-headers.mjs
import { getView } from "./utils.mjs";

export default async (req, res) => {
  res.setHeader("Content-Type", "text/html");

  const [html, err] = await getView("index");
  if (err) {
    res.writeHead(500).end("Internal Server Error");
    return;
  }

  res.writeHead(200).end(html);
};

Start the server (node index.mjs), open /no-headers, and check the developer tools > network tab. Enable preserver log and hit refresh a few times.

Open any of them, and check the Response Headers - there is nothing related to caching, and the browser obeys.

HTTP/1.1 200 OK
Content-Type: text/html
Date: <date>
Connection: keep-alive
Keep-Alive: timeout=5
Transfer-Encoding: chunked

Last-Modified - Endpoint

Spec

Create a new endpoint (to be registered at the url /last-modified). It reads the modification time of the file (mtime) and adds it formatted as UTC under the Last-Modified header.

// src/last-modified.mjs
import { getView, getViewStats } from "./utils.mjs";

export default async (req, res) => {
  res.setHeader("Content-Type", "text/html");

  const [stats, errStats] = await getViewStats("index");
  if (errStats) {
    res.writeHead(500).end("Internal Server Error");
    return;
  }

  const lastModified = new Date(stats.mtime);
  res.setHeader("Last-Modified", lastModified.toUTCString());

  const [html, errGet] = await getView("index");
  if (errGet) {
    res.writeHead(500).end("Internal Server Error");
    return;
  }

  res.writeHead(200).end(html);
};

In fact, among the response headers to /last-modified, you find:

HTTP/1.1 200 OK
Last-Modified: Thu, 15 Nov 2023 19:18:46 GMT

Anyway, if you refresh the page, the entire resource is still downloaded.

Yet something changed - the browser found Last-Modified, so it reuses the value for the If-Modified-Since Request Header. The serve receives that value and, if the condition is found to be not true (not modified since), returns the status 304 Not Modified.

import { getView, getViewStats } from "./utils.mjs";

export default async (req, res) => {
  res.setHeader("Content-Type", "text/html");

  const [stats, _] = await getViewStats("index");

  const lastModified = new Date(stats.mtime);
  lastModified.setMilliseconds(0); // IMPORTANT
  res.setHeader("Last-Modified", lastModified.toUTCString());

  const ifModifiedSince = new Headers(req.headers).get("If-Modified-Since");
  if (
    ifModifiedSince &&
    new Date(ifModifiedSince).getTime() >= lastModified.getTime()
  ) {
    res.writeHead(304).end();
    return;
  }

  // This is done ONLY IF it was not a 304!
  const [html, _] = await getView("index");

  res.writeHead(200, headers).end(html);
};

By spec Last-Modified

Note:

The Response Header Last-Modified is always added, even in the case of 304 Not Modified.
The Request Header if-modified-since may not be present - definitely happens on the first call from a new client.

Most importantly, HTTP dates are always expressed in GMT, never in local time.

While formatting a date using toUTCString, you may observe that the resulting string loses information about milliseconds. However mtime retains millisecond precision - it may have a few milliseconds more than the value received from the client, which, after formatting, loses those milliseconds.

To ensure a valid comparison between the two values, it becomes necessary to remove the milliseconds from the mtime before performing the comparison.

lastModified.setMilliseconds(0);

Finally, request the resource few times.

Now, just go and update the HTML file. Then ask the browser to refresh and expect to receive a 200 OK Response.

It's essential to recognize that the 304 response is consistently more lightweight than the 200 response. Beyond just the reduced data payload, it contributes to a decrease in server load. This optimization extends beyond mere HTML file reads and can apply to any intricate or resource-intensive operation.

Last-Modified is a weak caching header, as the browser applies a heuristic to determine whether to fetch the item from the cache or not. Heuristics vary between browsers.

How to Google Sign-in your users in 5 minutes

Francesco Di Donato — Wed, 25 Oct 2023 15:30:09 +0000

A crucial aspect of any startup is providing users with the means to authenticate themselves. There are numerous methods available for achieving this, but if you're looking for a straightforward and effective option, Sign in with Google is often the first choice.

Integrating Google Sign-In is surprisingly simple with authentication providers. Personally, I'm quite a fan of Stytch for several compelling reasons:

No Credit Card Required: they doesn't ask for your credit card information during the setup phase.
Variety of Providers and Methods: It offers a wide range of alternative providers and authentication methods.
Robust Documentation and Responsive Support: they provide extensive documentation, and their support team is quick to assist when needed.

How to Set It Up

Begin by visiting Stytch and creating an account. It is important that you select CONSUMER AUTHENTICATION.
In the sidebar, navigate to Configuration > API Keys and save the project_id and the secret somewhere secure, like your .env file.
Next, go to Configuration > OAuth and enable the Google provider. You'll receive a link, which you can use as the href attribute value in an <a> tag.
Lastly, instruct Stytch on where to redirect the user after completing authentication. Under Configuration > Redirect URLs, define a redirect URI for both signup and login. You can even have separate URIs for each.

Integration in Your Project

The minimum requirement is a simple HTML page that presents the <a> element with the href obtained in the previous section.

You'll also need an endpoint exposed to the redirect URI set in the previous section. This endpoint should be a GET method to which Stytch will send the authenticated client.

Stytch will attach two query parameters:

stytch_token_type, with a value of oauth, which allows you to identify the authentication method used (though it can be ignored for this tutorial).
token, a string that must be exchanged with the Stytch servers.

If you're using Node.js, the process is straightforward, as shown in this example:

import express from 'express';
import { Client } from 'stytch';

const client = new Client({
   project_id: process.env.PROJECT_ID,
   secret: process.env.PROJECT_SECRET,
});

const app = express();

app.get('/api/stytch/callback/signup', async (req, res) => {
   const token = req.query.token;

   const response = await client.oauth.authenticate({ token, session_duration_minutes: 60 * 60 });

   // Just an example
   db.users.add(response.user);

   res.cookie('token', res.session_jwt, { httpOnly: true });

   res.redirect("/dashboard");
});

// Omitting app.get("/api/stytch/callback/login") for brevity

app.listen(5173);

Give It a Try

To test it, run a live server and open the HTML page. Click the button to have your browser redirect you to the link provided by Stytch. Choose which Google account to use. The first time, it will invoke the signup endpoint, and all subsequent attempts will use the login endpoint

Unlock the Boundless Potential of ShipRapid!

But wait, this is just the tip of the iceberg. Your journey has only just begun, and you have the power to explore, adapt, and shape the system to match your unique vision.

On the flip side, if you've been nurturing that brilliant idea, the one you're itching to transform into a thriving startup, then you've landed on the right launchpad. I present to you: ShipRapid!

Imagination, intuition, decision-making, and speed of execution.

In the ever-evolving world of startups, timing is everything. You can't afford to get bogged down by technicalities.

Let the market itself guide your efforts and investments.

For those who crave speed, I've meticulously crafted ShipRapid, a SvelteKit template - not just a template; it's a supercharged toolkit offering modular, out-of-the-box solutions that cater to the essentials of every startup:

Authentication: Seamlessly connect with Google and harness the magic of Magic Link for ultra-convenient logins.
Payments: Sail smoothly with Stripe's payment handling, ensuring secure and seamless transactions.
Databases: Establish a robust foundation with MongoDB for data management that's as agile as your ambitions.
Content Management: Navigate the seas of content with a built-in CMS that powers your documentation, blogs, and static content with ease.
SEO Mastery: Enhance your online presence through intuitive SEO management tools.

And that's just the beginning; there's a treasure trove of features waiting for you.

Discover ShipRapid

go:generate 102

Francesco Di Donato — Sat, 25 Feb 2023 19:09:31 +0000

Like everything in existence, a generator is a function that (eventually) takes input and (eventually) returns output.

support code

Setup

I will assume from this post on that go mod init have been executed (if not see 101).

terminal

touch main.go division.generator.go

main.go

package main

//go:generate go run division.generator.go 12 4

import "fmt"

func main() {}

NOTE: Adding the suffix *.generator.go it's not part of the convention it's something I do.

division.go

//go:build ignore

package main

import (
    "fmt"
    "os"
    "strconv"
)

func main() {
    args := os.Args

    invoker := os.Getenv("GOFILE") // injected since it is executed via go:generate

    numerator, _ := strconv.Atoi(args[1])
    denominator, _ := strconv.Atoi(args[2])

    fmt.Println("args", args)
    fmt.Println("invoker", invoker)
    fmt.Printf("%d / %d = %d\n", numerator, denominator, numerator/denominator)
}

Usage

terminal

go generate ./...

output

args [path/to/exe/division.generator 12 4]
invoker main.go
12 / 4 = 3

A lot of env variables

GOFILE is not the only env variable provided.

for _, ev := range []string{"GOARCH", "GOOS", "GOFILE", "GOLINE", "GOPACKAGE", "DOLLAR"} {
    fmt.Println(ev, os.Getenv(ev))
}

terminal

GOARCH arm64
GOOS darwin
GOFILE main.go
GOLINE 3 // lineno of //go:generate 
GOPACKAGE main
DOLLAR $

Reuse across different projects

It is necessary to build the generator and place it in the GOPATH.

terminal

go build -o division division.generator.go
mv ./division $GOPATH/bin

main.go

package main

//go:generate division 12 4

import "fmt"

func main() {}

NOTE: No go run, just the name of the executable.

References

go:generate 101

Francesco Di Donato — Sat, 25 Feb 2023 18:22:28 +0000

How to use go:generate?

support code

Setup

terminal

go mod init github.com/<username>/<reponame>

Create two files. main.go will use gen.go as generator.

terminal

touch main.go gen.go

main.go simply logs "World!" and runs the generator via the special comment.

main.go

package main

//go:generate go run gen.go

import "fmt"

func init() {
    fmt.Println("main.go#main.init")
}

func main() {
    fmt.Println("World!")
}

NOTE: There is no space between the slashes and go:generate.

NOTE: not only gen.go, but go run gen.go.

gen.go declares package main, which would be forbidden were it not for the special comment.

gen.go

//go:build ignore

package main

import "fmt"

func init() {
    fmt.Println("gen.go#main.init")
}

func main() {
    fmt.Println("Hello")
}

NOTE: There is not space between the slashes and go:build.

Usage

terminal

go generate ./...

Output

gen.go#main.init
Hello

terminal

go run .

terminal

main.go#main.init
World!

Although the subcommand name is generate, the **generator* need not generate a file.*

References

support code