DEV Community: William Beuil

À La Recherche Des Analytics

William Beuil — Thu, 08 Jul 2021 18:04:09 +0000

Ami lecteur, si vous êtes en train de lire cet article c'est que vous recherchez un moyen de mesurer le nombre de vues sur votre site internet. Certes, il existe Google Analytics. Malheureusement, bien que gratuit, ce n'est pas du tout un outil facile à utiliser. J'ai personnellement opté pour une alternative et je vais essayer de vous expliquer pourquoi j'ai choisi Plausible Analytics.

C'est quoi Plausible ?

Plausible Analytics a été créé et est toujours maintenu par Uku Taht et Marko Saric, originaires d'Estonie. C'est un service assez récent puisqu'il a été commencé en décembre 2018 et a été lancé officiellement en production en Avril 2019. C'est un outil qui semble être une alternative à Google Analytics simple et respectueuse de la vie privée.

Ses points forts

Ce que j'apprécie le plus dans Plausible, c'est avant tout un service open source, c'est-à-dire que vous pouvez aller voir directement le code source voire y contribuer sur leur projet GitHub.

C'est simple à utiliser et à intégrer d'autant plus que le script est petit, moins de 1 KB, et donc très rapide à charger.

Ils n'utilisent en aucun cas les cookies, contrairement à Google Analytics, ce qui les rend compatible RGPD et PECR. Dites au revoir aux bannières d'autorisations de cookies.

Il n'y a aucun tracking des utilisateurs entre leurs appareils, ni entre les sites visités et les applications utilisées, ce qui signifie qu'ils ne peuvent pas connaître ou comprendre le comportement de vos utilisateurs.

Toutes les données collectées sont affichées ci-dessous. Comme vous pouvez le voir, il n'y a aucune donnée personnelle collectée. Au final, Plausible mesure la tendance globale du trafic sur le site internet.

En dernier, je ne suis pas obligé d'utiliser leur solution SAAS. En effet je peux l'héberger où je veux et le mettre en accès public pour une envie de transparence.

Héberger Plausible comme moi

Pour ce petit projet, nous allons utiliser leur solution clé en mains.

Nous allons déployer l'infrastructure sur AWS avec comme outil IaC (Infrastructure as Code) Terraform.

Le diagramme ci-dessous résume parfaitement l'architecture :

D'abord, il nous faut un VPC qui va nous permettre d'y intégrer d'autres ressources dans un réseau privé et isolé.

resource "aws_vpc" "vpc" {
  cidr_block = "10.0.0.0/16"
}

Pour permettre au serveur Plausible d'avoir un accès à internet, nous devons le placer dans un sous-réseau (e.g. subnet en anglais) public. Pour ceux qui ne le savent pas, on dit qu'un sous-réseau est public s'il est associé à une table de routage (e.g. route table en anglais) comportant une route vers une passerelle internet (e.g. internet gateway en anglais).

resource "aws_subnet" "subnet" {
  vpc_id     = aws_vpc.vpc.id
  cidr_block = "10.0.0.0/24"
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.vpc.id
}

resource "aws_default_route_table" "rt" {
  default_route_table_id = aws_vpc.vpc.default_route_table_id
}

resource "aws_route" "r" {
  route_table_id         = aws_default_route_table.rt.id
  gateway_id             = aws_internet_gateway.gw.id
  destination_cidr_block = "0.0.0.0/0"
}

Pour sécuriser le serveur, nous avons besoin d'un groupe de sécurité (e.g. security group en anglais) qui agit en tant que pare-feu virtuel pour notre serveur afin de contrôler le trafic entrant, comme les requêtes HTTP, et sortant.

resource "aws_default_security_group" "sg" {
  vpc_id = aws_vpc.vpc.id
}

resource "aws_security_group_rule" "i_http" {
  type              = "ingress"
  from_port         = 8000
  to_port           = 8000
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "HTTP"
  security_group_id = aws_default_security_group.sg.id
}

resource "aws_security_group_rule" "e_all" {
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "All protocols"
  security_group_id = aws_default_security_group.sg.id
}

Nous aurons aussi besoin d'un accès SSH sur notre serveur afin de pouvoir configurer correctement Plausible. Pour faire simple on va autoriser toutes les IP à se connecter en SSH, mais sachez qu'en production il faut uniquement autoriser votre adresse IP.

