DEV Community: JohnDotOwl

PostgreSQL 17 Installation on Ubuntu 24.04

JohnDotOwl — Thu, 10 Oct 2024 07:58:53 +0000

Overview
PostgreSQL 17 is the latest major release of the popular open source relational database. It comes with many new features and improvements such as enhanced monitoring capabilities, improved performance, logical replication enhancements, additional server configurations, and security advancements.

In this tutorial, we will cover how to install PostgreSQL 17 on Ubuntu 22.04 We will also look at some basic configuration to allow remote connections, enable password authentication, and get started with creating users, databases etc.

Prerequisites
Ubuntu 24.04
Root privileges or sudo access
use sudo su to get into root instead of ubuntu(default user)

Step 1 - Add PostgreSQL Repository

First, update the package index and install required packages:

sudo apt update

Add the PostgreSQL 17 repository:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Import the repository signing key:

curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg

Update the package list:

sudo apt update

Step 2 - Install PostgreSQL 17

Install PostgreSQL 17 and contrib modules:

sudo apt install postgresql-17

Start and enable PostgreSQL service:

sudo systemctl start postgresql
sudo systemctl enable postgresql

Check the version and ensure it's Postgresql 17:
psql --version
You should get something like

psql (PostgreSQL) 17.0 (Ubuntu 17.0-1.pgdg24.04+1)

Step 3 - Configure PostgreSQL 17

Edit postgresql.conf to allow remote connections by changing listen_addresses to *:

sudo nano /etc/postgresql/17/main/postgresql.conf
listen_addresses = '*'

Configure PostgreSQL to use md5 password authentication by editing pg_hba.conf , this is important if you wish to connect remotely e.g. via PGADMIN :

sudo sed -i '/^host/s/ident/md5/' /etc/postgresql/17/main/pg_hba.conf
sudo sed -i '/^local/s/peer/trust/' /etc/postgresql/17/main/pg_hba.conf
echo "host all all 0.0.0.0/0 md5" | sudo tee -a /etc/postgresql/17/main/pg_hba.conf

Restart PostgreSQL for changes to take effect:

sudo systemctl restart postgresql

Allow PostgreSQL port through the firewall:

sudo ufw allow 5432/tcp

Step 4 - Connect to PostgreSQL

Connect as the postgres user:

sudo -u postgres psql

Set a password for postgres user:

ALTER USER postgres PASSWORD 'VeryStronGPassWord@1137';

Conclusion
We have successfully installed PostgreSQL 17 on Ubuntu, performed some basic configuration like enabling remote connections, set up password authentication, created a database and users. PostgreSQL is now ready to be used for development or production workloads.

PostgreSQL 17 has significant improvements and is highly recommended as an upgrade.

Vacuum memory optimization: Up to 20x less memory consumption
Write throughput: Up to 2x better for high concurrency workloads
Query performance: Improved for IN clauses using B-tree indexes
JSON support: Added JSON_TABLE, JSON constructors, and query functions
COPY command: Up to 2x faster when exporting large rows
Logical replication: No need to drop slots during major version upgrades
Backups: New incremental backup support in pg_basebackup
Monitoring: Added progress reporting for index vacuuming
I/O improvements: New streaming I/O interface for faster sequential scans
MERGE enhancements: Added RETURNING clause and ability to update views

Building and Running a Rust Application with Docker on Mac (Apple Silicon)

JohnDotOwl — Wed, 13 Mar 2024 15:43:23 +0000

This guide will walk you through the process of building and running a Rust application using Docker. The provided Dockerfile is designed to build a Rust application for the ARM64 architecture and run it in a lightweight Debian container.

Dockerfile

# syntax=docker/dockerfile:1

################################################################################
# Create a stage for building the application.

ARG RUST_VERSION=1.69.0
ARG APP_NAME=my_app_name
FROM --platform=linux/arm64 rust:${RUST_VERSION}-slim-bullseye AS build
ARG APP_NAME
WORKDIR /app
RUN apt-get update && apt-get upgrade -y
RUN apt-get install -y pkg-config openssl libssl-dev ca-certificates
RUN \
  apt-get install ca-certificates && \
  apt-get clean
