Le multi-tenant, un indispensable pour une solution SaaS

Explorez l'importance de l'architecture multi-tenant dans les solutions SaaS. Cet article compare différentes méthodes, leurs avantages et défis, idéal pour les développeurs et décideurs IT intéressés par l'optimisation des services SaaS.

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.

Architecture single-tenant vs multi-tenant

Gestion en single-database

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

Architecture multi-tenant single-database

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.

Architecture multi-tenant multi-schema

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.

Architecture multi-tenant multi-database

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.

Sommaire
Nos autres catégories
Partager sur :
Nos autres catégories
Partager sur :

Ne manquez rien
Abonnez-vous à notre newsletter

Notre newsletter tous les mois :
Je m'abonne
Merci ! C'est dans la boîte :)
Oops! Something went wrong while submitting the form.

Nos experts vous parlent
Le décodeur

L'Architecture hexagonale : Introduction
26/2/2024

Découvrons aujourd’hui l'univers captivant de l'architecture hexagonale. Cette approche du développement d'applications mobiles repose sur des principes fondamentaux, offrant une structure robuste et évolutive. Dans cet article, explorez les bases de l'architecture hexagonale, découvrez des exemples concrets sur GitHub et apprenez à l'intégrer avec Spring Boot. Optimisez votre code, maîtrisez l'inversion des dépendances et transformez votre façon de concevoir des applications mobiles.

Bienvenue dans le futur du développement logiciel !

Qu'est-ce que l'architecture hexagonale ?

L'architecture hexagonale redéfinit la conception des applications mobiles. À la base de cette approche novatrice se trouvent des principes clés, sculptant une structure en forme d'hexagone. Cette méthode se distingue par son agilité, son adaptabilité et son aptitude à créer des applications robustes. Découvrons les fondements de l'architecture hexagonale pour comprendre comment elle redéfinit le développement logiciel.

L'architecture hexagonale transcende les schémas conventionnels de développement logiciel. Imaginons-la comme une vue aérienne de votre application, où un hexagone représente le cœur, le noyau de votre système. Plongeons dans les détails de cette approche novatrice.

Au centre de cette structure, nous trouvons l'hexagone central. C'est le cœur, le noyau où réside la logique métier de votre application. Cet espace défini par l'hexagone représente l'essence même de ce que votre application offre à ses utilisateurs.

Les côtés de l'hexagone représentent les couches périphériques. Chacune de ces couches a un rôle spécifique dans l'interaction de l’application avec le monde extérieur. De la gestion des entrées/sorties à la persistance des données, ces couches entourent le noyau central, mais sans créer de dépendances directes avec lui.

Les interactions entre le cœur et les couches périphériques se font à travers des ports et adaptateurs. Les ports définissent des interfaces au sein du noyau, tandis que les adaptateurs fournissent des implémentations concrètes pour ces interfaces. Cette modularité offre une flexibilité essentielle, permettant à l'application de s'adapter sans altérer sa logique métier.

Enfin, l'inversion des dépendances est le principe qui gouverne l'architecture hexagonale. Plutôt que d'avoir des dépendances directes, le cœur de l'application dépend d'abstractions définies par les ports. Cette inversion crée un environnement flexible permettant des modifications sans impacter la stabilité du système.

Pour comprendre pleinement l'architecture hexagonale, explorons des exemples concrets. 

L'architecture hexagonale ne se contente pas de suivre les sentiers battus du développement logiciel. Imaginez-la comme une vue aérienne de votre application, où un hexagone représente le cœur, le noyau vibrant de votre système. Plongeons dans les détails pour rendre cette approche plus tangible.

Au cœur, l'hexagone central incarne la logique métier de votre application. C'est là que réside l'essence de ce que votre application offre à ses utilisateurs. Autour de ce noyau, les côtés de l'hexagone représentent les couches périphériques. De la gestion des entrées/sorties à la persistance des données, chaque couche a un rôle précis dans l'interaction de l'application avec le monde extérieur.

Exemples concrets

Imaginons une application de gestion de tâches où le cœur de l'hexagone représente la logique de gestion des tâches, des deadlines, etc. Les côtés de l'hexagone pourraient inclure une couche d'interface utilisateur, une couche de persistance des données, et une couche de services externes.

