Forem: Andreas Bergström

Using FastMCP with OpenAI and Avoiding Session Termination Issues

Andreas Bergström — Sun, 10 Aug 2025 10:32:13 +0000

Using FastMCP with OpenAI: Avoiding Session Termination Issues

When integrating FastMCP as a Model Context Protocol (MCP) server for OpenAI’s Responses API, you may encounter a frustrating issue:

OpenAI sends DELETE requests to end the MCP session after each call, without automatically creating new sessions for subsequent requests. This will result in FastMCP responding:

{
    "jsonrpc": "2.0",
    "id": "server-error",
    "error": {
        "code": -32600,
        "message": "Not Found: Session has been terminated"
    }
}

The Fix: `stateless_http=True`

When instantiating your FastMCP server, set:

from fastmcp import FastMCP

mcp = FastMCP(
    name="MyToolServer",
    stateless_http=True  # crucial for streaming stability
)

@mcp.tool()
def greet(name: str) -> str:
    return f"Hello, {name}!"

if __name__ == "__main__":
    mcp.run(
        transport="http",
        host="0.0.0.0",
        port=8000
    )

Why This Works

stateless_http=True disables stateful session tracking.
Every request is handled independently, so OpenAI’s DELETE calls don’t break the connection.
Without it, streaming sessions will be terminated prematurely.
More details: OpenAI Forum Thread

Caveats

Session IDs won’t persist between requests, so advanced workflows relying on session state won’t work.
Sampling and certain bi-directional streaming patterns may not be supported in stateless mode.

TL;DR

If your OpenAI + FastMCP streaming requests fail after one call,
set stateless_http=True when starting the server.
It’s the simplest fix to keep your MCP server ready for every new streaming request.

Redirecting mobile users to App or Play Store in NextJS

Andreas Bergström — Mon, 27 Nov 2023 19:53:11 +0000

So here is the case: you have a mobile app for both iOS and Android and you have decided to promote it. While you could simply ask people to search for it on App Store or Google Play, that's not ideal. But you also don't want to use multiple URLs and let the audience write/click/scan the appropriate one for them.

Also, a substantial amount of users don't know if they use iOS or Android. They are simply interested in testing your app but unless they can just click a button to get it, you will loose them. Or at least make them irritated before they even installed your app.

While there are many services that provide a way to use a single URL and QR-code that redirects a mobile user to the correct app store depending on her platform, it is extremely easy to implement a homegrown solution. Let us see how this can be done when using Next.

Overview of the Approach

The solution involves two main components in a NextJS application:

The Middleware (middleware.ts): This file is responsible for detecting the user's device type and redirecting them to the correct app store.
A Placeholder Page (app/get.tsx): This page serves as a trigger for the middleware.

Let's delve into the details of these components.

Creating the Middleware (middleware.ts)

The middleware is the heart of our solution. It detects the user's device type and then redirects them to the appropriate store. Here’s the breakdown:

import type { NextRequest } from 'next/server'
import { NextResponse, userAgent } from 'next/server'

export function middleware(req: NextRequest) {
  const { ua } = userAgent(req)

  if (/iP(hone|ad|od)/.test(ua)) {
    return NextResponse.redirect(
      'https://apps.apple.com/in/app/yourapp/id123456789'
    )
  } else if (/Android/.test(ua)) {
    return NextResponse.redirect(
      'https://play.google.com/store/apps/details?id=com.yourapp'
    )
  } else {
    return NextResponse.redirect('https://yourdomain.com')
  }
}

export const config = {
  matcher: '/get',
}

We use a middleware to return the redirect as early as possible before rendering anything to the user.

Key Points:

Device Detection: We use regular expressions to determine whether the user's device is an iPhone, iPad, iPod, or Android.
Redirection: Depending on the device type, we redirect the user to either the App Store or Google Play Store.
Fallback: For non-mobile users, we redirect them to a default website.

For iOS the redirect should open App Store straight away, while on Android the user will be taken to the web version of Play Store but a modal will be displayed about opening your app in the native Play Store app. There are solutions to this which involve different ways of launching Play store but that's for another article.

Setting Up the Placeholder Page (app/get.tsx)

This page serves as a trigger for the middleware. This would normally never be executed unless the middleware for some reason fails to redirect the user. It's a simple component that redirects to the home page:

import { redirect } from 'next/navigation'

export default async function DownloadAppRoute() {
  redirect('/')

  return <div></div>
}

Own the contact points

That's it! From here you can evolve this solution futher, for example by adding stats. One easy tweak could be to change the fallback to a page about your app.

By hosting the solution yourself you maintain control of the contact point to the end-user, any SEO-boost is given to your domain and any QR-codes you use will be pointed to your domain directly. This is in contrast to using 3rd party services where the redirect goes through their domains, so if you ever stop paying the invoices any printed links or QR-codes will be rendered useless.

Python del vs assigning to None

