Ces dernières années, les sites statiques sont revenus à la mode. Légers, rapides, ils sont très adaptés à certains besoins, à un usage en mobilité. Malgré leur nom, ils peuvent aussi se faire dynamiques, côté client. Et servir de base de travail pour une application web progressive (PWA). On vous explique comment.
Dans un précédent article, nous avions décortiqué ce qui fait la spécificité des PWA. Mais cela peut sembler abstrait. Pour mieux comprendre nous allons aujourd'hui créer avec vous une telle application. Cela commence par la mise en ligne d'un site très simple, statique, qui ne nécessite donc aucune technologie spécifique côté serveur.
Le statique, c'est fantastique
Une tendance que l'on retrouve chez les défenseurs de la JAMStack (JavaScript, API, Markdown) et des générateurs de sites statiques, permettant d'en créer depuis de simples fichiers textes. Un concept à l'origine des GitHub Pages (via Jekyll) mais il existe des dizaines d'outils du même genre dont 11ty, Hugo, Hexo ou même le français Cecil.
Dans ce dossier nous opterons pour une méthode 100 % manuelle, ce qui vous aidera à mieux comprendre ce qui compose un site, comme il en existe des millions en ligne, que n'importe qui peut créer simplement. Puis comment en faire une PWA. Libre à vous de plonger ensuite dans les méandres de bibliothèques et frameworks plus complexes à la manière d'Angular, React, Vue.js ou même d'outils comme Gatsby.
Pour rendre le tout plus intéressant, notre site utilisera une dose de JavaScript pour charger du contenu, le traiter puis l'afficher. Seule contrainte : nous avons besoin d'un hébergement sécurisé (HTTPS/TLS), un prérequis des PWA. Heureusement, il existe des services qui proposent de telles solutions, avec un accès gratuit pour de petits projets.
Un « Hello, World ! » gratuit mais sécurisé
Il y a quelques années, il était impensable de pouvoir diffuser une page web avec accès sécurisé sans totalement dépendre d'une plateforme tierce et de ses contraintes. Let's Encrypt a tout changé en 2016, permettant à n'importe qui d'obtenir un certificat gratuit pour son nom de domaine, facile à créer et à mettre en place.
Malgré cela, il est rare de pouvoir trouver des hébergeurs avec une offre gratuite. Si Scaleway le fait, c'est uniquement à travers son offre de stockage objet (75 Go offerts) qui n'est pas vraiment prévue pour cela. Ce n'est pas le cas de Gandi, Infomaniak ou OVH pour ne citer que ces exemples. Surtout, ils en sont resté à des méthodes de déploiement « old school », nécessitant en général de passer par un serveur FTP pour envoyer vos fichiers.
Il existe pourtant bien mieux désormais. Avec ses Pages, GitHub avait montré la voie dès 2015 : il suffisait d'envoyer des fichiers texte au format Markdown dans un dépôt via Git, et votre site est publié. L'upload peut ainsi se faire via une multitude de clients compatibles, ou l'interface web du service. La conversion en site est assurée par Jekyll.
Certains hébergeurs se sont inspirés de ces méthodes et ont capitalisé dessus, ainsi que sur la JAMStack et la mode des sites statiques. C'est notamment le cas de l'américain Netlify. Il propose ainsi de nombreux services et plugins, du serverless, du déploiement simplifié, et surtout des comptes gratuits pour les projets personnels.
Création et mise en ligne de la première version du site
Le nombre de sites hébergés est illimité, mais vous ne devez pas dépasser 100 Go de bande passante par mois et 300 minutes de build time via Git, ce qui est largement suffisant. D'autres limites sont imposées, tous les détails se trouvent par ici. Aucun moyen de paiement n'est nécessaire pour créer un compte, un email suffit.
Ce sera donc suffisant pour notre test du jour, d'autant que les certificats Let's Encrypt sont gérés. On commence donc par créer un fichier index.html dans un dossier de notre machine nommé Site.
Une première page web qui contient le code suivant :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Bonjour, le monde !</title>
</head>
<body>
<p>Bonjour, le monde !</p>
</body>
</html>
C'est un simple « Hello, world ! ». On déclare une page HTML, en français, utilisant le codage de caractères UTF-8 (à utiliser par défaut), avec un titre et un paragraphe affichant notre message à quiconque se rendra sur le site internet. Vous pouvez lancer ce fichier avec votre navigateur pour observer le résultat.
Pour le mettre en ligne, rendez-vous dans l'onglet Sites de Netlify, puis glissez votre dossier Site dans la zone prévue à cet effet. Un espace d'hébergement sera créé, une URL (xxx.netlify.app) lui sera attribuée.
Votre site est désormais en ligne. Facile non ?
Notez que vous pouvez opter pour une mise en ligne via Git. Trois plateformes sont gérées pour cette méthode de déploiement continu : GitHub, GitLab et Bitbucket. Seuls les comptes Business peuvent le faire depuis un serveur Github/GitLab auto-hébergé. Autre bonne nouvelle, l'accès est sécurisé (HTTPS/TLS) par défaut.
Vous pouvez aussi opter pour un nom de domaine personnalisé. Netlify en vend mais vous pouvez aussi le faire chez votre registrar habituel. Il faudra simplement y configurer votre zone DNS pour qu'elle pointe vers les serveurs de Netlify. Ce dernier peut également gérer entièrement les DNS de votre domaine. C'est à vous de voir.
Différents guides (en anglais) sont disponibles par ici.
Ajoutons un peu de style à notre site
Prochaine étape, faire de cette page web un environnement un peu plus accueillant. Pour cela, nous lui fournissons une icône. Nous avons opté pour une fusée sur Flaticon. Attention, pensez à bien créditer le site et l'auteur si vous faites de même sur l'un de vos projets. C'est l'une des exigences de la licence gratuite du service.
Nous récupérons différentes tailles : des carrés de 16, 32, 64, 128 et 512 pixels. Avec Gimp, nous plaçons celle de 512 px centrée sur un fond noir de 1024x1024 px (Image > Taille du canevas puis Calque > Nouveau calque). Cela sera utile pour plus tard, pour en faire une icône maskable pour notre PWA.
Nous plaçons tous ces fichiers dans un répertoire nommé assets :
Nous modifions la page web en lui ajoutant des éléments décrivant notre projet : constituer une page référençant la liste des paquets du dépôt GitHub de winget via ses manifestes. On modifie donc le titre, on ajoute des descriptions, une barre de navigation, un logo, une dose de responsive, etc. Le résultat est le suivant :
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta property="og:locale" content="fr_FR">
<meta property="og:site_name" content="Packages winget">
<meta property="og:title" content="Packages winget">
<title>Packages winget</title>
<meta property="og:description" content="Retrouvez le contenu du dépôt des packages winget">
<meta name="description" content="Retrouvez le contenu du dépôt des packages winget">
<link rel="stylesheet" type="text/css" href="style.css">
<link rel="icon" type="image/png" href="assets/icon-16.png">
<link rel="apple-touch-icon" href="/assets/icon-maskable.png">
</head>
<body>
<nav>
<a href="/"><img id="logo" alt="Logo Paquets winget" src="assets/icon-32.png">Paquets winget</a>
</nav>
<main>
<span id="pkgsList">Le contenu du dépôt winget est en cours de chargement...</span>
</main>
</body>
</html>
On a tout d'abord ajouté de nombreuses balises META qui servent à déclarer des propriétés. La première par exemple pour que le site s'adapte à l'écran de l'appareil (smartphone, tablette, ordinateur). Certaines sont issues du standard OpenGraph (og). Nous déclarons certaines icônes pour qu'elles soient utilisées par le navigateur ou iOS, par exemple quand un utilisateur ajoute le site à son écran d'accueil (apple-touch-icon).
Vous noterez également que nous avons référencé une feuille de style CSS (stylesheet), sobrement nommée style.css. Nous créons ce fichier à la racine du projet. On lui ajoute le code suivant :
body {
background: #283134;
font-family: monospace;
font-size: 1em;
overflow-wrap: anywhere;
margin:0;
}
body, a {
color: #dae5e9;
}
a:hover {
color: #ea7e19;
}
nav {
width:100%;
position: fixed;
margin: 0;
font-size: 20px;
font-weight: 900;
background: #05384a;
padding: 10px;
}
main {
width: 95%;
margin: auto;
padding-top: 70px;
}
#logo {
vertical-align: middle;
margin-right: 15px;
}
Il s'agit ici essentiellement de gérer des marges et des alignements, tailles de police et autres couleurs, comme pour les liens (a) ou lorsqu'on les survole (hover). Certaines sont liées à un id particulier (#).
On enregistre l'ensemble des fichiers. On fait un glisser-déposer du dossier Sites dans la section Deploys du projet Netlify. Quelques secondes plus tard, votre site est mis à jour, accessible à tous.
Ajoutons un peu de dynamisme
Un site statique au sens de la JAMStack est un site qui ne nécessite pas de traitement par le serveur. Cela tombe bien, Netlify n'en propose pas. Mais on peut tout de même ajouter du JavaScript côté client afin de charger des données, gérer une connexion, des commentaires, etc. Dans ce guide, nous allons charger un fichier JSON.
C'est celui fourni par GitHub, contenant la liste des répertoires de manifestes du dépôt winget-pkgs :
On créé un fichier app.js à la racine du projet et on y place le code suivant :
const wingetUrl = "https://api.github.com/repos/microsoft/winget-pkgs/contents/manifests"
// On récupère la liste des paquets, on affiche une erreur en cas de problème
fetch(wingetUrl)
.then(response => response.json())
.then(jsonPkgs => showPkgs(jsonPkgs))
.catch((error) => console.log("Erreur pendant la récuparation du JSON des paquets winget : ", error))
// On affiche la liste des paquets dans la zone pkgsList
let showPkgs = (data) => {
let zone = document.getElementById("pkgsList")
let frag = document.createDocumentFragment();
// Pour chaque élément du fichier JSON on créé une puce avec un lien
// On stocke le tout dans un fragment dans un premier temps
data.forEach(app => {
let link = document.createElement("a")
link.href = app.html_url
link.target = "_blank"
link.rel = "noopener"
link.innerText = app.name
let puce = document.createElement("li")
puce.appendChild(link)
frag.appendChild(puce)
});
// On affiche le nombre d'éléments
zone.innerText = `Le dépôt de winget compte ${data.length} entrées : `
// On affiche la liste à puce en utilisant le fragment
let list = document.createElement("ol")
list.appendChild(frag)
zone.appendChild(list)
document.title = `Paquets winget (${data.length})`
}
Ici, l'objectif est très simple, récupérer le contenu de l'URL, puis envoyer les données à notre page sous la forme d'une liste à puces si tout s'est bien passé. Sinon, une erreur sera affichée au sein de la console du navigateur.
Les plus attentifs auront remarqué que nous utilisons ici une syntaxe JavaScript dite moderne (ECMAScript 2015), reposant sur les fonctions fléchées et les promesses permettant des actions asynchrones et enchainées (then, error). Une manière de faire simplifiant énormément les choses par rapport à l'époque des requêtes XHR.
Il faut désormais dire à notre site de lancer ce JavaScript. On le déclare donc à la fin de la section body :
<script src="./app.js"></script>
On peut une dernière fois glisser-déposer le dossier dans Netlify pour mettre à jour le site. On s'aperçoit qu'il est désormais pleinement fonctionnel et très rapide. Valide selon les règles du W3C.
Par défaut un texte est affiché, une fois les données récupérées et traitées, elles sont affichées. Ce site n'a que deux défauts : il n'est pas accessible hors-ligne et les informations sont récupérées depuis le dépôt GitHub winget-pkgs à chaque fois que l'on consulte la page. C'est là que la magie de la PWA entre en action.
Le site que vous devriez obtenir si tout s'est bien passé
Dans le prochain article de notre dossier, nous convertirons donc notre page web en application progressive, dotée d'un service worker, installable sur un ordinateur ou un appareil mobile, fonctionnant en toutes circonstances. Vous retrouverez le code source de ce projet et son évolution dans ce dépôt GitHub.
Commentaires (44)
#1
#2
Hello ! Franchement j’adore ce genre d’article qui donne des perspectives modernes sur les technologies qui ont le vent en poupe… Je développe pour les besoins de mon boulot régulièrement mais sans être réellement développeur et j’avoue que ça me permet de garder un oeil sur les trucs rapides/faciles à mettre en place pour certains besoins ! Merci !!!
#3
Dans notre équipe nous utilisons sphinx-doc pour générer toute la documentation de nos projets. Comme tous les README, CHANGELOG, How-To, etc, sont disponibles dans les repos en markdown, la CICD récupère tout ça et en fait un joli site user friendly de la même façon.
On génère aussi les schémas d’infra basés sur les inventaires de déploiement avec les noms des composants, les éléments déployés, les versions middlewares et progiciels, de quand date le déploiement déploiement continu, etc.
Ces outils sont très pratiques lorsque l’on est pas développeur Web et qu’on souhaite facilement publier un contenu lisible à destination d’équipes diverses.
#3.1
Tu as Pandoc qui est pas mal et assez puissant dans le genre, avec de nombreux formats acceptés en entrée/sortie. On devrait en reparler à l’occasion d’ailleurs
#3.2
Je l’avais vu à ce moment là mais il me paraissait trop compliqué par rapport à ce qu’on voulait faire. Sphinx + l’éternel thème “Readthedocs” suffisait largement.
Le plus compliqué dans l’histoire a surtout été de réussir à définir une normalisation sur l’écriture des différents
.mddes repos, pour permettre à l’outil de build de savoir retrouver ses petits en amont.Du côté des schémas d’infra, comme on déploie tout avec Ansible, c’est un template qui se base sur l’inventaire des environnements. Cela permet de générer tout ça en mode GitOps en centralisant la source d’information. Le principal objectif était notamment de supprimer ces immondes fichiers Excel de “gestion d’environnements” que personne ne connaît, que chacun maintient en un exemplaire dans son coin, et qui ne sont de toute façon jamais à jour.
#4
Cool, c’est compatible ie8 ?
#5
Merci, j’ai appris plein de choses en 20mn. Continuez ce genre d’articles, et vivement la suite.
#6
Il y a également document.createDocumentFragment() qui permet de gagner en performance lorsqu’on ajoute beaucoup d’éléments au DOM. Même si dans ce cas, le gain n’est pas vraiment flagrant s’il existe.
#6.1
Oui pas bête, bon dans le cas présent ça ne changerait effectivement pas grand chose mais ça ne coûte rien d’optimiser
#7
C’est l’article qui m’a décidé à m’abonner. Vivement la suite !
#8
Pas mal, le script ne serait pas mieux dans la section head appelé en onload sur body ?
C’est plus propre, à ça permet d’exécuter le js uniquement quand la page html est totalement chargée est rendue (bon là ça devrait aller :) )
#8.1
Disons que j’ai fait comme ça pour cette partie pour éviter d’avoir à l’expliquer
#8.2
Dans ce cas, il est sans doute plus simple de mettre le script dans l’en-tête mais en lui mettant l’attribut
deferet ainsi être sûr qu’il sera exécuté une fois l’ensemble de la page chargée. Et ça évite la complexité de de voir spécifier un onload à la main.C’est moderne et plutôt considéré comme une bonne pratique car on centralise les dépendance en en-tête tout en assurant l’ordre de chargement (l’ordre de déclaration) et que tout ce qui doit être chargé en fin de load le sera vraiment.
«explicit is better than implicit»
#9
Merci beaucoup, vivement la suite du dossier !
#10
Cela ne m’a pas l’air extraordinairement compliqué, vu que j’ai compris le tuto.
Je vais suivre cela de près, ça m’a l’ait intéressant.
#11
Super intéressant. Merci pour ce genre d’articles que je vais suivre de près
Et comme d’hab les commentaires vont apporter une mine d’infos précieuses…
Merci à NI d’exister et à toutes les personnes qui postent
#12
Super, c’est pile ce qu’il me faut pour un projet perso.
Il reste une grosse difficulté en ce qui me concerne car je cherche à me connecter à une base de données (via une API SQL), côté client et je n’ai rien trouvé qui permette d’éviter le php.
Quand je parle d’API SQL, il s’agit d’appeler les procédures et fonctions SQL qui vérifient les arguments et rendent impossible toute tentative d’injecter des commandes non désirées. Le code javascript client aurait donc des droits extrêmement cadrés sur la base (aucun droit d’utiliser la commande SELECT sur une quelconque partie de la base).
Pour le moment, je n’ai que la solution de faire des scripts php qui prennent les arguments dans des posts et renvoient des objets json en retour pour la communication entre la page et la base.
#12.1
Bah il suffit de faire des web services.
#12.2
Et tu n’as pas le choix de la manière dont les données sont stockées ou mises à disposition ? Sinon tu peux regarder du côté du serverless pour faire l’intermédiaire. Une autre possibilité que je n’ai pas développé ici c’est d’intégrer les données à la génération du site statique via un script avant le déploiement (mais ça dépend de la fréquence de mise à jour des données)
#12.3
Si tu veux de la BDD sans serveur, tu peux regarder les solutions de BDDaaS de la famille de firebase
Cela étant tu échappes à l’administration d’un serveur applicatif, mais c’est pas dit que ce soit beaucoup plus simple (en particulier tu n’échappes pas au point qui m’a toujours semblé le plus pénible dans ce type de briques: dire qui à le droit de faire quoi).
#13
Ya que moi qui trouve dommage de bouffer la batterie de nos smartphones alors que depuis des lustres on a inventé les langages compilés qui sont quand même bien moins énergivore ? Parce que finalement c’est pas vraiment statique comme site (même si les fichiers eux le sont)
#13.1
Comme dit plus haut tu peux décider de générer le fichier avant le déploiement depuis les données. Tu perdras juste sur la fraîcheur des données.
#13.2
Bon je retourne me coucher et je relis après
#14
Je prends beaucoup de plaisir à lire ces articles qui nous mettent le pied à l’étrier sur un sujet. Merci beaucoup NI !
#15
Noui. Je ne connais pas pour les autres, mais pour OVH (oui, ce n’est qu’un exemple :)), l’accès SSH fourni à partir de l’offre perso fait qu’on peut mettre à jour son site simplement à coup de
git push.P.S. Hors sujet: en éditant, j’ai l’impression que les balises Markdown de code inline des commentaires (
coucou) ne sont pas respectées. Elles forcent l’interprétation en un code multiline, et donc préfixé et suffixé d’un saut de ligne.#15.1
Infomaniak pareil, tu as accès en ssh au serveur qui héberge ton site web depuis une dizaine d’années.
Je faisais mes modifs/publications par sshfs pour le site que j’avais dessus.
#15.2
Oui enfin ça reste de la bidouille pour geek assez loin de ce que proposent les services à la Netlify & co.
#16
rololo ces suites d’articles faits et à venir, c’est chouette :)
je teste celui-là dès demain, ça m’intéresse fort fort.
#17
Bon, je ne résiste pas à poser un truc ici sans avoir lu l’article en détail …
Donc, probablement un peu hors sujet, toussa … Mais …
Statique ! Ça va quand même causer un peu de statique !
J’auto-héberge un max de trucs chez moi. Ça inclus des galeries de photos.
Y’a 15 ans et quelques, j’utilisais Gallery 2. Et j’ai beaucoup souffert quand la Debian est passée à Gallery 3. Un site en PHP + DB (MySQL ou autre) + copie des photos dans une arborescence spécifique. Tout a explosé ! Présentation générale moche, pertes des albums, pertes des commentaires …
Je suis reste longtemps sans rien, je suis passé par des JAlbum ou des trucs du genre. Jusqu’à ce que je découvre Lazygal : ligne de commande, la photo originale reste à sa place, des miniatures sont générées là où on le souhaite, un bête fichier texte de commentaire par album et par photos.
Du coup, j’ai un peu customisé le thème par défaut, scripté un peu la génération des albums, et roule ma poule, mes galeries sont revenues !
Pour ce qui est de la sécurisation, ça n’est pas le problème de Lazygal, c’est celui de nginx : un coup de Let’s Encrypt et on n’en parle plus.
Au passage, j’y pense seulement maintenant : si il y a des gens intéressés, je me suis codé un utilitaire pour commenter facilement les albums et les photos. On browse une arborescence, on affiche une photo et on la commente, et les fichiers sont générés en live pour Lazygal (un simple refresh les fera apparaître).
Je pose ça sur GitHub ou un truc du genre ?
#18
Une question : on a souvent dit que PWA était trop contraint sous iOS (souvent sans plus de précisions). Possible d’en savoir plus ? C’est toujours le cas avec iOS 14?
Merci!
#18.1
Oui même si ça s’améliore peu à peu. Mais par exemple tu ne verras pas automatiquement d’installation proposée (comme sur Android), tous les derniers éléments pris en compte (genre pas mal de choses du manifeste ou les icones qui passent par les META Apple), des trucs qui ne marchent pas genre le pull to refresh (sur NXi par exemple c’est ok sur Android, pas sur iOS), etc.
#19
Super intéressant et bien résumé, au top ! Je ne pensais même pas que le sujet m’intéresserait. Vivement la suite !
#20
C’est un peu de la triche, mais pour ceux qui voudraient faire mumuse avec du JAMstack, voici un outil en ligne qui configure automatiquement un site avec thème, framework et CMS de votre choix :
https://app.stackbit.com/create
Sympa pour comparer les frameworks ou les CMS.
#21
Il y a quelques années j’utilisais Dropbox pour y poser un bête html et quelques images, ça marchait bien.
Mais ils ont enlevé la possibilité
#22
Amazon S3 avec le Static Hosting d’activé est une autre alternative, pas gratuite, mais au prix de l’object storage, quasiment.
#22.1
Oui mais comme tu dis, pas gratuit et faut se fader toute l’interface AWS (autant utiliser Scaleway pur ça du coup, comme dit dans l’article). Mais bon, c’est pas franchement prévu pour ni le plus simple.
#22.2
Surtout que l’API object storage de Scaleway est compatible S3. Ça permet de passer de l’un à l’autre sans changer d’outil et d’éviter (si on considère S3 comme le standard de facto…) le vendor-lockin.
Pour l’interface, il existe quand même pas mal d’outil GUI qui permettent de ne pas se taper la console AWS.
J’avais écrit ça il y a quelques années pour héberger son blog sur S3, avec Pelican dont tu parlais dans un commentaire plus haut.
https://particule.io/blog/blog-ci-aws/
#23
Excellent tuto, c’est super d’avoir des maj de tout ce qui se fait quand on n’est pas calé dans un sujet, j’espère que ça va continuer !
#24
#25
Vraiment sympa cet article pour un novice du dev comme moi ;-)
#25.1
#JavaScriptNation !
#25.2
Ma petite remarque, tu en fais ce que bon te semble ;)
Diffuser une news le samedi avant celle de Flock me l’a fait louper. Je l’ai aperçue parce que je voulais voir des nouveaux commentaires sur une autre news de la semaine dernière.
Inconsciemment pour moi, les dessins de Flock séparaient les différentes semaines, j’espère qu’il n’y a pas trop de personnes qui réagissent comme moi pour la visibilité de celle-ci.
#26
Oui après il y a les flux, elle est en une, etc. Donc elle reste tout de même assez visible a posteriori. Mais je comprends la remarque
#27
Netlify, c’est vraiment top comme service !