Développer avec le database branching

Hola, je vais vous présenter le début d'une nouvelle série d'articles dédiées à la construction d'un projet Web et Mobile en mettant à profit l'Architecture Hexagonale. Durant toute cette série, nous allons explorer comment la logique métier peut être partagée et gérée efficacement à travers différentes plateformes.

‍

Nos objectifs

‍

Nous allons avoir plusieurs objectifs à atteindre au fil de ce projet :

• Apprendre comment développer une application Web et Mobile à la fois en mettant à profit les technologies modernes (Nx, Expo, Remix, Vitest, etc.)
• Comprendre les principes de l'Architecture Hexagonale et comment l'appliquer pour optimiser le partage de la logique métier
• Gagner en compétence et en confiance pour lancer votre propre projet multi-plateforme, tout en développant une base de code propre et maintenable

‍

‍

La structure de la série

‍

Comme je l'ai dis au début de ce premier article, ce projet donnera lieu à une série d'articles qui sera structurée de cette manière :

• Partie 1 (cet article) : présentation du projet et mise en place d'un monorepo avec Nx
• Partie 2 : développer sans UI avec l'Architecture Hexagonale
• Partie 3 : partager de la logique métier et des composants entre le Web et le Mobile
• Partie 4 : refactor serein avec les tests et l'Architecture Hexagonale
• Partie 5 : déploiement Web et Mobile avec Netlify et EAS

‍

Le projet

‍