Andreas Bergström — Sat, 11 Nov 2023 16:37:38 +0000

Python utilizes garbage collection to free the developer from the hassle of manually handling allocating and de-allocating memory. But there are still some details that could suprise you unless you are aware of them.

Because even though the Python runtime will take care of memory management, sometimes developers will want to manually tell the garbage colletor that a variable is no longer needed. Either because they are doing some edge-case optimization and really know what they are doing or they think they are smart but have no idea what they are doing. Most likely the latter as the Python runtime most often does not release unused memory back to the operating system.

But when someone need to somehow mark a variable as ready to be freed by the garbage collector, there are usually two solutions they come across:

x = None

del x

The difference is that x = None will free whatever it referenced but keep the name around even though it’s just referencing None (which is a type, NoneType).

On the other hand del x will completely remove both the name and what it referenced. If you thereafter try to use x an NameError will be thrown (or AttributeError in case of a object property).

So in practice, by assigning None to a name you can still use it in expressions while using del the name is completely removed. In the first case a few bytes is needed to keep the name in memory, while the later completely clears all memory usage.

import sys
import gc

x = 'Some text here to give the variable a decent size'
y = 2
print('x value before deletion: {}'.format(x))
print('x size before deletion: {} bytes'.format(sys.getsizeof(x)))
print('y value before deletion: {}'.format(y))

x = None
del y
gc.collect() # Not really needed, just to show garbage collection has been done hereafter

print('x value after deletion: {}'.format(x))
print('x size after deletion: {} bytes'.format(sys.getsizeof(x))) # A few bytes needed to keep symbol name
print('x type after deletion: {}'.format(type(x)))

if not x:
    print('Can still use x!')

print('y value after deletion: {}'.format(y)) # Will throw NameError (AttributeError in case of class property)

Output:

x value before deletion: Some text here to give the variable a decent size
x size before deletion: 98 bytes
y value before deletion: 2
x value after deletion: None
x size after deletion: 16 bytes
x type after deletion: <class 'NoneType'>
Can still use x!
Traceback (most recent call last):
  File "Untitled.py", line 21, in <module>
    print('y value after deletion: {}'.format(y)) # Will throw NameError (AttributeError in case of class property)
NameError: name 'y' is not defined

As you can see in the error above, if you for whatever reason need to hook into the memory management, unless you know the difference between assigning to None and using del it could confuse you.

Let us now look at the bytecode to see the technical difference:

import gc
import dis

def using_none():
    x = 1

    x = None # <-- ASSIGNING TO NONE

def using_del():
    x = 1

    del x # <-- USING DEL

print("Bytecode when assigning to None:")
dis.dis(using_none)
print("\nBytecode when using del:")
dis.dis(using_del)

Output:

Bytecode when assigning to None:
  5           0 LOAD_CONST               1 (1)
              2 STORE_FAST               0 (x)

  7           4 LOAD_CONST               0 (None)
              6 STORE_FAST               0 (x)

              8 LOAD_CONST               0 (None)
             10 RETURN_VALUE

Bytecode when using del:
 10           0 LOAD_CONST               1 (1)
              2 STORE_FAST               0 (x)

 12           4 DELETE_FAST              0 (x)
              6 LOAD_CONST               0 (None)
              8 RETURN_VALUE

So using del results in only one bytecode, DELETE_FAST, while assigning to None actually runs a full assignment using LOAD_CONST and STORE_FAST. The last LOAD_CONST before RETURN_VALUE in both functions is simply the return value None that every Python function implicitly returns.

Node 21 brings built-in WebSocket support

Andreas Bergström — Mon, 16 Oct 2023 18:19:32 +0000

Update 2023-10-17: Node 21 has now shipped with WebSocket support as predicted, read more:

https://nodejs.org/en/blog/announcements/v21-release-announce#built-in-websocket-client

If you're a part of the JavaScript jungle, you know how we all have been longing for some native WebSocket love in Node. WebSockets are like that secret sauce to making any app conversation go smoothly in real-time, back and forth between the client and server. But hey, Node has been playing hard to get on this one for a while. However, recent pull request activity suggest that Node version 21 might just be the game changer we've been waiting for, thanks to some community heroes putting in the elbow grease.

Now, let's talk about a recent pull request that's caught the eye over at the Undici project, which is Node’s own client for handling HTTP. This pull request is all about bringing WebSocket support to the table. It's like a beacon of hope for us, showcasing that, yeah, Node isn't going to let the modern web sprint ahead while it’s tying its shoelaces.

There’s an issue that popped up in the Node repo a while ago, which screams the community’s long-standing wish for some WebSocket magic. This thread is like a saga of devs dreaming about WebSockets dancing in Node natively.

So, what’s the big deal with WebSockets in Node? Well, it's not just about making real-time chit-chat easier; it's also about shipping Node with batteries included and gaining a small performance boost out of it. As Node version 21 is gearing up to see the daylight, having native WebSocket support could mean we get to build snazzier, more interactive apps.