# Build the application.
# Leverage a cache mount to /usr/local/cargo/registry/
# for downloaded dependencies and a cache mount to /app/target/ for 
# compiled dependencies which will speed up subsequent builds.
# Leverage a bind mount to the src directory to avoid having to copy the
# source code into the container. Once built, copy the executable to an
# output directory before the cache mounted /app/target is unmounted.
RUN --mount=type=bind,source=src,target=src \
    --mount=type=bind,source=Cargo.toml,target=Cargo.toml \
    --mount=type=bind,source=Cargo.lock,target=Cargo.lock \
    --mount=type=cache,target=/app/target/ \
    --mount=type=cache,target=/usr/local/cargo/registry/ \
    <<EOF
set -e
rustup target add aarch64-unknown-linux-gnu
cargo build --locked --release --target aarch64-unknown-linux-gnu
cp ./target/aarch64-unknown-linux-gnu/release/$APP_NAME /bin/server
EOF

################################################################################
# Create a new stage for running the application that contains the minimal
# runtime dependencies for the application. This often uses a different base
# image from the build stage where the necessary files are copied from the build
# stage.
#
# The example below uses the debian bullseye image as the foundation for running the app.
# By specifying the "bullseye-slim" tag, it will also use whatever happens to be the
# most recent version of that tag when you build your Dockerfile. If
# reproducibility is important, consider using a digest
# (e.g., debian@sha256:ac707220fbd7b67fc19b112cee8170b41a9e97f703f588b2cdbbcdcecdd8af57).
FROM --platform=linux/arm64 debian:bullseye-slim AS final

# Create a non-privileged user that the app will run under.
# See https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user
ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

# Copy the executable from the "build" stage.
COPY --from=build /bin/server /bin/

# Expose the port that the application listens on.
EXPOSE 1000

# What the container should run when it is started.
CMD ["/bin/server"]

Understanding the Dockerfile

The Dockerfile consists of two stages: a build stage and a final stage.

Build Stage

The build stage is responsible for compiling the Rust application. It uses the official Rust Docker image as a base and installs the necessary dependencies. The Dockerfile then leverages several Docker features to optimize the build process:

Bind Mounts: The source code is mounted into the container using a bind mount, avoiding the need to copy the code into the container for each build.
Cache Mounts: The Cargo registry and compiled dependencies are cached using cache mounts, speeding up subsequent builds by reusing downloaded and compiled artifacts.

The build stage compiles the Rust application using cargo build --release and copies the resulting binary to /bin/server.

Final Stage

The final stage creates a minimal runtime environment for the application using the debian:bullseye-slim image as a base. It performs the following steps:

Create a Non-Privileged User: A non-privileged user named appuser is created to run the application, following best practices for container security.
Copy the Binary: The compiled binary from the build stage is copied into the final image at /bin/server.
Expose Port: The container exposes port 1000, which is the port the application listens on.
Default Command: The container is configured to run the /bin/server binary when started.

Building the Docker Image

To build the Docker image, run the following command in the directory containing the Dockerfile:
docker build --platform linux/arm64 -t my_app_name .

Running the Docker Container

To run the Docker container, use the following command:

docker run -d --name my_app_name -p 1000:1000 --restart on-failure --memory 1g --memory-swap 1g my_app_name

Laravel 10 FrankenPHP with PHP 8.3 with Ubuntu 22.04

JohnDotOwl — Wed, 24 Jan 2024 13:43:04 +0000

Operation System : Ubuntu 22.04 ARM
Server Provider : AWS - t4g.micro (2vCPU with 1GB Ram)

Before getting started with FrankenPHP, you need to prepare your operation system with libraries and PHP required for Laravel.

Update and Upgrade your Operating System

sudo apt update
sudo apt upgrade
sudo apt install zip unzip

Install PHP 8.3

# Add Ondrej's PPA
sudo add-apt-repository ppa:ondrej/php 
# Press enter when prompted.