Les interactions entre le cœur et les couches périphériques s'effectuent à travers des ports et adaptateurs. Les ports définissent des interfaces au sein du noyau, tandis que les adaptateurs fournissent des implémentations concrètes pour ces interfaces. Cette modularité offre une flexibilité essentielle, permettant à l'application de s'adapter sans compromettre sa logique métier.

Supposons que le port "GestionTâchesPort" définisse les opérations nécessaires à la gestion des tâches. L'adaptateur "GestionTâchesAdapter" fournirait l'implémentation concrète de ces opérations, interagissant avec la base de données et les services externes.

Enfin, l'inversion des dépendances règne en maître dans l'architecture hexagonale. Plutôt que des dépendances directes, le cœur dépend d'abstractions définies par les ports. Cette inversion crée un environnement souple, permettant des modifications sans secouer la stabilité du système.

Plutôt que d'avoir des dépendances directes vers la base de données, le cœur dépendrait d'interfaces définies dans le port "PersistancePort", laissant les détails d'implémentation à l'adaptateur "PersistanceAdapter".

En résumé, l'architecture hexagonale offre une vision stratégique du développement logiciel. Elle place la logique métier au centre, entourée de couches flexibles facilitant l'interaction avec le monde extérieur. Cette approche, avec son hexagone central et ses principes fondamentaux, ouvre la voie à des applications mobiles robustes, adaptables et pérennes.

Les principes de l'architecture hexagonale

L'architecture hexagonale repose sur des fondements solides, formant une structure en forme d'hexagone pour créer des applications mobiles robustes. Décortiquons les principes clés qui définissent cette approche innovante :

  • L'architecture hexagonale est structurée en couches fondamentales. De la couche d'infrastructure à celle de persistance, chaque strate joue un rôle crucial. Cela offre une organisation claire, favorisant la stabilité et la modularité.
  • Le point d'entrée représente l'accès initial à l'application, tandis que la logique métier dicte son fonctionnement interne. Cette dualité assure une expérience utilisateur fluide, équilibrant l'interaction extérieure avec la logique interne.
  • Fondamentale à l'architecture hexagonale, l'inversion des dépendances renverse les schémas traditionnels. Cette approche permet à l'application de s'adapter aux changements sans compromettre sa stabilité. Elle crée un environnement où la logique métier guide les détails d'implémentation.

Mise en pratique de l'architecture hexagonale

Découvrons comment concrètement mettre en œuvre l'architecture hexagonale dans le développement d'applications mobiles. Plongeons dans des exemples tangibles pour comprendre son impact réel.

Explorez un exemple concret sur GitHub où le code source d'une application est dévoilé. Chaque composant, de la couche d'infrastructure à la couche de persistance, est clairement défini. Visualisez comment ces éléments s'entremêlent pour former une structure cohérente. Cette transparence simplifie le processus de développement, permettant une compréhension facile et une évolution efficace de l'application.

L'intégration pratique de l'architecture hexagonale est facilitée avec Spring Boot. Cette union offre une approche concrète pour développer des applications mobiles robustes. Elle simplifie la gestion des dépendances et maintient la flexibilité, permettant aux développeurs de se concentrer sur la création plutôt que sur des considérations techniques. 

L'architecture hexagonale dans le contexte du Domain-Driven Design

Plongeons dans la synergie puissante entre l'architecture hexagonale et les principes du Domain-Driven Design (DDD), développant ainsi des applications mobiles de plus grande qualité.

L'architecture hexagonale et le Domain-Driven Design (DDD) fusionnent harmonieusement pour définir des modèles de domaine robustes offrant ainsi une approche complète du développement logiciel.

Lorsque nous plongeons l'architecture hexagonale dans le contexte du Domain-Driven Design (DDD), une collaboration symbiotique émerge. Ces deux approches, axées sur la compréhension profonde du domaine métier, se renforcent mutuellement.

1. Collaboration Harmonieuse

Imaginons une application de commerce électronique. Dans l'architecture hexagonale, le cœur de l'hexagone représente la gestion des commandes, des transactions, et des stocks, constituant la logique métier centrale. Dans le contexte du DDD, ces entités deviennent les agrégats du domaine, chacun avec son propre cycle de vie et ses règles métier spécifiques. Ainsi, l'hexagone central et les agrégats du DDD collaborent harmonieusement pour façonner le modèle de domaine.

2. Réflexion sur le Contexte Limité