Keep in mind Deno and Bun already comes with WebSocket support out of the box. Node should do to.

Configure TypeORM migrations in 5 minutes

Andreas Bergström — Sun, 15 Oct 2023 08:39:24 +0000

Database migrations are a crucial part of any robust, scalable application, allowing you to manipulate your database schema without touching the data. If you're building a NestJS application, you'll find that TypeORM is one of the most powerful tools available for this. In this blog post, we'll delve into how to manage database migrations effectively in TypeORM.

Setting Up the NestJS App Module

The first step to handling migrations in TypeORM is to set up your app.module.ts file. You can configure the TypeOrmModule to automatically run migrations when the application starts.

Here is an example:

// app.module.ts
import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { ConfigService } from '@nestjs/config';

@Module({
  imports: [
    TypeOrmModule.forRootAsync({
      inject: [ConfigService],
      useFactory: (config: ConfigService) => ({
        type: 'postgres',
        url: config.get<string>('DB_URL'),
        migrations: ['/migrations/*{.ts,.js}'],
        migrationsTableName: '_migrations',
        migrationsRun: true,  // Auto-run migrations
        entities: ['dist/**/*.entity{.ts,.js}'],
        synchronize: !!config.get<string>('DB_SYNC') || false,
        logging: true,
      }),
    }),
    // Other modules
  ],
})
export class AppModule {}

Key Points

migrationsRun: true: This will run the migration files automatically when your application starts.
synchronize: false: This should be set to false in production as it can drop your database tables.

Install TS-Node

You will need ts-node to execute TypeScript files directly for migration purposes.

Install it as a development dependency:

npm install ts-node --save-dev

NPM Scripts for Migrations

Add these scripts in your package.json file:

{
  "scripts": {
    "typeorm": "ts-node ./node_modules/typeorm/cli",
    "typeorm:run-migrations": "npm run typeorm migration:run -- -d ./typeOrm.config.ts",
    "typeorm:generate-migration": "npm run typeorm -- -d ./typeOrm.config.ts migration:generate ./migrations/$npm_config_name",
    "typeorm:create-migration": "npm run typeorm -- migration:create ./migrations/$npm_config_name",
    "typeorm:revert-migration": "npm run typeorm -- -d ./typeOrm.config.ts migration:revert"
  }
}

TypeORM Configuration

Create a typeorm.config.ts file:

// typeorm.config.ts
import { DataSource } from 'typeorm';
import { ConfigService } from '@nestjs/config';
import { config } from 'dotenv';

config();

const configService = new ConfigService();

export default new DataSource({
  type: 'postgres',
  url: configService.get<string>('DB_URL'),
  entities: ['dist/**/*.entity{.ts,.js}'],
  migrations: ['dist/migrations/*.js'],
});

The Magic of `generate-migration`: Auto-detecting Changes in Entities

One of the most powerful features of TypeORM is its ability to automatically detect changes in your entities and generate the appropriate migration files for you. This saves you the manual labor of writing SQL queries for each change in your entity. The generate-migration command comes in very handy for this purpose.

How It Works

The generate-migration command compares the entities in your project with your database's current state and generates a new migration file containing all the SQL queries needed to transition your database schema to match your entities.

Here's how you can use it:

npm run typeorm:generate-migration -- --name=YourMigrationName

Replace YourMigrationName with a name that describes the changes in this migration.

Example

Suppose you have an existing User entity, and you add a new column email.

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @Column()  // Newly added
  email: string;
}

If you run generate-migration, TypeORM will automatically detect the new email column and generate the necessary SQL query to add this column to the user table in your database.

Important Note

Although this feature is incredibly helpful, it's not a complete substitute for understanding your database schema and migrations. It is good practice to review the generated migration files and test them in a controlled environment before applying them to your production database.

Using the NPM Scripts

Now you can use the following commands:

Run Migrations: \npm run typeorm:run-migrations\\
Generate Migrations: \npm run typeorm:generate-migration -- --name=MigrationName\\
Create Empty Migration: \npm run typeorm:create-migration -- --name=MigrationName\\
Revert Last Migration: \npm run typeorm:revert-migration\\

And that's it! You're now ready to manage your database schema changes effectively using migrations in TypeORM with a NestJS application.

Would you like to know more details about any specific part of the process? I'd be happy to clarify or go into more detail!

Easily style active links in Tanstack Router

Andreas Bergström — Sat, 14 Oct 2023 07:45:23 +0000

UI/UX has both high hanging and low hanging fruits, and this is certainly one of the more low hanging ones to enhance the experience. A main navigation, be it a navbar or a navigation tree on either side, that indicates where in it the user is currently browsing is one of the more basic things. This is perhaps also the oldest UX tool the web has, dating back to the first HTML pages and browsers in the 90's.