resource "aws_security_group_rule" "i_ssh" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "SSH"
  security_group_id = aws_default_security_group.sg.id
}

Nous pouvons, ensuite, créer l'instance EC2 dans laquelle nous allons installer Plausible.

resource "aws_instance" "instance" {
  ami                         = "ami-0b3e57ee3b63dd76b"
  instance_type               = "t2.micro"
  subnet_id                   = aws_subnet.subnet.id
  associate_public_ip_address = true
  key_name                    = "plausible"
  user_data                   = file("script.sh")
  root_block_device {
    volume_size           = 8
    volume_type           = "gp2"
    encrypted             = true
    delete_on_termination = false
  }
}

La clé SSH a été créée avec la commande aws ec2 create-key-pair --key-name plausible --query "KeyMaterial" --output text > plausible.pem.

Je me suis permis d'y ajouter un script qui va automatiquement mettre à jour tous les paquets, et installer docker et docker-compose dans l'instance à son initialisation pour gagner du temps.

#!/bin/bash
yum update -y
amazon-linux-extras install -y docker
service docker start
usermod -a -G docker ec2-user
chkconfig docker on
curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
reboot

Maintenant, nous avons plus qu'à suivre le guide officiel.

On télécharge en premier leur projet :

$ curl -L https://github.com/plausible/hosting/archive/master.tar.gz | tar xz
$ cd hosting-master

Puis, nous devons ajouter les variables d'environnement requis dans le fichier plausible-conf.env :

ADMIN_USER_EMAIL=XXX@gmail.com
ADMIN_USER_NAME=XXX
ADMIN_USER_PWD=XXX
BASE_URL=http://1.2.3.4:8000 = l'adresse IP publique de votre instance EC2
SECRET_KEY_BASE=XXX = une clé secrete aléatoire en base64

Comme j'aimerais utiliser mon compte Gmail pour leur fonctionnalité d'emailing, il faut créer un mot de passe d'application et ajouter les variables d'environnement suivantes :

SMTP_HOST_ADDR=smtp.gmail.com
SMTP_HOST_PORT=465
SMTP_USER_NAME=XXX@gmail.com
SMTP_USER_PWD=XXX = votre mot de passe d'application
SMTP_HOST_SSL_ENABLED=true

Enfin, nous pouvons lancer le serveur Plausible avec docker-compose up -d.

Nous devrions pouvoir aller sur http://1.2.3.4:8000 dans notre navigateur préféré et voir la page d'authentification de Plausible. Une fois l'enregistrement terminé, nous devrions avoir le script à rajouter dans le tag head de notre site pour commencer à mesurer le nombre de vues.