Poursuivons avec la réflexion sur le contexte limité du DDD. Supposons que notre application de commerce électronique ait également un module de gestion des utilisateurs. Dans l'architecture hexagonale, cela devient une autre zone centrale, avec ses propres ports et adaptateurs. Dans le contexte limité du DDD, ce module représente son propre sous-domaine avec ses règles métier distinctes. Cette approche permet une séparation claire des préoccupations et une meilleure compréhension du modèle de domaine, alignant ainsi l'architecture hexagonale avec les principes du DDD.

3. Alistair Cockburn et les Fondements

Alistair Cockburn, un pionnier du Domain-Driven Design, souligne l'importance de définir des interactions précises entre les entités du domaine. Dans l'architecture hexagonale, cela se traduit par la définition précise des ports et adaptateurs, offrant une interface bien définie pour chaque interaction. Cette synchronicité entre les principes de Cockburn et l'architecture hexagonale garantit une compréhension approfondie du domaine et une mise en œuvre logicielle qui reflète fidèlement la réalité métier.

L'architecture hexagonale et le Domain-Driven Design forment une alliance puissante. En utilisant des exemples concrets, nous avons vu comment ces approches complémentaires collaborent pour créer des modèles de domaine clairs, des contextes limités bien définis, et des applications mobiles riches en fonctionnalités métier.

Nos conseils pratiques et astuces

Explorez des conseils concrets et des astuces judicieuses pour optimiser l'utilisation de l'architecture hexagonale dans le développement d'applications mobiles.

Dans la mise en œuvre de l'architecture hexagonale, privilégiez la clarté. Des noms de classes explicites aux commentaires informatifs, assurez-vous que chaque composant de votre application est compréhensible. La transparence facilite la collaboration et la maintenance à long terme.

Investissez dans des tests unitaires approfondis. L'architecture hexagonale favorise la testabilité, alors profitez-en. Des tests solides garantissent la stabilité de votre application et facilitent l'identification rapide des problèmes potentiels.

Accompagnez votre code d'une documentation complète. Décrivez les choix architecturaux, les interactions clés, et les modèles de domaine. Une documentation détaillée facilite l'intégration de nouveaux membres dans l'équipe et assure une compréhension globale du projet.

Soyez sélectif quant aux dépendances. Limitez-vous aux dépendances nécessaires pour éviter la complexité inutile. Une architecture hexagonale bien conçue privilégie la simplicité, ce qui facilite la maintenance et l'évolutivité.

Adoptez une approche itérative. L'itération continue associée au réajustement est essentielle. Recueillez les retours, identifiez les améliorations possibles, et évoluez constamment. Cette approche flexible s'aligne parfaitement avec les principes de l'architecture hexagonale.

L'architecture hexagonale se révèle comme une approche incontournable pour le développement d'applications mobiles. Avec ses principes solides, sa mise en pratique transparente, et sa synergie avec le Domain-Driven Design, elle offre une solution robuste et flexible.

Priorisez la clarté, investissez dans des tests unitaires approfondis, documentez judicieusement, évitez les dépendances superflues, et adoptez une approche itérative pour un succès continu.

En embrassant l'architecture hexagonale, vous développez des applications mobiles plus résilientes et créez une base pour l'innovation future. Restez agile, apprenez constamment, et évoluez avec votre application.

L'architecture hexagone est le socle sur lequel repose l'avenir du développement logiciel mobile.

Laravel vs Symfony : quel Framework choisir ? Le guide
4/12/2023

Bienvenue dans l'univers du développement web, où chaque choix compte. Laravel et Symfony, deux géants du langage serveur PHP, se disputent la première place. Dans cet article, nous plongeons dans les détails, examinant performances, sécurité, et courbes d'apprentissage.

Prêts à choisir le Framework idéal pour votre projet ? 

Laravel et Symfony : Les titans du développement PHP

Dans l'arène du développement serveur PHP, deux titans émergent : Laravel et Symfony.

Laravel, créé par Taylor Otwell, séduit par son architecture élégante basée sur le modèle MVC (pour Modèle-Vue-Contrôleur), ses outils puissants, et une courbe d'apprentissage conviviale.

De l'autre côté, Symfony, de SensioLabs, brille par sa modularité et des composants réutilisables. Avant de choisir votre champion, explorons en détail ce que chaque Framework peut vous offrir.