TanStack Router, liked for its typesafe approach that borrows lots of ideas from Vue/Angular routers, offers a smooth solution to this UI necessity through the activeProps attribute of its Link element. This attribute allows developers to apply specific styles to active links, enhancing the navigation experience. Let's delve into a practical example to see activeProps in action.

Constructing the Navigation Component

In our scenario, we'll construct a MainNav component to render a navigation menu with two items: Dashboard and Messages.

import { dashboardRoute, threadsRoute } from '@/Router'
import { Link } from '@tanstack/react-router'

export function MainNav() {
  const menuItems = [
    { name: 'Dashboard', path: dashboardRoute.fullPath },
    { name: 'Messages', path: messagesRoute.fullPath },
  ]

  return (
    <nav className='hidden md:flex items-center space-x-4 lg:space-x-6 mx-4 text-gray-500'>
      {menuItems.map((item) => {
        return (
          <Link
            key={item.name}
            to={item.path}
            className='text-sm font-medium transition-colors hover:text-black'
            activeProps={{ className: 'text-black' }}
          >
            {item.name}
          </Link>
        )
      })}
    </nav>
  )
}

Here’s a breakdown of the key parts in the code snippet above:

We defined a MainNav function component.
We created an array menuItems to store our navigation items, where each item has a name and a path.
Within the nav element, we iterated over menuItems to generate Link elements for each navigation item.
For each Link element, we applied common styling via the className attribute and used the activeProps attribute to specify the styling for active links. When a link is active, the text-black class is applied, changing its text color to black.

The activeProps attribute offers a neat and intuitive way to style active links, improving user orientation and the overall user experience. The use of activeProps in TanStack Router's Link element demonstrates a practical solution for achieving a polished, user-friendly navigation system.

For further insights and use-cases, refer to the official TanStack documentation on Navigation.

Finally you can skip dotenv in Node

Andreas Bergström — Sat, 09 Sep 2023 07:33:31 +0000

Node.js has been at the forefront of backend development for over a decade now, largely due to its scalability and efficient performance. Every new release brings with it a myriad of features aimed at simplifying development, and Node.js v20.6 is no exception. One small but highly appreciated feature in this release is the built-in .env file support for configuring environment variables.

What are .env Files?

Environment variables are a crucial part of modern development workflows. They let you store sensitive information, application configurations, and even runtime settings away from your application code. .env files have become the de facto standard for managing these variables. While environment variables are usually injected into production containers, during local development it is common to have the variables in files such as .env.test and .env.development.

How Does it Work?

Prior to v20.6, handling environment variables often involved using external libraries like dotenv, which would parse .env files and inject the variables into process.env. With this new feature, you can directly pass the .env file as an argument to the Node.js runtime.

Syntax

The .env file should be formatted as an INI file, meaning each line contains a key-value pair for an environment variable. For example, your .env file might look something like this:

DB_URL=foo
JWT_SECRET=foo
LOG_LEVEL=debug

Running your Application

You can initialize your Node.js application with predefined configurations using the following CLI command:

node --env-file=config.env index.js

This will load all the environment variables from config.env into your application's environment. For example, you can now access the password as follows:

const DB_URL = process.env.DB_URL;

NODE_OPTIONS in .env

This new feature doesn't just stop at handling your custom environment variables. It extends to built-in Node.js options as well. Traditionally, defining NODE_OPTIONS would involve including them in your package.json or setting them in your shell before running your application. With this new built-in .env support, you can include NODE_OPTIONS directly in your .env file.

For example, your .env file could contain:

NODE_OPTIONS=--experimental-modules --inspect
LOG_LEVEL=debug

Why Is This Important?

Simplified Workflow
This change simplifies the developer experience by natively incorporating what was already a de facto standard in Node.js development.

Less Dependence on External Packages
By incorporating this feature into the core, Node.js reduces the number of third-party packages that developers need to be familiar with, making it easier to get up and running.

Unified Configuration
This feature also encourages a more unified approach to configuration, bringing environment variables and Node options into a single, easily manageable file.

You might still need 3rd party libraries for frontend

While Node.js 20.6 has streamlined environment variable management with its built-in .env support, it's important to note that this feature doesn't extend to React and React Native. These frameworks don't utilize the Node.js runtime in production and have their own build processes and runtimes. As a result, developers may still need to rely on existing methods for environment variable management. For instance, legacy React projects often make use of tools like create-react-app, which handles .env files in its own way, while React Native developers may turn to libraries such as react-native-config. Any newer projects would probably use Vite, Astro and similiar which has built-in support.

Node.js v20.6's addition of built-in .env file support is more than just a convenience feature; it's a strategic move to maintain its competitive edge in a landscape increasingly influenced by newcomers like Deno and BUN. These emerging technologies have placed a significant emphasis on developer experience right out of the box, pushing Node.js to evolve and incorporate such enhancements natively. This update is not just about streamlining application development in Node.js; it's also about responding to the challenges and setting the bar high in a rapidly evolving ecosystem.

