### Redis n'est plus sous licence open source

![redis-logo.png](https://bo.dev-freelance.fr/uploads/redis_logo_ac9ef3d8fb.png)

**Redis**, désormais détenu par une société commerciale a vu sa licence changer de forme. Il se trouve que dans son code source, il y avait également la participation de la communauté du libre. 

Du jour au lendemain ce code source s'est retrouvé sous le joug d'une société qui, désormais, l'exploite uniquement à ses fins. 

Le problème qu'il s'est passé, ce n'est pas d'essayer de faire le l'argent en tant que société. 

Moi même, je suis développeur et je suis bien placé pour savoir qu'à un moment donné il faut valoriser son travail qui a demandé des efforts de conception/réalisation. Mais lorsque des gens interviennent bénévolement pendant des années afin de faire évoluer le projet, s'approprier leur travail gratuitement, c'est du vol.

La communauté du libre n'a pas tardé à s'organiser.

### La naissance du projet Redict

![redict-logo.svg](https://bo.dev-freelance.fr/uploads/redict_logo_64df6171d3.svg)

**Redict** pour **RE**mote **DICT**ionary a été créé sous licence **LGPL 3.0** par la communauté du libre.

Le projet **Redis**, je connais bien. J'ai de nombreux projets qui s'en servent et Dieu sait que même ce blog s'appuie sur **Redis**. 

Je vais migrer dès que je peux sur **Redict** et l'objectif de cet article est de voir s'il y a moyen de remplacer ce service en fournissant le moins d'efforts possible.

Dans cet article nous allons installer Redict via docker, puis nous effectuerons un test simple d'écriture et lecture. Enfin, je ferai un test local du moteur de blog et nous verrons si Redict est totalement compatible avec les manipulations plus complexes (pattern de clé etc...).

### Installation de Redict via Docker

Je me crée un dossier **redict-test**, et dans un fichier **docker-compose.yml**:

```shell
version: "3.1"

services:
  db:
    image: registry.redict.io/redict
    restart: always
    ports:
      - 6379:6379
```

Une fois le fichier créé, on peu lancer le service: 

```shell
sudo docker compose up -d
```

Nous pouvons vérifier son bon fonctionnement en temps réel:

```shell
sudo watch docker compose ps
```

### Test de Redict avec Node.js

Nous allons créer un projet simple en Node.js Typescript (je ne fais plus de Javascript), mais pas de panique, vous allez voir c'est tout aussi simple. Suivez le guide !

Création d'un **package.json** et ajout des dépendances:

```shell
yarn init

yarn add redis
yarn add typescript @types/node ts-node -D
```

Nous pouvons maintenant créer un fichier, **index.ts**:

```js
import { createClient } from "redis";

(async () => {
  const client = await createClient({
    url: "redis://127.0.0.1:6379",
  })
    .on("error", (err) => console.log("Redis Client Error", err))
    .connect();

  await client.set("key", `value ${Date.now()}`);
  const value = await client.get("key");
  console.log(value);
  await client.disconnect();
})();
``` 

Pour lancer, nous avons juste besoin d'entrer:

```shell
npx ts-node index.ts
```

Nous devrions obtenir le résultat suivant:

```shell
value 1712480118619
```

Victoire ! 🎉🎉

Je tiens tout de même à préciser, que nous pouvons utiliser **redis-cli**, comme nous le faisions habituellement avec **Redis**.

Vu que tout semble ok pour un besoin simple de lecture/écriture, essayons de répondre à un besoin plus complexe.

### Mettre le cache lifecycle du blog sur Redict

Je mets en place mon blog en local avec un dump des articles en ligne. 

<u>Nous n'avons aucun changement à faire au niveau des libs, ni même des variables d'environnement.</u>

Je lance un **monitor** sur un **redis-cli** qui se connecte au serveur **Redict**, et voici ce qu'il se passe lorsque je navigue sur le site:

![redict.gif](https://bo.dev-freelance.fr/uploads/redict_2112928dc8.gif)

Tout semble fonctionner à l'identique, je crois que nous avons réussi ! 🥳

Il ne me reste plus qu'à lancer le chantier en production.


large_redict-cover.jpg

medium_redict-cover.jpg

small_redict-cover.jpg

thumbnail_redict-cover.jpg

redict-cover.jpg

Redis, la base de données en RAM qui fonctionne en clé-valeur a changé de licence dernièrement. Fini le BSD, bonjour le copyright. C'est un move qui a légèrement agacé la communauté de la Tech.

Redis n'est pas mort, mais vive Redict

### Le concept Firebase

**Firebase** est [une plateforme initialement créée pour distribuer de la donnée](https://firebase.google.com/). 

La société proposait une approche intéressante qui permettait **d'émettre un event** sur modification de la base de donnée, ainsi permettre une écoute de cet événement côté applicatif. 

C'est un avantage considérable, permettant d'avoir un aspect temps réel sur les applications, tout comme j'en parlais dernièrement dans cet article concernant l'approche [Meteor.js](https://dev-freelance.fr/dev/substituer-meteor-js).

Avec le temps, la société a ajouté énormément d'outils permettant d'accélérer le développement et le prototypage, notamment les suivants:

- **Connexion Oauth** 🔒 built-in (Google, Facebook, Twitter, et autres providers)
- **Monitoring stats** 📈
- **Emails** ✉️
- **Cloud functions** 🪄
- **Big data**  🔎
- **File storage** 📁

Il faut savoir qu'il s'agit d'une base **NoSQL**, et qu'aucun schéma n'est requis pour commencer à insérer des données en base. Il comporte énormément d'avantages, tels que le prototypage rapide, la possibilité d'itérer en cours de route et d'ajouter de nouveau champs à notre modèle et j'en passe.

**Firebase** est devenu tout un tas de chose très puissant mais tout en restant simple d'utilisation. A tel point qu'il a été racheté par **Google**, qui a senti l'opportunité !

Il a été décliné un peu plus tard en **Firestore** qui est un variant un peu plus "cloud" avec quelques features en plus pour la distribution à grande échelle.

Je l'ai moi même utilisé à l'époque pour plusieurs projets mobiles chez **Scimob**, société de **Webedia**, et sur quelques projets perso, comme **Food Meter** l'application qui compte les calories via infos open data.

![foodmeter.jpg ><](https://bo.dev-freelance.fr/uploads/foodmeter_a9697988d9.jpg)

## Et Supabase là-dedans ?

![supabase_logo.jpg](https://bo.dev-freelance.fr/uploads/supabase_logo_6d0cb7478c.jpg)

[Supabase](https://supabase.com/) selon ses propres mots, se veut comme une alternative à **Firebase**. 

Techniquement il s'agit d'une base **PostgreSQL**, wrappée de manière à permettre un broadcast d'event si besoin. L'outil embarque aussi d'autres features tels que: 

- L'authentification 🔒
- Instant API ⚡ (le fait de déployer directement un REST API sur la table que vous créez en base)
- Edge Functions 🪄 (des fonctions serverless)
- Real Time Subscriptions 📞 (events)
- Storage 📁 (envoie de fichiers)
- Vectors ➡️ (dont nous parlerons ensuite)

Ca fait déjà pas mal de monde tout ça ☝️. Mais attendez la suite ! 😋

Avec **Supabase**, vous pouvez déployer toutes ces features directement sur votre machine, sans avoir besoin de passer par un SaaS. Disons plutôt que le SaaS, ce sera pour déployer votre application une fois vos devs terminés et que vous voulez mettre votre application en ligne sans vous prendre la tête à gérer l'hébergement (et oui, peut-être que la gestion de machine, ça vous répugne et que vous préférez rester focus sur la partie dev).

### Un exemple pour tester Supabase sur votre machine

Je vous propose de récupérer [ce projet de chat](https://github.com/shwosner/realtime-chat-supabase-react?tab=readme-ov-file).

Il s'agit d'un projet de chat en **React.js**, qui va vous permettre de tester rapidement **Supabase** et son côté temps réel.

Une fois que vous avez cloné le projet sur votre machine, nous allons installer les dépendances du projet **React**:

```shell
yarn
```

Maintenant, nous allons installer **Supabase** sur votre machine. 

Dans un second terminal, dans le même répertoire, faîtes: 

```shell
npx supabase init
```

Init va créer votre répertoire supabase et sa configurtion initiale. Puis, pour démarrer votre instance faîtes:

```shell
npx supabase start
```

A ce stade, vous avez installé les container docker de **Supabase** et les avez lancé avec la configuration du répertoire.
Vous devriez avoir un message comme ceci:

```shell
     Started supabase local development setup.

    API URL: http://127.0.0.1:54321
    GraphQL URL: http://127.0.0.1:54321/graphql/v1
    DB URL: postgresql://postgres:postgres@127.0.0.1:54322/postgres
    Studio URL: http://127.0.0.1:54323
    Inbucket URL: http://127.0.0.1:54324
    JWT secret: super-secret-jwt-token-with-at-least-32-characters-long
    anon key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiO...
    service_role key: eyJhbGciOiJIUzI1NiIsInR...
```

Rendez-vous sur votre interface Studio URL --> http://127.0.0.1:54323.

### Création de votre table sur Supabase

Allez dans le menu **SQL Editor** et collez la requête de création de table fournie avec le projet de chat:

![supabase_config.png](https://bo.dev-freelance.fr/uploads/supabase_config_fb7ec41715.png)

```sql
CREATE TABLE messages (
  id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  username VARCHAR NOT NULL,
  text TEXT NOT NULL,
  country VARCHAR,
  is_authenticated BOOLEAN DEFAULT FALSE,
  timestamp timestamp default now() NOT NULL
);
```

Lancez la requête, et ensuite dirigez vous dans le menu **Table Editor**, cliquez sur **messages**:

![supabase_table.png](https://bo.dev-freelance.fr/uploads/supabase_table_9b87aec637.png)

Et maintenant, n'oubliez pas d'activer le **Real Time** (en haut à droite), sur votre table **messages**:

![supabase_realtime.png](https://bo.dev-freelance.fr/uploads/supabase_realtime_8a04cfc33b.png)

## Configuration de l'env sur l'application React

Dans le dossier du projet chat que vous avez cloné un peu plus tôt, créez un fichier **.env**

```shell
VITE_SUPABASE_KEY=<la clé anon fournie par la commande supabase start>
VITE_SUPABASE_URL=<API URL fournie par la commande supabase start>
```

### Lancement de voter projet chat temps réel Supabase

Maintenant que la partie configuration est faîte, vous pouvez lancer votre projet chat

```shell
yarn dev
```

Vous n'avez pas besoin de créer de compte, ou de configurer l'Oauth github livré avec le projet. Je l'ai fait, mais comme cette partie est optionnelle, nous n'aurons pas besoin d'en parler ici.

### Essai du projet chat

![supabase.gif](https://bo.dev-freelance.fr/uploads/supabase_c093675853.gif)

Je suis plutôt satisfait de son fonctionnement, en sachant que si l'on regarde dans les détails du projet, l'insertion se fait très simplement, comme pourrait le faire un firebase: 

```javascript
// supabaseClient.js
import { createClient } from "@supabase/supabase-js";

const supabaseUrl = import.meta.env.VITE_SUPABASE_URL;
const supabaseKey = import.meta.env.VITE_SUPABASE_KEY;
const supabase = createClient(supabaseUrl, supabaseKey);

export default supabase;
```

Puis dans votre composant: 
```javascript
const { error } = await supabase.from("messages").insert([
        {
          text: message,
          username,
          country,
          is_authenticated: session ? true : false,
        },
      ]);
```

### Alors, que vaut Supabase ?

Pour résumer, **Supabase** est une technologie qui vous permettra d'aller vite, il embarque énormément de fonctions comme listés au-dessus. 

En sachant, que vous disposez d'une **API Rest** qu'il vous faut configurer avec <u>les politiques de sécurité</u>, comme précisés dans [les exemples](https://supabase.com/docs/guides/api/quickstart).

Les **Edge Functions** vous permettront de préparer des fonctions stockés et distribués, pour exécuter du code de manipulation de données côté serveur uniquement. Pour en savoir plus, consultez la documentation [ici](https://supabase.com/docs/guides/functions/quickstart).

Pratique pour mettre en place des **batchs** de traitement de données: 

- Pour publier une newsletter en parcourant la base d'inscrits
- Pour faire passer des documents en archive régulièrement
- Pour changer les statuts de certaines données en base

Par ailleurs, l'hébergement de **Vecteurs** permettent de donner un sérieux avantage à votre base:

- Hébergement de données complexes
- Capacités à faire des recherches d'éléments similaires en base
- Apporte des possibilités d'exploitation dans le domaine de l'**IA**

Pour en apprendre d'avantage sur le sujet, [la documentation fournie même des exemples](https://supabase.com/docs/guides/ai/concepts).

Honnêtement, je ne m'attendais pas à autant de chose lorsque j'ai essayé ce projet pour la première fois, mais je dois admettre que je suis agréablement surpris.

Qu'on le veuille ou non, **Firebase** avec une approche **NoSQL** rencontre forcément un problème de croisement de données lorsque les modèles sont un peu trop imbriqués. **Supabase** utilise une approche <u>de base relationnelle</u> et ne rencontre pas les mêmes problèmes, en revanche nécessite plus d'organisation lors de la conception de données. 

Utiliser **Supabase** implique d'avoir un peu plus de maturité dans sa vision technique, donc ne s'adressera qu'aux développeurs un peu plus expérimentés, ou aux projets qui ont un modèle de données éprouvé, peu enclin à être altéré dans le temps.

La **R&D** n'est pas morte 💪, il est toujours possible d'innover même dans des domaines qui semblent être maîtrisés et dominés depuis longtemps. 

**Supabase** est un exemple d'innovation et loin d'être une simple copie de **Firebase**, je pense réellement que c'est un challenger concret qui apporte quelque chose de nouveau au paysage tech. 

En revanche, je vous suggère tout de même la vigilance concernant la sûr utilisation des events pour le temps réel. Dans ma vie ayant travaillé sur des jeux massivement multijoueur en entreprise qui s'appuyait sur des technologies tel que **Firestore**, j'ai pu voir que le concept n'est pas fait pour être exploité uniquement pour cette raison. 

En effet, à partir de 6000 écoutes, vos propagations sont différés sur les listeners, <u>entraînant des retards, des désyncho</u> etc... Dîtes vous que le broadcast a une latence difficile à maîtriser dans le temps, car <u>il ne s'agit pas que de vous sur toute la plateforme SaaS mais de tous les clients du services</u>. En d'autre termes, le débit ne vous étant pas dédié, vous ne maîtriserez jamais le paramètre timing. Pour cela je vous conseille une architecture Socket master/slave sur vos propres infrastructures.

De même la licence de **Supabase** est intéressante (MIT license), mais le phénomène **Redis** a montré que dès qu'une entreprise est à l'origine d'un produit, cela peut rapidement tourner au fiasco. 

large_supabase_cover.jpg

medium_supabase_cover.jpg

small_supabase_cover.jpg

thumbnail_supabase_cover.jpg

supabase_cover.jpg

Dernièrement on parlait des avantages de Meteor en essayant de reproduire l'aspect temps réel du framework à la mano. Aujourd'hui je vous présente Supabase, un autre concept orienté temps réel, mais qui dont la réactivité vient avant tout de la base de données, pensée comme un firebase.

Supabase, le firebase-like sur votre machine

## Coder sur un Arduino R3 Uno sous Linux

J'ai choisi ce **Arduino** car il faut bien l'avouer, <u>il ne coute pas grand chose</u> et permet tout de même de faire des projets. Une fois reçu, je n'ai pas pu m'empêcher de déballer le carton et de lancer un "Hello World" sur cette board.

![Arduino R3 Uno.jpg](https://bo.dev-freelance.fr/uploads/Arduino_R3_Uno_8aca2a8b5e.jpg)

Mais ici on parle d'électronique, donc plutôt que d'afficher un Hello World, on va jouer avec une led.  😂

Petite info mais pas des moindres, je suis **sous Ubuntu 22**.

## Télécharger le programme Arduino IDE pour Linux

Rendez-vous sur le site d'[arduino](https://www.arduino.cc/).

Cliquez sur **Softwares**, vous devriez voir une section **Downloads** avec Arduino IDE. 

Au moment où j'écris cet article, il s'agit de la version **Arduino IDE 2.3.2**, choisissez la version de **Linux AppImage 64bits**.

## Lancement d'Arduino IDE sur Ubuntu

Une fois téléchargé, rendez-vous dans le dossier de téléchargement depuis un terminal. N'hésitez pas à rendre votre fichier exécutable via la commande: 

```shell
chmod +x ./arduino-ide_2.3.2_Linux_64bit.AppImage
```

Connectez votre board via un cable USB type B, on peut maintenant lancer le programme:

```shell
./arduino-ide_2.3.2_Linux_64bit.AppImage
```

## Un sample code pour pouvoir tester notre board

Le site [arduino.cc ](https://arduino.cc) regorge d'exemples que vous pouvez télécharger et tester à souhait. 

On va prendre un sample très simple, dans la partie **Hardware**, si vous cliquez sur votre board (la mienne étant un Arduino R3 Uno), vous pourrez voir une liste d'exemples. 

Je choisis **Blink** pour cet exemple, retrouvez le [ici](https://docs.arduino.cc/tutorials/uno-rev3/Blink/).

Bon allez, je vous le donne:

```c
/*
  Blink

  Turns an LED on for one second, then off for one second, repeatedly.

  Most Arduinos have an on-board LED you can control. On the UNO, MEGA and ZERO
  it is attached to digital pin 13, on MKR1000 on pin 6. LED_BUILTIN is set to
  the correct LED pin independent of which board is used.
  If you want to know what pin the on-board LED is connected to on your Arduino
  model, check the Technical Specs of your board at:
  https://www.arduino.cc/en/Main/Products

  modified 8 May 2014
  by Scott Fitzgerald
  modified 2 Sep 2016
  by Arturo Guadalupi
  modified 8 Sep 2016
  by Colby Newman

  This example code is in the public domain.

  https://www.arduino.cc/en/Tutorial/BuiltInExamples/Blink
*/

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);  // turn the LED on (HIGH is the voltage level)
  delay(1000);                      // wait for a second
  digitalWrite(LED_BUILTIN, LOW);   // turn the LED off by making the voltage LOW
  delay(1000);                      // wait for a second
}
```

Vous le copiez/collez dans l'interface, sauvegardez le dans un fichier (j'ai choisis **blink_sample.ino**).

Et soyez sûr de bien choisir votre board dans la liste déroulante, comme ceci:

![arduino_ide.png](https://bo.dev-freelance.fr/uploads/arduino_ide_3a38a72464.png)

Une fois que tout parait Ok, commencez par vérifier votre code en cliquant sur **Verify**:

![arduino_ide_verify.gif](https://bo.dev-freelance.fr/uploads/arduino_ide_verify_80eb81f123.gif)

Un terminal s'ouvre en bas et vous donne un statut de votre code actuel, s'il occupe trop de mémoire ou non (je pense que ça devrait aller 😅)

Une fois que vous êtes prêt, cliquez sur Upload pour envoyer le code à votre board et observez la led orange scintiller. N'hésitez pas à réduire les **delay** dans le code pour vérifier que tout fonctionne bien. 

Bien entendu, <u>à chaque modification du code, vous devrez</u>: **Sauvegarder**, **Vérifier** et **Uploader** de nouveau.

Si vous rencontrez un problème de droit à cette partie, il vous faudra peut-être entrer la commande suivante pour autoriser l'écriture sur la board: 

```shell
chmod a+rw /dev/ttyACM0
```

Et voilà, vous avez fait un Hello "Blink" sur votre Arduino ! 🥳 🎉 Félicitations !



large_arduino_linux.jpg

medium_arduino_linux.jpg

small_arduino_linux.jpg

thumbnail_arduino_linux.jpg

arduino_linux.jpg

Vous voulez prototyper quelque chose en électronique ? Vous voulez le faire sous Linux ? Super, c'est ici que ça se passe !

Utiliser un Arduino Uno R3 sous Linux

# Pourquoi remplacer Meteor.js ?

Non ce n'est pas une blague pour un 1er Avril ! 
J'aime beaucoup le framework **Meteor**, d'ailleurs je vous en ai déjà parlé dans [cet article](https://dev-freelance.fr/dev/meteorjs-react-typescript). Tout d'abord, prenons le temps d'analyser la situation et tâchons de comprendre pourquoi nous pourrions remplacer **Meteor.js** par une autre technologie. 

## Les guidelines de Meteor.js, un parti pris très fort

**Meteor.js** vous force à structurer votre code autour de son architecture, c'est à dire qu'il vous faut exploiter les mécaniques de **Tracker** de manière à optimiser au mieux le render. Pour ma part, j'utilise toujours **Meteor** avec **React**, bien que j'ai commencé comme beaucoup de gens avec **Blaze**. Mais dès que la version **React** a été publiée, je ne suis plus jamais reparti en arrière. 

Si vous n'êtes pas familier avec **Meteor**, les **Trackers** sont comme une sorte de **hook** qui va être déclenché lorsqu'un **Model** sera altéré côté base. En gros, s'il y a un update, c'est ce même **tracker** qui va prévenir votre composant pour que vous puissiez rafraîchir la donnée. On pourrait presque dire, qu'il s'agit tout bonnement d'un **socket listener** en attente d'un événement qui sera propagé au moment d'une écriture. 

## Meteor.js, les releases qui se font attendre

Très souvent sur **Meteor**, les nouvelles versions ont tendance à se faire attendre. Probablement que l'équipe qui maintient le projet a aussi du travail en parallèle et je comprends parfaitement que ce ne soit pas une priorité. Après tout, la version actuelle est toujours stable, tout fonctionne, il ne s'agit finalement que de quelques concepts en plus, ou rarement quelques dépréciations. 

En ce moment même, la version 3 de **Meteor** se fait attendre, bien qu'ils aient mis en ligne une version 3 beta. Il faut savoir que la version définitive était planifiée pour Q4 2023, or vous voyez on est déjà en plein Q2 2024 et ce n'est toujours pas terminé. 

J'apprécie beaucoup ce que fait la communauté **Meteor** et tout ce qu'ils ont apporté comme vision, comme intelligence. Le concept se veut simple: on s'occupe de propager l'information, écoute le bon événement et ton application sera réactive (pour tout ceux qui recherche le temps réel dans ce qu'ils produisent).

## Pourquoi aurait-on besoin de la v3 de Meteor ?

**Meteor** dans sa version 2 s'appuie sur **Fibers** qui est déprécié depuis **Node 16**. **Fibers** servait à gérer l'asynchrone sur les anciennes versions de **Node**. C'était un outil qui permettait de wrapper du code asynchrone et de l'exécuter avec le côté "bloquant".

```javascript
var Fiber = require('fibers');

function sleep(ms) {
	var fiber = Fiber.current;
	setTimeout(function() {
		fiber.run();
	}, ms);
	Fiber.yield();
}

Fiber(function() {
	console.log('wait... ' + new Date);
	sleep(1000);
	console.log('ok... ' + new Date);
}).run();
```

Depuis que **Fibers** a été déprécié, cela va probablement impacter **Meteor** en proposant une approche **async**/**await**, donc il va falloir se préparer à faire de la ré-écriture. Mais ce chantier ne pourra pas commencer tant que la version 3 ne sera pas définitivement sortie. 

## Si on devait refaire Meteor

Je me suis lancé dans une analyse par l'exemple, en me disant, si tu devais tout refaire, sans le framework Meteor, quels serait ta checklist en matière de feature ? 

Premièrement, je ne souhaiterais pas forcément tout reprendre de Meteor. Il y a de bonnes idées, mais je pense que beaucoup de choses seraient surtout long à réimplémenter. De même, je mettrai sur la balance, ce que la feature m'apporte réellement avant de me lancer sur certains sujets.

- Un monorepo front et back : que je ne referai pas car dans une approche similaire, **Next.js** fait parfaitement le boulot. 
- Un wrapper **Mongo** qui permet, côté front, de faire des appels **socket** et côté back les appels database avec une propagation après écriture : que je compte reproduire (plus simplement)
- Le wrapper **Mongo** côté front qui permet d'héberger une base allégée sur navigateur et permet de faire tourner votre application en dégradé : que je referai pas faute de temps, mais probablement dans une prochaine version.

## Notre objectif

Avant d'aller plus loin, il convient de se fixer un objectif atteignable, même si l'on peut le redéfinir une fois atteint. Le but est de savoir où nous allons.

Faire une boîte à idées !

On doit pouvoir: 
- Créer des comptes utilisateurs (s'enregistrer, se connecter, se déconnecter)
- Créer des sujets publics ou dans des groupes
- Poster ses idées dans les sujets
- Créer des groupes (publics ou privés)
- Interagir avec les groupes (demander à rejoindre, inviter, accepter un utilisateur, refuser, bannir, etc...)
- Manager les ressources (créer, supprimer)
- Toute l'application doit être temps réel

Nous sommes 5 jours après le début de la rédaction de cet article et toutes ces features fonctionnent et m'ont demandé quelques soirées et 7000 lignes de code.

![count_lines_ideezbox.png](https://bo.dev-freelance.fr/uploads/count_lines_ideezbox_20dd1f36a3.png)

## Les outils pour recoder Meteor from scratch

Nous allons utiliser, pour le back:

- **Node.js** + **Typescript**
- **ExpressJS**, **SocketIO**, **Multer**, **Moongoose** > **MongoDB** et **JsonWebToken**

Nous allons rester sur une API très classique, mais qui a fait ses preuves en terme de robustesse.

Côté front, nous utiliserons:

- **React.js** + **Typescript**
- **React-router-dom v6**, **React-Hook-Form**, **React-Query**, **Socket.io** et **Tailwind** pour le **CSS**

### Homemade Reactive project

J'ai passé quelques jours à coder ce projet pendant mon temps libre et avant d'aller dans le détail, voici à quoi ça ressemble lorsqu'on l'utilise.

<iframe width="100%" height="400" src="https://www.youtube.com/embed/FqVaMn3w8co?si=H20uPQXDmr4GBzMs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen onload="this.style.height=(this.contentWindow.document.body.scrollHeight+20)+'px';this.stype.width='100%';"></iframe>

### Comment je m'y suis pris pour reproduire l'effet temps réel

Mon code n'est pas open source pour toute la partie logique car j'utilise des procédés que j'emploie dans les projets que je livre, mais je tacherai de vous expliquer dans les grandes lignes comment peut-on mettre en place cette mécanique d'auto refresh.

Premièrement, je n'ai rien changé à une **API REST** habituelle. J'appelle mes routes qui utilisent **Mongoose** et qui font les opérations d'écriture en base. Cependant, je me suis organisé pour que chacune des routes de type écriture, c'est à dire **POST**, **PUT**, **PATCH**, **DELETE** propagent une fois les opérations terminés, un message sur socket contenant la liste des models qui viennent d'être mis à jour.

Côté front, j'ai créé un **Provider** avec **React** pour instancier ma socket, et j'écoute un event, qui, une fois reçu, me permettra d'invalider des patterns de clé dans le cache de **React-Query** (via **predicate**). Ce qui signifie, que si j'ai un composant qui a une queryKey sur ['Users', 'id user'], dès que vois passer des modifications côté base, je vais propager un event pour rafraîchir les composants qui font des requêtes sur une ressource 'Users'. 

De cette manière, le client sait quand est-ce que la ressource qu'il consulte est obsolète et gère lui même son re-render. 

![flow_meteor_like.png](https://bo.dev-freelance.fr/uploads/flow_meteor_like_cb4c4b5755.png)

### En 2024, il est simple de refaire un Meteor.js allégé

Il m'aura fallu une heure ou deux pour réaliser ce prototype de communication front/back (<u>hors logique applicative</u>), tant il est simple à déployer avec les outils d'aujourd'hui : **React** qui permet le re-render automatique dès qu'il y a **mutation du state**, **React-Query** qui gère un **query cache**, le pattern **Provider/Context** qui vient wrapper tous mes composants. 

Désormais, nous avons clairement tous les outils pour recréer, à notre façon, un framework comme **Meteor** sans avoir la contrainte d'organisation repo, d'utiliser **Tracker**, de **Meteor.call** ou autre.

En contre-partie, sur cette implémentation simpliste, je n'ai pas de base dégradée. Mais je me suis penché sur le sujet, et je pense qu'il y a matière à gérer cela avec un **PouchDB**. 

En revanche, j'aimerais, qu'en mode dégradé les bases locales ne contiennent que les changements en attente de synchronisation. C'est à dire que nous perdrons le côté historique des données, dès que la connexion serveur est interrompue. Mais cela permet de voir l'application front comme un système de transition, qui chercherait à vider les tables côté front pour confirmer l'insertion côté back. 

Probablement pour une v2 😊 



large_Recoder Meteor.jpg

medium_Recoder Meteor.jpg

small_Recoder Meteor.jpg

thumbnail_Recoder Meteor.jpg

Recoder Meteor.jpg

Meteor JS est une technologie intéressante pour son approche reactive via les Trackers. Elle gère à votre place énormément de chose pour que vous ayez à vous concentrer sur la partie métier. 

Si je devais substituer Meteor.js aujourd'hui

J'ai toujours aimé coder sur ma machine, faire les tests que je veux, où je veux et quand je veux. 

Pour vous dire, lorsque j'ai suivi le programme de formation [Temporal](https://dev-freelance.fr/dev/connaissez-vous-temporal), ils proposaient de faire un cours en ligne avec une instance de test en ligne. J'ai detesté l'idée et je suis allé déployer ma propre instance avant de commencer le cours.

Aujourd'hui je vous propose la même approche si vous commencez à coder vos **Smart Contracts** en **Solidity**.

Pour ceux à qui ça ne parle pas: **Solidity** est un langage de programmation compilé qui sort un **bytecode** (le fameux contrat) qui ira sur la blockchain **Ethereum**. Et oui, les **smart contracts** sont plus que de la crypto monnaie sur une chaîne, c'est aussi un code qui tourne sur une chain. Cela permet de nombreux avantage, comme le fait de bénéficier de la blockchain, pouvoir voir ce qui s'est passé au fil du temps, rendre impossible l'altération ou l'annulation à tout va de ce qui a été fait, etc... 

La blockchain **Ethereum** ayant été conçu pour tenir compte de l'impact sur l'environnement, il faut savoir que la lecture depuis un **smart contract** (étant donné que le code est propagé, il pourra être lu depuis plusieurs noeuds de cette chaîne, c'est une opération dérisoire donc gratuite en terme d'impact environnemental). En revanche, pour toute opération d'écriture, il faudra propager l'écriture sur les autres noeuds, et cela engendrera un paiement de **gas fee** (une sorte de taxe écologique pour avoir écrit). De la même manière déployer votre **smart contract** déclenche un **gas fee**, et plus ce dernier est lourd (en poids bytecode), plus le **gas fee** est élevé. 

Voici pour la partie concept et théorie. Maintenant si l'on veut commencer à coder...

On utlise le langage **Solidity** pour coder des smart contracts sur la blockchain **Ethereum** et pour coder du **Solidity** il y a un IDE en ligne très utilisé qui s'appelle **Remix**. 

Quasiment tout le monde, si ce n'est tout le monde utilise **Remix** afin de "ne pas se casser la tête" avec la mise en place des comptes de tests, avec les wallets **Ethereum** virtuels etc...

L'IDE se présente comme ceci :

![remix ide.jpg](https://bo.dev-freelance.fr/uploads/remix_ide_1fd1a2cc6f.jpg)

Et vous permet de manager de façon simple, des fichiers (extension .sol) qui seront le code source de votre **Smart Contract**.

Maintenant, on est d'accord que si vous voulez faire un **Smart Contract**, un tant soit peu ambitieux, ça deviendra vite compliqué. Vous n'allez pas copier-coller le contenu de vos fichiers sur l'IDE en ligne à chaque fois que vous allez reprendre vos sessions de code. 

Il y a un outil qui vous permet de gérer partiellement le problème: **remixd** (j'imagne comme remix daemon).

Vous pourrez stocker et organiser vos fichiers chez vous, les versionner, comme vous le ferez pour n'importe quel projet. 
Et depuis ce code source hébergé chez vous, en passant par ce fameux outil,  vous pourrez ouvrir un port sur votre machine pour permettre au site de **Remix IDE** de se connecter sur votre arborescence et accéder à vos fichiers.

En d'autres termes, c'est un tunnel (ou selon mes termes, une back door 😂). Mais pas de panique, nous allons le tweaker un peu.

### Installation de Remixd en local

Commençons par l'installer:

```shell
npm install @remix-project/remixd -g
```

Créez votre repository, et vous pouvez démarrer l'écriture de vos scripts Solidity.
En temps normal, pour travailler sur Remix IDE en ligne, on utilise la commande qui suit:

```shell
remixd -s ./src -u https://remix.ethereum.org
```

Mais nous allons essayer de travailler totalement en local, y compris pour la partie **Remix IDE**.

### Déploiement d'un serveur Remix avec Docker

Pour cela nous allons utiliser **Docker** et déployer une instance **Remix** depuis un container.

```shell
docker pull remixproject/remix-ide:latest
docker run -p 8080:80 remixproject/remix-ide:latest
```

Maintenant que **Remix IDE** tourne en local, on peut faire pointer notre **Remix Daemon** sur cette instance:

```shell
remixd -s ./src -u http://localhost:8080
```

Je me suis créé un repository comme ceci:

![solidity-dev.png](https://bo.dev-freelance.fr/uploads/solidity_dev_eab900145b.png)

### Déploiement d'un premier smart contract en local

Et maintenant, rendez vous sur votre navigateur : [http://localhost:8080](http://localhost:8080)

Il suffit de dérouler le dropdown pour sélectionner localhost, cliquez sur "connect" sur la modal:

![solidity.gif](https://bo.dev-freelance.fr/uploads/solidity_15d677985d.gif)

Il nous faut alors, compiler notre **Smart Contract** pour générer le **bytecode**:

![solidity-compile.png](https://bo.dev-freelance.fr/uploads/solidity_compile_9097db28e3.png)

Puis nous allons déployer le contract, rendez-vous dans le menu **Deploy & Run transactions** (sur la gauche). 

Vous observerez que vous disposez de plusieurs wallets de test avec 100 Ether chacun.

Cliquez sur **Deploy** et c'est parti !

![solidity-deploy.png](https://bo.dev-freelance.fr/uploads/solidity_deploy_5b60c1569f.png)

<u>Observez que le nombre d'Ether sur votre account a été décrémenté par le déploiement du contract !</u>

Maintenant nous pouvons manipuler notre smart contract:

![solidity-contract.gif](https://bo.dev-freelance.fr/uploads/solidity_contract_b7d06cd221.gif)

Evidemment à chaque fois que vous incrémentez votre compteur, vous payez quelques **gas fees**.

Voilà, et tout ça depuis votre machine, génial non ? 🤓


large_smart-contracts.jpg

medium_smart-contracts.jpg

small_smart-contracts.jpg

thumbnail_smart-contracts.jpg

smart-contracts.jpg

Privacy matters ! J'aime beaucoup héberger mes propres solutions, et développer sur ma machine plutôt que sur des plateformes en ligne. Je vais vous expliquer comment programmer sur une blockchain Ethereum de test depuis votre propre machine.

Coder des Smart Contracts Solidity sur votre propre machine

Je vous ai dit, je suis un grand fanatique des hooks, leur réutilisabilité, leur accès au lifecycle etc font d'eux un atout fondamental de React.

Aujourd'hui on va parler du Dark Mode et du Light Mode. N'ayant pas besoin de présenter davantage le sujet, je vous propose de passer immédiatement à la pratique.

On va directement créer un hook qui renverra un booléen isDarkMode dès que le thème d'affichage change. Il s'agira d'un state donc, cela va redéclencher le render de vos composants.

```javascript
// /hooks/useTheme.tsx

import React from "react";

export const useTheme = () => {
  const [isDarkMode, setIsDarkMode] = React.useState(false);

  React.useEffect(() => {
    if (
      window.matchMedia &&
      window.matchMedia("(prefers-color-scheme: dark)").matches
    ) {
      setIsDarkMode(true);
    }

    const listener = (event: MediaQueryListEvent) => {
      const newColorScheme = event.matches ? "dark" : "light";
      setIsDarkMode(newColorScheme === "dark");
    };

    window
      .matchMedia("(prefers-color-scheme: dark)")
      .addEventListener("change", listener);

    // Cleanup
    return () => {
      window
        .matchMedia("(prefers-color-scheme: dark)")
        .removeEventListener("change", listener);
    };
  }, []);

  return { isDarkMode };
};
```

Ensuite nous pouvons l'utiliser dans n'importe quel composant en une simple ligne: 

```javascript
const { isDarkMode } = useTheme();
```

Et avec ce hook des plus rudimentaire, nous obtenons ceci :

![dark_mode.gif](https://bo.dev-freelance.fr/uploads/dark_mode_825bf6b918.gif)

Dans cet exemple, je remplace le logo de la navbar en fonction du thème pour passer du noir au blanc.

🎉🎉 Victoire ! 😊

large_Hook-Dark-Mode.jpg

medium_Hook-Dark-Mode.jpg

small_Hook-Dark-Mode.jpg

thumbnail_Hook-Dark-Mode.jpg

Hook-Dark-Mode.jpg

Voici un hook en React que j'aime utiliser pour gérer le Dark Mode. Cela vous évitera de faire des gymnastiques CSS pour savoir si votre page est affiché en Dark Mode ou Light Mode.

Un hook React pour gérer le Dark Mode

# React-Query

[React-Query](https://tanstack.com/query/latest/docs/framework/react/overview) est une librairie pour gérer les requêtes en **React.js** qui s'utilise aussi bien avec du **Rest API** ou du **GraphQL**. 

L'utilisation de **react-query** demande la mise en place d'un **higher order component** qui viendra wrapper les composants dans lesquels on déclenche les requêtes.

**React-Query** est :
- Simple à mettre en place
- Gère le cache de réponses nativement
- Rend très simple les **Render conditionnels**, **Refetching** etc...

En fait l'outil n'ayant quasiment que des **pour** et peu de **contre**, je ne peux que le recommander chaudement.

# Un hook pour utiliser une requête

React-Query est lui même un hook, donc vous vous demanderez probablement, pourquoi un hook ?

<u>Etant donné, qu'il n'est pas rare d'avoir plusieurs composants ou pages qui utilisent les mêmes requêtes, voir les requêtes comme des hooks permet de réduire la duplication de code.</u> 

hooks/posts.tsx :

```
import React from "react";
import { useQuery } from "react-query";

export const useGetPost = () => {
  const { isFetching, error, data } = useQuery({
    queryKey: ["posts"],
    queryFn: () =>
      fetch("https://jsonplaceholder.typicode.com/posts").then((res) =>
        res.json()
      ),
  });

  return {
    isFetching,
    error,
    data,
  };
};
```

☝️ Il est possible de factoriser encore plus la partie requête en créant une librairie **api**, utiliser des variables d'environnement pour l'URL, etc...  

Enfin dans la page qui déclenche la requête, vous pouvez tout simplement faire :

```
function App() {
  const { isFetching, data: posts } = useGetPost();

  return (
    <div className="App flex justify-center flex-wrap">
      {isFetching && "Getting posts..."}
      {!isFetching &&
        posts?.map((post: Post) => {
          return <PostCard key={post.id} post={post} />;
        })}
    </div>
  );
}
```

Cette méthodo permet de factoriser et d'organiser sainement vos requêtes pour la réutilisation.

Cela donne une arborescence comme suit :

```
├── src
│   ├── App.css
│   ├── App.test.tsx
│   ├── App.tsx
│   ├── components
│   │   └── post.tsx
│   ├── custom-types
│   │   └── post.ts
│   ├── hoc
│   │   └── queries.tsx
│   ├── hooks
│   │   └── posts.tsx
│   ├── index.css
│   ├── index.tsx
```

En tout cas je vous recommande cette organisation, du moins, éviter au maximum de faire des appels direct à **react-query** dans les composants et recréer systématiquement des copies de vos requêtes. 
Car le jour où l'API évoluera et les endpoints changeront de forme, cela vous évitera de repasser partout pour faire des correctifs. 

Voici [le repository](https://github.com/aluzed/react-query-hook-sample/tree/master).

Soyez efficacement paresseux ! 🐼




large_react-query.jpg

medium_react-query.jpg

small_react-query.jpg

thumbnail_react-query.jpg

react-query.jpg

Tous les projets  React ne sont pas égaux en matière d'organisation des requêtes. J'aime bien que les dossiers ne soient pas un labyrinthe et que l'on sache exactement quoi faire pour répliquer l'existant sans créer de doublons. Voici comment je procède.

Organiser efficacement ses requêtes React-Query

# Pourquoi ne pas partir d'un Boilerplate ?

J'évite toujours de partir d'un **Boilerplate** public pour plusieurs raisons :

- Je veux éviter d'avoir trop de dépendances pour simplifier la maintenance et la montée de version. 
- Je veux maîtriser ce qui est installé dans mon projet pour éviter tout problème de hack ou problème de droit.
- A part les gros projets, les **boilerplates** sont souvent déjà obsolètes

# Certains boilerplate sont pratiques

Il y a tout de même certains **boilerplate** qui sont utiles : 

- **Create React App**
- **Next.js**

Et il m'arrive même d'en faire pour moi même, mais pour un projet backend **Typescript**, on peut partir from scratch

# Un projet Typescript avec Jest et SWC 

Il ne faut pas grand chose pour mettre cela en place :


```bash
mkdir new_project
cd new_project

yarn init

# Install Typescript

yarn add -D typescript @types/node ts-node
npx tsc --init

# Cela va générer un fichier tsconfig.js
# En général je configure les rootDir et outDir

# Install Jest

yarn add -D jest @swc/core @swc/jest @types/jest 
npx jest --init

# Cela va générer un fichier jest.config.js 
```

Dans le fichier jest.config.js

```bash
module.exports = {
	// ...
	transform: {
		"^.+\\.(t|j)sx?$": ["@swc/jest"],
	},
};
```

Vous pouvez maintenant créer votre fichier **src/index.ts**

Pour exécuter le code :

```bash
npx ts-node src/index.ts
```

Pour exécuter les tests :

```bash
npx jest 
```

large_building-construction-typescript.jpg

medium_building-construction-typescript.jpg

small_building-construction-typescript.jpg

thumbnail_building-construction-typescript.jpg

building-construction-typescript.jpg

Pour monter un projet backend Typescript en moins d'une minute, from scratch, sans partir d'un boilerplate, rien de plus simple...

Un projet backend Typescript from scratch

Si vous faîtes du frontend **ReactJS**, il est fort probable d'avoir du code qui ressemble à ceci :

```js
<div className="flex flex-col items-center w-full px-20 mt-20">
      <div className="flex items-center pb-8">
        {Object.keys(totalSell).map((currency: string) => {
          return (
            <Badge
              key={currency}
              color={
                totalSell[currency] - totalBuy[currency] > 0 ? "green" : "red"
              }
              title={`Total Buy: ${totalBuy[currency].toFixed(2)} - 
              Total Sell: ${totalSell[currency].toFixed(2)}`}
              className="text-3xl"
            >
              {currency}:{" "}
              {(totalSell[currency] - totalBuy[currency]).toFixed(2)}
            </Badge>
          );
        })}
      </div>
```

Fonctionnellement tout est OK, ce composant s'affiche bien etc. 


<u>Mais vous ne trouvez pas cela perturbant d'avoir autant de balise dans une partie qui est sensé être composé que de strings ?</u> 🤔

Lorsque je vois ça, il me faut un peut plus de temps pour me projeter sur ce à quoi cela peut ressembler au rendu. Aussi, je me dis que le code pourrait être bien plus lisible et structuré pour nos collègues. 💡

Quelque chose qui ressemble à ceci par exemple :

```js
<div className="flex items-center pb-8">
        {Object.keys(totalSell).map((currency: string) => {
          return (
            <Badge
              key={currency}
              color={
                totalSell[currency] - totalBuy[currency] > 0 ? "green" : "red"
              }
              title={new TextFormatter(
                `Total Buy: %totalBuy% - Total Sell: %totalSell%`
              ).format({
                totalBuy: totalBuy[currency].toFixed(2),
                totalSell: totalSell[currency].toFixed(2),
              })}
              className="text-3xl"
            >
              {new TextFormatter(`%currency%: %balance%`).format({
                currency,
                balance: (totalSell[currency] - totalBuy[currency]).toFixed(2),
              })}
            </Badge>
          );
        })}
      </div>
```

Et pour arriver à ce résultat, je vais créer une classe **TextFormatter** comme ceci :

```typescript
class TextFormatter {
  text: string;

  constructor(text: string) {
    this.text = text;
  }

  toString() {
    return this.text;
  }

  format(
    obj: Record<string, string | number>,
    options = { openTag: "%", closeTag: "%" }
  ) {
    let result = this.text;
    for (let key of Object.keys(obj)) {
      result = result.replace(
        new RegExp(`${options.openTag}${key}${options.closeTag}`, "g"),
        obj[key].toString()
      );
    }
    return result;
  }
}

export default TextFormatter;
```

Vous pouvez personnaliser les tags sur la méthode format en second paramètre :

```typescript
new TextFormatter(`{{currency}}: {{balance}}`).format({
  currency,
  balance: (totalSell[currency] - totalBuy[currency]).toFixed(2),
}, { openTag: '{{', closeTag: '}}' })
```

Je ne vous cache pas que je garde tout de même, une préférence pour un texte sans brackets, donc j'éviterai de l'utiliser sous cette forme.

Voilà je pense qu'avec cela, vous serez en mesure de faire du texte plus lisible dans vos composants React. 😉

Bon code à vous !

large_formater-texte-react.jpg

medium_formater-texte-react.jpg

small_formater-texte-react.jpg

thumbnail_formater-texte-react.jpg

formater-texte-react.jpg

Lorsque l'on fait du frontend en React, il n'est pas rare d'avoir du code horrible à relire, surtout lorsque celui ci est composé de templates string dans tous les sens, on obtient on joyeux galimatias. Je vous propose d'y remédier.

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