
Hello World !

A l'occasion de la refonte de mon site web perso, j'ai décidé de m'offrir un blog pour vous parler de (et vous partager) ce que je fais.

Alors allons-y et commençons par parler de ce site. Ce sera l'occasion de parler de comment il a été fait de manière général, et de définir les prochains sujets que je traiterai dans ce blog.

Quand j'ai décidé de refaire mon site perso, j'avais l'embarras du choix en termes de technos à utiliser : ReactJS (que je connais très bien), Angular (que j'ai connu par le passé), VueJS...

Mais m'intéressant de plus en plus à la JAMStack, et amoureux de React, j'ai cherché un framework qui allie ces deux merveilleux mondes. Et c'est c'est là où je suis tombé sur GatsbyJS.

> Attends, Attends ! C'est bien tout ça mais de quoi tu parles ?

Je ferai des posts pour détailler chacune de ces notions, mais voici brièvement de quoi il est question.

## JAMStack

Dans le monde du développement Web, après la stack LAMP (pour Linux Apache MySQL Php) largement utilisées dans les années 2000, puis la stack MEAN (pour MongoDB, Express, Angular, NodeJS) qui a trouvé sa popularité dans les années 2010, nous venons d'assister à la naissance de la nouvelle "hype" du dév web : La stack JAM (pour Javascript, Api, Markup) ou plus simplement "le retour aux sites statiques".

Le principe est simple:

- Les fonctionnalités dynamiques du site sont gérées par Javascript.
- Les fonctionnalités côté backend sont interfacées via des APIs réutilisables, accessibles en HTTPS, par le code JS.
- Le tout est servi par des pages HTML (Markup) statiques

Sur cette page web par exemple (oui, celle que vous êtes en train lire ^), les fonctionnalités dynamiques (navigation, chargement différé des images, etc...) sont gérées en JS. Cet article est écrit en markdown et est stocké côté serveur. Et enfin, toutes les pages sont calculées et construites à partir du contenu au moment du build, ce qui en fait un site complètement statique.

> Ok, ok, mais en quoi c'est bien ?

Les avantages sont nombreux:

- **La performance :** Le site, ainsi que ses assets étant des fichiers statiques, il peuvent être servi depuis un CDN.
- **La sécurité :** Plus besoin de de soucier des failles du côté du serveur ou de la base de données.
- **Le coût :** L'hébergement des fichiers statiques coûte très peu cher, voire est complètement gratuit.
- **La scalabilité :** Votre site web ne peut pratiquement pas être victime de son succès, grâce aux CDN.
- **L'expérience développeur :** Les architectures monolithiques laissent place à des architectures découplées. Ce qui permet aux développeurs front d'aller plus vite et de manière plus ciblée.

> Ouais ok, c'est pas mal ton truc. Mais ça a l'air bien compliqué à mettre en place. Comment on fait du coup ?

Alors oui, on peut toujours écrire toutes ses pages directement en HTML à la main, mais on est d'accord que passées des pages web super simples, ça se corse très vite, et là on oublie tout de suite l'approche composants, la réutilisabilité du code, et tout ce qui fait le développement moderne...

Non, pour ça, on s'appuie sur des générateurs de sites statiques, et il y en a plusieurs : Jeykill (l'un des premiers sortis, en 2015), Gatsby, NextJS, Hugo, etc... chacun vient avec son lot de fonctionnalités embarquées, son framework frontend (React, Vue, Preact,...) et son système de plugins qui va nous faciliter la vie sur bien des aspects.

Pour ce site, mon choix s'est porté sur Gatsby.

## GatsbyJS

Gatsby est un générateur de sites web statiques, basé sur React et GraphQL.

Dans ce qui m'a séduit, il y a les généralités :