Laravel

Laravel est un Framework PHP qui a su captiver la communauté des développeurs. Imaginé par le développeur américain, Taylor Otwell, Laravel séduit par son architecture claire et élégante, basée sur le modèle architectural MVC. Cette structure facilite la conception d’applications et le développement en offrant une séparation nette entre les composants d’un projet.

Laravel ne fait pas que promettre, il délivre des performances remarquables. Les temps de réponse sont optimisés pour offrir une expérience utilisateur plus fluide. La gestion intelligente des bases de données et les outils intégrés font de Laravel un choix judicieux pour des applications performantes.

Dans le monde numérique d'aujourd'hui, la sécurité est primordiale. Pour cela, Laravel intègre des systèmes robustes garantissant la protection à long terme de vos applications web modernes. Des mécanismes de sécurité avancés sont mis en place pour contrer les menaces potentielles.

La courbe d'apprentissage est souvent un obstacle, mais pas avec Laravel. Son approche conviviale permet aux développeurs de rapidement maîtriser le Framework. La documentation détaillée et la communauté active font de l'apprentissage une expérience fluide.

Exemple de code concret : Gestion des utilisateurs avec Laravel

Une image contenant texte, capture d’écran, logiciel, multimédiaDescription générée automatiquement

  • Laraval utilise l’ORM (pour Object Relational Model) Eloquent pour simplifier les opérations d’interactions avec la base de données.
  • La fonction bcrypt () sécurise le mot de passe avant son enregistrement.
  • La réponse est renvoyée au format JSON.

Laravel est votre allié dans la création d'applications web dynamiques et performantes.

Symfony

L’univers du Framework PHP Symfony est tout aussi passionnant. Renommé, riche et modulaire, Symfony est développé et maintenu par la société française SensioLabs. Symfony se démarque par son approche modulaire et ses composants réutilisables, offrant une flexibilité remarquable dans la conception d’application web.

Symfony ne se contente pas d'une architecture flexible, il excelle également en matière de performances. Les temps de réponse compétitifs et la gestion efficace des ressources font de Symfony un choix judicieux pour réaliser des applications PHP performantes.

La sécurité étant une priorité dans le paysage numérique actuel, Symfony intègre des mécanismes de sécurité assurant la protection de vos applications contre les menaces. La courbe d'apprentissage de Symfony est également conçue pour faciliter l'adoption du Framework. Les développeurs bénéficient d'une documentation exhaustive et d'une communauté active, simplifiant ainsi l'exploration des fonctionnalités avancées de Symfony.

Exemple de code concret : gestion des utilisateurs avec Symfony

Une image contenant texte, capture d’écranDescription générée automatiquement

  • Symfony utilise l’ORM Doctrine ainsi que les méthodes setName(), setEmail(), et setPassword() pour définir les propriétés de l'objet utilisateur.
  • Le mot de passe est sécurisé à l’aide de password_hash().
  • La méthode flush() persiste les changements en base de données.
  • La réponse est renvoyée au format JSON.

En somme, Symfony est un partenaire fiable pour le développement web.

Comparaison directe

Plongeons dans la comparaison directe entre Laravel et Symfony, examinant de près les éléments clés qui pourraient influencer votre décision dans le choix du Framework PHP idéal.

Performance : la quête de la réactivité

La performance est cruciale pour une expérience utilisateur optimale. Nous comparons les temps de réponse de Laravel et Symfony pour vous aider à choisir le Framework qui offre la réactivité nécessaire à votre projet.

  • Temps de Réponse : Laravel excelle avec des temps de réponse moyens de 250 millisecondes, offrant une expérience utilisateur rapide. Symfony, bien que compétitif, tend à se situer légèrement au-dessus, aux alentours de 300 millisecondes.
  • Exemple : Un site e-commerce nécessitant une navigation rapide pourrait bénéficier des performances de Laravel, assurant une réponse quasi-instantanée lors de la recherche de produits.

Architecture : MVC sous le microscope