How to style for print in Tailwind

Andreas Bergström — Sun, 13 Aug 2023 18:21:07 +0000

Ever been merrily coding away when suddenly the thought strikes, "What if someone... prints this page?" And the more ominous: "What if it looks like a Picasso painting after a rough night when they do?"

For a web app that's more of an interface than a classic document, you probably don't care that much about its print appearance as it's unlikely someone would print something there. But for a typical document-oriented website with lot's of text and image content, you might wanna have a look at its print preview. Looks terrible, right? How do we fix this without resorting to the hell of custom CSS classes and files? Like this?

@media print {
  a {
    color: inherit;
    text-decoration: none;
  }
}

Well, no! With Tailwind's ever-so-handy print and screen modifiers, your website can look fabulous on screens AND on paper. No more nightmares about confetti-like printouts!

Setting up print and screen prefixes in Tailwind

Tailwind is the awsome utility-first CSS framework we wish we could use in every client or work project. It's like the Swiss Army knife of styling - just without the tiny, almost useless, scissors. Most utilities are activated right from the get-go. But some? They're like hidden Easter eggs waiting for you to find. Enter: the print and screen modifiers.

From the get-go it's not available, but luckily you don't need to install any plugin to get started. Simply open up the tailwind.config.js file and extend the available screens:

module.exports = {
  // ... rest of tailwind config
  extend: {
    screens: {
      print: { raw: 'print' },
      screen: { raw: 'screen' },
    },
  },
}

This way, Tailwind will now auto-generate media queries prefixes that you can use in your classes. You can use them to entirely show or hide elements depending on print or not, or tweak any CSS you want accordingly:

<div class="print:text-xl screen:text-sm">I’ll look big on paper but compact on screen!</div>

Let's go through a few other examples of where you would want to tweak the print styling on your page.

Hide navigation and footer elements

When a user prints a webpage, they typically don't need the website's navigation bar, footer, or any site-wide banner elements. These are essentially useful only in a digital context. Therefore, it's a common practice to hide these elements in the print version.

<nav class="print:hidden"> ... </nav>

Hide interactive elements

Interactive elements, such as buttons, dropdowns, and forms, serve no purpose on a printed page. It's a good idea to hide them to avoid confusing the reader.

<button class="print:hidden">Click Me!</button>

Display URLs for links

Hyperlinks are interactive elements that work wonders on screens but are dormant on paper. To provide context, it can be helpful to display the URL next to the link text in the print version so readers can manually access them if needed.

For this one we do need to add a custom CSS class to our global CSS, but only one!

@media print {
  a[href]:after {
    content: " (" attr(href) ")";
  }
}

Optimize images and graphics

High-color images might not always print well, especially in grayscale. You might want to enhance the contrast, remove background images, or even swap colored images with their grayscale counterparts to ensure clarity.

<img src="colored-image.jpg" class="screen:block print:hidden">
<img src="grayscale-image.jpg" class="screen:hidden print:block">

Considering the distinct nature of screens and printed pages, these tweaks can significantly improve the clarity, relevance, and aesthetics of printed content.

Understanding Cache-Control and ETag for efficient web caching

Andreas Bergström — Thu, 10 Aug 2023 07:49:17 +0000

Web performance is essential in delivering a seamless user experience. One way to boost this performance is by implementing efficient caching strategies. Among numerous techniques available, two HTTP headers that play a central role in this endeavor are Cache-Control and ETag. These headers can help your website load faster by minimizing unnecessary network requests while ensuring that your users always see the most up-to-date content.

Cache-Control: Mastering the Basics

The Cache-Control header, as its name suggests, dictates how HTTP responses should be cached by browsers and other intermediate caches. It uses various directives to control the caching behavior:

