Dans la suite de mon redesign de https://teletravail.guru, on va commencer à parler technique et pragmatisme, notamment vis-à-vis des architecture Single Page Application qui sont devenu le standard côté front.
Pour ceux qui n’aurait pas suivi le début de l’histoire, je vous remet les liens ici:
- Refonte de télétravail.guru (2/4) - Le Design
- Refonte de télétravail.guru (1/4) - Le Branding
- Refonte de télétravail.guru - Introduction
Mon idée, au moment de recommencer le frontend, était de partir sur une architecture que je manipule au quotidien : une Single Page Application. Cela vient surtout du fait que je maitrise très bien les technos associées (Vue et Vuetify) et que cela me permettait de démarrer avec pas mal de choses clés en main côté front.
Sauf, que cette architecture a pas mal d’inconvénients :
- diminution de la qualité de la SEO
- augmentation de la taille du site sur les machines clients
- augmentation de la complexité du code pour un site relativement simple techniquement
En général quand je fais des petits tests techniques, j’essaie toujours de rajouter une petite dose de challenge, que ce soit pour faire de la veille ou en mode hackathon pour tester une technologie. Ça fait un moment que j’entends beaucoup de bien de l’approche Server Side Rendering (SSR) qui consiste à effectuer un premier rendu de la page côté serveur. Si la question vous intéresse, je ne saurais que trop vous recommander la lecture de “Rendering on the web” qui revient un peu sur les différents modèles.
La plupart du temps, je considère que je n’en ai pas besoin, mais dans mon cas, la SEO va devenir importante. Or, c’est probablement le cas d’école pour introduire cette technologie. Je décide donc d’en profiter pour apprendre à faire du Nuxt.js.
Ce n’est pas l’objet de cet article (peut-être que j’y reviendrai plus tard), mais j’ai tordu l’usage du framework en tentant d’accéder à la base de données directement plutôt que de rajouter une couche, ce qui a l’air d’être le cas d’usage préconisé. Malheureusement, cela a rendu mon expérience très améliorable. Si jamais quelques personnes savent m’orienter vers des solutions pour ne pas créer un Backend for frontend, je suis preneur.
Il n’y a pas eu que des mauvais côtés. En voulant à tout pris créer une interface de recherche avec auto complétion, j’ai complètement plongé dans un terrier de lapin.
Je suis un grand fan des solutions de recherche à la Elasticsearch ou Algolia, mais il faut des infrastructures dédiées ou payer une licence, des pipelines d’ingestion de données, bref, un tas de choses que je n’avais ni le temps ni l’envie de faire.
J’avais depuis longtemps envie de réaliser un projet avec https://lunrjs.com/ qui est un port de solr côté JS, et qui peut tourner dans un navigateur. Autre avantage, il y a la possibilité d’extraire l’index vers un fichier JSON. J’ai donc réalisé un script d’indexation, et pour le reste, c’est la SPA qui utilise l’index Lunr pour l’autocomplétion.
Le résultat est un peu bancal, mais j’en suis super fier et surtout ça m’a permis d’éprouver le concept surtout d’un point de vue UX.
Tout ceci étant dit, mon prototype ressemble à quelque chose, mais le code commence déjà à prendre des allures d’usine à gaz sans résoudre la majorité des problématiques que j’ai soulevé plus tôt. Mais c’est une bonne façon d’introduire mes idées à @constant_des.
Je ne l’ai pas précisé jusque là, mais l’appli est développé en Python avec Django, et avec @constant_des, on n’en est pas à notre coup d’essai.
Récemment on a travaillé sur une autre application qui nous plait beaucoup (https://news.telary.io), qui a pris un peu la même direction en début de développement. Elle est maintenant développée en Vue + Vuetify, mais il nous a fallu pas mal d’itérations pour la stabiliser et réduire le nombre de bugs bloquants qui résistaient.
Avec cette expérience, le modèle SPA nous apparait plus comme une faiblesse qu’une force, surtout quand on pense aux problèmes que j’évoquais en début d’article (SEO, poids, complexité…) Les fonctionnalités offertes par Django, comme son back-office, finissent de faire pencher la balance en sa faveur.
@constant_des sait que j’aime les challenges, ce qu’il me propose : Reprendre le design de la version en Vuetify, supprimer les fonctionnalités trop compliquées (exit l’autocomplete) et faire un MVP de https://teletravail.guru le mieux possible avec Django.
Franchement ça n’a pas été une mince affaire, mais qu’est-ce que ça a été satisfaisant !
Je vous explique tout ça dans le prochain post: Refonte de télétravail.guru (4/4) - Les basiques