L'architecture MVC (Modèle-Vue-Contrôleur) est le pilier du développement web moderne. Analysons comment Laravel et Symfony abordent cette structure fondamentale et en quoi cela peut impacter la gestion de votre code.

  • Laravel : Son modèle MVC clair offre une structure fluide. Les développeurs peuvent facilement segmenter les responsabilités, améliorant la maintenabilité du code.
  • Symfony : Une approche modulaire permettant une personnalisation avancée. Les composants réutilisables simplifient le développement, mais cela peut entraîner une complexité accrue pour les petits projets.
  • Exemple : Un projet nécessitant une structure claire et simple pourrait préférer Laravel, tandis qu'un système complexe pourrait tirer parti de la modularité de Symfony.

Command Line Interface (CLI) : L'art de la ligne de commande

La ligne de commande est l'alliée du développeur moderne. Comparons comment Laravel et Symfony s'engagent dans le royaume de l'interface en ligne de commande (CLI), facilitant ainsi le flux de travail du développeur.

  • Laravel : La CLI de Laravel simplifie les tâches courantes telles que la génération de code, facilitant le flux de travail du développeur.
  • Symfony : Une CLI robuste, mais avec une courbe d'apprentissage plus prononcée. Elle offre une personnalisation avancée, mais peut sembler complexe pour les débutants.
  • Exemple : Pour un développeur qui privilégie la simplicité et la rapidité, la CLI de Laravel serait un choix naturel.

Migration de base de données : Gestion intelligente des données

La migration efficace de la base de données est un défi incontournable. Jetons un regard attentif sur la manière dont Laravel et Symfony simplifient ce processus critique pour garantir une gestion fluide des données.

  • Laravel : Les migrations simplifient les changements de schéma de base de données. Les développeurs peuvent versionner et partager ces modifications facilement.
  • Symfony : Des migrations intégrées offrant également une gestion efficace des changements de base de données. Les bundles Symfony facilitent la modularité.
  • Exemple : Un projet nécessitant des mises à jour fréquentes de la base de données pourrait bénéficier de la simplicité des migrations de Laravel.

N’hésitez pas à plonger davantage dans ces détails pour faire un choix éclairé entre Laravel et Symfony, en alignant les forces de chaque Framework avec les exigences spécifiques de votre projet.

Frameworks PHP : Un choix déterminant pour le développement web

Explorez l'impact déterminant que le choix entre Laravel et Symfony peut avoir sur votre projet de développement web.

Choisir le bon Framework : un dilemme crucial

La sélection du bon Framework PHP est un dilemme majeur, influençant directement la réussite de votre projet. Laravel et Symfony offrent des avantages uniques, mais lequel répond le mieux à vos besoins spécifiques ?

  • Laravel : Excellant dans la simplicité et la rapidité de développement, Laravel est souvent le choix préféré pour les projets de taille moyenne nécessitant une mise en œuvre rapide.
  • Symfony : Connu pour sa modularité et ses composants réutilisables, Symfony brille dans des projets plus complexes où la personnalisation et la réutilisation de code sont essentielles.
  • Exemple : Un site vitrine pour une petite entreprise pourrait privilégier la simplicité de Laravel, tandis qu'un système de gestion complexe opterait probablement pour la modularité de Symfony.

Forces et faiblesses : un examen critique

Chacun des Frameworks a ses points forts et ses faiblesses. Examinons en détail les avantages et les limitations de Laravel et Symfony pour vous guider dans cette décision cruciale.

  • Laravel : Points forts dans la simplicité, la documentation claire et la courbe d'apprentissage conviviale. Cependant, sa modularité peut être moins flexible pour des projets très spécifiques.
  • Symfony : Excellant dans la modularité, Symfony offre une flexibilité maximale, mais sa courbe d'apprentissage peut être plus abrupte pour les débutants.
  • Exemple : Un projet nécessitant des fonctionnalités spécifiques pourrait bénéficier de la flexibilité de Symfony, tandis qu'un projet plus simple pourrait opter pour la simplicité de Laravel.

Taille du projet : l'importance du contexte

La taille de votre projet est un facteur déterminant. Nous évaluons comment Laravel et Symfony s'adaptent aux projets de différentes envergures, vous permettant ainsi de choisir en fonction de vos besoins spécifiques.

  • Laravel : Idéal pour des projets de taille moyenne, où la rapidité de développement est cruciale.
  • Symfony : Convient particulièrement aux projets de grande envergure, offrant la modularité nécessaire pour gérer la complexité.
  • Exemple : Un blog personnel pourrait tirer parti de la simplicité de Laravel, tandis qu'un système de gestion d'entreprise complexe pourrait profiter de la robustesse de Symfony.