- **Gratuit et Open Source** (bon ok, ils le sont tous)
- **React** (et ça, j'adore !)
- **GraphQL** (et ça, c'est vraiment cool)

Et il y a les raisons de fond :

- **La gestion de données :** Gatsby utilise GraphQL pour créer une couche de données (data layer). Il est fait de manière à pouvoir collecter des données de n'importe quelle source, ça peut être du Markdown, JSON, votre CMS préféré, API externes... vraiment n'importe quelle source ! Et au moment du build, il crée un serveur GraphQL interne avec toutes ces données. Donc dans vos composants React, toutes les données sont collectées au moment du build à partir de ce même serveur, sous forme de requêtes GraphQL.
- **La richesse de l'écosystème :** Gatsby existe depuis très peu de temps, mais il affiche déjà une documentation très complète et un bon nombre de "starters" pour vous aider à démarrer rapidement dans des configurations différentes.
- **La performance :** Gatsby met un point d'honneur sur tout ce qui touche la performance et l'accessibilité, et vous le ressentirez vraiment sur votre produit final (vous n'avez qu'à lancer un audit lighthouse de ce site pour en avoir la preuve). De tout les générateurs que j'ai pu tester, c'est celui qui sort vraiment du lot.

Et puis bon, si on ne profite même pas de ces projets perso pour apprendre de nouvelles choses et se faire sa propre idée...

> Attends, mais Gatsby ne gère pas le contenu !

Une fois la structure du site faite, il me fallait en effet un gestionnaire de contenu, un CMS "headless" en somme. Là encore, ce ne sont pas les choix qui manquent, Gatsby permettant de requêter n'importe quelle source. Alors on se retrouve avec :

- Des CMS "classiques" (souples mais peu performants), de type Wordpress (PHP, hébergé ou "On Premise") ou Drupal (PHP),
- Des CMS un peu "moins classiques" (plus rapides), comme Ghost (NodeJS) ou OctoberCMS (Laravel),
- Ou encore avec des CMS carrément "nouvelle génération" et mieux adaptés à la JAMStack, comme Strapi, Contentful, ou Netlify CMS.

## Netlify CMS

C'est un CMS développé par Netlify, le spécialiste de l’hébergement et du déploiement de sites statiques.

Il est embarqué dans votre site, est très simple à configurer (quelques minutes suffisent pour démarrer) et s'appuie sur Git. En effet, il ne requiert pas de base de données et le contenu que vous rédigerez sera directement stocké dans votre repo Git (Github, Gitlab ou BitBucket) sous forme de fichiers Markdown (donc statiques !).

On ne peut pas faire plus rapide ou plus sécurisé ! Je n'ai rien d'autre à rajouter ^^

> Un site web statique, du contenu dans Git... mais t'héberge ça comment ?

Il n'y a rien de plus simple qu'héberger un site web statique, et les solutions ne manquent pas : Google Firebase, Amazon S3, Netlify, Github Pages, Zeit Now, Surge, un simple serveur Apache ou Nginx perso... et on peut même héberger son site statique sur Dropbox (oui, oui)

## Netlify

Au début, j'étais parti sur Firebase, pour sa gratuité et sa simplicité (et puis oui, je connaissais déjà bien). Il suffisait de `yarn build`er son site puis de le `firebase deploy`er pour voir ses changements appliqués en prod.

Sauf que voilà, avec l'utilisation de Netlify CMS depuis son interface web, qui push directement les modifications dans Git, il fallait à chaque fois rouvrir le projet en local, tirer les changement de Git (`git pull`), démarrer le serveur en local pour vérifier (prévisualiser) les changements (`yarn start`), reconstruire le projet (`yarn build`) et enfin lancer le déploiement (`firebase deploy`). Fastidieux travail donc, que tout bon développeur doit chercher à automatiser. Il faut donc monter un deuxième environnement sur Firebase (on l'appelle preview ou qualif ou recette...), une PIC (Plateforme d'Intégration Continue) grâce à Gitlab CI (vu que mon code est hébergé sur Gitlab) et commencer à scripter ses pipelines... mais cherchant à simplifier au maximum les choses et n'utilisant que la fonctionnalité d'hébergement (Hosting) de Firebase, rien ne justifiait de rester dessus si une solution plus simple se présentait. Et ça tombait bien, puisque Netlify fait tout ce que Firebase ne fait pas.

Netlify s'est spécialité dans l'hébergement de sites statique, il est très jeune aussi mais il monte à vitesse grand V. Il est tout aussi gratuit que Firebase mais propose quelques fonctionnalités très intéressantes :

- Le déploiement : Contrairement à Firebase qui se limite à l'hébergement, Netlify peut "builder" votre site. Il détecte automatiquement la nature de votre projet (ici Gatsby) et auto-configure le build.
- Le déploiement continu : Dès que vous poussez une modification sur votre branche principale (disons `master`), Netlify build et déploie automatiquement votre site en prod.
- Le "preview" des Merges Requests : Admettons que votre branche de travail s'appelle `develop`, dès que vous créerez une MR sur `master`, Netlify va la builder et la déployer non pas en prod mais sur un environnement interne, vous permettant ainsi de la prévisualiser. Il fera de même à chaque `commit` sur cette MR. Au moment où vous êtes content du résultat et que vous "mergez" la MR sur `master`, Netlify effectue un build de prod.
- Gestion des formulaires : Un formulaire de contact sur votre site ? Pas besoin de le gérer en JS, pas besoin d'appel API, vous rajouter deux attributs à votre formulaire et Netlify s'en occupe au moment du build. Vous recevrez les envois du formulaire directement dans votre dashboard Netlify et, si vous le souhaitez, par mail.

Tout ceci a fait que j'ai eu envie de tester cette solution, et de finalement l'adopter.

## Conclusion

Voilà, on arrive à la fin de ce premier article. Il y a beaucoup de choses à dire et j'espère qu'il n'a pas été trop long.

Je vous ai présenté les choix principaux que j'ai fait pour construire ce site web. Je tâcherai de détailler chaque solution dans un post à part pour pouvoir entrer un peu plus dans le détail.

En attendant, n'hésitez pas à laisser un commentaire, pour dire ce que vous en pensez ou si vous avez des questions.



Pour ce deuxième article de mon blog, je vais rentrer un peu plus dans le vif du sujet de la JAMStack et des sites web statiques, avec [Gatsby](https://www.gatsbyjs.org).

[Gatsby](https://www.gatsbyjs.org) est un générateur de sites web statiques, basé sur [React](https://fr.reactjs.org) qui monte avec une puissance phénoménale. Je l'ai essayé et comme la majorité des développeurs l'ayant essayé, je l'ai trouvé impressionnant et je l'ai adopté.

Gatsby compile votre projet en assets statiques, mais utilise les capacités dynamiques de React au besoin.

Quelques points forts de Gatsby:

- Très rapide 🚀(Server Side Rendering, Code splitting, prefetching, optimisation des images, etc...). Tout ce qui se fait de mieux dans le dév web moderne
- Une documentation très complète et accessible
- Une communauté grandissante et passionnée
- Une expérience dévelopeur très agréable : C'est un système puissant et assez complexe mais pensé de manière à nous simplifier et nous abstraire au maximum cette complexité en couvrant la majorité des besoin et use-cases classiques.
- La liberté d'utiliser n'importe quelle source de données (fichiers locaux, API, CMS, bases de données...)

## Les starters

Une des choses vraiment cool de Gatsby est l'abondance des [projets starters](https://www.gatsbyjs.org/starters). Ce sont des projets "modèles" que la communauté met à disposition, pour aider les développeurs à démarrer rapidement selon le cas d'usage ou les outils souhaités. De plus, une attention particulière est donnée aux best practices sur ces projets, ce qui contribue à notre amélioration.

Utiliser un starter est aussi le choix d'avoir ces outils préférés déjà embarqués (linter, pretifier, etc...). Ainsi, vous avez, par défaut, accès à certaines commandes utiles, que l'on retrouver dans la section `scripts` du fichier `package.json`, comme ici, par exemple, avec le starter par défaut de Gatsby :

```json
"scripts": {
  "build": "gatsby build",
  "develop": "gatsby develop",
  "format": "prettier --write src/**/*.{js,jsx}",
  "start": "npm run develop",
  "serve": "gatsby serve",
  "test": "echo \"Write tests! -> https://gatsby.dev/unit-testing\""
}
```

Vous pouvez filtrer les starters par technos, outils, etc... Mais comme au début ma liste de pré-requis était plutôt simple (`prettier` pour le formatage du code, optimisation des images, [react-helmet](https://github.com/nfl/react-helmet) pour la gestion du SEO) et que j'avais envie d'implémenter le reste moi-même pour me familiariser avec ce système, je suis parti avec le plus basic des starters, à savoir [gatsby-starter-default](https://www.gatsbyjs.org/starters/gatsbyjs/gatsby-starter-default).

## L'outillage pour démarrer

**Node.js et NPM:**

Si vous êtes ici, c'est que vous connaissez un minimum cet environnement permettant de faire tourner du code Javascript en dehors du contexte navigateur

> Note: La version minimale de Node.js supportée par Gatsby est la 8, libre à vous d'utiliser une version plus récente

Un simple node -- version et un npm --version permettent de connaître les versions actuellement installées

**Yarn**

Dans la communauté de développeurs front, il y a ceux qui aiment utiliser `npm` pour gérer les dépendances de leurs projets, et les autres. Je fais partie des autres, ayant déjà eu plusieurs soucis avec `npm` dans le passé, j'ai fait le choix de `yarn`.

Pour installer `yarn` de manière globale sur votre système, rien de plus simple :

```bash
npm i -g yarn
```

**Git:**

Quand vous démarrez un projet Gatsby, ce dernier télécharge le starter sélectionné (ou à défaut, celui par défaut) depuis un repo Git. Il est donc essentiel d'avoir l'outil Git en ligne de commande installé sur votre machine.

**Gatsby CLI**

Le CLI (Command Line Interface) de Gatsby est un package NPM publié sur `npmjs`, il permet de démarrer un projet mais propose aussi les outils nécessaires pour visualiser votre projet en cours de développement.

Pour l'installer :

```bash
npm i -g gatsby-cli
```

ou, si vous avez fait le choix d'utiliser yarn :

```bash
yarn global add gatsby-cli
```

Une fois l'installation terminée, vous pouvez créer votre projet avec la commande

```bash
gatsby new <nom_projet> <url_starter>
```

## Allons-y !

Ouvrez votre terminal et tapez les commandes suivantes :

```bash
gatsby new hello-gatsby # crée un dossier hello-gatsby et installe le starter (par défaut, ici) dedans
cd hello-gatsby # naviguer vers le dossier du projet
yarn install # installer les dépendances (peut être simplifié en tapant juste "yarn"
yarn start # exécute le script "start" du package.json (on peut aussi lancer directement avec "gatsby develop")
```

Le projet compile bien, et vous pouvez visualiser le résultat en allant sur http://localhost:8000 sur votre navigateur. Bravo !

### Architecture du projet

Prenons quelques minutes pour regarder comment est disposé notre projet. Dans notre dossier hello-gatsby. Selon le starter que vous avez sélectionné, vous aurez tout ou partie de l'arborescence suivante :

```
├── .cache/
├── plugins/
├── public/
├── src/
    ├── components/
    ├── images/
    ├── pages/
    └── html.js
├── gatsby-browser.js
├── gatsby-config.js
├── gatsby-node.js
├── gatsby-ssr.js
├── package.json
```

#### Dossiers

- `/.cache` Généré automatiquement. Ce dossier est un dossier de cache interne créé automatiquement par Gatsby. Les fichiers qu'il contient ne doivent pas être modifiés. Il doit être ajouté à votre fichier `.gitignore` si ce n'est pas déjà le cas.
- `/public` Généré automatiquement au moment du build. C'est ce dossier qui contiendra les fichiers et assets compilés de votre projet. Doit être ajouté à votre fichier `.gitignore` si ce n'est pas déjà le cas.
- `/plugins` Ce dossier comporte les plugins spécifiques qui ne sont pas publiés comme package npm (locaux donc).
- `/src` C'est votre dossier de "travail". Il contiendra tout votre code qui conditionne ce qui est affiché sur votre site web, comme votre header/footer, vos templates de pages. Vu que Gatsby est basé sur `React.js`, le contenu de ce dossier, dépendra certes de votre projet, mais ressemblera forcément à un projet `React.js` classique.
  - `pages` Chaque composant que vous créez dans ce dossier devient une page de votre site, avec un chemin (URL path) basé sur son nom.
  - `/templates` Contient les gabarits qui serviront à générer des pages dynamiquement.
  - `html.js` Il nous servira à surcharger la configuration par défaut du fichier `index.html` généré.
- `static` Tout fichier que vous mettrez ici ne va pas être traité par Webpack. Il sera copié tel quel dans le dossier `public`. Il servira notamment pour des assets à embarquer dans notre site (fichiers téléchargeables par exemple).

#### Fichiers

- `gatsby-browser.js` Ce fichier vous servira à définir un usage spécifique des API du navigateur. Certains plugins vous demanderont de rajouter du code dedans.
- `gatsby-config.js` Ce fichier est le moteur même de votre projet Gatsby. Dans ce fichier, vous pouvez définir les méta-data de votre site comme son titre et sa description, les plugins que vous souhaitez activer ainsi que la définition de leurs options...
- `gatsby-node.js` Ce fichier vous servira à définir un usage spécifique des API Node.js. C'est dans ce fichiers que vous pourrez générer des pages dynamiquement.
- `gatsby-ssr.js` Ce fichier vous servira à définir un usage spécifique des API du Server Side Rendering.

## Analyse du projet

Ouvrez le projet avec votre IDE préféré (Perso, j'utilise [VS Code](https://code.visualstudio.com)), démarrez le serveur (`gatsby develop` ou `yarn start`) et commençons à tester.

Comme vous pouvez le remarquer, vous avez 3 composants dans votre dossier `pages` : `404.js`, `index.js` et `page-2.js`.

Si vous faites pointer votre navigateur sur [http://localhost:8000](http:localhost:8000) vous verrez s'afficher le contenu du composant `index.js`.

A partir de là, modifier votre site est très simple, ouvrez le fichier `index.js` dans votre IDE et faites des modifications sur le composants, puis sauvegarder pour voir les modifications s'appliquer instantanément.

De la même manière, vous pouvez modifier le fichier `page-2.js` qui est accessible à l'adresse http://localhost:8000/page-2

### Navigation entre les pages

Il est possible de créer des liens entre les pages grâce à un composant React fourni par Gatsby, appelé Link.

Pour illustrer cet aspect, on va ajouter une nouvelle page `src/pages/page-3.js`, et on va créer un lien sur la `page-2`. Pour ce faire, importez le composant Link dans composant `page-2`:

```jsx
import { Link } from 'gatsby';
```

et utilisez-le dans votre code jsx:

```jsx
<Link to="/page-3/">Page 3</Link>
```

Testez le fonctionnement sur votre navigateur.

### Ajouter du style

Dans vos composants, il est possible d'importer n'importe quel fichier CSS :

```jsx
import './index.css';
```

et appliquer les classes adéquates sur les éléments que vous souhaitez styliser :

```jsx
<p className="my-class">...</p>
```

Autrement, vous pouvez également définir des styles "in-line" directement dans votre code JSX, bien que je ne saurais vous recommander cette pratique, du fait qu'elle impacte la lisibilité et la maintenabilité de votre code :

```jsx
<p
  style={{
    margin: '0 auto',
    padding: '20px',
  }}
>
  Hello world
</p>
```

### Utiliser les plugins Gatsby

Gatsby propose toute une panoplie de fonctionnalités embarquées. Mais il peut être agrémenté par d'autres fonctionnalités fournies par les [plugins](https://www.gatsbyjs.org/plugins/). Et il y en un bon nombre.

Il y a 3 types de plugins dans l'écosystème Gatsby:

- **_Source plugins_** : Ces plugins requêtent les données à partir d'une source donnée et créent des noeuds (nodes) qui peuvent ensuite être filtrées par les _transformer plugins_.
- **_Transformer plugins_** : Il transforment les données fournies par les _source plugins_ en données utilisables par Gatsby.
- **_Functional plugins_** : Ces plugins ajoutent de nouvelles fonctionnalités à Gatsby, comme la génération d'un sitemap ou autre.

L'installation d'un plugin passe par 2 étapes simples :

- Installer le plugin avec `npm`/`yarn`
- Déclarer le plugin dans le fichier de configuration de Gatsby `gatsby-config.js`

Par exemple, pour installer le plugin permettant de générer un sitemap :

```bash
yarn add gatsby-plugin-sitemap
```

Et dans le fichier `gatsby-config.js` (vous pouvez le créer s'il n'est pas déjà fourni par votre starter), ajouter le plugin au tableau exporté :

```javascript
module.exports = {
  plugins: ['gatsby-plugin-sitemap'],
};
```

C'est tout, votre plugin fait désormais son travail.

## Construction le site statique (Build)

Quand avez fini de personnaliser votre site Gatsby et que vous voulez construire un package de production, vous aurez besoin de lancer la commande suivante :

```bash
gatsby build
```

ou si cela a été configuré dans les scripts `package.json` :

```bash
yarn build
```

Une fois l'opération réussi, le "bundle" de votre site sera présent dans le dossier `public`.

Vous pouvez visualiser le résultat du build en lançant la commande :

```bash
gatsby serve
```

ou si cela a été configuré dans les scripts `package.json` :

```bash
yarn serve
```

qui lancera un serveur local présentant le contenu du dossier `public`, avec donc un résultat très similaire à ce que vous auriez en production.

## Déploiement

Dès que vous êtes content(e) du résultat, tout ce dont vous avez besoin pour voir votre site en ligne est de déployer le contenu du dossier `public`.

Dépendant de la solution de déploiement choisie, il y aurait plusieurs étapes ici. Je ferai prochainement des posts pour les plus connues. En attendant, je vous renvoie vers [la très bonne documentation](https://www.gatsbyjs.org/docs/deploying-and-hosting/) du sujet sur le site de Gatsby.


Un partenaire pour tous vos projets

Développeur Web

Mes technos du moment

Développement Mobile

Développement Front-end

Développement Back-end

Encadrement technique

“It always seems impossible until it is done“

Quelle que soit votre taille

Je partage avec vous