## Pourquoi Tailwindcss ? 🤔

Il existe déjà des librairies **CSS** tels que **Bootstrap**, **Bulma**, **Ui-kit** etc... Ces librairies ont apporté leur lots de nouveautés notamment le passage à la grille de N colonne pour organiser ses vues de manière horizontale. 

Mais ces librairies ont déjà une d'identité visuelle forte et lorsque l'on veut créer quelque chose de personnalisé, il faut souvent importer ces librairies (qui sont déjà lourdes), puis les personnaliser (ajouter un custom CSS qui alourdi d'autant plus notre projet).

**Tailwindcss** propose une approche de compilation à la volée qui va garder uniquement l'essentiel de ce que nous utilisons dans le projet. 
Cette approche permet d'optimiser la taille de nos livrables, de plus **Tailwind** est une alternative qui laisse place à notre créativité en matière de design car cette librairie ne fourni que les outils. C'est à vous de créer vos composants etc...

### A quoi sert Classnames ? 🧐

[Classnames](https://www.npmjs.com/package/classnames) est un paquet qui permet les classes d'un composant de manière très simple. Cette librairie permet d'ajouter les classes conditionnellement et de concaténer, etc....

```tsx
import cn from 'classnames'

type ComponentProps = {
  bold: boolean
}

const Component = ({  bold }: ComponentProps) => {
  return (
    <div className={cn('rounded-lg', 'bg-white', { 'font-bold': bold, 'font-semibold': !bold })}>
      // contenu...
    </div>
  )
}
```

Dans cet exemple, la classe au moment du rendu sera 'rounded-lg bg-white font-semibold' ou 'rounded-lg bg-white font-bold' en fonction de la valeur de la propriété bold. Et on peut continuer à mixer les propriétés en ce sens. 

D'ailleurs, il n'est pas obligatoire de passer une seule classe par argument, on aurait très bien pu mettre ensemble les deux premiers arguments : 'rounded-lg bg-white'.

### Faire aussi bien que Tailwindcss et Classnames réunis 🤝

Le paquet [twind](https://www.npmjs.com/package/twind) prend le meilleur des deux mondes. <u>Et c'est littéralement la révolution !</u>

Commencez par installer le paquet : 

```
yarn add twid
```

Puis vous pouvez vous en servir comme ceci : 

```tsx

const Title = () => {
  return (
    <h1 class="${tw`font-bold text(center 5xl white sm:gray-800 md:pink-700)`}">
      This is Twind!
    </h1>
  ) 
}
```

Remarquez que dans cet exemple qui vient de la documentation de **twind**, on utilise <u>text(...)</u> comme une fonction. Tout ce qui se trouve entre les parenthèses seront concaténés par **text-**. **Le code est donc encore plus court à écrire pour un résultat similaire.**

Pratique non ?

En n'oubliant pas d'installer l'extension vscode pour avoir l'intellisense : 

![twind-extension-vscode ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_07_20_09_29_35_e2b454b62c.png)

Vous pourrez bénéficier ensuite de l'auto-complétion avec le raccourci "CTRL + Space" (sous linux)

![twind-intellisense-usage ><](https://bo.dev-freelance.fr/uploads/intellisense_40c38468f1.gif)

En tout cas, cette librairie m'a convaincu et j'ai fait le choix de m'en servir pour mes projets futurs. 😃


large_sigmund-F_m44ut3XTw-unsplash.jpg

medium_sigmund-F_m44ut3XTw-unsplash.jpg

small_sigmund-F_m44ut3XTw-unsplash.jpg

thumbnail_sigmund-F_m44ut3XTw-unsplash.jpg

sigmund-F_m44ut3XTw-unsplash.jpg

Tailwindcss c'est un peu la librairie CSS parfaite qui permet d'utiliser des classes au lieu de devoir déclarer du CSS. Cette librairie fait gagner un temps fou et plus le temps passe à l'utiliser, plus votre vitesse de programmation. Aujourd'hui nous allons voir une librairie qui cumule Tailwindcss et Classnames.

Tailwindcss et Classnames en un seul package

## Créer son projet de A à Z quand on n'est pas développeur ⌨️

Aujourd'hui plusieurs solutions s'offrent à vous pour créer votre Proof of Concept (POC). 

Nous allons comparer les différentes solutions qui s'offrent à vous, en passant par les outils no-code, aux prestataires ou au fait de créer votre produit vous-même.

Puis nous détaillerons les étapes clés pour la réalisation de votre application.

### Les solutions no code 📱

Le marché a compris que beaucoup de gens souhaitaient se lancer mais peu ont les compétences pour pouvoir le faire réellement. 

Pour autant est-ce un problème ?

Plus maintenant ! **Les développeurs ont créé des outils no-code qui permettent à des non devs de pouvoir donner vie à leur projets**. 

Qu'est-ce qu'un outil no-code ?

C'est une solution qui va vous permettre de créer vos applications grâces à des vues simples et du glisser-déposer... 

Est-ce la fin des développeurs ? 

Les gens pensent : "Oh mon Dieu 😱, demain le métier de développeur sera obsolète parce qu'il y a des outils no-code pour remplacer les développeurs !". 

Et ben non, les développeurs n'auront qu'à se mettre à développer eux aussi des outils no-code, donc cela n'est en rien un frein à notre métier. 

Tout comme l'IA aujourd'hui, puisque l'on commence à créer des applications à partir d'intelligence artificielle. Il suffit de passer sur du développement d'IA une fois que le marché sera saturé par ce genre de solutions. Les développeurs, s'adaptent, et derrière chacun de ces outils, il y a toujours des développeurs, rassurez-vous, on n'est loin d'être sur la sellette. 😂

Lorsque je tape solution no-code sur google, j'ai cette liste de produits qui s'affichent : 

- [Out Systems](https://www.outsystems.com/)
- [Flutter Flow](https://flutterflow.io/)
- [No Code](https://www.nocode.tech/category/app-builders)
- [Kiss Flow](https://kissflow.com/)

Et j'en passe...

#### Quels sont les limites (actuelles) des solutions no-code ? 😢

Il y a des raisons pour lesquelles je ne peux pas recommander de passer directement sur des solutions no-code. Bien sûr ces solutions s'améliorent chaque jour, les développeurs travaillent d'arrache-pied pour régler ces problèmes. Mais nous allons les lister tout de même : 

##### Le prix 💸

le prix est affolant, la plupart des solutions sont très chères (jusqu'à 1500€ /m) et en plus ce prix évolue en fonction du nombre d'utilisateurs (cela veut dire que ces solutions vous prendront une partie de votre marge tout au long de votre croissance). Par opposition, certains prototypes vous coûteront quelques milliers d'euros, soit quelques mois d'abonnement, ensuite toute votre marge sera conservée.

##### La propriété intellectuelle 📃

Vous ne possédez pas le code source, mais uniquement votre acquisition client. C'est bien d'avoir une grosse base client, et cela a beaucoup de valeur, en revanche lors d'une revente, cette acquisition vous rapporte beaucoup moins que si vous avez des brevets ou si vous possédez votre code source (dans ma carrières j'ai déjà travaillé en tant que "cleaner" de code source en vue d'une acquisition, il y a un audit pour estimer la valeur de la boite sur de grosses transactions).

##### La perte de contrôle 🧗

Cette couche qui vous permet de créer vos applications crée aussi une couche d'opacité sur ce qu'il se passe réellement côté code. Cela rend les problèmes plus difficiles à identifier et vous êtes tout autant exposé aux bugs (comme sur un projet traditionnel que vous développez). C'est à dire que vous avez le même niveau de risque, pour moins de maîtrise. 

##### Les supports semblent limités 🖥

La plupart des solutions ont l'air de mettre le paquet sur les apps mobiles, ce n'est pas totalement une mauvaise chose. La majorité des utilisateurs sont sur mobile, mais pourquoi ne pas être directement multi device ? C'est à dire tablette, PC et mobile ! Tout dépend ensuite du marché cible. Si vous faites un outil destiné au B2B (donc les professionnels) il y a de fortes chances pour que votre outil soit surtout utilisé sur un PC (comme dans le cadre du travail). Donc limiter à l'utilisation mobile reviendrait à se fermer des portes quand on sait que les professionnels travaillent essentiellement sur des ordinateurs et pas des téléphones. 

#### Les bons côtés du no-code 😃

Je ne veux pas dépeindre un portrait sombre de cette solution qui comporte toutefois de bons côtés : 

- Vous pouvez mettre en place quelque chose et toucher un marché pour tester une idée
- Vous décider du besoin et du workflow
- Vous obtenez des compétences de création sans avoir eu à apprendre un métier complexe 

Au final, cette solution n'est pas si mal si vous arrivez à atteindre votre objectif, c'est à dire lancer votre produit et à condition que cela ne vous coûte pas un rein. 

### Développer ou faire développer sa solution 👨‍🔬

Vous décidez de faire vous-même ou faire faire votre développement par un freelance ou une agence. Il y a tout de même des choses à savoir et quelques raccourcis à prendre pour vous faire gagner du temps et de l'argent.

Les langages les plus utilisés en France sont **Node** et **PHP**. 

La plupart des vues utilisent : **HTML**, **CSS**, **Javascript** et **Node.js** utilise déjà Javascript, ce qui signifie que **Node.js** est le langage où vous avez le plus de chances de tomber sur un **profil fullstack** (qui va s'occuper de coder les fonctionnalités serveurs "backend" et les vues "frontend"). 

Comment choisir au mieux ? 

![choix-stack-technique-node-php ><](https://bo.dev-freelance.fr/uploads/stack_drawio_33c66b415d.png)

Lorsque votre projet comporte une partie temps réel, que ce soit notification temps réel sur écran, chat, vidéo, audio, etc... Il est recommandé d'utilisé un langage comme Javascript qui est orienté événement. **PHP** est un langage synchrone qui fait très bien l'affaire lorsqu'il faut coder une API qui fait des enregistrements dans une base de données. 

Une chose est sûr moins vous avez besoin de développeurs pour lancer votre projet, moins vous aurez à mettre la main à la poche. Maintenant, tout dépend du compromis que vous êtes prêt à faire sur les délais de livraison. 

**Si vous êtes vous-même développeur, faîtes simple. Restez dans votre domaine de compétence tant qu'il répond à votre besoin. Si vous faîtes du PHP, du Ruby, du Python, etc... Passez directement à la suite**.  👍

Si vous devez choisir un développeur **PHP**, demandez à utiliser le framework **Laravel** ou **Symfony** (les plus répandus sur le marché), pour ne pas être pieds et poings liés à un seul développeur.
Si vous choisissez un développeur **Node.js**, demandez à utiliser **Next.js** pour avoir le frontend **React** de la même façon. Sinon travaillez avec quelqu'un qui maitrise des technologies comme **Express.js** pour faire l'API et le front en **React** ou **Vue.js**.

Pour le frontend, je ne partirai pas sur autre chose que **React** ou **Vue.js** car **Angular** est une solution unifiée et est un peu plus rare sur le marché. Encore une fois, le but de cette démarche est de ne pas vous bloquer pour que votre projet puisse être maintenu par un plus grand nombre de développeurs.

#### Formuler son besoin ✏️

Pour obtenir une estimation claire et précise vous avez besoin d'élaborer un cahier des charges ou du moins un document de spécification des besoins.

Qu'est-ce que vous souhaitez réaliser ? A quoi sert votre application ? 

Il est beaucoup plus simple pour un développeur d'avoir une idée de comment faire ce que vous voulez si vous êtes précis dans votre demande et s'il comprend votre objectif. Ainsi, vous ne devez pas répondre à la question **"quoi ?"** (un produit qui fait telle chose ou telle autre chose...) mais répondre à la question "**comment ?**" (nous souhaitons répondre à tel besoin en faisant...). C'est déjà beaucoup plus précis comme demande.

Expliquez en 1 paragraphe le problème que vous souhaitez résoudre. En étant totalement réaliste, si cela dépasse 10 lignes, votre projet va vous coûter un bras. 😂

##### Préparer la base de données 📝 

Si votre application doit stocker des éléments dans une base, quels sont les données que vous souhaitez stocker et quels sont les champs associés ? 

Par exemple : 

Nous souhaitons stocker des utilisateurs avec les champs suivants : 
- Nom
- Prénom
- Email
- Profession

Nous souhaitons stocker les postes occupés par ces utilisateurs : 
- Utilisateur concerné
- Nom entreprise
- Intitulé profession
- Date début
- Date fin

etc... 

Pour aller plus vite lors de l'élaboration d'un **POC**, je vous recommande l'utilisation de **MongoDB**. Il s'agit d'une base de données plus souple qui vous permettra de faire évoluer votre besoin pendant les développements.

##### Envoi de documents 📄

Dans votre application, est-ce que vous devez envoyer des documents en tant qu'utilisateur ? Mettre en ligne des documents PDF ? Des vidéos ? Des photos ? 

En fonction des réponses, cela signifie qu'il va falloir mettre en place des espaces de stockage, cela peut aussi influencer le prix de votre prototype. Car il faudra inclure non seulement des développements, mais aussi le prix du stockage en ligne et de la distribution. (Par exemple : mettre en place un serveur de streaming coûte plus cher en nombre de serveur qu'une plateforme de distribution de photo comme fotolia ou istock).

##### Workflow et Wireframe 📋

Comment souhaitez-vous organiser votre projet ? Quels sont les écrans ? Comment ces écrans communiquent-ils entre eux ? 

Il est plus simple de faire estimer un projet lorsque tout cela est déjà bien défini. En général j'essaye de faire une cartographie des écrans en reliant entre eux les écrans connectés. Cela me donne un arbre de connexion inter-écrans. Pour réaliser ce schéma j'utilise une application en ligne que je recommande souvent : [App Diagrams](https://app.diagrams.net/).

![connexion-inter-ecrans ><](https://bo.dev-freelance.fr/uploads/screen_connections_drawio_672f183ec3.png)

Ce schéma permet de savoir plusieurs choses :
- Le nombre minimum d'écrans pour pouvoir sortir votre projet
- Le fait de devoir gérer des espaces publics ou privés

Il est possible d'aller encore plus loin, où vous pouvez, par écran faire la cartographie de tous les appels API que vous souhaitez faire. Pour maîtriser quels sont les requêtes nécessaires pour chaque écran.

Chaque écran fera l'objet d'au moins une tâche sur votre **To-Do list**. Vous pourrez, bien sûr choisir de découper davantage afin d'avoir quelque chose de plus digeste pour commencer à travailler.

Pour chaque écran, vous devez élaborer un **wireframe**, c'est à dire une maquette qui va guider votre création graphique et vous permettre de positionner vos éléments.

![wirefrape-unsplash ><](https://bo.dev-freelance.fr/uploads/sigmund_4_U_Gmm3_WR_Uo_Q_unsplash_af7d465e85.jpg)

Lorsque vous faîtes vous-même la réalisation de votre projet, vous pouvez passer cette étape, mais sachez qu'elle va simplifier votre vision de la page et vous permettra plus facilement de mettre en place votre vue sous forme de brique réutilisable. 

**Ce travail va permettre de simplifier largement les estimations car vous avez une idée précise de ce dont vous avez besoin**. Plutôt que de recevoir une fourchette globale pour tout le projet, vous pouvez demander l'estimation en temps la plus haute pour chacune de ces pages. De cette façon vous obtiendrez le temps total que cela demande pour réaliser votre projet.

##### Gestion de votre application ⚙️

Nous venons de travailler sur des vues et la partie affichage avec laquelle vos utilisateurs vont interagir. Il faut maintenant penser aux vues administrateurs de votre projet. 

Certains projets arrivent à se passer de cette partie car on peut directement insérer des données en base etc... C'est à dire prendre quelques raccourcis quand il s'agit de l'administration de votre projet.

**Cependant, si votre projet doit être administrable par un utilisateur, est-ce qu'il vous faut des écrans dédiés à l'administration ? (Ce que l'on appelle dans le jargon : un backoffice)**.

Si la réponse est oui, je vous invite à recommencer le processus Workflow et Wireframe, cette fois-ci pour les vues d'administration.

#### Déployer votre solution 🚀

Une fois que le prototype est codé, il vous faut livrer tout ça. 

- Soit vous décidez de tout faire vous même en optant pour un VPS (meilleur rapport qualité/prix du marché), 
- Soit vous sous-traitez cette demande. 

Si dès le départ vous êtes sur une solution orienté cloud serverless, cela vous coûtera un peu plus cher mais au moins vous n'aurez rien à maintenir et à monitorer. 

Comptez aussi de quoi prendre un nom de domaine en moyenne 10€ / an (cela dépend de l'extension souhaitée).

Avec mon VPS j'affiche un prix TTC par an, domaine compris de 58 €.

Pensez également au prix du déploiement si vous ne le faîtes pas vous même, sur la base du temps de prestation. 

### Conclusions 👨‍⚖️

Nous avons vu les avantages et les inconvénients des outils no-code, cela reste une option envisageable si vous n'êtes pas développeur. Ou sinon, vous pouvez travailler vous-même pour votre solution ou sous-traiter la réalisation de votre produit. A l'instant T, cela peut vous sembler plus cher que la solution no-code, mais dans la durée il s'avère que non, d'autant plus vous serez propriétaire du code source et la valeur dégagé par votre produit sera supérieure. 

Gardez en tête que la plupart des solutions no-code ont tendance à établir les prix en fonction du nombre d'utilisateurs. Cela aura tendance à faire plafonner vos résultats si ceux-ci évolue en même temps que votre produit. 

**Si vous voulez dégager plus de marge, je vous conseille d'opter pour une solution dont les coûts fixes sont les plus bas**.

### Après le prototypage ? 🔭

Une fois que votre prototype est fini, vous pouvez le faire évoluer vers une version plus pérenne. La première chose à faire est d'atteindre un marché, vous aurez préalablement travaillé votre communication et votre acquisition client. 

C'est toute cette partie marketing, et la diffusion de votre produit qui doit occuper votre esprit.

Pour ce qui est du produit en lui même, vous pouvez l'améliorer de manière itérative. De petits cycles vont améliorer une partie de votre produit, vous permettra de stabiliser votre application en même temps que vous prendrez des parts du marchés.

Par exemple vous pouvez choisir : 
- d'ajouter une fonctionnalité
- de refaire le design de certains écrans
- d'améliorer certaines fonctionnalité pour encaisser une plus grosse charge client
- etc...

**L'amélioration sera une tâche continue de votre projet après son lancement**. Vous pourrez choisir de tout faire en parallèle (en constituant une équipe, ou en y travaillant à temps plein), ou étaler ces choix dans le temps. Voilà pourquoi, vous n'avez pas besoin de tout améliorer en amont, mais simplement de sortir quelque chose. 

Plus votre projet et les étapes le constituant seront clairs dans votre esprit, plus il sera simple de le réaliser. Et pour reprendre Napoleon Hill : **"Tout ce que le mental de l’homme peut concevoir, il peut le réaliser"**. 


large_callum-hill-NGGkGzslIaM-unsplash.jpg

medium_callum-hill-NGGkGzslIaM-unsplash.jpg

small_callum-hill-NGGkGzslIaM-unsplash.jpg

thumbnail_callum-hill-NGGkGzslIaM-unsplash.jpg

callum-hill-NGGkGzslIaM-unsplash.jpg

Comment vous y prendre si vous souhaitez créer votre application ou votre plateforme ? C'est une question à laquelle il n'y a pas qu'une seule réponse possible mais je vais tenter de répondre en argumentant au maximum.  

Comment réaliser votre projet étape par étape

## Pourquoi parler du déploiement de son code ? 🤔

Les développeurs ont trop tendance à mettre de côté cette compétence clé pour la création d'un produit (web, application, etc...). Lorsque vous travaillez des semaines, des mois sur quelque chose, pour que tout cela ait un sens, il faudra déployer à un moment où un autre. 

Soyez sûr qu'à ce moment là, on ne parle pas de faire un **npm dev/yarn dev** dans sa console en pensant que ça va régler le problème.
Le déploiement n'a rien à voir avec le fait de faire tourner du code sur sa machine pendant les développements. 

Premièrement ces scripts font beaucoup de choses automatiques pour vous, comme le **Hot-Module-Reload** (**HMR**), la compilation du code pendant la modification pour avoir une page web "live" avec votre service. Sachez que c'est une grosse erreur de lancer sa production en mode dev, car le **HMR** ne compresse pas le code source pour rendre les **stack** et **debug** lisibles. Cela signifie que vous êtes en train de livrer des sources plus lourdes et plus longues à charger pour vos utilisateurs...  😕

Mais aussi le lancement de votre serveur en mode dev affiche énormément d'informations, que vous ne voulez pas forcément afficher à vos utilisateurs. Parmi ces informations, vous retrouverez les logs d'erreurs, les stack trace en cas de bug, peut être même l'affichage en clair de log d'informations contenants des token etc... Bref beaucoup de mauvaises pratiques pour une production. Faire une vraie "**MEP**" comme on dit dans le jargon (pour mise en production), c'est un travail.

Cette compétence n'est pas simple, elle requiert : 
- de la compréhension : qu'est-ce que vous déployez, 
- de la vigilance : savoir mettre en place du monitoring, 
- du savoir faire : maîtriser son système d'exploitation, les versions, les compatibilités ou conflits
- de la veille : se tenir informé des failles, de l'évolution des packages

### Anticiper le déploiement ♟️

Lorsque vous codez, vous devez aussi anticiper sur cette étape ultime de votre création, la mise en production. Et le fait d'y penser d'avance se traduit par le fait d'intégrer au niveau du code plusieurs éléments qui dissocie d'avance la partie de code qui s'exécute pendant les tests et la partie de code qui s'exécute uniquement en production. 

Bien évidemment cela n'est pas toujours le cas. Il n'y a aucune obligation à exclure une partie du code de votre environnement de développement, mais cela arrive souvent. Par ailleurs, pour gérer de manière plus efficace les environnements, nous utilisons souvent un fichier d'environnement au niveau de la racine de votre projet. Ce fichier s'appelle par convention "**.env**" et les paquets comme [dotenv](https://www.npmjs.com/package/dotenv) nous permet de manipuler vos environnements au niveau du code plus facilement.

Dans ce fichier **.env**, on va retrouver de manière générale : 
- la "connection string" vers la base de données
- les clés API utilisés dans le projet
- etc...

Il s'agit d'une simple association clé/valeur sous cette forme : 

```
DATABASE=mysql://user:pass@host:port/dbname
API_KEY_A=wIenv_0nw9418QnqzlRIciap_@
API_KEY_B=W34WnfiroVJrizerO95ç0_JVnernazo
```

Et pour les utiliser au niveau du code après avoir importé votre librairie **dotenv**, vous pourrez tout simplement faire : 

```javascript
const pg = require('knex')({
  client: 'pg',
  connection: process.env.DATABASE,
  searchPath: ['knex', 'public'],
});

const apiA = InitApiA(process.env.API_KEY_A);

// ....

```

⚠️ Mais du coup, puisque vous intégrez des clés sensibles à votre fichire **.env**, il convient de ne pas le versionner sur vos repository. Pensez à ajouter une ligne dans votre **.gitingore** afin de ne pas l'ajouter à vos commits. 

En général ce que je fais, c'est que je laisse un fichier de plus que je nomme **.env.sample** dans lequel je laisse une liste des clés sans valeurs de ce que j'ai besoin d'initialiser dans mon environnement. (Juste une sorte de rappel). 

```javascript
DATABASE=
API_KEY_A=
API_KEY_B=
```

### Effectuer le déploiement 🚀

Pour ce qui est du déploiement de votre projet, tout dépend de la direction que vous aviez pris au moment de la conception de votre solution. 

Est-ce que vous avez fait le choix de faire du développement traditionnel ou une **solution serverless** ? 

Ce que j'entends par **solution serverless**, c'est une solution qui repose essentiellement sur des services managés (**SaaS**), en gros du full cloud. C'est à dire que le provider s'occupe de la mise à disposition du service, de la montée en version, de l'hébergement et du monitoring. [On en avait parlé pour les bases de données.](https://dev-freelance.fr/dev/passer-de-frontend-a-backend-les-bases-de-donnees) Il en est de même pour la partie code. 

Avez-vous fait le choix d'un framework **Node** ou **PHP** traditionnel ou avez vous fait le choix d'un service de **cloud functions** ?

C'est à dire que vous créez des morceaux de codes qui vont être exécutés à des moments précis : 

- Lors de l'appel d'une route HTTP comme c'est le cas pour [Google cloud functions](https://cloud.google.com/functions) ou [Amazon lambda](https://aws.amazon.com/fr/lambda/)
- Lors d'événements spécifiques (création de fichier sur un espace de stockage cloud, appel en cascade après une **cloud function**, etc...)

Je n'ai pas de préférence particulière au niveau des services de **cloud functions**, j'ai testé les deux providers et j'aime beaucoup les deux. Je dirais juste qu'**Amazon** a décliné un peu plus ses outils, ce qui permet plus de souplesse, si vous optez pour la mise en place d'une solution cloud **Amazon**.

Ainsi, je pense que les deux solutions peuvent convenir à vos besoins si vous décidez de passer sur du **serverless** pour ne pas vous embêter avec le maintient d'un serveur et surtout de ses différents services (le serveur **HTTP**, l'instance de votre serveur de code, le serveur de base de données, le serveur de cache). 

Si vous passez sur une solution **serverless**, le déploiement est assez cadré. Vous ne risquez pas vraiment de vous perdre, car les procédures vous guident pas à pas. De plus, vous avez aussi des framework **Node.js** tel que [Serverless Framework](https://www.serverless.com/) qui est vraiment pas mal pour faire votre déploiement Amazon Lambda sans trop vous casser la tête. Le framework est très bien documenté et est open-source.

Vous avez aussi d'autres services managés tels que [Vercel](https://vercel.com/) pour **Next.js** qui va gérer toute la partie déploiement beaucoup plus facilement pour vous lorsque vous l'aurez associé à **Github**.

<u>Le seul petit bémol pour les solutions managés, c'est le prix.</u>

⚠️ **Il va falloir passer à la caisse, autrement dit tout le temps que vous ne passerez pas à maintenir vous même vos serveurs, vous allez le payer et forcément, le prix est un peu plus élevé qu'un service que vous maintenez vous-même.**

Pour vous donner un ordre d'idée, j'ai un projet assez basique qui tourne sur AWS depuis quelques années avec une stack : **API Gateway**, **Lambda Node.js**, **RDS PostgreSQ**L. J'utilise le serverless pour [cette application mobile](https://play.google.com/store/apps/details?id=com.versusdb.app) qui me coûte en moyenne <u>40 € /mois</u> en SaaS, donc le coût, n'est pas négligeable.

---

D'un autre côté, vous pouvez opter pour une solution où vous allez vous même tout mettre en oeuvre. Elle vous demandera un peu plus d'efforts, de temps, de compréhension, mais au final, ce n'est pas plus mal non ? <u>Non seulement, on a la maîtrise totale de ce que l'on fait, on apprend, mais en plus, cela nous fait faire des économies.</u>

Avant d'entrer dans le détail des modes de déploiement, il faut savoir qu'en fonction des machines pour lesquelles vous optez, vous allez devoir faire les choses différemment. A l'époque, la plupart des serveurs étaient des serveurs **PHP** et ne proposaient pas beaucoup d'alternatives : 

- **Les serveurs mutualisés** : plusieurs clients se partagent une ressource machine, en sachant que l'on n'a pas besoin d'avoir une puissance de calcule énorme pour tous les types de services ou de sites.
- **Les serveurs dédiés** : disposer de la puissance de toute la machine rien que pour vos sites ou services.

Tout deux avec tout de même des limitations au niveau du réseau qu'il faudra finalement se partager depuis l'hébergeur, mais pas de panique, ces derniers disposent de connexion qu'un particulier de rêve pas d'avoir chez lui, donc au niveau des limites, on est très loin.

Aujourd'hui avec d'autres langages de programmation comme **Node.js** ou même un peu avant **Node** avec **Ruby on Rails**, on voit de plus en plus des serveurs privés virtuels (**VPS**). On va dire qu'il s'agit d'un mi-chemin entre le dédié et le mutualisé. 
Il s'agit de mutualiser les ressources machines mais, au niveau des services eux mêmes, chacun dispose de son service dédié, voire même d'une connexion **SSH** vers la machine.

Un **serveur dédié** ou un **VPS** vous donne tout deux un accès **SSH** vers la machine. Vous pourrez vous connecter via votre terminal et y effectuer toutes les opérations souhaités (installations, configurations, etc...).

En revanche cela demande de s'y connaitre un peu en serveur **linux**. Etant donné qu'il s'agit d'une machine, vous avez aussi le système d'exploitation à gérer. Très souvent vous serez sous linux, mais pour la distribution, vous devriez avoir le choix au moment de souscrire à la formule. Pour vous donner un ordre de grandeur, les VPS sont accessible avec des offres qui coutent environ 10€ / mois en moyenne. 

Il y a beaucoup d'hébergeurs entre **OVH**, **Scaleway**, **PulseHeberg**, **Gandi**, etc. 
Je pense tout de même que le meilleur rapport qualité/prix est **PulseHeberg**. Certes, le prix ne fait pas tout, mais au niveau du service c'est à dire la machine en elle même ainsi que la connexion, je suis satisfait. Tout le reste, je le fais moi, alors pourquoi payer plus cher ? 😅 

J'ai testé tous ces services de VPS sauf **Gandi** (un peu trop cher pour mon besoin).
Pour info chez **PulseHeberg**, je me retrouve donc avec **2 vCore** (vCore pour virtual core, environ 50% du temps machine d'un core standard), **2go de ram** (ce n'est pas beaucoup), **30go de SSD** (c'est largement suffisant pour ce que j'en fait) pour <u>4 € / mois</u>. 🤠

#### Les différents modes de déploiement 🧐

A l'époque avec les **serveurs mutualisés**, les déploiements se faisaient encore via **FTP**. Il fallait envoyer fichier par fichier les sites et applications, via le protocole de File Transfert... Une méthode un peu archaïque à ce jour.

Mais cette époque est révolue. Depuis que l'on donne aux utilisateurs de plus en plus d'accès aux ressources machines, que ce soit sur les **serveurs dédiés** ou les **VPS**.

Puisque vous pouvez décider de ce que vous installez sur le serveur, au delà du langage de programmation, vous pouvez très bien mettre en place des outils de déploiement. 

#### Directement sur la machine 🚢

Si on décide de déployer notre serveur directement sur la machine. Ce n'est pas l'idéal car si l'on change de serveur, il faut tout refaire, mais cela reste une option. Dans l'idéal je recommanderai d'avoir des scripts de déploiements qui ne sont pas liés à la machine.

**Je préfère vous prévenir, peu importe la méthode que vous emploierez à terme, il est fort probable et recommandé de commencer par tout faire à la main (on va taper chaque commande nous même)**. 

On va se connecter sur le serveur et faire chaque étapes les unes après les autres : 
- installation des paquets systèmes et dépendances
- pull du projet
- configuration de l'env, les clés, etc...
- création du service sur **systemctl** (fortement recommandé !), d'autres personnes utilisent [PM2](https://pm2.keymetrics.io/) pour les projets **Node**
- lancement des services

Créez un fichier script sur le côté pour copier/coller les commandes à chaque étape de votre configuration serveur. En faisant cela, vous êtes en train de créer le script de déploiement. Il convient de grouper ensuite les parties de script afin d'isoler chaque étape de déploiement. En calquant la liste vue précédemment.

#### Sur des containers 🚚

Voici une autre approche qui consiste à déployer le serveur via des container **Docker**. Pour ceux qui ne connaissent pas du tout [Docker](https://www.docker.com/), je vous conseille de faire quelques recherches sur le sujet car cela en vaut la peine. 

⚠️ Attention pour cette partie, sachez que cela ne fonctionne pas avec tous les **VPS** (qui sont des **container** ou des **VM**), Docker ayant besoin de certains jeux instructions et autorisations... Pour les **serveurs dédiés**, vous pouvez y aller sans problèmes !

Docker vous permet de livrer votre code sous forme de briques en fonction de vos besoins. C'est-à-dire que si vous avez besoin d'un serveur web, vous pouvez mettre un container **HTTP** (**Apache** ou **Nginx**), un container base de données (**MySQL**, **PostgreSQL** ou **Mongo**), un autre container **Node** v.XX (avec un mapping vers le dossier de code source afin que **Node** puisse interprêter votre code).

Dans ce cas, votre code source sera prêt à bouger d'une machine à l'autre très facilement. De plus, les containers eux-mêmes peuvent être déployés en groupe via des outils comme [Docker-Compose](https://github.com/docker/compose).

#### Automatiser ses déploiements 🤖

Aujourd'hui on a des outils comme [Jenkins](https://www.jenkins.io/) qui sert à gérer et orchestrer ce qu'il se passe sur votre serveur. **Jenkins** vous offrira une interface sur laquelle créer vos **workflow**. Remarquez que ce service aussi peut être déployé via un container **Docker**, si vous souhaitez gagner du temps.

Par exemple : 
- Un **workflow** déploiement qui appelle chacun des scripts vu ci-dessus.
- Un autre **workflow** mise à jour qui n'appelle qu'une partie des scripts pour mettre à jour le code sources et les dépendances puis relancer les services

**Jenkins** distribue également beaucoup de plugins pour ajouter des fonctionnalités, comme : appeller certains scripts, envoyer des notifications, etc...

De plus **Jenkins** est un serveur web, celà implique qu'il est possible de mettre en place des endpoints qui vont déclencher des workflows. Cela vous permet entre-autre de mettre en place des **webhooks** !

Concrètement, les **webhooks** sont des URLs appelées par certains services comme **Github** (mais pas que) qui permettent de faire suite à des événements spécifiques au service. Dans notre cas on pourrait mettre très rapidement en place notre **CI/CD** : **Continuous Integration, Continuous Delivery**.

Autrement dit, on peut tout simplement, depuis Github demander à Jenkins de déployer notre code sur le serveur en fonction de certains événements (comme les **push** sur la **branche master**).

#### Sécurisez vos déploiements 🔒

Jenkins est totalement exposé au web depuis le port que vous aurez choisi, il convient de mettre un peu de sécurité en place pour éviter le pire.

Essayez de mettre en place un moyen d'authentification (au moins un **Basic Token**) sur vos **webhook**. 

Pour vos projets gitbub en repository privés, je vous recommande fortement, l'utilisation de [clés de déploiement](https://docs.github.com/en/enterprise-server@3.4/authentication/keeping-your-account-and-data-secure/reviewing-your-deploy-keys) afin de ne jamais exposer vos identifiants / mot de passe.

Sur vos **workflow**, mettez toujours des étapes de tests, comme le lancement de vos Tests Unitaires. Et si les tests sont au rouge, arrêtez le déploiement, pour d'éviter de casser votre production.

Mettre en place un [fail2ban](https://doc.ubuntu-fr.org/fail2ban) afin de limiter la casse au niveau des tentative de brutforce par les bots.

Mettre en place un [ufw](https://doc.ubuntu-fr.org/ufw) firewall avec des règles de qu'est-ce que l'on ouvre ou pas comme ports (attention au port SSH 22, vous risquez de perdre totalement la connexion vers votre serveur si vous vous y prenez mal).

En général je désactive totalement les connexions **SSH** qui ne sont pas en **authorized_keys** et je whiteliste uniquement ma clé publique (avec backup des clés sur USB au cas où).

Voici quelques lignes de ma config ssh : 

```
    PasswordAuthentication no
    PubkeyAuthentication yes
    UsePAM no
    MaxAuthTries 2

```

### Surveiller son serveur 📈

La dernière étape une fois que votre site est en ligne, consiste à voir ce qu'il s'y passe. Pour cela, il faut mettre en place des logs. Sans chercher à faire trop compliqué j'ai tendance à demander à mes services de rediriger tout sur **/var/log/syslog** puis je me mets en écoute dessus en cas de besoin.

Si vous voulez aller plus loin dans les logs, vous avez des outils comme **Sentry** et **Dynatrace**. Qui permettront notamment de vérifier la performance de vos applications, en matière de délais.

### Pour aller plus loin 🔍

C'est un vaste sujet que je continue d'étudier chaque jour, le déploiement et l'administration des machines est vraiment un domaine passionnant, plein de challenge (lorsqu'il faut faire avec de toutes petites ressources, réussir à trouver des optimisations, des hacks ou encore lorsque vous avez des distributions linux exotiques... c'est du vécu ! 😂).

Tout ce que l'on a vu ici ne sont que des approches. Il ne tient qu'à vous de les challenger, de les améliorer, de faire autrement, mais je vous invite à mettre en place le plus d'automatisation. 

Un déploiement maîtrisé, c'est beaucoup plus de sérénité pour les développeurs car on sait que l'on a la capacité de rollback rapidement en cas de problèmes.

On peut aller encore beaucoup plus loin dans l'automatisation de ses déploiements via des outils comme [Terraform](https://www.terraform.io/). Cela nécessite un peu de pratique et de la formation, mais comme à peu près tout, il faut bien commencer quelque part. 😅

**Et comme j'aime souvent le dire : le rythme de déploiement de votre projet est un peu le rythme cardiaque de votre projet**.


large_ian-battaglia-9drS5E_Rguc-unsplash.jpg

medium_ian-battaglia-9drS5E_Rguc-unsplash.jpg

small_ian-battaglia-9drS5E_Rguc-unsplash.jpg

thumbnail_ian-battaglia-9drS5E_Rguc-unsplash.jpg

ian-battaglia-9drS5E_Rguc-unsplash.jpg

Un des grands oubliés d'un développeur fullstack, c'est de pouvoir déployer. Très souvent, on vous dira qu'être un développeur fullstack ne signifie pas devoir se charger du déploiement et qu'il s'agit d'une compétence SysAdmin ou Ops. Cependant, lorsque vous faîtes vous même votre projet de A à Z, il faudra bien le déployer !

Passer de frontend à backend - le déploiement

## La maîtrise de vos données 👌

Un des pilier d'une application c'est bien la couche de données, d'ailleurs, je pense même que c'est la couche technique (non perçu par le client) la plus importante, et je vais vous expliquer pourquoi. 

**Les données sont les seuls éléments de votre application dont l'intégrité est un besoin capital et la disponibilité une préoccupation majeure.**

Pour le dire simplement, on peut changer la couche graphique (partie frontend) de votre application, on peut changer votre backend (remplacer les API par un nouveau framework, un nouveau langage), <u>mais vos données doivent rester intactes et accessibles</u>. 

Il faut que vos données soient sans cesse cohérentes et que l'accès au données soit contrôlé. Tant au niveau de la base elle même (user/password), mais aussi au niveau accès ressource. Un utilisateur peut modifier son compte utilisateur mais pas celui d'un autre. **Comprenez qu'il y a des mécaniques de vérification qui devront être pris en compte et surtout mis en place.**

Quels sont les points à maîtriser pour déployer notre base de données applicative sereinement ?

### Choisir sa base 🤔

Il y existe plusieurs types de bases de données que vous pouvez déployer pour faire votre application. Chacun avec ses avantages et ses inconvénients : 
- les bases **SQL** : efficace pour le calcul et l'association de données inter-table (en gros je peux facilement associer un produit à un utilisateur etc car ces bases de données sont dites relationnelles).
- les bases **NoSQL** : qui signifie Not Only SQL et pas No SQL... Qui sont des bases orientés document (où il est plus difficile de faire des associations inter-données, mais qui permettent d'avoir une structure plus malléable).

Une des grosses différences entre ces deux types de bases, c'est que les bases **SQL** ont besoin d'avoir une structure bien définie : un champs possède tel nom et est de tel type (définition des colonnes). **SQL est une base pratique pour un projet mature en terme de besoin** : 
- vous savez quelle donnée vous souhaitez enregistrer, 
- vous savez pourquoi vous stockez ces informations 
- et quels sont les liens entre ces données.

Alors que la base de donnée documents vous permet d'être beaucoup plus souple : vous pouvez faire évoluer la source de données quand bon vous semble et ajouter des champs à la volée. Il est même possible que dans une source de même type, les documents aient des clés différentes. **Ce type de base est parfait dans une phase de rodage du modèle de donnée et de structure**. De même, sa performance fait que vous pourrez la garder indéfiniment tant que votre structure est optimisée.

Par exemple, en NoSQL, il est possible d'avoir une source de données Produits, et un produit aurait la clé "size" et un autre produit aurait la clé "quantity" sans la clé size... Je ne recommande pas cette pratique qui crée beaucoup de confusion à la lecture des données et vous force à implémenter beaucoup de vérifications.

Concernant les technologies à votre disposition, pour les bases **SQL**, les plus utilisés sont les bases [MySQL](https://www.mysql.com/) et [PostgreSQL](https://www.postgresql.org/). Les deux fonctionnent très bien et possèdent une communauté très active si vous cherchez de la documentation.

J'ai une tendance particulière à aller vers du MySQL pour des projets simples et du PostgreSQL pour des projets plus complexes avec beaucoup plus de données (> 1go).

Pour les bases **NoSQL**, les plus connus sont [MongoDB](https://www.mongodb.com/) et les bases [Neo4j](https://neo4j.com/). J'adore **MongoDB**, c'est un type de base que j'utilise souvent pour prototyper rapidement. 

Pour les bases **Neo4j**, je dois admettre que je n'y connais pas grand chose car je ne m'en suis jamais servi. Mais le concept est le suivant : essayer de garder les avantages des bases documents en mettant l'accent sur les relations inter-données. Ce qui nous donne **une base de données orienté graph** (pour faire le lien entre les données). Et ici l'objectif est clair, essayer de faire des bases documents avec les avantages des bases relationnels. Cependant la syntaxe est particulière et il vous faudra apprendre le **Cypher**, un graph query langage qui vous permet de faire des requêtes.

---

Le sujet de la base de données est tellement un sujet critique que de nombreux acteurs ont cherché à résoudre cette problématique afin de vous apporter des solutions simples. 

**Google** déploie plusieurs services de données simples en SaaS : 
- **Firebase** : une base documents simple avec une couche socket pour propager des événements
- **Firestore** : comme firebase mais avec des services en plus comme les notifications, le machine learning, etc...
- **Datastore** : commence à être abandonné pour firestore (les API sont dores et déjà les mêmes)
- **Bigtable** : base de données NoSQL pour des grosses opérations (calculs de stats, analyse, etc...)

**Amazon** aussi met en place plusieurs services : 
- **DynamoDB** : une base documents peu coûteuse et pratique
- **DocumentDB** : une base de données MongoDB-like (les prix commencent à 190$ environ par mois)
- **RDS** : une base de données SQL (MariaDB ou PostgreSQL)

Il existe bien d'autres offres en SaaS pour les bases de données, mais je ne vais pas faire une liste exhaustive des possibilités. Je vous ai listé ici les plus utilisés et les plus documentés.

Tous ces services sont managés pour vous, cela signifie que vous n'aurez pas à les tenir à jour en terme de version, de sécurité, d'intrusion, etc... Les providers s'occupent de tout et c'est là l'intérêt. Mais vous l'aurez compris, il s'agit d'un service donc cela vous demandera de mettre la main au portefeuille.

### Utiliser un ORM ⚒️

Si vous décidez de partir sur une base déployée par vos soin : SQL ou base document. Vous allez devoir gérer le service, les montées en version, la maintenance etc... Mais pas que !

Côté code, il faut réussir à vous y connecter. Et pour ce faire, il y a des librairies qui gèrent pour vous, de manière simple, les sockets et l'accès aux données. 

Ces librairies s'appellent les ORM : Object-Relational Mapping, c'est à dire un objet qui est lié à la donnée depuis le code. Soit une visualisation simplifiée de la donnée afin de la manipuler plus facilement.

Pour les bases SQL, les ORM sont légions : 
- **Knex.js**
- **Prisma**
- **Sequelize**

Ces ORM sont très bien documentés et tout ce dont vous avez besoin est à votre disposition. Comment créer un objet, comment écrire, comment lire, comment mettre à jour et comment supprimer... Tout y est !

Pour les bases de données NoSQL, notamment MongoDB :
- **Mongoose** : l'ORM le plus connu
- **Prisma** : avec une syntaxe très proche du modèle SQL

L'**ORM** vous garantie d'accéder à la donnée de manière efficace, sans duplication de code et de cadrer votre utilisation par les conventions. Dans une équipe, cela vous permettra d'avoir un code source organisé et de pouvoir travailler en toute cohésion grâce à une méthodologie commune.

D'une certaine façon, les bases de données **SaaS** déployés par les providers sont eux-aussi livrés avec des librairies en guise d'**ORM**. Cela facilitera son intégration et soyez sûr qu'ils aient mis le paquet sur la documentation puisqu'ils souhaite une adoption massive du marché. Ce qui signifie que la qualité du service et de la documentation seront au rendez-vous.

### Les points d'attention ⚠️

Après avoir vu les types de base de données et les **ORM**, il est temps de parler de ce sûr quoi vous devez être vigilent pour vous assurer le maximum de confort et de fiabilité en matière de données.

#### La performance des bases de données ⚡️

Premièrement je vais aborder le sujet de la performance lorsque l'on fait un choix de base de données. 

On s'attend à :
- des réponses rapides
- pouvoir faire des tris rapidement
- pouvoir filtrer les résultats

La performance est souvent un des critères mis en avant pour le choix d'une base de données. Mais sachez que la performance ne dépend pas que de la technologie mais aussi des performances machines. 

Une machine avec un SSD, beaucoup de RAM et beaucoup de cores sera forcément plus performante qu'une demi-VM avec une ram ponctionnée et 50% du temps CPU... On va dire que jusque là tout est logique.

**Mais il faut savoir que la performance s'entretient** ! Il n'est pas rare de voir les performances d'un système de base de données décliner dans le temps. 

Pourquoi ? 

Tout simplement parce qu'il y a plus de données à traiter...

Que peut-on faire dans cette situation ? 

#####  Les indexes 🔍

Y-penser dès le départ en anticipant sur les tables qui vont grossir rapidement, les colonnes clés sur lesquels filtrer, etc... Et mettre en place des **indexes**. Les indexes vont jouer comme des poids dans la structure de vos données. En gros, ils vont expliquer au moteur de base de données qu'est-ce qui est suffisamment important pour que la base optimise la distribution de cette donnée. 

Pour vous illustrer un peu cela : 

Lorsque l'on crée une table Users, votre clé primaire ID est indexée par défaut. Autrement dit, lorsque vous recherchez un User, en mettant une condition sur l'ID vous irez beaucoup plus vite que si vous le cherchez par son email.

Maintenant, le système d'indexation n'est pas exclusivement dédié à la clé primaire, vous pouvez très bien indexer n'importe quelle donnée de votre table. Car vous savez que vous vous servirez de tel champs pour vos requêtes. **Et cette optimisation prendra certes un peu plus d'espace sur le disque, mais vous sauvera la mise quand vous aurez atteint une taille critique de base**.

De plus, le système d'indexes n'est pas réservé aux bases SQL. Vous pouvez tout aussi bien mettre des indexes sur des bases NoSQL. Il faut garder en tête que c'est important et y penser en amont.

##### Le nettoyage des bases 🧹️

Par ailleurs, il y a aussi à travail à faire quant au nettoyage des données. Lorsqu'un projet va durer dans le temps et risque de fortement grossir, il faut mettre en place des règles de nettoyage de votre base de données.

En **PostgreSQL** vous avez un système de **VACCUM** qui va surtout être utile pour la partie disque. Mais entre-nous, il y a moyen d'optimiser tout type de base à condition d'avoir une méthode et de faire des choix.

Sur d'anciens projets, on avait pris l'habitude de garder 1 à 2 ans d'historique en base dite "active" et de basculer le reste en base dite "d'archive". Cela permet  de maintenir le volume de données dans une tranche qui fait que le temps de traitement sera impacté dans une moindre mesure. 

Après, il faut que le projet s'y prête, mais globalement on a toujours des méthodes qui permettent d'adapter la mise en place de ce genre de bascule. Typiquement, vous pouvez décider que pour les années à archiver, on ne garde en base que les minimum, maximum et moyenne pour certaines métriques, etc...

Je vous le disais, <u>il s'agit de choix</u>, dans le but de garder un applicatif fluide lorsqu'il exécute des requêtes.

#### Votre trousse de premier secours 🚑

**Il est impératif de vous munir d'outils pour des interventions rapides en cas d'urgence**. Il vous faut constituer ce que j'appelle <u>la trousse de secours de votre base de données</u>.

Autrement dit, je me prépare souvent une liste de scripts prêt à être exécutés via un CLI (terminal) à tout moment pour me sauver la mise en cas de besoin.

<u>En général il faut que ce genre d'opération mette moins d'une minute à lancer (l'exécution, c'est autre chose...)</u>. 

Voici la liste de ce que je garde sous le coude en cas de besoin : 

- Un script de déploiement de la base
- Un script de backup de votre database
- Un script de restauration votre base 
- Un script pour créer vos utilisateurs 
- Un script pour mettre à jour un mot de passe utilisateur
- Un script qui permet de feed (mettre en base les données essentiels au bon fonctionnement de votre projet)

Voilà je pense qu'on a fait un peu le tour pour la partie base de données. Comme vous pouvez le voir il y a de nombreux sujets à aborder, et il en reste encore tellement ! 

Je peux vous rassurer, j'ai commencé de 0 moi aussi, et ces informations deviendront totalement logiques et simples pour vous aussi dans très peu de temps. 
Il suffit de s'y mettre !

Dans un prochain article on parlera des déploiements, restez connectés ! 😉

large_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

medium_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

small_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

thumbnail_tobias-fischer-PkbZahEG2Ng-unsplash.jpg

tobias-fischer-PkbZahEG2Ng-unsplash.jpg

Dans notre démarche pour passer de développeur frontend à développeur backend, les bases de données sont un point de passage obligatoire pour devenir fullstack. Quels sont les points essentiels à maîtriser pour surmonter aisément cette étape ?

Passer de frontend à backend - les bases de données

Mon quotidien fait que je rencontre énormément de développeur Backend et Frontend, à différent niveaux de compétence pour qui le sujet back/front est toujours un débat.  Pourtant, je reste persuadé que l'on peut faire les deux, à partir du moment où on en ressent le besoin. 

Dans mon cas j'ai commencé sur du dev système avec du **C**, **C++** et à un moment de ma vie, j'ai eu à coder des interfaces. Au départ, c'était des **IHM** (interface homme-machine) en **C++**, puis en passant sur du Web, j'ai commencé à coder des vues HTML.

Aujourd'hui, je vais tenter de mettre le doigt sur les compétences à maîtriser pour pouvoir coder du backend lorsque l'on est plutôt orienté frontend. <u>Cet article fait partie d'une série de plusieurs articles que je posterai dans les jours qui viennent</u>.

**Qu'est-ce qui fait que je n'ai pas de préférence particulière ?**

Le fait d'avoir une réelle compréhension de ce qu'il se passe des deux côtés fait qu'il n'y a rien de mystique à mes yeux. Et quand on n'a aucune barrière mentale, tout est possible. C'est pourquoi, dans cette série d'articles je vais lister les éléments à comprendre et à maîtriser afin de vous aider à passer du front au back. 

Prêt ? 😊

## Appréhender le développement backend

Tant que le mot "backend" ne déclenche pas de frissons chez vous et un brun de dégoût, c'est qu'il y a de l'espoir !
Le code backend a beaucoup de charme et vous vous porterez bien mieux en comprenant un peu ce qu'il se passe de l'autre côté du réseau.

Comprendre le backend vous permettra de travailler sur vos propres API (interface de programmation), c'est à dire la brique que vous allez appeler pour effectuer des opérations : 
- insertion en base
- appels de devices
- interaction avec l'extérieur (paiement, services, etc...)

Vous serez en mesure de faire un produit complet de A à Z, bien que, je préfère le dire, la partie backend se décompose en plusieurs compétences : 
- **le développeur backend** : qui se concentre sur les services API
- **le sys dba** : qui maîtrise les bases de données
- **le sys admin** : qui maîtrise le déploiement

### Le réseau

La communication front/back se fait <u>toujours</u> par le biais du réseau. Cela implique qu'en fonction du protocole utilisé côté backend, il vous faudra comprendre comment cela fonctionne et ce que cela implique.

Généralement, sur des technologies Web, on est sur du **TCP** pour des échanges client-serveur standard et parfois de l'**UDP** pour l'image, la voix ou des échanges intenses comme les jeux en ligne. 

Pour faire simple, le protocole **TCP** implique une stricte vérification de chaque paquet reçu pour être sûr que tout correspond au message initial. En cas de paquet perdu, le protocole demande à réémettre le paquet. Il y a tellement de vérification pour que rien ne passe à la trappe que l'on dit que ce protocole est orienté qualité/fiabilité, mais cela implique aussi quelques lenteurs.
A contrario, l'**UDP** est un protocole basé sur l'efficacité. On ne fait pas de vérification de paquet, juste des échanges en faisant "confiance" au pair connecté. Et ce "non-contrôle" fait de lui le protocole le plus rapide des deux.

Et ce qui va sortir et entrer de votre interface réseau dans vos applications (votre carte wifi ou votre carte ethernet) sera en **TCP** ou **UDP**. Ce qui signifie que c'est au dessus de cette brique, que viendra se poser les autres protocoles de plus haut niveau.

Lorsque l'on est développeur Web, on travaille essentiellement avec de l'[HTTP](https://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol) pour nos API. 
Nous distinguons alors 2 choses : la requête (ce que le client demande) - la réponse (ce que le serveur retourne).

#### Commençons par les réponses HTTP

Ce qu'il faut garder en tête lorsque l'on communique en HTTP avec un serveur c'est que le code de statut ou encore status code nous explique ce qu'il s'est passé sur le serveur.

Par exemple : 
Status 200 - tout est ok

Dans les grandes lignes : 
- Status 2XX : ok
- Status 3XX : redirection, ou page non modifiée (généralement interprété directement par le navigateur)
- Status 4XX : erreur de la part du client (autorisation non suffisantes, page introuvable, etc...)
- Status 5XX : erreur de la part du serveur (un service a mal répondu ou un bug dans le code)

Associé à ce statut, il y a parfois un message mais notez que souvent le message est absent, surtout dans les cas d'erreur, car le statut est déjà suffisant pour donner l'information.

#### Les requêtes HTTP

Pour les requêtes, on va dire que cela dépend de l'architecture que vous utilisez. Le plus souvent, on passe par du [REST API](https://fr.wikipedia.org/wiki/Representational_state_transfer), c'est à dire faire des requêtes dont le header "**method**" décrira le type d'action que l'on souhaite faire :

- **GET** : généralement utilisé pour les lectures
- **POST** : généralement utilisé pour les écritures
- **PATCH** : généralement utilisé pour mettre à jour quelques champs d'un modèle
- **PUT** : généralement utilisé pour remplacer totalement un modèle
- **DELETE** : généralement utilisé pour supprimer un modèle

Et grâce à ces méthodes on va créer les routes pour effectuer les opérations de type CRUD (Create, Read, Update, Delete). Notre front n'aura plus qu'à consommer ce service en appelant les routes avec les bons paramètres et le tour est joué. Notre serveur répondra en effectuant les opérations nécessaires.

Il existe aussi d'autres architectures de requêtes comme [GraphQL](https://fr.wikipedia.org/wiki/GraphQL) qui n'utilise que les requêtes de type **POST** et permet de faire des opérations de type :

- **Query** : pour lire des informations depuis le serveur
- **Mutation** : pour écrire des informations depuis le serveur (que ce soit Create, Update ou Delete)

Le GraphQL utilise une syntaxe particulière qu'il vous faudra apprendre et comprendre avant de pouvoir évoluer confortablement avec cette architecture.

La différence majeure entre ces deux architectures : **REST** et **GraphQL**, c'est que **GraphQL** se concentre sur l'efficacité des trames réseaux car il permet de récupérer des champs spécifiques en lecture et écriture (donc contrôler la taille du trafic réseau, alors que **REST** renverra systématiquement tous les champs d'une réponse (à moins de coder un système de data picker en paramètre...).

#### Point d'attention sur cette partie réseau 

Lorsque vous choisirez votre architecture HTTP, je vous conseille de bien respecter les conventions. 

Sur du REST, je vous recommande d'être rigoureux sur la création de vos routes. Il y a des patterns à bien respecter, par exemple : 
**method: DELETE route: /post** est largement suffisant pour décrire une action de suppression d'un post, évitez les **routes: /post/supression**... 😅

### Le choix du framework

Peu importe le langage de programmation que vous utilisez, lorsque vous devez coder une API, vous allez au plus simple en sélectionnant un Framework qui va accélérer votre développement et cadrer les choses. Avec **Node.js**, ils sont nombreux, entre **Express**, **Hapi**, **Koa**, **Nest**, etc. Les principes restent les mêmes, effectuer des échanges réseaux client-serveur et gérer les requêtes en envoyant des réponses. 

Par ailleurs, il est tout à fait possible d'opter pour un framework dédié au **serverless**. C'est à dire que le framework va organiser le code de manière à être déployé sur des services managés par des providers tels qu'**Amazon** ou **Google**. C'est un choix envisageable et plein de sens, totalement dans l'air du temps, efficace puisque vous vous concentrez sur le code, <u>mais aussi plus couteux</u>.

De même **Next.js** est un peu, à sa façon, un très bon compromis. En effet, ce que vous produisez comme code pourra être déployé via [Vercel](https://vercel.com/) un service managé dédié à **Next.js** (solution que j'ai testé sur une mission, et qui s'avère incroyablement efficace), tout en vous donnant la possibilité de déployer vous même à moindre coût si vous le souhaitez (solution pour laquelle j'ai opté pour ce blog 😃). 

**Meteor.js** est un peu un ovni à sa manière avec son protocole **DDP** qui va mixer plusieurs technologies entre l'**HTTP**, le **RPC**, les **sockets**... N'hésitez pas à consulter [les quelques articles](https://dev-freelance.fr/dev/meteorjs-react-typescript) que je poste sur le sujet, car je suis moi même un utilisateur de **Meteor**.

### Pour aller plus loin

Sachez qu'il existe un projet qui se démocratise de plus en plus ces derniers temps : le [WebRTC](https://en.wikipedia.org/wiki/WebRTC) pour de la communication Web. Il est surtout utilisé pour transporter la voix ou l'image, parfois pour chatter mais c'est rare. Ce protocole peut fonctionner autant sur du TCP ou sur de l'UDP, bien que l'UDP soit privilégié.

Dans le prochain article on parlera des bases de données, toujours dans l'optique de passer de développeur frontend au développeur backend. 😉

mohammad-rahmani-_Fx34KeqIEw-unsplash.jpg

large_mohammad-rahmani-_Fx34KeqIEw-unsplash.jpg

medium_mohammad-rahmani-_Fx34KeqIEw-unsplash.jpg

small_mohammad-rahmani-_Fx34KeqIEw-unsplash.jpg

thumbnail_mohammad-rahmani-_Fx34KeqIEw-unsplash.jpg

Un développeur est une personne qui sait coder. Cependant, au quotidien, on choisi souvent une spécialisation, car on a peut être une appétence particulière pour les interfaces lorsque l'on est développeur frontend,  ou pour le système lorsque l'on est développeur backend. Mais cette vision du développement n'est-elle pas erronée ?

Passer de frontend à backend - le réseau

Je vous propose une liste d'outils j'utiliserais pour accélérer les développements et à la fin de cet article je vous dévoilerai combien de temps je peux mettre à le faire.

Entendons-nous bien, cette estimation est faite pour un site mono produit, avec pas ou peu de déclinaisons et un design assez simple à intégrer. Je ne prends pas en compte le design car je le fais en même temps que mes composants mais autant compter 1 à 2 jours en plus pour peaufiner le rendu.

## Les librairies que j'utilise pour coder une page de vente

### Moteur de page 🚀

[Nextjs](https://nextjs.org/) et **Typescript** pour bénéficier d'un système de page avec **React** comme moteur de rendu et une API rapide à mettre en œuvre. **Next** nous fait gagner au moins 2 semaines de boulot et est maintenu par une communauté active.

### Les outils de style et design 💅

[Tailwind](https://tailwindcss.com/) pour le CSS car même si cette librairie ne fait pas tout, elle permet d'aller très très vite avec des classes pré construites. Pour peu qu'on les connaisse bien, le gain de temps n'est pas négligeable. Couplé au package [classnames](https://www.npmjs.com/package/classnames), ces librairies permettront d'ajouter des classes optionnelles, de les concaténer etc...

### Les outils de formulaires ✏️

[React-Hook-Form](https://react-hook-form.com/) pour les formulaires, il me font gagner 10% à 15% de mon temps sur les formulaires. Elles permettent un two-way binding très simple à intégrer au lieu de tout faire à la main avec un useState.

### Les outils de requêtes client/server  📡

[React-Query](https://tanstack.com/query/v4) (devenu Tanstack query dernièrement) pour les requêtes, car c'est un outil pratique et permettant de mettre en cache des réponses serveur. Il gère tout seul l'invalidation de donnés et se couple parfaitement avec des hooks. De plus avec next il existe d'autres fonctionnalités tels que le prefetch en server side qui sont des alternatives intéressantes en cas de besoin. 

### Les outils de paiement 💰

[Stripe](https://stripe.com/docs) pour le paiement ! C'est un must have lorsque vous intégrez un système de paiement. J'ai l'impression qu'il a été créé pour les développeurs tant il est pratique à intégrer et fourni énormément d'outils pour vous faciliter davantage la tâche. 

**Stripe** ne se contente pas uniquement d'exposer une API, il fourni lui même des librairies client et serveur pour vous permettre d'intégrer le service plus facilement.

Vous avez notamment des outils et CLI qui vous permettront de tester les **webhook** en mode développement (pour un retour sur une IP local). Ainsi que tout un système de jeu de test pour faire des essais d'achat sans frais pendant les développements. 

Je précise qu'en général j'opte pour une intégration totale de la partie paiement sur le site pour éviter les redirections. Le temps de friction épargné peut augmenter le nombre de ventes.

### Les outils de base de données 💾

[Mongodb](https://www.mongodb.com/) comme base de données pour structurer à son rythme très facilement. Pour des projets un peu plus matures en terme de structure et de donnés je dirai un [**Postgresql**](https://www.postgresql.org/). 

### Le choix de l'ORM 🛠

Pour accélérer notre développement, il nous faut un ORM pour faire le lien code/base.
Si mon choix de base se porte sur **Mongo** je prendrais la librairie [Mongoose](https://mongoosejs.com/) pour l'intégration et pour **Postgres** je choisirais [Prisma](https://www.prisma.io/). 

**Prisma** fonctionne aussi avec les bases Mongo mais son approche est très orienté sequel, de ce fait vous écrivez les requêtes un peu trop comme s'ils étaient en SQL, a moins de faire du raw mais cela n'a pas beaucoup de sens.

### Les outils d'envoie d'emails ✉️

[Mailgun](https://www.mailgun.com/) pour les emails transactionnels. Cela ne vous épargnera pas le fait de devoir obtenir un SMTP pour vos envois mais mailgun se chargera du reste.


## Combien de temps faut-il avec ces outils pour coder sa propre page de vente ?

Avec ces 8 outils, je dirais qu'il me faut entre 3 et 4 jours pour créer de A à Z un tunnel de vente totalement personnalisé avec paiements, mails, contact messages. Et ce temps est nécessaire que pour un premier projet, car, avec des briques réutilisables ce temps peut être divisé par 3 ou plus. 

Ce qui signifie que votre première page de vente serait la plus longue et par la suite ce temps deviendrait dérisoire.

La première page de vente que j'ai codé date de 2020 et utilise d'autres technologies (entre-autres : Node, Handlebars, Stripe, Jquery, Mailgun). Cette page m'avait pris une semaine à l'époque avec des outils moins efficaces.

En ce moment même je travaille sur un projet de page de vente pour un **SaaS** et même en incluant le temps de développement du **service** je suis à moins d'une semaine de développement.

Alors vous attendez quoi pour vous lancer ? 🧐

cesar-carlevarino-aragon-NL_DF0Klepc-unsplash.jpg

large_cesar-carlevarino-aragon-NL_DF0Klepc-unsplash.jpg

medium_cesar-carlevarino-aragon-NL_DF0Klepc-unsplash.jpg

small_cesar-carlevarino-aragon-NL_DF0Klepc-unsplash.jpg

thumbnail_cesar-carlevarino-aragon-NL_DF0Klepc-unsplash.jpg

Lorsque l'on pense à une page de vente, on pense systématiquement à Shopify. Cet outil fonctionne très bien et est très efficace. Cependant, pour un développeur c'est assez frustrant de ne pas pouvoir faire tout ce que l'on veut de sa page. Si je devais faire une page de vente de A à Z moi-même, voici ce que j'utiliserais en tant que développeur.

Les 8 outils parfaits pour coder une page de vente

## Pourquoi utiliser Marked avec Strapi ?

Sur **Strapi**, lorsque l'on crée son modèle de données, le champs **Rich Text**, idéal pour un article de blog est écrit en **Markdown**.

Cela est pratique pour écrire quelque chose rapidement et en tant que développeur, car ce langage se veut relativement simpliste. 

Dernièrement, [je vous disais que j'avais choisi React-Markdown](https://dev-freelance.fr/dev/personnalisation-de-react-markdown-en-typescript) pour interprété le markdown généré par mon contenu. C'était vraiment pas mal, mais j'ai fini par revenir sur ma décision afin de mettre un outil plus complet, capable d’interpréter du **HTML**, créer des comportement Custom, etc...

### Remplacement de la librairie React-Markdown

On installe notre librairie Marked : 

```sh
yarn add marked hljs
yarn add -D @types/marked
```

N'hésitez pas à regarder [la documentation pour en savoir plus sur Marked](https://marked.js.org/using_advanced).

Dans ma page : 

```tsx
import { marked } from 'marked'
import hljs from 'highlight.js'
import MarkdownLink from '@components/markdown-link'

import 'highlight.js/styles/atom-one-dark.css'

marked.setOptions({
  highlight: (code, language) =>
    language ? hljs.highlight(language, code).value : hljs.highlightAuto(code).value,
})

marked.use({ renderer: MarkdownLink })

function MyPage () {
  // ... init
  
  return (
    // ... components
    <div
      className={classNames('w-full mb-4', s['article'])}
      dangerouslySetInnerHTML={{
        __html: marked(post.attributes.content),
      }}
    ></div>
  )
}

export default MyPage
```

Voici mon composant pour personnaliser les liens :

```tsx
// @components/markdown-link

import { Renderer } from 'marked'

const MarkdownLink: Partial<Omit<Renderer<false>, 'constructor' | 'options'>> = {
  link(href: string, title: string, text: string) {
    return `<a href="${href}" target="_blank" rel="noreferrer" ${
      title ? 'title="' + title + '"' : ''
    }>
        ${text}
      </a>`
  },
}

export default MarkdownLink
```

Il n'aura pas fallu plus de lignes pour pouvoir remplacer **React-Markdown** par **Marked**. 
Donc au niveau de la mise en place, on va dire que c'est très simple. 

### Qu'est-ce qui a réellement changé avec Marked

Désormais, je peux mettre des balises **HTML** dans le markdown et elles seront directement interprété ensuite. C'est vraiment très pratique, surtout que **Next** fait un premier render côté back, et d'après les tests, j'obtiens une page déjà rendue avec le Markdown interprété et un résultat très propre pour le référencement.

Il y a tout de même un petit bémol, cette opération n'aura pas été sans inconvénients, car le revers de la médaille, c'est que désormais au build je suis passé de 173ko à > 400ko sur la page de lecture d'article à cause de la taille des bundles depuis l'ajout de **Marked**.

J'imagine que cela génère quelques lenteurs au chargement de la page, mais d'après les tests cela reste raisonnable et ne gène en rien le confort de navigation.

Voilà, pour ma part je continuerai à améliorer le blog petit à petit, tout en sachant que j'ai déjà commencé à faire de nouveaux projets, mais je vous en dirai plus prochainement. 😃



large_kevin-canlas-cFFEeHNZEqw-unsplash.jpg

medium_kevin-canlas-cFFEeHNZEqw-unsplash.jpg

small_kevin-canlas-cFFEeHNZEqw-unsplash.jpg

thumbnail_kevin-canlas-cFFEeHNZEqw-unsplash.jpg

kevin-canlas-cFFEeHNZEqw-unsplash.jpg

Dernièrement, j'écrivais un article sur la personnalisation de React-Markdown. Cette librairie comporte beaucoup d'avantages, elle est pratique, simple, légère. Mais elle comporte aussi des inconvénients, elle est assez limitée en terme de possibilités. C'est pourquoi je passe à Marked...

Passage de React-Markdown à Marked

## Petit historique de React.js

**React.js** est une librairie fascinante. Elle a apporté une organisation et la capacité à réutiliser du code pour la composition des pages webs. Son approche orienté composant fait d'elle la reine des librairies pour coder les vues.

Notez que j'aime aussi beaucoup **Angular**, un peu moins **Vue.js** mais pour des raisons personnelles d'organisation de code.

D'après [Wikipedia](https://fr.wikipedia.org/wiki/React), les équipes de **Facebook** travaillaient sur **React** depuis 2013. Ce n'est qu'à partir de 2017 ou le marché a commencé à s'ouvrir à cette technologie, jusqu'alors utilisée par les équipes de Facebook elle même.

Pour ma part, j'ai commencé à utiliser **React** vers 2016, via des formations que j'avais acheté sur **Udemy** car j'étais en pleine recherche de performance et d'amélioration quant à mon organisation frontend. Avant mon passage à **React**, j'étais sur **AngularJS** et juste avant j'étais toujours sur du **jQuery**...

A cette époque React.js n'avais absolument rien à voir avec la librairie mature que l'on connait aujourd'hui. on devait utiliser des **.createComponent()** en **ES5**...

Plus tard, j'ai beaucoup aimé le passage à l'**ES6** via les class components

```jsx 
class MyComponent extends Component { 
  //... 
}
```
A ce moment là, j'étais en poste dans une société de média, et comme j'en faisait depuis maintenant un an, j'ai formé mes collègues à cette librairie. Ils ont beaucoup aimé et l'ont adopté par la suite.

La librairie a connu beaucoup de transformations depuis mes débuts dans et lorsque ces changements ont eu lieu, j'étais déjà en production sur des sites grand public. C'est pourquoi, je vais vous donner ici, ce que je pense être la clé pour <u>bien maîtriser React</u>.

### Le lifecycle

Ou encore le cycle de vie, concerne toutes les étapes par lesquelles notre interpreteur JS va passer et effectuer des opérations. 

Par exemple : 
- Avant le rendu
- Après le rendu

La maîtrise du **lifecycle** est une notion importante afin de bien comprendre **React** et d'être capable d'en faire ce que l'on veut. Les **React class components** ont plusieurs méthodes qui permettent d'effectuer certaines opérations pendant son **lifecycle**. 

### Questions 

**Avec les class components, quelle méthode permet d'effectuer des opérations avant Render ?**

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" data-target="resp-1" onclick="unSpoil(this)">
spoil
</button>

<div class="hidden p-4 bg-gray-400 my-4 rounded-lg" id="resp-1">
componentWillMount() devenu UNSAFE depuis.
</div>

**Par quoi peut-on remplacer cette méthode depuis les Functional components ?**

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" data-target="resp-2" onclick="unSpoil(this)">
spoil
</button>

<div class="hidden p-4 bg-gray-400 my-4 rounded-lg" id="resp-2">
Par rien du tout.

Tout ce qui doit être exécuté avant render peut être mis dans la fonction avant le return.
</div>

**Comment faire un équialent de componentDidMount() sur un Functional component aujourd'hui ?**

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" data-target="resp-3" onclick="unSpoil(this)">
spoil
</button>

<div class="hidden p-4 bg-gray-400 my-4 rounded-lg" id="resp-3">
En utilisant un useEffect avec un dependency array vide


```tsx
  React.useEffect(() => {
    // ... code
  }, []);
```
</div>

**Que peut-on retourner dans un hook useEffect et pourquoi le fait-on ?**

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" data-target="resp-4" onclick="unSpoil(this)">
spoil
</button>

<div class="hidden p-4 bg-gray-400 my-4 rounded-lg" id="resp-4">
useEffect retourne une fonction équivalente au componentWillUnmount. 

Cette fonction sert à faire du nettoyage dans le cas où on utilise des événements de type listener dans le useEffect. Il convient de faire un removeListener pour éviter que les callback s'empilent. Les événements en Javascript sont gérés comme une pile (stack) qui est dépilée au moment du déclenchement.
</div>

**A quoi sert l'attribut key en React ?**

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" data-target="resp-5" onclick="unSpoil(this)">
spoil
</button>

<div class="hidden p-4 bg-gray-400 my-4 rounded-lg" id="resp-5">
L'attribut key permet à React de se repérer lorsqu'il fait son render. Cela lui permet de savoir dans quel élément il se positionne. 

D'ailleurs key n'est pas utile que dans les boucles, sur Next.js, il permet de localiser un noeud commun et le remplacer s'il le faut.
</div>

large_green-chameleon-s9CC2SKySJM-unsplash.jpg

medium_green-chameleon-s9CC2SKySJM-unsplash.jpg

small_green-chameleon-s9CC2SKySJM-unsplash.jpg

thumbnail_green-chameleon-s9CC2SKySJM-unsplash.jpg

green-chameleon-s9CC2SKySJM-unsplash.jpg

Cela fait un petit moment que je travaille avec React.js. J'ai été candidat à des entretiens sur cette techno et j'ai moi même fait passer des entretiens. Si on testait un peu nos connaissances ?

Testez-vous sur le lifecycle de React

Dernièrement, je vous parlais un peu de **Meteor.js**, au travers de deux articles que je vous invite à lire si ce n'est pas le cas : 
- [Utiliser Meteor avec React et Typescript](https://dev-freelance.fr/dev/meteorjs-react-typescript)
- [Uploader des fichiers avec Meteor.js](https://dev-freelance.fr/dev/uploader-fichiers-publics-meteorjs)

C'est une technologie que j'apprécie beaucoup et qui me permet d'accélérer la création de projets avec un côté temps réel. Pour rappel, un des principaux avantages de **Meteor**, c'est sa capacité à _propager le changement d'une donnée en base à tous les clients connectés_.

## Gestion de la pagination dans un HoC withTracker

**WithTracker** est le **HoC** (higher order component) de Meteor.js qui vous permet de faire le lien avec votre couche de données. Il convient alors de faire toute la partie manipulation de données à cet endroit.

Nous n'entrerons pas dans les détails de la définition des types et la définitions des API (que nous avons vu dans les articles précédents).

Voici une proposition d'organisation pour paginer vos pages avec **Meteor** et **MongoDB**.

### Organisation de la page

```tsx
import * as React from 'react'
import { useFind, useSubscribe, withTracker } from 'meteor/react-meteor-data'
import Spinner from '@components/spinner'
import Paginator from '@components/paginator'
import { ProductCollection } from '/imports/api'

type PageProps = {
  products: Products[] 
  count: number
  limit: number
  toPage: (p: number) => boolean
  isLoading: () => boolean
}

function Page({
  products,
  toPage,
  count,
  limit,
  isLoading
}: PageProps) {
  return (
    <div>
      {/* ... page */}
      {isLoading() && <Spinner />}
      {/* ... display products */}
      <Paginator
        toPage={toPage}
        count={count}
        limit={limit}
        displayPages={true}
        />
    </div>
  )
}

export default withTracker(() => {
  const isLoading = useSubscribe('products')
  const [currentPage, setCurrentPage] = React.useState(1)
  const limit = 15 // Limite par défault = 15 éléments
  const products = useFind(
    () => ProductCollection.find({}, { limit, skip: limit * (currentPage - 1) }),
    [currentPage, limit] // dépendances
  ) // On récupère les produits avec un offset

  return {
    limit,
    count: ProductCollection.find({}, { fields: { _id: 1 } }).count() ?? 0,
    products,
    toPage: (nextPage: number) => {
      const count = ProductCollection.find({}, { fields: { _id: 1 } }).count() ?? 0
      if (nextPage < count) {
        setCurrentPage(nextPage)
        return true
      }
      return false
    },
    isLoading,
  }
})(Page)
```

Vous remarquerez que nous avons mis un state dans le **HoC**, il va gérer la pagination basé sur un système d'offset/limit.

### Composant de pagination

Ensuite, je pagine via ce composant : 

```tsx
import * as React from 'react'
import cn from 'classnames'
import { FaAngleLeft, FaAngleRight } from 'react-icons/fa'

type PaginatorProps = {
  toPage: (p: number) => boolean
  defaultPage?: number
  hasNextPage?: boolean
  hasPrevPage?: boolean
  displayPages?: boolean
  maxVisiblePages?: number
  limit: number
  count: number
}

type FooterPage = {
  currentPage: number
  label: string
  onClick: (e: React.SyntheticEvent) => void
}

const Paginator = ({
  defaultPage = 1,
  toPage,
  hasNextPage,
  hasPrevPage,
  displayPages,
  maxVisiblePages = 5,
  limit,
  count,
}: PaginatorProps) => {
  const [page, setPage] = React.useState(defaultPage)
  const [visiblePages, setVisiblePages] = React.useState<FooterPage[]>([])

  const updatePage = (newPage: number) => {
    const pageChanged = toPage(newPage)

    if (pageChanged) {
      setPage(newPage)

      let newVisiblePages: FooterPage[] = []

      const start = newPage < 2 ? 0 : newPage - 2
      const lastPage = Math.ceil(count / limit)
      const end = start + maxVisiblePages < lastPage ? start + maxVisiblePages : lastPage

      for (let i = start; i < end; i++) {
        newVisiblePages.push({
          label: (i + 1).toString(),
          currentPage: i + 1,
          onClick: () => (newPage - 1 === i ? null : updatePage(i + 1)),
        })
      }

      setVisiblePages(newVisiblePages)
    }
  }

  React.useEffect(() => {
    const lastPage = Math.ceil(count / limit)
    let newVisiblePages: FooterPage[] = []

    const start = page < 2 ? 0 : page - 2

    for (let i = start; i < lastPage; i++) {
      newVisiblePages.push({
        label: (i + 1).toString(),
        currentPage: i + 1,
        onClick: () => (page - 1 === i ? null : updatePage(i + 1)),
      })
    }

    setVisiblePages(newVisiblePages)
  }, [limit, count])

  return (
    <div className="pagination">
      {hasPrevPage && (
        <button
          className="btn btn-light"
          onClick={(e) => {
            e.stopPropagation()
            updatePage(page - 1)
          }}
        >
          <FaAngleLeft size={28} />
        </button>
      )}

      {displayPages && (
        <div className="inline">
          {maxVisiblePages &&
            visiblePages.map((p, index) => {
              return (
                <button
                  className={cn(
                    'btn me-2',
                    p.currentPage === page ? 'btn-dark' : 'btn-light'
                  )}
                  onClick={p.onClick}
                  key={index}
                >
                  {p.label}
                </button>
              )
            })}
        </div>
      )}

      {hasNextPage && (
        <button
          className="btn btn-light"
          onClick={(e) => {
            e.stopPropagation()
            updatePage(page + 1)
          }}
        >
          <FaAngleRight size={28} />
        </button>
      )}
    </div>
  )
}

export default Paginator
```

Vous devriez avoir un composant qui ressemble à cela :

![paginate-meteor-mongo ><](https://bo.dev-freelance.fr/uploads/paginator_2c3d95797c.png)

En sachant que vous avez les props **hasNextPage** et **hasPrevPage** qui affichent les chevrons si vous les passez à **true**. (Ces propriétés sont optionnelles).

De même, vous pouvez ou non afficher les pages sous forme de numéro en retirant la propriété **displayPages**.



large_bence-boros-KnVUtC5bl_A-unsplash.jpg

medium_bence-boros-KnVUtC5bl_A-unsplash.jpg

small_bence-boros-KnVUtC5bl_A-unsplash.jpg

thumbnail_bence-boros-KnVUtC5bl_A-unsplash.jpg

bence-boros-KnVUtC5bl_A-unsplash.jpg

Meteor.js vous permet de déclarer vos collections de données MongoDB très simplement. Mais son implémentation de Mongo est wrappé dans une librairie custom à Meteor. De même, l'utilisation de Mongo avec le protocole DDP et le wrapper de Meteor qui permet de faire des appels à la base de données côté frontend demande un peu d'organisation. C'est pourquoi je vous propose une approche pour réaliser la pagination de vos données.

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