Performance attendue : Une réflexion essentielle

Quelles performances attendez-vous de votre application web ? Laravel et Symfony offrent des approches différentes. Décortiquons ces approches pour vous aider à prendre une décision éclairée.

  • Laravel : Performances élevées pour des projets de taille moyenne, avec des temps de réponse compétitifs.
  • Symfony : Excellentes performances également, mais peut être plus adapté à des projets plus vastes.
  • Exemple : Un site de portfolio artistique pourrait privilégier les performances de Laravel, tandis qu'un site e-commerce à fort trafic pourrait opter pour Symfony.

Préférences des développeurs : Un facteur humain

L'adhésion des développeurs à un Framework peut être un critère déterminant. Découvrez comment Laravel et Symfony sont perçus dans la communauté des développeurs, un aspect clé pour le succès à long terme de votre projet.

  • Laravel : Apprécié pour sa simplicité et son approche élégante, attirant souvent les développeurs cherchant une courbe d'apprentissage plus douce.
  • Symfony : Adopté par des développeurs expérimentés cherchant une modularité étendue et une personnalisation avancée.
  • Exemple : Une équipe de jeunes développeurs débutants pourrait se sentir à l'aise avec la simplicité de Laravel, tandis qu'une équipe expérimentée pourrait être attirée par la puissance de Symfony.

Après avoir exploré les nuances de Laravel et Symfony, il est temps de conclure. Chaque projet a des besoins uniques, et votre décision devrait être ancrée dans une évaluation minutieuse des forces et des faiblesses de chaque Framework.

En conclusion, gardez un œil sur l'horizon du développement web. Les Frameworks évoluent, les tendances changent. Votre choix devrait également être orienté vers l'avenir, en tenant compte des mises à jour futures, de la communauté active et des innovations à venir.

Votre choix entre Laravel et Symfony déterminera la trajectoire de votre projet. Explorez les possibilités infinies offertes par ces Frameworks PHP et prenez votre décision en connaissance de cause. Votre aventure de développement web commence ici. Bonne exploration !

Test Driven Development (TDD) : Guide pour un Développement Efficace
21/9/2023

L'origine


Le Test-Driven Development plus communément appelé TDD n'a pas été inventé par une seule personne mais par plusieurs développeurs. Kent Beck est souvent la personne la plus affiliée au TDD parce qu'il est celui qui l'a popularisé lors de ses travaux sur la méthodologie Extreme Programming à la fin des années 90. Néanmoins il est important de rappeler qu'il n'est pas le créateur de l'outil qu'est le TDD, il a été mis en place pour tout un tas de personne, dont notamment Martin Fowler (co-auteur du Manifeste Agile) ou encore Ward Cunningham et Ron Jeffries qui ont fondé l'Extreme Programming avec Kent Beck.


Un outil de travail


L'outil


Le TDD est un outil de travail qui permet au développeur de coder en étant guidé par les tests. Il permet d'avancer étape par étape, petit pas par petit pas, pour avancer vers une solution toujours plus fiable.


Cette solution plus fiable est notamment due à sa forte proximité avec les principes SOLID. En effet, le TDD facilite la mise en place des principes SOLID. En écrivant d'abord des tests, il est plus naturel de concevoir un code simple et cohérent qui respecte les principes tels que l'encapsulation, le découplage, la gestion des dépendances et la séparation des responsabilités. On se retrouve plus naturellement avec des modules indépendants et l'injection de dépendances, ce qui conduit à du code plus propre.


Le TDD et les principes SOLID vont donc de pair pour une conception logicielle de qualité.



  1. Nous avons une première phase (rouge sur le schéma) où nous devons écrire un test qui échoue, basé sur une spécification. NB : on n'écrit pas de code de production (code final) tant que le test n'est pas en échec.
  2. La deuxième phase (verte sur le schéma) consiste à faire passer le test en succès en écrivant du code de production et tout en restant le plus simple possible. NB : on écrit uniquement le code nécessaire pour faire passer le test et sans retourner dans le code du test.
  3. La dernière phase (bleue sur le schéma) concerne le refactoring. On met à jour le code en appliquant les bonnes pratiques, le clean code, etc. Une fois que le refactoring est fait, si les tests passent toujours, on conserve le refactor et on passe aux prochaines spécifications, sinon, on annule le refactor et on essaye autre chose. NB : ne doit jamais effectuer de refactoring dans les autres phases, seulement ici.


