## Utiliser les lifecycle de Strapi.js 

Dernièrement je vous disais j'ai migré le blog depuis un projet custom **Node.js** **Express** & **Handlebars** vers un **Next.js** + **Strapi TS-beta**, et je ne regrette pas du tout. Cela m'a permis d'accélérer le processus développement au maximum. Au lieu de partir de 0 et devoir créer chaque brique, je suis parti de Strapi qui faisait tout le travaille de persistence et les routes API pour moi. J'estime que j'ai gagné 40% à 50% du temps de développement en procédant de la sorte.

### Mise en place du caching avec Strapi

J'ai continué à améliorer cet outil avec une gestion de cache Redis qui permet de charger les données beaucoup plus rapidement du back au front. 

Pour vous rafraîchir la mémoire je vous mets le lien de ma vidéo sur le caching [ici](https://youtu.be/RLzHGZXl2C0).

J'ai mis en place des clés de caches en me basant sur les endpoints. En n'oubliant pas d'ajouter un pattern commun afin de pouvoir effectuer des actions groupés sur les clés de cache.

Lors de chaque Lecture, je vérifie d'abord l'existence des données dans le cache, et si Redis n'a pas de données, on va écrire le cache sans TTL. Etant donné que nous accédons à une seule et unique base dont le seul accès en écriture est Strapi, on respecte la règle qui nous permet de contrôler notre cycle de vie du cache. 

En lecture : 
![redis-cache-optimisation-strapi ><](https://bo.dev-freelance.fr/uploads/cache_drawio_37eca56d42.png)

On récupère les données depuis le cache ou on écrit le cache sans limite de durée.

En écriture : 
![redis-cache-flow-strapi ><](https://bo.dev-freelance.fr/uploads/cache_write_drawio_34863e3ee8.png)

On en profite pour flusher totalement le cache via un pattern afin de récupérer de nouveau les données à jour. Autrement dit, je suis en mesure de garder le cache jusqu'à ce qu'un article soit modifié, supprimé ou qu'un nouvel article soit créé.

Cette simple optimisation me permet de charger mon contenu très rapidement, et éviter de flooder mon serveur Strapi en cas de requête répétée. 

large_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

medium_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

small_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

thumbnail_luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

luan-gjokaj-y4_xZ3cs96w-unsplash.jpg

J'ai accéléré mon site avec du cache Redis, en me servant de strapi comme CMS Headless. Je vous explique tout ici.

Comment j'ai optimisé Strapi pour mon blog

## Programmer à deux : le Peer-Programming

Vous est -il déjà arrivé d'être complètement bloqué sur quelque chose, de passer des heures, voire des jours pour débloquer la situation alors que cela aurait très bien pu se faire en une vingtaine de minutes si vous aviez une information clé ?

Cela arrive à tout le monde, et nous réagissons très différemment face à cette situation. Certains se renferment sur eux même et cherchent la solution jusqu'à la trouver. D'autres n'hésitent pas à faire des signes lorsqu'ils sont bloqués. 

Cela demande parfois un peu de courage de dire que l'on n'arrive pas à comprendre ou à faire quelque chose, or, le Peer Coding ou encore le Peer Programming peut nous permettre d'avancer beaucoup plus vite.

### La résolution de problèmes, c'est notre quotidien

On le sait tous, le développement est un outil, il sert à matérialiser une idée, à répondre à un problème, à répondre à un besoin. Or, il est prouvé que la résolution de problème occupe au minimum 20% à 30% de notre temps de développement.

Avec le temps, les outils tels que les Tests Unitaires (TU) ou encore les langages fortement typés servent à réduire ce temps d'intervention. 

Il est tout de même bien mieux de faire du préventif, c'est à dire anticiper en amont les dysfonctionnements, que faire du curatif, c'est à dire faire le pompier et éteindre le feu, une fois que ça brûle déjà.

La résolution, où l'anticipation de problème devient de ce fait obligatoirement présent dans nos journées types de développeur. Parfois même, lorsque l'organisation est très mauvaise, elle occupe plus de la moitié du temps passé à travailler.

J'espère que vous réalisez que plus de 50% de votre temps, passé à fixer des bugs et gérer des problèmes non anticipés, c'est un signal d'alarme grave. Il faut revoir les méthodologies, les outils, l'organisation du projet pour faire plus de "prédictions" sur les scénarios... 

Bien que la résolution de problème est un passage obligatoire de notre journée voire nos semaines de développement. Je constate que le Peer Coding dans ces moments là est un outil adapté à ces situations.

### Qu'est-ce que le Peer Coding

Le Peer Coding, signifie travailler en équipe avec un collègue. Et contrairement à ce que l'on peut penser, cela ne retire pas une capacité de production du projet, car comme expliqué plus haut, la résolution de problème occupe déjà du temps quoique l'on fasse. Tout projet connait forcément des bugs, il s'agit alors de s'organiser pour les anticiper, ou les résoudre plus rapidement.

**Le Peer Programming, c'est un accélérateur de résolution de problèmes**

Cela permet plusieurs choses : 

- Réfléchir selon différentes perspectives (et très souvent cela permet une observation jusqu'alors mise de côté par le développeur)

- 2 cerveaux valent mieux qu'un, donc cela double presque le nombre de solutions ou propositions envisageables

- Cela permet de renforcer le travail d'équipe, c'est à dire, partager sur un point précis les conventions sur lesquels on s'est mis d'accord pour collaborer

- Monter en compétence, si un des développeur est plus expérimenté

Il est important de gagner en expérience collectivement. Cela signifie que chacun des membres de l'équipe, face à une même problématique connait désormais le chemin pour le résoudre. Aussi, cela permet de lisser le niveau moyen de l'équipe et de pouvoir plus facilement absorber le turnover.

**Retour à l'essentiel**

Lorsque l'on résout des problèmes, ce n'est pas par envie, par passion ou parce que c'est fun, mais surtout parce que c'est vital pour le projet. On le fait parce qu'on doit le faire. Cependant, il faut tout de même reconnaître que cela apporte, en définitive, moins de valeur pour le projet final, même s'il permet d'augmenter les connaissances techniques de l'équipe.

Il convient donc d'user de tous les moyens à notre portée pour mettre un terme au problème rencontré. Le Peer Coding qui est un outil permettant d'accélérer la résolution de problèmes, ne vas peut être pas réduire le nombre de problèmes rencontrés pendant le temps de travail, mais accélérer la résolution afin de pouvoir se remettre à faire du code productif, soit l'implémentation de nouvelles features.

### Quand le Peer Programming sert à boucler des tâches pointues

Lorsque l'on travaille sur des features techniques très complexes, il est préférable de réfléchir à plusieurs afin de ne rien laisser au hasard. La conception se fait alors en équipe, et il n'est pas rare que les premières implémentations aussi. 

Créer un nouveau module en équipe se fait couramment, d'autant plus que cela permet de partager le même niveau d'information avec tout le monde. 

Ce procédé accélère même souvent la sortie de ce nouveau module car il est stimulé par une poussée collective.

### Les outils de Peer Programming

**Pour faire du Peer Programming, faut aussi des outils.**

Contrairement aux outils de versionning tel que git etc qui permettent déjà de travailler en collaboration, le Peer Coding, c'est le fait de travailler simultanément sur une tâche avec un collègue. Et pour le faire efficacement, il faut impérativement des outils.

Lorsque l'on travaille en présentiel, cela peut très bien se faire dans un bureau avec un crayon et une feuille de papier. Mais depuis le COVID et la standardisation du télétravail, pour faire du Peer Coding, il faut des outils de communication performants.

Pour ma part, j'ai choisi d'utiliser [Discord](https://discord.com/) car il permet de faire tout ce dont on a besoin :

- La communication vocale

- La communication vidéo (Webcam ou Partage d'écran)

- Un chat écrit pour s'échanger du code source

J'ajoute à cela d'autres outils qui permettent de faire des dessins et schéma : 

- [Excalidraw](https://excalidraw.com/) pour dessiner

- [Draw.io](https://app.diagrams.net/) pour faire des schéma

**Parfois un schéma vaut 15 minutes d'explications**

Il est beaucoup plus simple de pouvoir visualiser un schéma notamment pour traiter les états d'un programme, les parcours possibles, les embranchements, que de lister uniquement les cas envisageables. 

En conclusion, le Peer Coding est un outil super pour faire progresser ses équipes. Il est bien loin le temps où on te disait "Surtout ne copiez pas sur votre voisin", lorsque l'on est une équpe de développeurs, rien n'est plus faux. 

Faire du Peer Programming vous aidera à résoudre plus rapidement les problèmes et partagera immédiatement l'information entre les développeurs. 

Cependant, pour pouvoir le faire efficacement, il faut des outils adaptés. J'ai essayé pendant longtemps avec Slack, mais comparé à Discord, les appels vidéos font parties de la formule payante. Pour Microsoft Teams, il fait quasiment tout, si ce n'est qu'il n'y a qu'un présentateur à la fois, alors que sur Discord, on partage tous nos écrans simultanément et cela permet un retour d'informations immédiat de la part de chacun.


large_628a3afa2808c86687728726_be727063db.jpeg

medium_628a3afa2808c86687728726_be727063db.jpeg

small_628a3afa2808c86687728726_be727063db.jpeg

thumbnail_628a3afa2808c86687728726_be727063db.jpeg

628a3afa2808c86687728726_be727063db.jpeg

Comment utiliser le Peer Programming comme un levier lors de la résolution de problèmes ? Si une équipe s'en sert efficacement, elle peut améliorer considérablement ses rendements.

Les bénéfices du peer-coding

## De Javascript à Typescript

On m'en avait parlé à l'époque et j'avais beau l'avoir testé, j'étais sceptique. Mais je le confirme, typescript change la vie !

Enfin... Pas Typescript seul, mais Typescript couplé à plusieurs autres choses comme un linter et un prettier etc... là, ça change tout, mais pourquoi ?

**Typescript seul, ne fait pas de miracles**

Pensez à mettre en place un linter (pour ma part, eslint fait largement le café ☕️) et au moins une extension Prettier configuré.

### Un code uniforme

Il est difficile de travailler en équipe sans mettre en place des règles. Dans le code, cela peut être frustrant de voir 3 implémentations différentes de la même logique, etc. 

Mais on n'y peut rien, tout le monde ne pense pas de la même façon. Pour régler en partie ce problème les linters sont des outils assez pratiques. Mais au delà de la mise en forme, l'indentation, l'utilisation des double ou simples quote, les accolades, etc, il est difficile de vraiment travailler de manière très homogène en équipe. 

Typescript, ne fera, certes, pas de miracles ici, mais il a le mérite de rendre les choses tellement lisible que de mettre en place des règles d'implémentations et autres conventions peut être plus simple qu'avec du pur JS.

La codebase servant d'exemple pour comment faire les choses, permettra à tout nouveau développeur de se greffer et suivre les pratiques mises en place par l'équipe. 

### La vérification en amont

En général la mise en place de tests unitaires demande non seulement, de maintenir ce code en fonction de l'évolution des implémentations, mais en plus de penser à le lancer (ou l'automatiser). Le plus souvent ça se fait avant les commit si vous utilisez un outil comme husky, mais si vous avez des collègues un peu flemmards, les TU peuvent servir aussi de décoration...

Littéralement, j'ai déjà travaillé avec des gens qui ne les lançaient jamais, et c'est très désagréable car il faut vraiment mettre tous les tests à jour par lot de plusieurs features, tout en sachant que cela ne durera pas.

Avec Typescript, on n'est pas libre de ne plus faire de test, mais au moins, on peut faire une stratégie de test basé sur des features un peu critiques. En revanche, la compilation fera déjà un travail de vérification pour voir si le code est cohérent avec les déclarations. Cette vérification automatique élimine, la majorité des bugs qui nous passent sous le nez en temps normal. En tout cas je constate que le travail que je livre est beaucoup plus robuste qu'avant. Il est même pas rare qu'un bug qui paraisse venir de notre partie du code viennent d'une API ou d'un scénario non planifié.

Il y a désormais, une complémentarité avec les TUs. Les TUs permettent de vérifier des scénarios utilisateurs (à condition que ceux-ci soient connus), en dehors dans l'utilisation au quotidien de vos librairies etc, il arrive parfois, lors des appels, de ne pas passer les bons paramètres.

Et c'est à ce moment que Typescript peut cadrer un peu l'utilisation de ces librairies car le typage va même jusqu'à prévoir le fait que les variables peuvent être absentes lors de l'exécution, et vous permettre d'anticiper (fallbacks, conditions, etc...).

**Typescript est complémentaire à vos tests unitaires, les utiliser ensemble c'est vous assurer un code solide et fiable**

### La productivité est-elle impactée ?

Au début, il faut l'avouer, ça demande un petit temps d'adaptation, pas forcément un an, mais bien quelques semaines, afin de pouvoir régler tous les problèmes communs, apprendre quelques subtilités comme le typage directement via les clés d'un objet (keyof typeof...), etc.

Le but est de vraiment jouer le jeu et non pas mettre des "any" partout pour aller plus vite. Honnêtement si vous passez à typescript pour utiliser "any", autant rester sur du JS 😕

Parfois, on est obligé de s'en servir, mais tant que l'on peut, il faut prendre le temps de déclarer des types. Le réel avantage de Typescript, c'est que lors des suggestions pour l'autocomplétion dans l'IDE, on voit directement ce qui est mandatory ou pas, le type de donnée attendu, et là, vous êtes bien content d'avoir pris du temps à la déclaration.

![typescript ><](https://bo.dev-freelance.fr/uploads/62782b89d4908592dedbefca_29b219d85d.gif)

### En conclusion

Typescript c'est vraiment une transformation du développement JS. Car il instaure une robustesse jusqu'alors difficile d'atteindre. De plus avec un peu de pratique, on va même plus vite qu'en pur JS grâce à l'autocomplétion détaillée et le typage attendu.

A titre d'exemple, j'ai refait from scratch, un composant React d'auto table qui m'avait mis 2 jours à l'époque en JS, après 6 mois de TS, sans m'inspirer du code existant (vraiment de 0), je l'ai refait en 2 heures.

Certes, les outils ont évolués aujourd'hui, avec les hooks, les providers/context, mais je le dis honnêtement, je pense passer pas moins d'une journée à le refaire si c'était du JS car je me serai forcément gouré quelque part dans l'implémentation, sans le savoir jusqu'à l'exécution.

large_6274ff94d4908592dedbefb6_5cd3218615.png

medium_6274ff94d4908592dedbefb6_5cd3218615.png

small_6274ff94d4908592dedbefb6_5cd3218615.png

thumbnail_6274ff94d4908592dedbefb6_5cd3218615.png

6274ff94d4908592dedbefb6_5cd3218615.png

Typescript permet de faire du code plus beau, plus lisible, plus robuste, et ce n'est pas forcément plus lent à produire !

Typescript change la vie

## Les bases de données évoluent chaque jour

**Historique**

Inventés dans les années 1960, les bases de données ne datent pas d'hier.

Initialement, l'informations était séparée en deux niveaux hiérarchique : les informations identiques sur plusieurs enregistrements et un niveau étendu pour une hiérarchie en arbre.

Au tout début, nous avons commencé le stockage d'informations sous forme de fichiers pour tendre vers un model relationnel. Cela s'explique par la densité des informations à relier entre elles, le modèle sql qui permettait l'indexation et l'optimisation de performance, mais surtout appuyé par le fait que la vitesse de transfert disque -> mémoire était plafonné à des débits assez lent.

**Quid d'une base documents aujourd'hui**

L'avènement des SSD, permettant des débit d'entrée/sortie énormes, la baisse des coûts de mémoire RAM et l'augmentation des débits de BUS mémoire permet aisément de repasser sur des modèles documents sans avoir de perte significative de performances jusqu'à un certain volume de donnée.

**Une technologie controversée**

Les frustrés des bases documents sont souvent des gens qui l'ont connu il y a très longtemps et sont facinés par le passage au SQL qui a été une évolution majeure à cette époque. Soit, il s'agit d'un public qui a fait le choix d'une base document pour de mauvaises raisons. Mais dans tous les cas, il n'y a aucune base mieux que l'autre dans l'absolu ! Tout dépend de ce que vous souhaitez faire.

### Pourquoi faire le choix d'une base documents ?

Depuis que l'information vaut son pesant d'or, il convient de stocker tout ce qui pourrait de près ou de loin se monnayer. C'est une triste réalité contre laquelle la CNIL mène un combat sans relache pour protéger les consommateurs. Cependant, imaginez un instant travailler avec une base sql, lorsque chaque information peu devenir importante dans le futur, il convient de stocker tout ce que l'on peut, à partir du moment ou nous avons connaissance de ce besoin. C'est le principe même du big data, c'est à dire tout stocker afin d'avoir une base de connaissance dans laquelle piocher à tout moment.

Par exemple, les réseaux sociaux n'existaient pas il y a 20 ans, aujourd'hui, c'est une information importante pour cibler un consommateur. Nous pouvons donc stocker l'email associé à chaque réseau social dans notre base de données. Mais à la vitesse à laquelle les réseaux se développent, il y aura toujours un nouveau réseau inconnu dans un an. Entre les facebook, puis instagram, puis snapchat, puis tiktok... on le voit bien, c'est sans fin !

Si l'on travaillait en base SQL, il faudra à chaque fois, faire une migration de structure et ajouter la colonne... En base document, niet ! On ajoute ce qu'on veut ajouter à la volée, et c'est parti.

MongoDB pour ne citer que lui, est un parfait exemple de base qui peut grossir à la fois par le nombre d'items sauvegardé mais aussi par item en lui même. Et cela nous donne énormément de souplesse pour faire évoluer les modèles de données.

**SQL a dû s'adapter**

Face aux transformations du besoin de stockage d'information, SQL a dû aussi s'adapter au format document en intégrant la gestion du JSON (format de donnée imbriqué). Ainsi, il est possible d'ajouter la souplesse du modèle document dans une base SQL. Mais vous imaginez bien que cela n'est pas sans contrepartie. En atteignant une taille critique en volume Octet, vous atteindrez un niveau de ralentissement dû à la quantité des informations à parser (car le champs JSON est aussi indexé pour la recherche).

**Mongo aussi évolue**

Le bémol pour les bases fichiers c'est qu'au départ le stockage d'items ne permettait pas de modèle relationnel. Le lien entre deux éléments se faisait :

- Soit, en imbriquant directement l'intégralité d'un élément dans un autre (limité à 100 niveau d'imbrications). Ce qui gonfle la taille de l'item, qui reste limité à 16mo (BSON) par défaut sur une base MongoDB, donc limite les possibilités.

- Soit en stockant dans un tableau l'ID unique du document à imbriquer, mais impose l'exécution successive de requêtes afin de récupérer chaque élément.

Aujourd'hui, après plusieurs optimisations, Mongo a accéléré les recherches avec aggregation. Cela permet de processer les résultats côté base de données, afin d'affiner la recherche, pour retirer la charge du serveur de traitement (API, Framework, etc...).

A quel moment passer de l'un à l'autre ?
Une base document, que ce soit Mongo, Neo ou encore DynamoDB, est utile lorsque l'on souhaite stocker de la donnée brute à exploiter si besoin. Si on me demandait de faire un wikipédia, je ferai un mix de base document et moteur de recherche (Elaticsearch) car, sur chaque item, on pourra ajouter des clés spécifiques à l'item :

Par exemple :

- pour les animaux et les plantes : l'appellation latine
- pour les plats : un tableau d'ingrédients
- pour la mode (vêtement, chaussures, parfum) : un tableau des dates d'édition, ré-édition


Chaque élément ayant ses spécificités différentes d'un autre élément qui n'est pas de la même "famille".

Je me vois mal faire cela en SQL car on sera rapidement limité par la structure qui se veut commune entre les éléments.

Selon moi, SQL est un choix idéal pour une base qui peut être utilisé pour du calcul ou un maillage relationnel complexe entre les éléments, par exemple :

- des lignes comptables
- un historique d'achat
- un réseau social


Lorsque nous voulons récupérer les amis des amis de mes contacts pour les mettres en suggestion (même si cela est précalculé via une tâche autonome...) SQL est idéal pour le faire. Idem pour faire un calcul côté base de données, des dépenses entre deux périodes sur une table de transaction.

### Un système de stockage de données idéal

Comme on peut le voir, les deux modèles ont leur forces et leur faiblesses. Je pense qu'idéalement, il faudrait mixer les deux afin de tirer le meilleur de chacun. Je reste persuadé qu'il y a toujours un cas ou l'un est meilleur que l'autre.

**Une base document** : pour stocker le plus d'information possible

**Une base SQL** : pour du calcul ou des relations complexes

Aujourd'hui, nous sommes malheureusement confrontés à d'autres problématiques au niveau de l'infrastructure. Faire le choix de plusieurs technologies, c'est aussi, maintenir les deux, les faire évoluer pour éviter les exploits et toujours maintenir une cohérences entre les échanges inter-bases. Cela est très complexe et demande un minimum de personnes pour y parvenir. Je pense que, dès qu'une équipe est suffisamment grosse pour gérer les deux, il ne faut pas hésiter à le faire. En revanche, à taille humaine, le travail est colossal et promet une lourde charge quotidienne rien qu'au maintient de l'infrastructure.


medium_606ebcca7cbf7acafb056205_7de4588bcd.png

small_606ebcca7cbf7acafb056205_7de4588bcd.png

thumbnail_606ebcca7cbf7acafb056205_7de4588bcd.png

606ebcca7cbf7acafb056205_7de4588bcd.png

Lorsque l'on commence un projet, il convient de faire les bons choix quant au stockage des données. Pour cela, nous avons des outils adaptés à chaque besoin. Utiliseriez vous une base relationnelle ou une base documents ? Réponse dans cet article...

Découvrez tous nos articles de la catégorie Dev - page 7 sur 7

Comment j'ai optimisé Strapi pour mon blog

Les bénéfices du peer-coding

Typescript change la vie

SQL vs NoSQL