Sur un site Next.js, vous pouvez mettre le script dans le fichier _document.js :

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx)
    return { ...initialProps }
  }

  render() {
    return (
      <Html>
        <Head>
          <script async defer data-domain="example.com" src="http://1.2.3.4:8000/js/plausible.js" />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

Parfait ! Nous pouvons maintenant retourner sur http://1.2.3.4:8000 et voir les vues s'accumuler.

En résumé

Nous avons installé, configuré et déployé notre serveur Plausible sur AWS en utilisant Terraform. N'hésitez pas à suivre leur documentation si vous voulez davantage configurer votre serveur.

Merci d'avoir lu l'article ! Si vous avez aimé ou s'il vous a aidé d'une certaine manière, pensez à le partager. Probablement que j'écrirai dans une deuxième partie comment y intégrer le SSL.

Make Analytics Great Again

William Beuil — Thu, 01 Jul 2021 18:01:35 +0000

Dear readers, if you are reading this article, it means you're looking for a way to measure the number of views of your website. You could easily use Google Analytics, even though it's free, but it's really hard to fully understand and use it. I decided to go with an alternative and I will try to explain why I chose Plausible Analytics.

What is Plausible?

Plausible Analytics was created and is still maintained by Uku Taht and Marko Saric from Estonia. It is a fairly new web analytics service since it started in December 2018 and launched in April 2019. They say that it is a simple and privacy-friendly alternative to Google Analytics.

Its strengths

One of the main features I like about Plausible is that it is fully open source. You can see exactly what the code looks like and even contribute to it if you want in their GitHub repository.

It is so easy to integrate and since the script is only 1 KB, it's lightning-fast!

They do not use cookies whatsoever, compared to Google Analytics, which makes them GDPR and PECR compliant. Say goodbye to the cookie banner.

They're not tracking people across devices nor across websites and apps which means they can't know or understand the behavior of your users.

All collected data can be found below. As you can see there are no personal data or personally identifiable information collected. At the end of the day, Plausible only tracks the overall trends in my website traffic.

Last but not least, I can self-host it wherever I want and make it public so that everyone can see what I have access to.

Self-host Plausible like me

For this little project, we will use their up and running template that has everything we need to boot up our Plausible server.

We're gonna use Terraform as our IaC (Infrastructure as Code) tool and we will deploy our infrastructure to AWS.

What we're gonna build can be summarized with this diagram:

First, we need a VPC that lets us launch other AWS resources in an isolated virtual network that we can define as wanted.

resource "aws_vpc" "vpc" {
  cidr_block = "10.0.0.0/16"
}

Then, to enable Plausible to have access to the internet we need to place it in a public-facing subnet. For those who don't know, if a subnet is associated with a route table that has a route to an internet gateway, it's known as a public subnet.

resource "aws_subnet" "subnet" {
  vpc_id     = aws_vpc.vpc.id
  cidr_block = "10.0.0.0/24"
}

resource "aws_internet_gateway" "gw" {
  vpc_id = aws_vpc.vpc.id
}

resource "aws_default_route_table" "rt" {
  default_route_table_id = aws_vpc.vpc.default_route_table_id
}

resource "aws_route" "r" {
  route_table_id         = aws_default_route_table.rt.id
  gateway_id             = aws_internet_gateway.gw.id
  destination_cidr_block = "0.0.0.0/0"
}

To help secure the web server, we need a security group with rules which allow the web server to respond to inbound HTTP requests from the internet while simultaneously allowing all outbound IPv4 traffic.

resource "aws_default_security_group" "sg" {
  vpc_id = aws_vpc.vpc.id
}

resource "aws_security_group_rule" "i_http" {
  type              = "ingress"
  from_port         = 8000
  to_port           = 8000
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "HTTP"
  security_group_id = aws_default_security_group.sg.id
}

resource "aws_security_group_rule" "e_all" {
  type              = "egress"
  from_port         = 0
  to_port           = 0
  protocol          = "-1"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "All protocols"
  security_group_id = aws_default_security_group.sg.id
}

Since we need to configure the web server with several credentials, we need SSH access to it. To make it easy for this example, allow all IPV4 access to SSH but bear in mind that you should always allow only your IP address.

resource "aws_security_group_rule" "i_ssh" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  description       = "SSH"
  security_group_id = aws_default_security_group.sg.id
}

Let's create now the EC2 instance where the web server will be launched into.

resource "aws_instance" "instance" {
  ami                         = "ami-0b3e57ee3b63dd76b"
  instance_type               = "t2.micro"
  subnet_id                   = aws_subnet.subnet.id
  associate_public_ip_address = true
  key_name                    = "plausible"
  user_data                   = file("script.sh")
  root_block_device {
    volume_size           = 8
    volume_type           = "gp2"
    encrypted             = true
    delete_on_termination = false
  }
}

The SSH key has been created with aws ec2 create-key-pair --key-name plausible --query "KeyMaterial" --output text > plausible.pem.

I created a specific script to automatically update all packages and to install docker and docker-compose in our EC2 instance to make it quicker to launch our Plausible server.

#!/bin/bash
yum update -y
amazon-linux-extras install -y docker
service docker start
usermod -a -G docker ec2-user
chkconfig docker on
curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
reboot

Now, we can follow their guide.

We need to download their repository first:

$ curl -L https://github.com/plausible/hosting/archive/master.tar.gz | tar xz
$ cd hosting-master

Then, we need to add the required environment variables to plausible-conf.env:

ADMIN_USER_EMAIL=XXX@gmail.com
ADMIN_USER_NAME=XXX
ADMIN_USER_PWD=XXX
BASE_URL=http://1.2.3.4:8000 = the public IP of your EC2 instance
SECRET_KEY_BASE=XXX = a random base64 secret key

Since I want to use my Gmail account, I need to create a Google App Password and then add below environment variables to the configuration file:

SMTP_HOST_ADDR=smtp.gmail.com
SMTP_HOST_PORT=465
SMTP_USER_NAME=XXX@gmail.com
SMTP_USER_PWD=XXX = your Google App Password
SMTP_HOST_SSL_ENABLED=true

Finally, we can start our Plausible server with docker-compose up -d.

We should now be able to hit http://1.2.3.4:8000 in our favorite browser and see the login page of our Plausible server. At the end of the registration process, we should have the script that we would need to add to our website to start gathering page views.

In a Next.js website, you can add the script in the _document.js file:

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx)
    return { ...initialProps }
  }

  render() {
    return (
      <Html>
        <Head>
          <script async defer data-domain="example.com" src="http://1.2.3.4:8000/js/plausible.js" />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

Awesome! We can now check back our Plausible server at http://1.2.3.4:8000 to see whether we're getting any visits to our website.

Wrapping up

We've installed, configured, and deployed our Plausible server in AWS with Terraform. Don't hesitate to follow their documentation to further configure your Plausible server.

Thanks so much for reading! If you liked this post or it helped you in any way please consider sharing it. I will probably make a second blog post to upgrade our Plausible server to enable SSL requests.

Comment J'ai Fait Mon Blog Bilingue

William Beuil — Fri, 11 Jun 2021 23:25:39 +0000

C'est le tout premier article sur mon site, et pour commencer je vais vous expliquer comment j'ai créé mon blog. Je vais essentiellement parler des technologies utilisées et comment j'ai internationalisé le site.

Next.js

En tant que développeur React, je suis parti sur le framework Next.js pour mon blog. Cela fait plusieurs mois que je travaille avec et c'est juste incroyable. Plus besoin de passer du temps sur Webpack, les performances sont folles (e.g. regardez les statistiques sur ma dernière PR), mes pages sont dynamiquement générées en HTML, je peux utiliser les API Routes pour des besoins spécifiques comme du rendu d'images à la demande.

Bref, je suis totalement amoureux de ce framework ! D'ailleurs, n'oubliez pas de vous inscrire pour la Next.js Conf qui se tiendra en ligne.

SSG

Une des forces de Next.js c'est de pouvoir choisir sa méthode de récupération de données. Soit vous les récupérez au moment de build votre site (e.g. Static Site Generation), soit à la demande à chaque requête du site (e.g. Server Side Rendering).

J'ai choisi la première pour des raisons simples. Toutes les pages de mon site sont statiques. On peut donc les créer en amont et gagner en performance.

export const getStaticProps: GetStaticProps = async ({ locale }) => {
  const language = await import(`../locales/${locale}.json`);

  return {
    props: {
      lngDict: language.default,
    },
  };
};

API Routes

Laissez-moi vous dire que les API Routes c’est juste le feu ! Connaissant plutôt bien AWS Lambda, la tendance serverless est réelle et on devrait tous tester des outils comme les Lambdas ou les Cloudfare Workers. Du coup, le simple fait d’intégrer ce genre d’outil c’est la cerise sur le gâteau, à consommer abondamment.

Mes différentes façons d’utiliser cet outil :

Création d’un fichier SVG affichant les scores Lighthouse : lh-svg ;
Une API pour l’équipe FIFA Club Pro du FCSilmi : fcsilmi ;
Authentification Spotify : currently-playing ;

Sur mon site, j’utilise les API Routes pour 2 choses. La première, cela me permet de faire des requêtes aux serveurs de GitHub pour récupérer mes projets préférés et le graphique de contribution. La deuxième, cela me permet de créer à la demande une image pour mes articles de blog avec puppeteer-core.

export default async (
  req: NextApiRequest,
  res: NextApiResponse,
): Promise<void> => {
  const { slug } = req.query || {};

  if (slug) {
    const blogs = getBlogs();

    if (!blogs.find((blog) => blog.replace(/\.mdx/, '') === slug)) {
      return res.status(404).send('Not Found');
    }

    const html = generateBlogImageHTML(slug as string);
    const file = await screenshot(html);
    res.setHeader('Content-Type', `image/png`);
    res.setHeader(
      'Cache-Control',
      `public, immutable, no-transform, s-maxage=31536000, max-age=31536000`,
    );
    return res.status(200).end(file);
  }

  return res.status(404).send('Not Found');
};

Vercel

Mon site est déployé sur Vercel. Au tout début, j’étais parti du postulat qu’étant à la création de Next.js, ce sont les mieux armés pour créer la meilleure intégration avec leur framework.

Après utilisation avec plusieurs sites, et après avoir testé d’autres intégrations (e.g. Netlify notamment), j’ai maintenant la certitude que c'est la meilleure option d'hébergement pour Next.js. En 2 cliques vous pouvez héberger, non seulement votre projet Next.js, mais aussi d’autres projets (e.g. Vue, Angular). Avec Next.js version 10, on peut avoir gratuitement, pour un projet, les Next.js Analytics. On peut y intégrer des noms de domaine. Leur outil de gestion de variables d’environnements secrètes fonctionne à merveille et sans couac. Et on peut faire des connexions avec des outils tiers comme des GitHubs Apps. Essayez par vous-mêmes, vous n’allez pas le regretter.

Tailwind CSS

J’ai découvert Tailwind CSS en septembre dernier et depuis je ne peux m’en passer. Dès que je le peux, je l’utilise sans modération. Voilà mon humble avis sur le sujet :

Je peux rapidement créer une UI avec leurs utilitaires clés en main ;
J’ai drastiquement diminué la taille de mon bundle CSS malgré mon faible niveau en CSS ;
Je suis simplement plus productif avec ;

MDX

MDX, c’est ce qui fait que l’expérience en tant qu’auteur est si parfaite. C’est une extension du Markdown qui nous permet d’écrire du JSX dans des fichiers Markdown. Plus simplement, on peut écrire et bénéficier des composants React dans ces fichiers.

Pour un développeur comme moi qui écrit du Markdown à longueur de journée, c’est tellement bien. Pour ceux qui ne le savent pas, si vous utilisez régulièrement GitHub et GitLab, pour les pulls requests ou pour les issues, vous en écrivez.

# Comment écrire le paragraphe du dessus en Markdown:

[MDX](https://mdxjs.com/), c’est ce qui fait que l’expérience en tant qu’auteur est si parfaite. C’est une extension du Markdown qui nous permet d’écrire du JSX dans des fichiers Markdown. Plus simplement, on peut écrire et bénéficier des composants React dans ces fichiers.

Pour un développeur comme moi qui écrit du Markdown à longueur de journée, c’est tellement bien. Pour ceux qui ne le savent pas, si vous utilisez régulièrement GitHub et GitLab, pour les pulls requests ou pour les issues, vous en écrivez.

Ci-dessous, un exemple de MDX copié du site officiel :

# Hello, *world*!

Below is an example of JSX embedded in Markdown. <br /> **Try and change the background color!**

<div style={{ padding: '20px', backgroundColor: 'tomato' }}>
  <h3>This is JSX</h3>
</div>

mdx-bundler

Afin de faire fonctionner correctement Next.js avec des fichiers MDX, il faut pouvoir les compiler afin de les rendre utilisables en tant que composants React. Pour réaliser aux mieux cette tâche, j’utilise la nouvelle librairie mdx-bundler du célèbre Kent C. Dodds.

Je n’ai pas vraiment d’expériences avec les autres librairies (e.g. next-mdx-enhanced, next-mdx-remote) donc je ne me permettrais pas de juger les pour et les contre de chacun.

Afin de rendre l’expérience de lecture la plus agréable possible, j’ai essayé de customiser chaque composant de la page de l’article comme les titres et sous-titres, les images, les blocs de code ou les listes. D’autres composants viendront étoffer la liste au fur et à mesure.

Je me suis énormément inspiré de merveilleux blogs, notamment :

Frontmatter

Ce blog n’aurait jamais vu le jour sans des meta données pour chaque article de blog. Et pour cela, j’utilise ce qu’on appelle les frontmatter.

Utiles pour l’UI ou encore le SEO, on y écrit des pairs de clés-valeurs. Personnellement, je m’en sers pour le titre, la description, la date de publication, les tags ou encore la langue utilisée.

Ci-dessous un exemple pour cet article de blog :

---
title: "Comment J'ai Fait Mon Blog Bilingue"
description: "Un tour d'horizon de comment j'ai créé mon blog bilingue. Je vais essentiellement parler des technologies utilisées et comment j'ai internationalisé le site."
locale: fr
alternate: /blog/my-multilingual-blog
isPublished: true
publishedAt: "2021-05-22"
tags:
  - react
  - nextjs
  - tailwind
  - mdx
---

Le reste du contenu ...

Internationalisation

Depuis le début, je me suis juré de faire ce blog à la fois en anglais et en français. Heureusement avec la version 10 de Next.js, le développement de sites internationaux a été énormément facilité.

On a simplement à ajouter dans le fichier next.config.js la clé i18n avec les langues souhaitées. Next.js va alors automatiquement commencer à rediriger les utilisateurs sur les bons chemins du site (e.g /fr pour les francophones et / pour les anglophones) grâce aux headers Accept-Language de leur navigateur.

// Configuration de mon site

module.exports = {
  i18n: {
    locales: ['en', 'fr'],
    defaultLocale: 'en',
    localeDetection: false,
  }
}

J’utilise next-localization pour afficher les bonnes traductions dans mes composants React.

Quand on travaille sur des sites internationaux, il faut énormément penser en amont à comment organiser le SEO (Search Engine Optimization). Il faut donc être rigoureux sur la façon dont on organise le tag head dans son HTML.

J’ai essayé d’aller au maximum sur l’intégration des différentes langues. J'ai exposé 2 versions de flux RSS et de webmanifests en suivant au mieux les bonnes pratiques de W3C et de Google Search Console. N’hésitez surtout pas à me laisser des commentaires.

C’est quoi la suite ?

Je vais continuer à améliorer mon site, du point de vue du lecteur et de l’auteur. Si vous avez des idées de modifications, vous pouvez ouvrir une PR sur GitHub.

Je viens à peine de commencer mon aventure de créateur de contenus et je remercie tous ceux que je suis sur les réseaux et avec qui j’apprends tous les jours :

Retrouvez-moi pour du live-coding sur Twitch et bientôt sur Youtube. Abonnez-vous évidemment.

How I Made My Multilingual Blog

William Beuil — Fri, 04 Jun 2021 21:32:12 +0000

This is my very first blog post on my website, so for this one, I will try to explain how I came up with my blog. I will mostly explain the stack I used and how I tackled the internationalization of the whole website.

Next.js

As a React developer, I decided to create my whole website and thus my blog with the Next.js framework. It's been several months since I started using Next.js and it's just fantastic. I don't get to work extensively with Webpack, the performance is outstanding (e.g. look at these metrics on my latest PR), my pages are automatically generated as static HTML, I can use the API Routes for specific on-demand images.

Well, I'm just in love with this framework! Don't forget to get your ticket for the online Next.js Conf.

SSG

One of the main strengths of Next.js is its different methods of data fetching. You could either choose to fetch data at build-time (e.g. Static Site Generation) or on-demand on each request (e.g. Server Side Rendering).

I chose the former one since it's only a simple website with blogs where pre-rendering at build-time is possible and thus increases the performance.

export const getStaticProps: GetStaticProps = async ({ locale }) => {
  const language = await import(`../locales/${locale}.json`);

  return {
    props: {
      lngDict: language.default,
    },
  };
};

API Routes

API Routes are simply awesome. Coming from AWS Lambda, I think the serverless world should be learned and used extensively. Thus, having the luxury to have inside the Next.js framework a way to create and use easily a serverless function is just the cherry on the cake.

Several use cases of mine:

An endpoint to request an SVG file that displays Lighthouse scores: lh-svg;
An API for the FIFA Club Pro FCSilmi team: fcsilmi;
Endpoints for Spotify authentication: currently-playing;

On my website, I use the API Routes for two things. On one hand, to request my pinned repositories and my contribution graph on GitHub. On the other hand, to request on-demand images for my blog posts using puppeteer-core.

export default async (
  req: NextApiRequest,
  res: NextApiResponse,
): Promise<void> => {
  const { slug } = req.query || {};

  if (slug) {
    const blogs = getBlogs();

    if (!blogs.find((blog) => blog.replace(/\.mdx/, '') === slug)) {
      return res.status(404).send('Not Found');
    }

    const html = generateBlogImageHTML(slug as string);
    const file = await screenshot(html);
    res.setHeader('Content-Type', `image/png`);
    res.setHeader(
      'Cache-Control',
      `public, immutable, no-transform, s-maxage=31536000, max-age=31536000`,
    );
    return res.status(200).end(file);
  }

  return res.status(404).send('Not Found');
};

Vercel

My website is deployed on Vercel. As being the company behind Next.js, I initially expected them to have the best integration with their framework.

But after using it for multiple sites, I have several things to say about their product. In 2 clicks, you can deploy not only your Next.js website but also a ton of other javascript-based websites. Since Next.js 10, you can use freely, for just one website, their Next.js Analytics. You can configure custom domains, secret environment variables, integrate GitHub Apps to automate aspects of your workflow. Go try it for yourself, you won't be disappointed.

Tailwind CSS

I discovered Tailwind CSS last September and since then, whenever I can, I use it. Here are my two cents on this CSS framework:

I can rapidly build UI with already existing utility classes;
I decreased my CSS bundle size which means higher performance overall despite my not-so-good CSS skills;
I just feel more productive;

MDX

MDX is what powers this blog in terms of writing experience. It is an extension of the Markdown that lets us seamlessly write JSX in our Markdown files. Basically, we can use and benefit from React components inside a Markdown file.

For a developer like me, write in Markdown is a daily habit. Indeed, if you use GitHub or GitLab for your pull requests, then you've already written in Markdown.

# How I write the above paragraph in Markdown:

[MDX](https://mdxjs.com/) is what powers this blog in terms of writing experience. It is an extension of the Markdown that lets us seamlessly write JSX in our Markdown files. Basically, we can use and benefit from React components inside a Markdown file.

For a developer like me, write in Markdown is a daily habit. Indeed, if you use GitHub or GitLab for your pull requests, then you've already written in Markdown.

Here's an example with MDX copy from the official website:

# Hello, *world*!

Below is an example of JSX embedded in Markdown. <br /> **Try and change the background color!**

<div style={{ padding: '20px', backgroundColor: 'tomato' }}>
  <h3>This is JSX</h3>
</div>

mdx-bundler

To make Next.js works with MDX, we need to compile and bundle the markdown files. For this task, I decided to go with the new mdx-bundler library made by the famous Kent C. Dodds.

I don't have any experiences with the other libraries (e.g. next-mdx-enhanced, next-mdx-remote) so I won't judge the pros and cons of one compared to the others.

To increase the reader experience, I tried to customize as much as possible every component that renders the final page like the headings with custom anchor link, lists (unordered and ordered), images, codes, inline codes etc... More to come obviously with all the blog posts I want to write.

I was greatly inspired by awesome blogs I follow:

Frontmatter

What makes the whole blog complete is metadata. One way is the frontmatter.

I use them for UI and SEO purposes because I can store key-value pairs like title, description, publication date, tags and language.

Here's what this blog post looks like in terms of frontmatter:

---
title: "How I Made My Multilingual Blog"
description: "An overview of how I came up with my multilingual blog. I will mostly explain the stack I used and how I tackled the internationalization of the whole website."
locale: en
alternate: /blog/mon-blog-bilingue
isPublished: true
publishedAt: "2021-05-22"
tags:
  - react
  - nextjs
  - tailwind
  - mdx
---

Content here ...

Internationalization

Since the beginning, I knew I would like my blog to be both in french and in english. The latest major version, Next.js 10, released in October 2020, makes it even easier to create internationalized websites.

You just need to add in your next.config.js file, the i18n key with your languages and Next.js will start Subpath routing your user based on their Accept-Language header.

// Configuration for my website

module.exports = {
  i18n: {
    locales: ['en', 'fr'],
    defaultLocale: 'en',
    localeDetection: false,
  }
}

I work with next-localization to send the right translations to my child components.

When you work on an internationalized website, you need to think in terms of SEO (Search Engine Optimization) and thus you have to be thorough on what you display in your HTML <head> tag.

I tried to push to the extreme the internationalization by having both english and french RSS feeds, webmanifets and to change accordingly in the <head> tag the relevant link. As much as possible, I tried to follow the recommended practices as per Google Search Console or W3C. All feedbacks are welcome.

What's next?

I will continue to improve my website, both from the writer and from the user perspective. PRs are welcome if you want to be part of this adventure.

I've just started my creator journey and for that, I'm so thankful to all the creators I follow, from whom I learnt and still learn a lot:

I started to live streaming my developer adventure on Twitch, and hopefully, soon I will release my first video on Youtube.