L'approche TDD est un développement itératif et incremental qui met l'accent sur la qualité du code.


Le manifeste


Le TDD respecte certains principes qui sont :


  • Baby steps instead of large-scale changes

On avance petit pas par petit pas pour avoir une boucle de feedback rapide et régulière.


  • Continuous refactoring instead of late quality improvements

On améliore le code en continue, on s'en occupe tout de suite parce qu'un refactor annoncé pour plus tard n'arrive finalement en général jamais.


  • Evolutionary design instead of big design up front

On développe ce qui est nécessaire et suffisant et on évolue progressivement.


  • Executable documentation instead of static documents

Les tests mis en place pendant le TDD sont en réalité une documentation executable. L'idée est de lier la documentation avec le code pour s'assurer qu'elle est bien à jour et maintenue.


  • Minimalist code instead of gold-plated solution

Un code simple et qui fonctionne plutôt qu'une solution surdimensionnées avec un niveau de complexité bien trop élevé et pas nécessaire.




Le test propre

Given When Then


L'approche Given When Then est basée sur une convention développée dans le cadre du Behaviour-Driven Development autrement appelé BDD. Il s'agit d'une approche de développement axée sur la collaboration et la spécification du comportement à travers ds scénarios clairs et compréhensibles.


En utilisant cette convention on divise le test en trois parties :

  1. Given, la condition préalable au test
  2. When, l'exécution du système testé
  3. Then, le comportement attendu


Exemple : Given user is not logged in When user logs in Then user is logged in successfully


Should When


L'approche Should When est une convention de nommage facile à lire et plus largement utilisée.


En utilisant cette convention on divise le test en deux parties :

  1. When, la condition préalable au test
  2. Should, le comportement attendu


Exemple : Should have user logged in When user logs in


Arrange Act Assert


Le modèle Arrange Act Assert autrement appelé AAA est un pattern descriptif et révélateur des intentions pour structurer le test.


Le test est alors organisé de la manière suivante :

  1. La partie Arrange contient la logique de configuration du test. C'est ici qu'on initialise le test.
  2. La partie Act execute le système que l'on souhaite tester. C'est ici qu'on fait l'appel d'une fonction, d'un composant, d'un call API, etc.
  3. La partie Assert, vérifie que le système testé se comporte comme prévu. C'est ici qu'on vérifie que le résultat obtenu correspond au résultat attendu.


Exemple :




F.I.R.S.T.


Le principe F.I.R.S.T. est un ensemble de principes qui définissent les caractéristiques d'un test propre et de qualité.


Ces caractéristiques sont les suivantes :

  • Fast, un test doit être rapide et efficace de manière à pouvoir être exécuté fréquemment pour avoir un feedback régulier
  • Independent, les tests doivent être indépendants les uns des autres afin d'être exécutable individuellement et efficacement
  • Repeatable, un test doit être répétable dans n'importe quel environnement et à tout moment
  • Self-Validating, les tests doivent retourner un succès ou un échec afin de vérifier lui même si l'exécution du test a réussi ou échoué sans évaluation manuelle
  • Timely, les tests doivent être écrit avant ou en même temps que le code de production. ils doivent être maintenus et exécutés régulièrement


Quand l'utiliser ?


Quand ne pas l'utiliser plutôt !


Il n'est pas nécessaire et pas utile de faire du TDD quand on a pas de spécifications, quand les tests n'apportent rien, quand les tests sont trop lents, quand il n'y a pas de logique.


La démo


L'incontournable Fizz Buzz


Le Fizz Buzz est un exercice populaire qui permet d'appréhender la méthode TDD. Ce n'est qu'un échantillon et qu'un début de la méthode, mais ça reste intéressant.


Les spécifications sont les suivantes :

  • On commence à compter à partir de 1 jusqu'à 100
  • Lorsqu'on rencontre un nombre divisible par 3, on retourne "Fizz"
  • Lorsqu'on rencontre un nombre divisible par 5, on retourne "Buzz"
  • Lorsqu'on rencontre un nombre divisible par 3 et par 5, on retourne "Fizz-Buzz"


Nous allons utiliser le TypeScript pour mettre en place cet algorithme et le tester.


Première spécification


