Ce guide explique comment j'ai rationalisé le traitement des demandes, des validations et des réponses dans mes microservices Go, en visant la simplicité, la réutilisabilité et une base de code plus maintenable.
Je travaille avec des microservices dans Go depuis un certain temps et j'apprécie toujours la clarté et la simplicité qu'offre ce langage. L’une des choses que j’aime le plus chez Go, c’est que rien ne se passe en coulisses ; le code est toujours transparent et prévisible.
Cependant, certaines parties du développement peuvent être assez fastidieuses, notamment lorsqu'il s'agit de valider et de standardiser les réponses dans les points de terminaison de l'API. J'ai essayé de nombreuses approches différentes pour résoudre ce problème, mais récemment, en écrivant mon cours Go, j'ai eu une idée plutôt inattendue. Cette idée a ajouté une touche de « magie » à mes gestionnaires et, à ma grande surprise, elle m'a plu. Avec cette solution, j'ai pu centraliser toute la logique de validation, de décodage et d'analyse des paramètres des requêtes, ainsi qu'unifier l'encodage et les réponses des API. En fin de compte, j'ai trouvé un équilibre entre maintenir la clarté du code et réduire les implémentations répétitives.
Lors du développement de microservices Go, une tâche courante consiste à gérer efficacement les requêtes HTTP entrantes. Ce processus implique généralement l'analyse des corps de requête, l'extraction des paramètres, la validation des données et le renvoi de réponses cohérentes. Permettez-moi d'illustrer le problème avec un exemple :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 |
|
Laissez-moi vous expliquer le code ci-dessus, en me concentrant sur la partie gestionnaire où nous traitons manuellement :
Bien que le code soit fonctionnel, il implique une quantité importante de logique standard qui doit être répétée pour chaque nouveau point de terminaison, ce qui le rend plus difficile à maintenir et sujet aux incohérences.
Alors, comment pouvons-nous améliorer cela ?
Pour résoudre ce problème et améliorer la maintenabilité du code, j'ai décidé de diviser la logique en trois couches distinctes : Requête, Réponse et Validation. Cette approche encapsule la logique de chaque partie, la rendant réutilisable et plus facile à tester indépendamment.
La couche Request est responsable de l'analyse et de l'extraction des données des requêtes HTTP entrantes. En isolant cette logique, nous pouvons standardiser la façon dont les données sont traitées et garantir que toute l'analyse est traitée de manière uniforme.
La couche Validation se concentre uniquement sur la validation des données analysées selon des règles prédéfinies. Cela sépare la logique de validation de la gestion des demandes, la rendant plus maintenable et réutilisable sur différents points de terminaison.
La couche Réponse gère la construction et le formatage des réponses. En centralisant la logique de réponse, nous pouvons garantir que toutes les réponses de l'API suivent une structure cohérente, simplifiant ainsi le débogage et améliorant les interactions avec les clients.
Donc… Bien que diviser le code en couches offre des avantages tels que la réutilisabilité, la testabilité et la maintenabilité, cela comporte certains compromis. Une complexité accrue peut rendre la structure du projet plus difficile à comprendre pour les nouveaux développeurs, et pour des points de terminaison simples, l'utilisation de couches séparées peut sembler excessive, conduisant potentiellement à une ingénierie excessive. Comprendre ces avantages et inconvénients aide à décider quand appliquer ce modèle efficacement.
En fin de compte, il s’agit toujours de ce qui vous dérange le plus. Droite? Alors maintenant, mettons un peu de main dans notre ancien code et commençons à implémenter les couches mentionnées ci-dessus.
Tout d'abord, nous refactorisons le code pour encapsuler l'analyse des requêtes dans une fonction ou un module dédié. Cette couche se concentre uniquement sur la lecture et l'analyse du corps de la demande, garantissant qu'il est découplé des autres responsabilités du gestionnaire.
Créer un nouveau fichier httpsuite/request.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 |
|
Remarque : À ce stade, j'ai dû utiliser la réflexion. Je suis probablement trop stupide pour trouver une meilleure attente, faites-le. ?
Bien sûr, pour que nous puissions également tester cela, créez le fichier de test httpsuite/request_test.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
|
Comme vous pouvez le constater, la couche Demande utilise la couche Validation. Cependant, je souhaite toujours garder les couches séparées dans le code, non seulement pour faciliter la maintenance, mais parce que je souhaiterai peut-être également utiliser la couche de validation isolée.
En fonction des besoins, à l'avenir, je pourrai décider de garder toutes les couches isolées et de permettre sa co-dépendance en utilisant certaines interfaces.
Une fois l'analyse de la requête séparée, nous créons une fonction ou un module de validation autonome qui gère la logique de validation. En isolant cette logique, nous pouvons facilement la tester et appliquer des règles de validation cohérentes sur plusieurs points de terminaison.
Pour cela, créons le fichier httpsuite/validation.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 |
|
Maintenant, créez le fichier de test httpsuite/validation_test.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 |
|
Enfin, nous refactorisons la construction de la réponse dans un module séparé. Cela garantit que toutes les réponses suivent un format cohérent, ce qui simplifie la gestion et le débogage des réponses dans toute l'application.
Créez le fichier httpsuite/response.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 |
|
Créez le fichier de test httpsuite/response_test.go :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
Chaque étape de cette refactorisation nous permet de simplifier la logique du gestionnaire en déléguant des responsabilités spécifiques à des couches bien définies. Bien que je ne montrerai pas le code complet à chaque étape, ces modifications impliquent le déplacement de la logique d'analyse, de validation et de réponse dans leurs fonctions ou fichiers respectifs.
Maintenant, ce dont nous avons besoin, c'est de changer l'ancien code pour utiliser les calques et voyons à quoi cela ressemblera.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 |
|
En refactorisant le code du gestionnaire en couches pour l'analyse des requêtes, la validation et le formatage des réponses, nous avons réussi à supprimer la logique répétitive qui était auparavant intégrée dans le gestionnaire lui-même. Cette approche modulaire améliore non seulement la lisibilité, mais améliore également la maintenabilité et la testabilité en gardant chaque responsabilité ciblée et réutilisable. Le gestionnaire étant désormais simplifié, les développeurs peuvent facilement comprendre et modifier des couches spécifiques sans affecter l'ensemble du flux, créant ainsi une base de code plus propre et plus évolutive.
J'espère que ce guide étape par étape sur la structuration de vos microservices Go avec des couches de requête, de validation et de réponse dédiées vous a donné un aperçu de la création d'un code plus propre et plus maintenable. J’aimerais connaître votre avis sur cette approche. Est-ce que j'ai raté quelque chose d'important ? Comment étendriez-vous ou amélioreriez-vous cette idée dans vos propres projets ?
Je vous encourage à explorer le code source et à utiliser httpsuite directement dans vos projets. Vous pouvez trouver la bibliothèque dans le référentiel rluders/httpsuite. Vos commentaires et contributions seraient inestimables pour rendre cette bibliothèque encore plus robuste et utile pour la communauté Go.
À bientôt dans le prochain.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!