Do another update & upgrade to grab the latest files from PHP 8.3(Ondrej's PPA)

sudo apt update
sudo apt upgrade

Install new PHP 8.3 packages

sudo apt install php8.3 php8.3-cli php8.3-xml php8.3-{bz2,curl,mbstring,intl}

Navigate to the work directory

cd /var/www

Install Composer

sudo php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
sudo php -r "if (hash_file('sha384', 'composer-setup.php') === 'e21205b207c3ff031906575712edab6f13eb0b361f2085f1f1237b7126d785e826a450292b6cfd1d64d92e6563bbde02') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
sudo php composer-setup.php
sudo php -r "unlink('composer-setup.php');"

Most likely, you want to put the composer.phar into a directory on your PATH, so you can simply call composer from any directory (Global install), using for example:

sudo mv composer.phar /usr/local/bin/composer

sudo composer create-project laravel/laravel project_name

oops i'm still editing

StreamingLLM - 4 Million Token , 22x Faster

JohnDotOwl — Tue, 10 Oct 2023 02:14:50 +0000

Recent advances in natural language processing have led to the development of large language models (LLMs) like GPT-3 that can generate remarkably human-like text. However, a major limitation of LLMs is that their performance degrades rapidly as more context is provided. Attempting to feed LLMs unlimited data results in the model slowing down and eventually crashing.

A new technique called Streaming LM aims to solve this problem by allowing unlimited context to be provided to LLMs without sacrificing speed or overloading memory.

How LLMs Currently Work

LLMs like GPT-3 are based on the transformer architecture. Each new token that is processed increases the model's complexity quadratically. So feeding more data to the model exponentially increases training time and memory usage.

Current approaches to dealing with long context sequences include attention windowing, where older tokens are discarded, or keeping only the most recent tokens. However, both these methods result in the model losing the broader context.

Key Insights Behind Streaming LLM

The creators of Streaming LLM made an interesting observation about how attention is distributed in LLMs. They found that most of the attention is paid to the first few tokens, with diminishing attention paid to later tokens.

So even with a large context sequence, the first few tokens and the most recent tokens contain the majority of relevant information. The tokens in the middle receive negligible attention.

How Streaming LLM Works

Streaming LLM takes advantage of this attention phenomenon. Instead of feeding all tokens to the model, it provides:

The first few important tokens (attention syncs)
A rolling cache of the most recent tokens
As new tokens are added, expired tokens from the middle are dropped without significantly impacting performance.

This approach allows virtually unlimited context to be provided to the LLM while maintaining efficiency and avoiding memory issues.

Does This Solve LLMs' Context Limitations?

For certain use cases like long-form content generation, the Streaming LLM approach works very well. The context limit is essentially removed.

However, for cases like summarizing academic papers, detailed context will still be lost. So there are still limitations to how much context LLMs can effectively utilize.

Nonetheless, Streaming LLM is an exciting first step towards enabling LLMs to leverage far more data context than previously possible. The potential to enhance LLMs' understanding of long conversations and documents is immense.

The Future Possibilities

While Streaming LLM has its limitations, it opens up news avenues for feeding more data to LLMs. With further research, more advanced techniques could be developed to allow LLMs to thoroughly comprehend vastly more information.

The future of LLMs is bright. With innovations like Streaming LLM, models stand to become capable of far more complex and nuanced language understanding and generation.

Github - https://github.com/mit-han-lab/streaming-llm
Research Paper - https://arxiv.org/abs/2309.17453

Optimizing PostgreSQL Configuration with PgTune

JohnDotOwl — Mon, 02 Oct 2023 11:16:28 +0000

Introduction

PostgreSQL is a powerful open source relational database management system. However, like any complex software, PostgreSQL has numerous configuration parameters that can be tweaked and tuned for optimal performance. Choosing the right configuration settings can sometimes be difficult, but luckily there are tools available to help. One such tool is pgTune, which provides recommendations for PostgreSQL configuration based on your hardware specs and intended database workload. In this post, we’ll look at how to use pgTune to optimize your PostgreSQL installation.

Overview of PgTune

PgTune is a web-based tool created by PostgreSQL experts to simplify the process of configuring PostgreSQL settings. The pgTune website provides an easy-to-use form where you enter details about your hardware and database workload. PgTune then analyzes this information and provides a configuration file with optimized parameters.

Some of the key features of PgTune include:

Input fields for CPU, RAM, disks, database size, connections, etc.
Support for PostgreSQL versions 9.0 and above.
Settings optimized for OLTP or DW/OLAP workloads.
Additional tweaks for SSD storage, cloud environments, and more.
Output as a postgresql.conf file or comparison to your current config.

Using PgTune

Using pgTune to optimize your PostgreSQL config involves three simple steps:

Gather details about your hardware specs and database workload. This includes information like CPU cores, RAM size, disk types/sizes, database size, max connections, etc.
Enter the details into the pgTune web form. PgTune has sections for server hardware, storage, workload characterization, and other parameters.
Download the generated postgresql.conf file. The output will be a complete config file with pgTune's recommended settings based on what you entered.



/etc/postgresql/16/main/postgresql.conf

Once you have the optimized postgresql.conf file, you can replace your existing config with it to implement pgTune's recommendations. Make sure to restart PostgreSQL after replacing the config file.

PgTune Settings Overview

Some of the key PostgreSQL settings that pgTune will optimize include:

Shared buffers - Sets memory for cache
Work memory - For sorting operations
Maintenance work mem - For admin tasks like VACUUM
Checkpoint segments - For crash recovery
Effective cache size - Estimated memory for indexes/data
Synchronous commit - For write performance vs reliability

Modifying postgresql.conf

Make a backup copy of the existing postgresql.conf



sudo cp /etc/postgresql/16/main/postgresql.conf /etc/postgresql/16/main/postgresql.conf.bak

Reboot after editing it and if it fails , switch back to the original conf. using the following command.



sudo cp /etc/postgresql/16/main/postgresql.conf.bak /etc/postgresql/16/main/postgresql.conf



sudo systemctl restart postgresql

Conclusion

PgTune is a great open source tool for simplifying one of the most complex parts of PostgreSQL - configuration tuning. By automatically generating an optimized postgresql.conf based on your system specs and database workload, pgTune makes it easy to get the most out of PostgreSQL performance. The tool is constantly updated by expert PostgreSQL administrators and is highly recommended for any serious Postgres user. Give pgTune a try and see if it can take your database performance to the next level!

Host Docker Image Builds with GitHub

JohnDotOwl — Mon, 25 Sep 2023 12:37:58 +0000

Docker has become an essential tool for developing and deploying applications. Pairing Docker with GitHub workflows allows you to easily build Docker images and push them to registries like GitHub Container Registry (GHCR) on every code change. In this post, I'll show you how to set up a GitHub workflow to build and publish a Docker image.

The Sample Project

For this example, let's say we have a simple Node.js application called project-name that we want to Dockerize. The source code is hosted in a GitHub repo.

Our goal is to build a Docker image and push it to GHCR every time code is pushed to GitHub. This will allow us to always have an up-to-date Docker image built from the latest source.

Creating the GitHub Workflow

GitHub workflows are defined in YAML files stored in the .github/workflows directory of your repo. Let's create a file called docker-image.yml with the following contents:

name: Docker Image CI for GHCR

on: push

jobs:
  build_and_publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: build and push the image
        run: |
          docker login --username username --password ${{secrets.GITHUB_TOKEN}} ghcr.io
          docker build . --tag ghcr.io/username/project-name:latest
          docker push ghcr.io/username/project-name:latest

This defines a workflow that will run on every push to GitHub. It has one job called build_and_publish that will build the Docker image and push it to GHCR.

The steps use the GitHub Actions checkout action to clone the repo code. Then we build the image, tag it with the GHCR repository path, and push it.

The GITHUB_TOKEN secret allows us to authenticate with GHCR.

Triggering the Workflow

With the workflow defined, we can now trigger it by pushing code to GitHub.

For example, if we make a small change and push it:

git commit -m "Update README"
git push origin main

This will trigger the workflow, build the image, and push it to your GHCR repo.

We now have automated Docker image builds on every code change! The same pattern can be used to build and publish images to Docker Hub or other registries.

GitHub workflows are powerful for automating all kinds of development tasks. For Docker specifically, they provide an easy way to implement continuous integration and deployment pipelines.

Abstract

This post shows one of the most minimal GitHub workflows for automated Docker image builds on code pushes. The straightforward YAML provides a great example of no-frills Docker CI/CD.

PostgreSQL 16 Installation on Ubuntu 22.04

JohnDotOwl — Sun, 24 Sep 2023 11:43:55 +0000

Overview
PostgreSQL 16 is the latest major release of the popular open source relational database. It comes with many new features and improvements such as enhanced monitoring capabilities, improved performance, logical replication enhancements, additional server configurations, and security advancements.

In this tutorial, we will cover how to install PostgreSQL 16 on Ubuntu 22.04 We will also look at some basic configuration to allow remote connections, enable password authentication, and get started with creating users, databases etc.

Prerequisites
Ubuntu 22.04
Root privileges or sudo access
use sudo su to get into root instead of ubuntu(default user)

Step 1 - Add PostgreSQL Repository

First, update the package index and install required packages:

sudo apt update
sudo apt install gnupg2 wget nano

Add the PostgreSQL 16 repository:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

Import the repository signing key:

curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg

Update the package list:

sudo apt update

Step 2 - Install PostgreSQL 16

Install PostgreSQL 16 and contrib modules:

sudo apt install postgresql-16 postgresql-contrib-16

Start and enable PostgreSQL service:

sudo systemctl start postgresql
sudo systemctl enable postgresql

Check the version and ensure it's Postgresql 16:
psql --version
You should get something like

psql (PostgreSQL) 16.0 (Ubuntu 16.0-1.pgdg22.04+1)

Step 3 - Configure PostgreSQL 16

Edit postgresql.conf to allow remote connections by changing listen_addresses to *:

sudo nano /etc/postgresql/16/main/postgresql.conf
listen_addresses = '*'

Configure PostgreSQL to use md5 password authentication by editing pg_hba.conf , this is important if you wish to connect remotely e.g. via PGADMIN :

sudo sed -i '/^host/s/ident/md5/' /etc/postgresql/16/main/pg_hba.conf
sudo sed -i '/^local/s/peer/trust/' /etc/postgresql/16/main/pg_hba.conf
echo "host all all 0.0.0.0/0 md5" | sudo tee -a /etc/postgresql/16/main/pg_hba.conf

Restart PostgreSQL for changes to take effect:

sudo systemctl restart postgresql

Allow PostgreSQL port through the firewall:

sudo ufw allow 5432/tcp

Step 4 - Connect to PostgreSQL

Connect as the postgres user:

sudo -u postgres psql

Set a password for postgres user:

ALTER USER postgres PASSWORD 'VeryStronGPassWord@1137';

Conclusion
We have successfully installed PostgreSQL 16 on Ubuntu, performed some basic configuration like enabling remote connections, set up password authentication, created a database and users. PostgreSQL is now ready to be used for development or production workloads.

Why Your H1 and Title Should Be Different for SEO

JohnDotOwl — Thu, 14 Sep 2023 13:08:39 +0000

Why Your H1 and Title Should Be Different for SEO

Search engine optimization (SEO) is crucial for driving relevant organic traffic to your website. Two key on-page elements that influence SEO are your title tag and H1 heading.

While your title and H1 should complement each other, they serve different purposes and should not be identical. Here's why:

The Title Tag Focuses on Keywords

Your title tag appears in search engine results pages (SERPs) as the clickable link. It should contain your most important keywords and compel users to click. Having your target keyword appear early in the title tag signals to search engines what the page is about.

The title also needs to make sense for users. Closely mirroring the H1 in the title tag could result in odd, lengthy titles.

The H1 Summarizes the Content

Your H1 appears on the page itself as the main heading. It should summarize or introduce the content that follows. The H1 gives structure to your content for both users and search bots.

Repeating the title tag as the H1 would result in repetitive, potentially awkward headings. It also wastes an opportunity to include related keywords.

Complement Without Copying

The title and H1 should complement each other without being identical. For example, the title could focus on a location-based keyword while the H1 introduces the content topic.

Having variation also gives search engines more signals about your page's relevance. It helps avoid keyword stuffing.

In summary, keep your title tag and H1 heading focused on your target keywords, but make them distinct. This balance will help optimize the page for both search engines and users.

Example 1

Title: Affordable Pet Grooming in Los Angeles
H1: Professional Pet Grooming Services

The title focuses on the location and service keywords while the H1 introduces the content topic in more detail.

Example 2

Title: Best Mountain Bike Trails in Vermont
H1: Top Mountain Biking Trails to Try in Vermont

Again the title targets the location and keywords, while the H1 sets up the content as a list of recommendations.

Example 3

Title: How to Potty Train Your Puppy in 7 Days
H1: A Step-by-Step Guide to Potty Train Any Puppy in Just 7 Days

The title highlights the keyword phrase "potty train your puppy" while the H1 elaborates on the content as a guide.

Example 4

Title: Best Plumbers in Chicago - Top 10 Options
H1: Finding a Reliable Plumber in Chicago

What is Google's point of view?

It is a bad idea to duplicate your title tag content in your first-level header. If your page's title and h1 tags match, the latter may appear over-optimized to search engines.
Also, using the same content in titles and headers means a lost opportunity to incorporate other relevant keywords for your page.

https://developers.google.com/search/docs/appearance/title-link

Redirect to 404 - NextJs 13 App Directory

JohnDotOwl — Mon, 04 Sep 2023 13:39:25 +0000

The next/navigation package introduced in Next.js 13 App Directory makes it easy to handle 404 pages and redirect users when a page is not found.

One way to do this is with the notFound() function. Here's an example:

import { notFound } from 'next/navigation';

export default async function Component({ params }) {
  const { slug } = params;

  const res = await fetch(`https://api.example.com/item/${slug}`);

  if (res.status === 404) {
    notFound();
  }

  const item = await res.json();

  // rest of component
}

This fetches data for an item based on a slug. If the API returns a 404 status, we call notFound().

This will redirect the user to the custom 404 page defined in pages/404.js. It also shows the 404 page UI instantly without waiting for the fetch call, providing a smooth experience.

The key things to note:

notFound() prevents the rest of the component from rendering if called
It shows the 404 page immediately, no loading state
Custom 404 page is defined in src/app/not-found.tsx as usual
Some other examples of when you may want to use notFound():

User visits a deleted page
Invalid slug parameter
Authentication failure

The notFound() function makes handling 404s clean and idiomatic in Next.js. Give it a try in your Next 13 app!

Let me know if you would like me to expand on any part of this post. I'm happy to include more details on how to customize the 404 page, integrate with an CMS, or any other use cases!

Dynamic Metadata NextJS 13 App Directory

JohnDotOwl — Sat, 19 Aug 2023 05:40:45 +0000

When building a website with Next.js 13, you'll likely need to display dynamic metadata like product names. There are two approaches for handling metadata in Next.js app directory: static and dynamic.

Static metadata looks like:

export const metadata: Metadata = {
  title: '...',
  description: '...',
}

However, dynamic metadata is more common for sites displaying changing content. After researching solutions, I realized the only way to show dynamic metadata was calling an API on each page. But fetching metadata from an API on every page felt inefficient.

That's when I discovered request memoization - deduplicating similar API requests to avoid wasting resources. Here's how it works:

Create a shared cache for metadata API responses
Before fetching, check if response already exists in cache
If it does, return cached data instead of calling API again
If not, make API call and cache response By memoizing metadata API requests, we avoid duplicated network requests. The metadata is still dynamic, but now fetched only once per unique content.

This optimizations allows displaying dynamic SEO-friendly metadata in Next.js 13 without taxing our API. Request memoization is a simple but powerful strategy for improving performance in React and Next.js apps.

If you need a code reference, check it out below!

import Link from 'next/link';
import { Metadata, ResolvingMetadata } from 'next';
interface Params {
  slug: string;
}

export async function generateMetadata({
  params,
}: {
  params: Params;
}): Promise<Metadata> {
  const { slug } = params;
  // read route params
  const url = 'https://api.example.com/v1/component/' + slug;

  // fetch data
  const component_item = await fetch(url).then((res) => res.json());
  console.log(component_item);

  return {
    title: component_item.name,
    description: component_item.description,
  };
}

Request Memoization

React extends the fetch API to automatically memoize requests that have the same URL and options. This means you can call a fetch function for the same data in multiple places in a React component tree while only executing it once.

For example, if you need to use the same data across a route (e.g. in a Layout, Page, and multiple components), you do not have to fetch data at the top of the tree then forward props between components. Instead, you can fetch data in the components that need it without worrying about the performance implications of making multiple requests across the network for the same data.

Resources for Dynamic Metadata
https://javascript.plainenglish.io/mastering-metadata-in-next-js-a-comprehensive-guide-to-seo-excellence-ab9c2cf0dc35

https://nextjs.org/docs/app/building-your-application/caching#request-memoization

https://www.slingacademy.com/article/next-js-how-to-set-page-title-and-meta-description/

https://www.builder.io/blog/routing-seo-metadata-nextjs-13