On créé un fichier test fizz-buzz.test.ts et on créé notre premier test qui va gérer la spécification où on teste le nombre 1.





Ici, le test ne passe pas parce qu'on a pas encore créé la fonction fizzBuzz() et encore moins l'algorithme associé. Nous sommes donc à la première phase du TDD, la phase rouge, celle où on écrit un test qui échoue.


On va maintenant passer à la deuxième phase du TDD, celle où on va faire passer le test au vert. Pour cela, on va créer le fichier fizz-buzz.ts et écrire le code permettant de gérer notre cas de spécification.




Ici, on pourrait avoir tendance à faire un return String(n) directement, mais TDD nous dit de commence par écrire le code le plus simple possible pour faire passer le test au vert, et en réalité le plus simple et rapide et de tout simplement retourner 1 directement.


On va passer au prochain test qui est de tester l'input 2.



Le test échoue parce qu'on a pas encore géré ce cas dans notre fonction. On retourne donc dans notre fonction et on essaye de résoudre ce cas de la manière la plus simple et rapide.




Ici, encore une fois, le plus rapide est de retourner 2 si on a 2 en input.


Maintenant on arrive à la troisième et dernière phase du TDD, celle du refactor. En effet, actuellement nos tests passent avec succès, le code est simple, mais il pourrait l'être encore plus en appliquant de bonnes pratiques.


On va donc revenir sur notre fonction fizzBuzz() sans modifier les tests.




Notre fonction est maintenant simple, propre et concise et les tests sont toujours verts. Notre refactor est donc réussit, on peut passer à la prochaine spécification.


Deuxième spécification


Nous devons maintenant faire en sorte de retourner Fizz si l'input est divisible par 3.



Le test échoue, on va maintenant gérer le cas du Fizz dans la fonction.




Le code le plus simple pour retourner  Fizz quand on a 3 et de tester si n === 3.


On va maintenant gérer un deuxième cas où on a un nombre divisible par 3.




Le test échoue, on met à jour le code.




Le code le plus simple pour retourner Fizzquand on a 3 ou 6 et de faire un ||, mais on se rend bien compte qu'on peut améliorer le code en utilisant le modulo de 3. Les tests sont tous verts, donc on peut se permettre de passer à la phase de refactor en modifiant uniquement le code de la production.



Refactor terminé, tous les tests sont verts, on peut passer à la prochaine spécification.


Troisième spécification


Nous devons maintenant faire en sorte de retourner Buzz si l'input est divisible par 5.


On va aller un peu plus vite, mais le procédé est le même, on va d'abord faire un test avec un input 5 puis 10, puis refactor.




Dernière spécification


Nous devons maintenant faire en sorte de retourner Fizz-Buzz si l'input est divisible par 3 et par 5.


Comme pour les spécifications précédentes, on va faire un test avec un input 15 puis 30 et enfin refactor.


Et voilà !


Le mot de la fin


Stop aux amalgames ! Le TDD n'est pas un outil pour avoir une bonne couverture de code avec les tests, ce n'est pas simplement "faire des tests". Le TDD est un outil dont le but est de guider le développeur vers un objectif. Il permet de donner un feedback régulier afin de s'assurer qu'on est toujours sur la bonne voie. Il faut le voir comme un GPS, qui nous donne des directions à suivre (tourner à droite, aller tout droit pendant 2km, etc.) jusqu'à atteindre un objectif.


Les dédicaces


Échangeons sur votre projet !

Développement web
Application mobile
Design & Product
Nous contacter

Simulateur

Bienvenue dans le
simulateur d’estimation

Sélectionnez
vos besoins

Sélectionnez un ou plusieurs choix

Définissez les
fonctionnalités

Sélectionnez un ou plusieurs choix

Dernière
étape !

Renseignez votre adresse mail pour recevoir l’estimation !
Obtenez l’estimation
Précédent
Suivant

Bravo ! Vous avez terminé
l’estimation de votre future app !

Vous recevrez dans votre boite mail l’estimation personnalisé. Une estimation vous offre la possibilité de vous projeter dans un budget, vous permettant ainsi de planifier en toute confiance. Néanmoins, chez Yield, nous adoptons une approche agile, prêts à remettre en question et ajuster nos évaluations en fonction de l'évolution de vos besoins et des spécificités de votre projet.
Retour au site
Oops! Something went wrong while submitting the form.