Le besoin

Il m’arrive souvent de me lancer dans des prototypes, ne serait ce que pour explorer une idée ou découvrir une technologie. Très souvent cette idée est liée à une fonctionnalité dans le back qui ne requiert pas forcément de front pour fonctionner. Mais, soyons honnête, un prototype est toujours plus convaincant lorsqu’on le voit en action.

Et voici donc mon problème, si je souhaitais faire cette vitrine pour mon prototype je me retrouvais à développer la partie front en prenant à peu près n’importe lequel des grands acteurs (React, Angular, Vue ou plus récemment Svelte).

‍

Mais personnellement, je trouve cette étape lourde car elle n’amène pas de plus-value au prototype final et complexifie le déploiement de la solution (Un prototype est toujours meilleur s’il peut être partagé)

Une autre approche pourrait être d’avoir recours à des moteurs de templating (Jinja2 par exemple). Mais je trouve que le code généré n’est vraiment pas facilement lisible / évolutif.

Idéalement, si je peux faire une page html avec un semblant de navigation et quelques actions pour faire les preuves du prototype c’est amplement suffisant pour être convaincant.

‍

L’approche

Il est peut être temps pour moi de dire que je suis développeur python / javascript. Cependant, je pense que les principes peuvent être repris indépendamment du langage back utilisé à partir du moment où le serveur peut faire office de serveur statique.

Nous allons construire une application parfaitement inutile constituée d’une api pour accéder aux données et un front qui sera servi par une simple page html.

‍

Le back

J’adore utiliser depuis des années Fastapi pour sa simplicité et donc je pars là-dessus pour l’api et le serveur de fichier statique.

https://fastapi.tiangolo.com/

‍

1. Avoir un serveur en état de marche

Commençons déjà par fabriquer l’application de base qui sera servi sur le sous chemin /api.

main.py

‍

Normalement, si vous lancez ne serait-ce que ce fichier avec Uvicorn par exemple.

‍

On devrait alors avoir notre swagger qui est accessible et qui nous montre que tout va bien dans le meilleur des mondes.

‍

2. Construire une route sur l’api

Pour cela on va venir lire un fichier books.json trouvé en ligne pour la démo qui ressemble à ça :

‍

On va avoir besoin de rajouter quelques lignes pour décrire le format de ce que l’on lit.

‍

Une petite vérification sur le swagger que cela fonctionne et on va pouvoir s’intéresser au front :

‍

Le serveur statique

Fastapi propose une solution pour héberger les fichiers statiques que nous allons utiliser :

‍

En parallèle de ça, nous allons créer le répertoire static avec dedans un fichier index.html

	

	
	
		
		

		
		

			Books!
		
		
		
	

-->

static/index.html

‍

Vous devriez normalement avoir maintenant à la racine de votre serveur la page index.html qui est servie avec Books dessus.

‍

Tous les éléments sont là, on peut maintenant passer à la partie qui concerne vraiment ce blog qui est l’utilisation de htmx et d’alpine.js pour rendre nos pages statiques interactives.

HTMX & Alpine.js

htmx est une librairie javascript qui permet d’utiliser des outils comme AJAX ou les animations CSS directement depuis des attributs html.

https://htmx.org/docs/

‍

Alpine.js est quant a lui un framework javascript extrêmement léger.

https://alpinejs.dev/

‍

Ces deux technologies sont très complémentaires et faciles à mettre en oeuvre surtout grâce à CDN.

  	
    
    
    

	


-->

index.html

‍

Au passage, vous pouvez ajouter les librairies css que vous souhaitez pour faire un front visuellement plaisant. Personnellement, j’ai l’habitude d’utiliser tailwind / daisyui.

  	
    
    
    
		
    
    
    

	



-->

‍

Bref, vous pouvez garnir votre head avec les outils que vous souhaitez utiliser.

Navigation

Pour faire la navigation rapidement nous allons utiliser htmx. Htmx nous permet de faire une requête GET et d’injecter le résultat dans la page actuelle. Cela nous permet d’avoir un système de router rapide.

Nous allons faire deux pages distinctes: une pour les livres Books et une autre About.

L’arborescence de notre site ressemble à ça :

‍

Et voici le code associé pour les nouvelles pages :

This is books/index.html


This is about/index.html
-->

‍

Maintenant voici ce que htmx nous permet de faire pour faire une navigation rapide dans le index.html à la racine :

	
    

      

        

           Delia Tech Books
        
				
        

          Books
          About
        
      
    

    

	
	

-->

‍

On peut faire un Get qui cible l’url /books de notre site grâce à hx-get et on l’injecte dans la cible définie par hx-target. Et enfin on peut définir comment on injecte avec hx-swap en précisant innerHTML. Cela va conserver la balise <main>. Et on cible /about pour la deuxième url.

‍

Pour être honnête, c’est tout ce que j’ai utilisé dans cette démo en ce qui concerne htmx, mais cela va beaucoup plus loin. Surtout dès qu’on commence les formulaires.

Interactivité

Et maintenant c’est la partie Alpine.js.

Principalement, on va définir les appels à notre api et un store pour utiliser les informations récoltées dans l’interface.

-->

‍

L’objet api contient simplement la définition des fetch pour collecter les données.

Le store Alpine va simplement s’initialiser via la méthode init et définir sa variable books. On peut ensuite utiliser ce store dans n’importe quelle page que nous avons définie. Par exemple, dans books/index.html:

	

-->

‍

Avec une simple card de daisyui pour afficher les infos :

books/index.html

‍

Ce qui devrait donner :

‍

On peut mettre à jour la page about à jour indépendamment :

about/index.html

‍

Ce qui donne

‍

Conclusion

On a maintenant un système qui est entièrement encapsulé dans notre serveur back. Cela nous permet de travailler directement dans le back et de se concentrer uniquement sur cette partie. Pour les devops dans la salle, on peut également le déployer facilement sur n’importe quel serveur et surtout on a aucun temps de build lié à javascript.

Même s’il est rudimentaire, on a un système de navigation, on peut faire de l’interactivité et on peut avoir un visuel convaincant en très peu de temps et surtout en utilisant quelque chose très proche de html / javascript natif.

Pourquoi est-ce important ?

Parce que le système reste relativement agnostique. On peut faire un prototype entier sans faire de choix technologique pour le front et laisser cette question pour plus tard.

Il y a surement d’autres / meilleures approches à avoir avec htmx et alpine.js, mais personnellement c’était ma première utilisation avec mais sûrement pas la dernière.

Voici le lien vers le code source sur github :

https://github.com/sylvaintouret/fastapi-htmx-alpine-tutorial