Le projet qui va nous aider à mettre en avant l'Architecture Hexagonale est un outil de gestion de budget que l'on appellera broney (le bro qui t'aides à gérer ta money 😎). Cet outil sera composé de deux applications, une première, web, développée avec Remix et une deuxième, mobile, développée avec Expo. Nous aurons donc 2 applications React et React Native avec un package TypeScript qui contiendra la logique métier partagée entre ces 2 applications.

‍

Stack

La Stack que j'ai choisi est très subjective, on y trouve quelques frameworks qui mérite selon moi plus de lumière (Remix notamment et Nx face à NextJS et Turborepo). Néanmoins il est important de comprendre que peu importe les frameworks et libraires utilisées, le coeur de l'application sera complètement agnostique et réutilisable dans n'importe quel contexte.

• Monorepo avec Nx
• Application mobile avec Expo
• Application web avec Remix
• Testing avec Vitest
• Style avec Tailwind pour le web et twrnc pour le mobile
• Animation avec Framer Motion pour le web et React Native Reanimated pour le mobile
• Déploiement de l'application web avec Netlify
• Base de données, authentification, etc. avec Supabase
• Formatage du code avec Prettier
• Validation du code avec ESLint
• CI/CD avec les GitHub Actions
• Gestion d'état avec Zustand
• Gestion des formulaires avec React Hook Form
• Validation des types avec Zod
• Logging avec Sentry
• Traductions avec FormatJS
• Utilitaire de date avec date-fns

‍

Fonctionnalités

Pour mettre en avant l'Architecture Hexagonale nous allons avoir besoin de développer quelques fonctionnalités pour avoir de la logique métier. Nous allons nous focus sur les fonctionnalités suivantes :

• Mettre en place le storage : react native mmkv pour le mobile et localStorage pour le web
• Gérer les catégories : lister, ajouter, modifier et supprimer
• Gérer les portefeuilles : lister, ajouter, modifier et supprimer
• Gérer les transactions d'un compte : lister, ajouter, modifier et supprimer
• Authentification avec Supabase
• Dynamiser toute l'app avec Supabase

‍

Modèle de données

Pour mettre en place les fonctionnalités nous allons avoir besoin des entités suivantes :

• Wallet, un portefeuille qui a un solde négatif ou positif (par exemple on peut avoir le portefeuille "Compte Principal Julien" qui a un solde positif de 1000€)
• Category, des catégories servant à préciser le contexte des transactions faites (par exemple on a les catégories "Maison", "Restaurants" et "Divertissements")
• Transaction, les transactions sont liées à un portefeuille et à une catégorie pour savoir où l'argent est transférée (par exemple on a une transaction du portefeuille "Compte Principal Julien" de 50€ sur la catégorie "Restaurants")

‍

Mise en place du monorepo avec NX

‍

Initialisation du projet

Nous allons utiliser les commandes de Nx pour initialiser notre projet.

➜ npx create-nx-workspace@latest

✔ Where would you like to create your workspace? · broney
✔ Which stack do you want to use? · none
✔ Package-based monorepo, integrated monorepo, or standalone project? · package-based
✔ Enable distributed caching to make your CI faster · Yes

‍


Avec cette commande nous avons le projet Nx configuré de base et sans libs pour le moment. Nous allons travailler avec le style Package-Based Repos qui nous offre plus de liberté en limitant le couplage avec Nx si jamais on souhaite changer facilement d'outil de monorepo. Cela permet également d'avoir des node_modules différents pour chaque app ou lib du projet. En savoir plus sur les différents style d'implémentation de Nx.

‍

‍

Création de la lib core

Nous allons maintenant ajouter notre première lib, la plus importante : core. En effet, c'est dans cette lib que nous allons mettre notre Architecture Hexagonale et la logique métier qui sera utilisée par nos applications Web et Mobile.

➜ nx g @nx/js:lib libs/core

✔ Which unit test runner would you like to use? · vitest
✔ Which bundler would you like to use to build the library? Choose 'none' to skip build setup. · rollup

‍

Cette commande nous a généré une lib avec le framework de test Vitest, une config eslint et prettier que l'on peut adapter à nos preferences que je ne détaillerai pas ici.

Il est possible de compiler notre lib avec la commande nx core build et d'executer les tests avec nx core test.

‍

‍

Mise en place de la CI

Maintenant que nous avons les tests setup ainsi que prettier et eslint, il est pertinent de mettre en place une CI pour avoir du feedback régulier sur la bonne tenue du code. Pour la CI nous allons simplement suivre la documentation de Nx et utiliser les GitHub Actions.

Nous allons donc simplement ajouter un fichier .github/workflows/ci.yml assez simple qui peut être étoffé.

name: CI
on:
	push:
	branches:
	- main
	pull_request:

jobs:
	main:
		runs-on: ubuntu-latest
		steps:
			- uses: actions/checkout@v4
				with:
					fetch-depth: 0
			# Cache node_modules
			- uses: actions/setup-node@v3
				with:
					node-version: 20
					cache: 'yarn'
			- run: yarn --no-progress --frozen-lockfile
			- uses: nrwl/nx-set-shas@v4.0.4

			- run: npx nx format:check
			- run: npx nx affected -t lint,test,build --parallel=3

‍

Cette simple CI permet vérifier le bon formatage prettier, d'effectuer les validations eslint et de build et de s'assurer que les tests sont sans erreurs.

‍

‍

Structure du projet

‍

Rentrons plus en détails dans ce que l'on vise comme structure de projet une fois les apps mise en place et notre lib core développée avec l'architecture hexagonale.

- apps

    - mobile : notre application React Native développée avec Expo
    - web : notre application React développée avec React

- libs
    - ui : nos composants React et React Native utilisés par les apps web et mobile
    - tailwind : notre configuration tailwind utilisée par les apps web et mobile ainsi que la lib ui
    - core : notre architecture hexagonale qui contient le coeur de notre application et toute la logique métier réutilisable par les apps web et mobile

‍

Pour aller plus loin, on peut très bien envisager d'avoir une app en plus pour un Storybook.

La lib qui va nous intéresser et la lib core évidemment. Elle sera structurée de cette manière :

- libs
    - core
         - src
              - wallet
                   - tests
                        - wallet.service.test.ts : la logique métier testées
                        - wallet.test.ts : les règles métiers testées
                   - domain
                        - wallet.ts : l'entité qui représente les portefeuilles et qui contient des règles métiers
                        - wallet.repository.ts: le contrat qui détermine comment manipuler l'entité pour lister, ajouter, etc.
                        - wallet.service.ts : le service qui consume une implémentation de contrat‍
                   - infrastructure
                        - in-memory-wallet.repository.ts : une implémentation du contrat
                        - local-storage-wallet.repository.ts : idem
                        - supabase-wallet.repository.ts : idem
                   - user-interface
                        - wallet.store.ts : un store zustand vanilla, utilisable dans n'importe quel environnement javascript et qui sera utilisé dans nos apps
              - category
                   - ...
           - ...

‍

Nous verrons le contenu de chaque fichiers ainsi que les détails du fonctionnement de ces derniers dans le prochain article !

‍

‍

Conclusion

‍

Nous avons terminé le premier article de cette série sur le développement d'une application web et mobile avec l'Architecture Hexagonale et le partage de la logique métier et des composants UI.

Dans cette première partie nous avons vu comment mettre un place un monorepo et nous avons pourquoi et comment ce monorepo va nous aider à partager la logique métier entre nos différentes applications. Nous avons également bien délimité le périmètre et les fonctionnalités attendues pour notre première version, le MVP, de broney.

Enfin, à la fin de cet article nous avons commencé à entrevoir la structure du projet en mettant en évidence l'Architecture Hexagonale, ce sera le thème de la deuxième partie : Développer sans UI avec l'Architecture Hexagonale.

‍

À l'ère du développement web, choisir le bon Framework frontend peut définir le succès de votre projet. Aujourd'hui, plongeons dans le débat Vue.js vs React.js. Quel géant du JavaScript convient le mieux à votre vision ? C'est la question à laquelle nous répondrons dans cette comparaison détaillée. Explorez les fondamentaux, découvrez les différences clés, et faites un choix éclairé pour votre prochaine aventure digitale.

‍

Les fondamentaux de Vue.js et React.js

‍

Entamons notre exploration en mettant en lumière les caractéristiques distinctives de Vue.js et React.js, deux incontournables du développement JavaScript.

‍

Vue.js : une approche progressive

‍

Vue.js se démarque par son approche incrémentielle. Son système de composants facilite l'intégration avec des projets existants, offrant une simplicité appréciée. L'outil Vue CLI permet un démarrage rapide, un atout pour les projets de toutes envergures.

‍

La partie écrite en HTML propose une balise div avec l'id app, qui est la zone d'application que Vue.js cible.

À l'intérieur de cette balise, nous avons un bouton avec un événement @click qui déclenche la méthode showMessage() lorsque le bouton est cliqué. Le paragraphe avec la directive v-if  s'affiche uniquement lorsque la propriété messageVisible est true.

Enfin, la partie script JavaScript est écrite en Vue.js. Elle créée une nouvelle instance de Vue avec les données et les méthodes nécessaires. Lorsque le bouton est cliqué, la méthode showMessage() est appelée pour rendre le message visible.

‍

En résumé, ce code Vue.js crée une application basique avec un bouton qui, une fois cliqué, fait apparaître un message dans un paragraphe. La logique de rendu conditionnel est gérée par les propriétés réactives de Vue.js (messageVisible, dans ce cas).

‍

React.js : la puissance du Virtual DOM

‍

React.js brille avec le concept de Virtual DOM, améliorant significativement les performances. Sa flexibilité s'étend au-delà des applications web, permettant le développement d'applications mobiles avec React Native. Create React App offre, quant à lui, une entrée en matière rapide pour les nouveaux projets.

‍

‍

Dans cet exemple, nous utilisons la fonction useState() de React pour déclarer et initialiser l'état du composant fonction App. Sa syntaxe est simplifiée grâce à l'utilisation d’une fonction fléchée.

Pour des projets réels, il serait préférable d'utiliser des outils comme Create React App ou Nextjs pour une configuration plus complète et une structure de dossier organisée.

‍

Comparaison directe

‍

Plongeons maintenant dans une analyse détaillée des différences clés entre Vue.js et React.js, mettant en lumière les points qui pourraient orienter votre choix.

‍

Performance et DOM virtuel

En matière de performances, Vue.js excelle avec son système de rendu réactif. React.js, quant à lui, mise sur la puissance du Virtual DOM pour des applications fluides et réactives. Un point crucial à considérer selon les exigences de votre projet.

‍

Facilité d'apprentissage et courbe d'apprentissage

Vue.js se distingue par sa courbe d'apprentissage douce, idéale pour les débutants. À l'inverse, React.js offre une courbe d'apprentissage plus prononcée, mais son écosystème robuste attire les développeurs expérimentés. Un choix à faire en fonction de votre équipe et de vos délais.

‍

Composants et modularité

Vue.js brille avec son système de composants intuitif, favorisant la réutilisabilité. React.js propose également une approche modulaire, mais dans un écosystème plus vaste. Choisissez en fonction de la complexité de votre application et de vos besoins en modularité.

‍

Choisir en fonction de vos besoins

‍

Maintenant que nous avons disséqué les différences, concentrons-nous sur la prise de décision. Comment choisir entre Vue.js et React.js en fonction de vos besoins spécifiques ? C'est ce que nous allons explorer dans cette section.

Vue.js excelle dans le développement d'applications web, offrant simplicité et efficacité. À l'inverse, React.js élargit son spectre en permettant également le développement d'applications mobiles grâce à React Native. La nature de votre projet guidera ce choix crucial.

Vue.js se distingue par sa simplicité d'intégration avec HTML et CSS, facilitant la transition pour les développeurs. React.js adopte une approche JSX, plus proche du JavaScript pur. La préférence pour l'une ou l'autre dépendra de votre équipe et de vos préférences de codage.

‍

Communautés actives et support

‍

Entrons maintenant dans le monde des communautés, un aspect essentiel pour le succès continu d'un Framework. Voyons comment Vue.js et React.js se positionnent en termes de soutien et de ressources.

La communauté Vue.js connaît une croissance significative. Des forums actifs, des tutoriels, et un soutien en ligne abondant font de Vue.js une option attrayante pour ceux qui apprécient une communauté en pleine expansion.

Vue.js dispose d'un forum officiel où les développeurs de tous niveaux peuvent poser des questions, partager leurs expériences et discuter des meilleures pratiques. La communauté est connue pour être accueillante et réactive.

Les meetups et les conférences dédiés à Vue.js sont organisés régulièrement dans le monde entier. Ils offrent une excellente occasion de rencontrer d'autres développeurs, de partager des idées et d'en apprendre davantage sur les nouvelles fonctionnalités et les meilleures pratiques.

La documentation officielle de Vue.js est très complète et bien organisée. Elle propose des guides, des exemples concrets et une référence exhaustive pour aider les développeurs à comprendre et à utiliser Vue.js de manière efficace.

Vue Mastery propose des cours en ligne avancés pour les développeurs Vue.js de tous niveaux. Ces cours couvrent une variété de sujets, de l'apprentissage des bases à des sujets avancés tels que la gestion d'état avancée.

‍

React.js, avec l'une des plus grandes communautés, offre une richesse de ressources et de forums de discussion. La stabilité et la maturité de la communauté React.js en font un choix rassurant pour ceux qui recherchent une base solide de soutien.

Le répertoire GitHub de React est un centre actif de collaboration. Les développeurs peuvent signaler des problèmes, proposer des fonctionnalités, et contribuer directement au développement du Framework.

Reactiflux est une communauté React sur Discord où les développeurs peuvent discuter en temps réel, poser des questions et partager leurs expériences.

La documentation officielle de React est exhaustive et mise à jour régulièrement. Elle couvre tout, de l'installation à des sujets avancés tels que les Hooks, les Context API, et la gestion d'état.

La communauté React est très active sur Stack Overflow. Les développeurs peuvent poser des questions et obtenir des réponses rapides de la part de la communauté.

‍

Nos conseils pour optimiser votre choix

‍

Nous arrivons à la phase cruciale de la prise de décision. Comment optimiser votre choix entre Vue.js et React.js ? Découvrons des conseils pratiques pour guider cette étape.

Vue.js se démarque par son accent sur une expérience utilisateur fluide. Ses fonctionnalités réactives et sa simplicité d'utilisation en font un choix idéal pour des applications offrant une expérience utilisateur exceptionnelle.

Quel que soit le choix, misez sur la qualité. Évitez des refontes coûteuses en privilégiant la qualité dès le début. Des applications bien conçues offrent une base solide pour le succès à long terme, que vous optiez pour Vue.js ou React.js.

En fin de compte, le choix entre Vue.js et React.js est personnel, dépendant de vos besoins spécifiques, de la nature de votre projet, et de vos préférences. Dans la prochaine section, rappelons l'essentiel de cette comparaison et offrons une vision claire pour vous aider à faire le choix éclairé qui propulsera votre projet vers le succès.

‍

En conclusion, le choix entre Vue.js et React.js est une décision cruciale, dépendante de la nature unique de votre projet. Que vous soyez séduit par l'approche progressive de Vue.js ou par la puissance du Virtual DOM de React.js, l'essentiel est de faire un choix éclairé.

‍

À travers cette comparaison, nous avons exploré les fondamentaux, examiné les différences clés, et offert des conseils pratiques pour guider votre décision.

N'oubliez pas : la clé du succès réside souvent dans la simplicité. Optez pour le Framework qui s'aligne le mieux avec vos besoins, tout en privilégiant la qualité dès le départ. Que vous choisissiez Vue.js ou React.js, transformons ensemble votre vision en une réalité digitale.

Si des questions persistent ou si vous avez besoin d'un accompagnement plus approfondi, n'hésitez pas à nous contacter. Chez Yield Studio, nous sommes là pour concrétiser vos projets avec expertise et engagement.

Lorsque l’on développe une solution SaaS, il est nécessaire de bien penser son architecture, surtout si à l’avenir vous réfléchissez déjà à faire découpler plusieurs instances de celle-ci.

‍

Pour imager, prenons pour exemple un site e-commerce.

‍

Vous pouvez faire le choix de partir sur une architecture simple pour votre MVP, avec tout simplement votre boutique à Paris, mais dès lors où le besoin d’avoir plusieurs boutiques se présente, plusieurs questions vont venir à vous.

‍

Ces questions pourraient concerner :

La gestion du stock : est-elle centralisée ? Y-a-t’il un stock par boutique ?

La gestion des produits : est-ce que chaque boutique est indépendante, est-ce qu’elle a ses propres produits ?

La gestion des utilisateurs : est-ce que je stocke les données utilisateurs par boutique ? Est-ce que j’ai une base commune d’utilisateurs ?

‍

Toutes vos réponses vont impacter la façon dont vous allez mettre en place le multi-tenant.

‍

Le multi-tenant

Vous l’avez compris, on parle de multi-tenant lorsque l’on doit gérer plusieurs contextes dans une application, si l’on devait reprendre notre exemple précédent on considèrerait chaque boutique comme un contexte.

‍

Gestion en single-database

La gestion du multi-tenant au moyen d'une seule base de données présente plusieurs avantages significatifs.

Tout d'abord, elle simplifie considérablement la maintenance car il n'y a qu'une seule base a gérer en cas de bugs ou de restauration des backups.

‍

De plus, la base de données demeure relativement simple à gérer avec l'utilisation d'un champ tenant_id (store_id) pour distinguer les différents tenants.

‍

Cela offre un avantage financier car il n'y a pas de surcoût au niveau de l'infrastructure.

‍

L'approche du multi-tenant avec une seule base de données comporte également certains inconvénients notables.

‍

Dans le cas de l'utilisation d'un Framework PHP tel que Laravel ou Symfony par exemple, l'adaptation des packages de la communauté ainsi que des requêtes SQL est nécessaire, ce qui peut entraîner des coûts de développements supplémentaires.

‍

En effet, il faudra ajouter un critère à chaque requête pour spécifier le bon tenant à utiliser, un oubli entraînerait des conséquences assez importantes.

‍

De plus, la centralisation des données peut rendre la restauration de données complexe si on a besoin de restaurer les données pour un tenant précis.

‍

Gestion en single-database multi-schema

Une alternative possible dans l'implémentation du multi-tenant consiste à attribuer à chaque tenant ses propres tables au sein de la base de données.

Cette approche offre une isolation accrue et la gestion des données s'en retrouve simplifiée. Tout comme pour l'implémentation précédente, la restauration des données reste simple. En adoptant cette approche, on ajoute donc une séparation des données de tenants.

‍

Cependant, cette approche présente également quelques inconvénients.

‍

La nécessité de restaurer un tenant spécifique peut être plus compliquée, car il faut sélectionner individuellement chacune des tables lors du backup ou lors de la restauration.

‍

De plus, à mesure que le nombre de tenants augmente, le nombre de tables associées peut devenir considérable, ce qui risque de compliquer la gestion à long terme.

‍

Si des modifications sont apportées à la structure d'une table, chaque table dupliquée pour chaque tenant doit être mise à jour individuellement.

‍

Cela rend également la gestion des migrations compliquées avec des frameworks comme Laravel ou Symfony puisqu'ils n'ont pas été prévu à cet effet.

‍

Gestion en multi-database

L'utilisation du multi-tenant avec une base de données spécifique par tenant offre plusieurs avantages.

Une simplicité côté développement, où il suffit de spécifier quel tenant est utilisé sans adaptations complexes de packages ou de requêtes SQL. L'implémentation est donc plus rapide et le code plus facile à maintenir.

‍

Pour le backup et la restauration, il suffit de le faire sur la base de données du tenant.

‍

On peut optimiser les performances en ajustant les ressources allouées à chaque tenant en fonction de ses besoins.

‍

C’est également le schéma idéal si dans un projet chaque tenant correspond à un site client et que ces clients souhaitent une confidentialité et isolation de leur données.

‍

Et pour les désavantages de cette implémentation, on peut avoir plus de serveurs ou plus de base de données à maintenir, il faut avoir quelques bases côté infrastructure pour mettre en place et configurer les environnements et le coût d'infrastructure sera plus conséquent.

‍

Conclusion

Chaque architecture a ses avantages et inconvénients, la décision devra se prendre en fonction de vos besoins, de vos coûts, de l’effectif de votre équipe et de nombreux facteurs qui composeront la pérennité de votre projet.

‍

Sur le Framework Laravel, plusieurs packages existent pour gérer le multi-tenant. Si on devait en opposer deux, le package Laravel Multitenancy de Spatie propose une implémentation simple et légère qu’il faudra agrémenter de “Tasks” selon le mode de gestion que vous allez choisir, tandis que le package Tenancy d’ArchtechX propose plutôt une architecture plus complexe qui répond à un maximum de besoins avec plus d'opinion.

‍

Il est primordial de s’intéresser à chacune des solutions existantes et de créer des POCs avant de se lancer tête baissée dans l’implémentation du multi-tenant.

‍

Et vous ? Lequel de ces packages choisiriez-vous ?

‍

Si vous hésitez encore pas de panique ! Nous étudierons sans doute plus en détails les différences dans un prochain article.