<figure></figure><figure></figure><figure></figure>

Comme vous le savez sûrement, au fil du temps le blog korben.info est devenu un site conséquent et par son nombre de page que par sa sollicitation.Régulièrement,  nous cherchons et mettons en place divers outils ou méthodes dans le  but d’optimiser son exploitation, c’est à dire le rendre plus  performant, plus rapide, mais aussi plus stable.Inévitablement il arrive que ce soit l’infrastructure elle-même qui nécessite une optimisation.

Ces derniers temps, nous avons étudié la possibilité d’une  transition vers une nouvelle forme d’infrastructure. Cette forme,  récemment popularisé sous le nom un peu buzzword de  « serverless », propose de distinguer les différentes parties d’une  structure web classique pour les placer dans des environnements qui leur  sont adaptés et ainsi optimiser à chaque étape.

De manière générale, nous avons définis les objectifs avec les points suivants.

Optimiser le rendu web pour gagner en performances et en dynamisme ;

Bénéficier d’un dimensionnement dynamique pour absorber le trafic tout en économisant des ressources ;

Réduire la surface d’attaque pour maximiser sa sécurité ;

Favoriser la portabilité pour simplifier le changement de solution ou de prestataire.

Dans ce dossier, nous vous proposons d’explorer et de mettre en place un schéma d’infrastructure serverless, étape par étape.

Notre dossier sur l’infrastructure serverless

Infrastructure Serverless – Partie 1 : Générateur de site

Infrastructure Serverless – Partie 2 : Hébergement statique

Infrastructure Serverless – Partie 3 : Gestion de contenu (cet article)

Infrastructure Serverless – Partie 4 : Fonctions cloud (à venir)

Infrastructure Serverless – Partie 5 : Micro-services et conclusion (à venir)

Gestion de contenu

L’origine

Tout l’intérêt d’un site est son contenu (en principe).Le site statique que nous avons obtenu à la dernière étape offre un contenant parfait, mais jusque-là quasi vierge.

On pourrait envisager d’ajouter à la main notre contenu dans le  template, mais ce serait franchement contre productif et plus vraiment  un template. Donc on ne l’envisage pas et on se tourne plutôt vers un  CMS.

Le principe

L’idée de base derrière un CMS tel que WordPress est de manipuler le  texte, les images et les autres assets, simplement et efficacement pour à  peu près n’importe quel utilisateur. Il permet généralement d’éditer le  contenu du site via une interface web dédiée et facile d’utilisation.

Pour un blog, la mise en place d’un système pour la gestion de contenu est nécessaire.Mais  plus précisément ici, ce que l’on cherche, c’est un CMS exclusivement  utilisé pour le gestion éditoriale du contenu. Aucun traitement frontend  pour un accès public au contenu n’est attendu.

Ce gestionnaire est donc « sans tête » (headless), dans la  mesure où il ne propose que les interfaces utilisateur et programmatique  pour les données, mais sans fournir le rendu public, lui géré par notre  compilation (Partie 1 : Générateur de site).

La solution

Directement caractérisée par le CMS sélectionné, la nature du  stockage des données est très variable, de la classique base de données  aux fichiers Markdown dans un dépôt git, en passant par des solutions  SaaS.

Une liste déjà bien fournie est disponible sur le site de Gatsby, mais il en existe une floppée, WordPress lui-même compris (on y reviendra en Partie 5 : Micro-services et conclusion).

Leur principale caractéristique par rapport aux CMS tout-en-un est  donc de ne pas gérer eux même la compilation des pages publiques. Pour  contrebalancer et s’intégrer dans notre flux de travail, ils auront en  revanche les moyens de déclencher une compilation et un déploiement à  chaque édition du contenu.

L’usage simple

A partir de notre base de la dernière fois, nous allons configurer sur Gatsby une source de contenu.

Pour rester simple, le système de fichier du dépôt sera utilisé avec des fichiers Markdown, mais à nouveau d’autres CMS compatibles sont possibles dont un grand nombre avec un vraie interface de gestion et de rédaction.

Dans notre configuration Gatsby, le fichier gatsby-config.js, on y ajoute la configuration de la source.

plugins: [    {      resolve: "gatsby-source-filesystem", // <- pour traiter la source de données      options: {        name: "posts",        path: "./src/posts/",              // <- l'emplacement de notre source de données      },    },    "gatsby-transformer-remark",           // <- pour traiter le markdown  ],

Un autre fichier JavaScript va servir de base pour le rendu, en gros  comment intégrer les texte Markdown dans une structure HTML. C’est  littéralement un template, ici basé sur la version suggérée en documentation.

a. D’abord on importe nos dépendances locales.

import React from "react"import { graphql } from "gatsby"

b. Ensuite on défini notre fonction template.

export default function Template({  data, // <- injecté par le requête pageQuery plus bas}) {  const { markdownRemark } = data // <- contient les métadonnées et le corps  const { frontmatter, html } = markdownRemark  return (