max-age: Specifies how long (in seconds) a resource is considered fresh. After this time, the cache deems the resource stale and tries to re-fetch it.
no-cache: The cache must validate the stored copy with the server before serving it to the client, even if it's not yet stale.
no-store: The response should not be stored in any cache.
public and private: Define whether the response can be cached in a public cache (like a CDN) or only in a private cache (like a user's browser).
must-revalidate: Once the resource is stale, the cache must not use its stored copy without successful validation with the server.

For instance, Cache-Control: max-age=3600 instructs the client to consider the cached resource fresh for one hour. After that, the cache should consider the resource stale and try to re-fetch it.

ETag: The Freshness Validator

While Cache-Control provides general caching directives, ETag (Entity Tag) works as a validator, ensuring the freshness of a cached resource. An ETag is a unique identifier for a specific version of a resource. The server includes this tag in its response, and the client stores this ETag value along with the cached resource.

When the client needs the same resource again, it sends the stored ETag value in an If-None-Match header. The server then compares the current ETag value of the resource with the client's value. If they match, the client's cached version is still fresh, and the server returns a 304 Not Modified status, allowing the client to use its cached copy. If they don't match, the server sends the new resource with a new ETag.

Using Cache-Control and ETag together

Cache-Control and ETag often work together to effectively manage caching. Here's an example of how:



HTTP/1.1 200 OK

Cache-Control: max-age=3600

ETag: "12345"

Content-Type: text/html

In this scenario, Cache-Control instructs the client to cache the response and consider it fresh for one hour. Meanwhile, the ETag header is provided for validation in case the resource needs to be re-fetched after that hour.

Benefits of Using Both Cache-Control and ETag

Optimal Efficiency and Freshness:
By combining the expiration-based caching mechanism of Cache-Control with the validation-based approach of ETag, developers can ensure that a client doesn't even attempt to re-fetch a resource until necessary, but when it does, it's validated for freshness.
Reduced Server Load: With Cache-Control set to a specific max-age, requests for a resource don't hit the server until that age is reached. This means fewer requests overall, reducing the server's load. However, once that age is reached or if must-revalidate is set, having ETag ensures that a full resource doesn't have to be resent if nothing has changed.
Bandwidth Efficiency: By setting an ETag, if the resource hasn't changed when validation is sought, the server can send back a 304 Not Modified without sending the actual resource data again, thus saving bandwidth.
Granular Control Over Caching: Using Cache-Control, you can define caching rules for different types of resources. For instance, images and stylesheets that change infrequently can have a longer max-age, while dynamic content might have a shorter one or even a no-cache directive. This granularity ensures optimal user experience and server performance.

Why not just use ETag and skip cache-control?

Combining both ETag and Cache-Control allows for the most efficient caching possible.

Certainly, you can use only ETag for cache validation, but there are caveats:

Increased Server Requests: Without Cache-Control, clients might check with the server more frequently for resource validation. Even if the server is only returning 304 Not Modified statuses, it still means increased requests to handle and more round trips, causing slight delays.
Missed Optimization Opportunities: Cache-Control directives like immutable can be invaluable for resources you're certain won't change, like versioned files. Without using these directives, you could be missing out on optimal caching behaviors.
Lack of Control Over Where Content is Cached: Cache-Control allows you to specify whether a resource can be cached publicly (e.g., by CDNs) or only privately (e.g., by a user's browser). Without it, you lose this specificity.
Potential Over-Reliance on Validation: If you only rely on ETag, you're effectively forcing a check with the server every time a resource is requested, which might not always be necessary. It's like having a conversation where you continuously ask, "Has this changed?" instead of being told, "This won't change for the next hour."

In summary, while ETag alone offers a robust mechanism to ensure the freshness of cached content, combining it with Cache-Control provides a more comprehensive and efficient caching strategy. It's the synergy between the "how long to cache" of Cache-Control and the "has this changed" of ETag that delivers the best results in web performance.

Love the cache

Cache-Control and ETag are instrumental in efficient web caching. Understanding and implementing these headers can drastically improve your website's load time and performance. While Cache-Control sets the caching guidelines, ETag validates the cached resources' freshness, ensuring that your users always get the latest and fastest content. By properly leveraging these two, developers can deliver a smoother and more efficient user experience.

Simplify TypeScript builds with esbuild and skip tsc/tsx

Andreas Bergström — Wed, 09 Aug 2023 07:49:22 +0000

The JavaScript ecosystem constantly undergoes innovations. One of the more recent game-changers is esbuild, a lightning-fast JavaScript and TypeScript bundler. Unlike traditional TypeScript compilers like tsc, esbuild offers rapid compile times and a straightforward configuration. This post will delve into using esbuild to handle TypeScript compilation, emphasizing the vast array of parameters it offers.

Why esbuild over tsc?

Performance: esbuild leverages Go's performance benefits, offering incredibly fast bundling times compared to other bundlers and compilers.
Simplicity: esbuild's configuration is relatively straightforward, making it easy to integrate into existing projects.
Flexibility: esbuild provides various options, like the ability to output to different formats, set the platform target, and more.

Running esbuild in watch mode will allow you to use the same tool for production and development, without sacrificing performance!

Configuring esbuild for TypeScript

Firstly, ensure esbuild is part of your project:



npm install esbuild --save-dev

Here's our proposed NPM script configuration using esbuild:



{
    "scripts": {
        "build": "esbuild `find src \\( -name '*.ts' \\)` --platform=node --target=esnext --outdir=build --format=cjs",
        "build:watch": "npm run build -- --watch",
        "start": "node build | npx pino-pretty",
        "start:watch": "node --watch -r dotenv/config build | npx pino-pretty",
        "dev": "concurrently \"npm:build:watch\" \"npm:start:watch\""
    }
}

esbuild Parameters Explained:

Input Files: The find src \\( -name '*.ts' \\) portion locates all TypeScript files within the srcdirectory, feeding them to esbuild.
platform: The --platform=node flag ensures the code is compatible with a Node.js environment. Other possible values include browser for browser-specific output.
target: With --target=esnext, we instruct esbuild to output the latest version of ECMAScript. This is invaluable when you want to leverage the latest language features. Other values could be es6, es2016, etc., depending on your needs.
outdir: The --outdir=build option specifies the output directory for our compiled files. Replace build with any directory name of your choosing.
format: The --format=cjs command dictates the module system to be used. We've chosen CommonJS (cjs) here, but esbuild also supports esm (ES Modules), iife, and more.
watch: Adding --watch makes esbuild monitor file changes and recompile as necessary. This is invaluable during development, negating the need to manually trigger recompiles.
Concurrently: Not an esbuild parameter, but vital for our setup. concurrently runs multiple commands concurrently. In our script, it allows us to watch and build, and then run our application simultaneously.

Reaping the Rewards of esbuild

Bypass tsc/tsx: Transitioning to esbuild means a direct reduction in compile times.
Simplified Build Pipeline: The amalgamation of bundling and compiling under a single tool, esbuild, streamlines our pipeline.
Parameter-Driven Configuration: esbuild's parameters allow developers to easily craft a build process tailored to their specific requirements.

Wrapping Up

esbuild's emergence as a go-to TypeScript compiler promises faster development cycles and simplified build processes. Its array of parameters allows fine-grained control over the build, catering to a myriad of configurations. If you haven't yet, now might be the time to consider the switch from traditional tsc compilation. Happy building!

package.json: Not just a file, but a Developer's Toolkit

Andreas Bergström — Tue, 08 Aug 2023 05:51:17 +0000

Optimizing workflow is paramount for efficiency and productivity. A key player in achieving this within the Node.js ecosystem is the package.json file, a cornerstone for project configuration. This article delves into strategies that enhance the utility of npm scripts housed within package.json, guiding you from rudimentary implementations to intricate solutions tailored for sophisticated project demands.

Use Script Hooks to Integrate Pre- and Post-Tasks

Script hooks in package.json provide the ability to set up preliminary or follow-up tasks around a primary script. By using the pre and post prefixes, you create an automated sequence of operations that run before or after your main task.

Use Case: Consider a scenario where you want to lint your code before testing, and then clean up any generated artifacts after the test. Script hooks effortlessly weave these tasks together, ensuring your testing process is bracketed by necessary housekeeping tasks.

"scripts": {
  "pretest": "eslint .", 
  "test": "jest", 
  "posttest": "rm -rf ./coverage"
}

Harness Environment Variables for Dynamic Script Execution

Environment variables function as dynamic parameters within your scripts, enabling them to react to or utilize different settings or configurations. By tapping into process.env.npm_package_*, you can access any field in your package.json, letting scripts adapt based on the project's metadata.

Use Case: Suppose you've created multiple deployment environments for your application. By utilizing environment variables, you can ensure your scripts adjust accordingly, fetching the correct configurations or assets for each environment.

"name": "my-app",
"version": "1.0.0",
"scripts": {
  "start": "node index.js",
  "info": "echo The current app is $npm_package_name@$npm_package_version"
}

Ensure Cross-Platform Compatibility with Adaptive Scripts

Cross-platform compatibility ensures that your npm scripts perform consistently across different operating systems. By leveraging tools like cross-env, you can write scripts that adapt and execute flawlessly, whether on Unix, Windows, or other platforms.

Use Case: You're developing an application that will be deployed on various servers running different OS. To avoid deployment hiccups, ensuring that build, test, and other scripts run identically across these platforms is critical.

"scripts": {
  "start": "cross-env NODE_ENV=development node index.js"
}

Employ Concurrent Task Runners for Efficient Workflow

Executing multiple tasks concurrently can streamline your workflow. Tools like concurrently and npm-run-all manage the simultaneous execution of scripts, helping save time and resources.

Use Case: Imagine you're working on a web application. While the backend server runs, you might also want a file-watcher active, reloading the front end whenever changes are detected. Concurrent task runners make this multitasking a breeze.

"scripts": {
  "start:server": "node server.js",
  "start:watch": "nodemon .",
  "start": "concurrently npm:start:*"
}

Utilize Command Line Arguments to Customize Script Behavior

With the aid of command-line arguments, npm scripts can be tuned on the fly, giving you finer control over their execution. By using the -- syntax, you can pass additional parameters or options directly to your scripts.

Use Case: During development, you may need your server to run on different ports based on certain requirements or to avoid conflicts. Command line arguments offer the flexibility to alter this setting directly when running the script.

"scripts": {
  "start": "node index.js --port=3000"
}

Embrace npm Lifecycle Scripts for Stage-Managed Operations

npm lifecycle scripts determine the sequence of operations at different stages of your project's lifecycle. They provide structure and order, from initial setup (prepublish) to subsequent updates or deployments (postinstall).

Use Case: Before publishing a package to the npm registry, you might want to run tests and build the final version. Lifecycle scripts ensure these steps are followed in the right sequence, every time.

"scripts": {
  "prepublish": "npm run test && npm run build"
}

Document with Script Descriptions for Better Clarity

Starting with npm v7, the ability to annotate your scripts using the description field was introduced. This facilitates better documentation within the package.json itself, aiding in understanding and collaboration.

Use Case: As your project grows and more team members get involved, the purpose of certain scripts might become ambiguous. By providing descriptions, you ensure every team member understands each script's role, leading to smoother development cycles.

Understand the Trade-offs: && / & vs concurrently / npm-run-all

The choice between using && / & operators and tools like concurrently or npm-run-all might seem nuanced, but each has its advantages. The && operator ensures sequential execution, while & runs scripts in parallel. However, for more sophisticated management of parallel tasks, including error handling and cross-platform compatibility, concurrently and npm-run-all offer more robust solutions.

"scripts": {
  "start:server": "node server.js",
  "start:watch": "nodemon .",
  "start": "concurrently npm:start:*"
}

In further exploring the capabilities of npm scripts, it becomes evident that they encompass a comprehensive range of functionalities. The methodologies outlined here, ranging from foundational to advanced, serve as a structural basis upon which further optimizations can be instituted. It is recommended to adapt these strategies in alignment with the unique requirements and operational processes of your project.

Use Case: In a project where you want to compile your code, start a server, and launch a watcher all at once, merely using the & operator could result in messy logs and unhandled errors. Tools like concurrently allow you to run these tasks together but with cleaner output and better error management.

The future of AI assistants might begin in your app settings

Andreas Bergström — Mon, 07 Aug 2023 12:28:22 +0000

In today's software-driven world the complexity of applications and their settings often overwhelms users. Every app seems to come with its own intricacies and nuances, which can often lead to an overwhelming number of customization options. We've all heard the phrase, "don't make everything a setting." It's an attempt to curb the confusion that arises when an app presents too many options to the user. However, as we strive to create more personalized user experiences, the challenge to balance accessibility and customization continues to persist.

Enter the future of AI assistants, powered by Large Language Models (LLMs).

LLMs are transforming the way we interact with applications by providing an innovative solution to this issue. AI assistants, backed by these robust models, are adept at understanding and manipulating complex information. The idea is to let these intelligent assistants take the reins and manage your app settings based on your preferences and patterns.

Digging through app settings like these to find what you are looking for or just what's possible to configure might soon be as obsolete as floppy disks are today

How does this work?

When you download an app, instead of sifting through a maze of settings, you could simply express your preferences to your AI assistant. For instance, you might tell it, "I like a dark theme, I don't want notifications while I'm at work, and I prefer to have privacy settings at the maximum." The AI assistant would understand these preferences, navigate the app's settings, and make the appropriate adjustments for you.

Imagine never having to trawl through an application's settings or dig through online forums to understand how to change a particular setting. This would not only streamline the process but also make it far more user-friendly, particularly for those who might not be as technologically adept.

Moreover, these AI assistants could also learn and adapt to your behavior over time. If the assistant notices that you usually mute a particular app during your working hours, it can suggest or automatically make this setting for you.

The benefits are numerous. App developers can continue to provide a rich array of settings to cater to every possible user preference without overwhelming them. Users, on the other hand, get to enjoy a personalized experience without having to understand the intricacies of every app they use.

As we lean into this AI-dominated paradigm, an interesting trend emerges: the gradual phasing out of traditional, hand-built UIs in favor of more fluid, AI-driven interfaces. The classic app settings menu, with its myriad of toggles and sliders, might just be the first casualty in this shift. In place of visually navigating through structured menus, users could soon be engaging in more conversational interactions with their software, simply expressing preferences or commands verbally or through text. This not only simplifies the interaction but also allows for a more organic relationship between user and application.

Just as we saw the transition from command-line interfaces to graphical user interfaces, we might be on the cusp of another transformative shift: moving from static, user-driven settings interfaces to dynamic, AI-mediated conversations. This evolution could redefine our expectations of how software should respond and adapt to individual needs.

However, like any transformative technology, this approach comes with its challenges. Privacy and security are prime concerns, as is the potential for AI bias. App developers and AI researchers need to work together to ensure that AI assistants are reliable, secure, and fair, and that they operate in a manner that respects user privacy.

As we look to the future, one thing is clear: The advent of LLM-backed AI assistants is set to revolutionize how we interact with apps. By eliminating the need for users to grapple with complex settings, we are paving the way for a more seamless and intuitive user experience. We're on the brink of a new era where technology adapts to us, rather than the other way around. It's a future that promises to make our digital interactions more personalized, intuitive, and effortless.