Qu'est-ce que le middleware? Définition et exemples de cas d'utilisation

L'intergiciel est un terme couramment utilisé dans le développement Web. Cela peut signifier beaucoup de choses selon le contexte, ce qui rend le terme un peu déroutant.

Dans cet article, nous commencerons par définir le terme, puis continuerons avec une discussion sur différents cas d'utilisation.

Après avoir lu cet article, vous pourrez vous impliquer davantage dans les conversations techniques et architecturales avec vos pairs. Vous serez également plus capable de concevoir des API et des flux de données sécurisés et fiables.

Définition du middleware

L'intergiciel est un logiciel qui sert d'intermédiaire entre deux applications ou services pour faciliter leur communication.

Vous pouvez le considérer comme un proxy qui peut agir comme un accumulateur de données, un traducteur ou simplement un proxy qui transmet les requêtes.

Cas d'utilisation courants du middleware

1) Traducteur

Il existe de nombreux formats d'échange de données, tels que JSON, XML et Protobuf. Même si nous utilisons principalement JSON de nos jours, chacun d'entre eux a ses propres cas d'utilisation.

Par exemple, les protobuffers sont connus pour être plus performants que JSON, mais ils ne sont pas lisibles par l'homme. Vous pouvez donc utiliser des protobuffers pour les services internes et vous pouvez utiliser JSON lorsque le consommateur d'API est un navigateur.

Vous pouvez également consulter mon article sur les protobuffers si vous souhaitez en savoir plus à leur sujet.

Disons maintenant que nous avons besoin de ces deux services, qui parlent des protocoles différents, pour communiquer entre eux.

Nous pouvons créer un middleware qui utilise une bibliothèque de conversion de données et traduit les demandes dans un format que le service récepteur peut comprendre.

2) Accumulation-duplication de données

L'architecture de microservice est un modèle architectural populaire qui est couramment appliqué dans les applications modernes.

Si vous n'êtes pas familier avec l'architecture des microservices, cela signifie essentiellement que votre application se compose de nombreuses petites applications ou services indépendants les uns des autres et fonctionnant ensemble en communiquant sur Internet.

Par exemple, dans un projet de commerce électronique, vous pouvez avoir un microservice pour stocker et récupérer des produits, un autre microservice pour la recherche et un autre pour l'authentification et le stockage des utilisateurs. Et chacun a sa propre base de données.

Disons maintenant que nous voulons implémenter notre recherche de manière à ce qu'elle recherche à la fois les utilisateurs et les produits.

S'il s'agissait d'une application monolithique, nous pourrions simplement écrire une requête pour rechercher chaque table et joindre les résultats. Mais maintenant, nos bases de données fonctionnent sur différents serveurs.

Ce problème a plusieurs solutions, et nous en examinerons deux.

Accumuler des données

Nous pouvons utiliser un middleware pour envoyer des requêtes aux deux serveurs et leur demander de rechercher dans leurs bases de données des noms d'utilisateur et des produits qui correspondent au mot recherché.

Ensuite, nous pouvons accumuler les résultats des deux serveurs et les renvoyer au client. Notez que le nombre de requêtes augmente linéairement à mesure que nous augmentons le nombre de serveurs (et nous devons également fusionner ces données).

Dupliquer des données

Nous pouvons stocker des données en double dans notre serveur de recherche afin qu'il puisse les rechercher directement au lieu de demander aux serveurs de produits et d'utilisateurs. C'est moins efficace en termes de mémoire mais beaucoup plus rapide - et la vitesse est essentielle pour les services de recherche.

Si les tables dont nous avons besoin sont Produit et Utilisateur, nous pouvons également créer ces tables dans notre serveur de recherche. Ensuite, chaque fois que nous enregistrons un nouvel utilisateur dans notre base de données d'utilisateurs, nous en enregistrerons également une copie dans le serveur de recherche.

Nous avons quelques options: premièrement, nous pouvons appeler les méthodes de sauvegarde du serveur de recherche à partir des méthodes de sauvegarde des serveurs User et Product pour dupliquer les données. Ou nous pouvons créer un middleware pour l'enregistrement, qui fera ce qui suit:

  • Chaque fois qu'une demande de sauvegarde arrive, appelez la sauvegarde du serveur Produit / Utilisateur et la sauvegarde du serveur de recherche.
  • Si la première sauvegarde échoue, n'appelez pas la sauvegarde sur une autre (cela maintient la cohérence des bases de données).

Regardons les schémas de conception sans et avec un middleware. Tout d'abord, voici à quoi cela ressemble sans:

Ça a l'air moche, non? En effet, c'est moche et cela rendra votre code plus compliqué et étroitement couplé.

Voici la même solution avec un middleware:

Dans ce scénario, le côté client appelle simplement le middleware pour enregistrer un produit ou un utilisateur et il gère le reste.

Il n'y a pas de code lié à la duplication des données, que ce soit dans les serveurs Produit ou Utilisateur ou côté client. L'intergiciel s'occupe de tout cela.

3) Sécurité API

Pour tout code côté client frontal, nous pouvons afficher les requêtes sortantes, soit dans la console du navigateur, soit via un proxy.

Nous avons parlé d'un serveur utilisateur qui s'occupe de la connexion et de l'inscription. Si notre code frontal envoie directement les demandes à ce serveur, l'adresse de notre serveur d'authentification est exposée. Après avoir appris l'adresse IP de notre backend, les attaquants peuvent utiliser des outils pour trouver nos points de terminaison et analyser notre serveur à la recherche de vulnérabilités.

Nous pouvons utiliser un middleware comme proxy pour masquer l'URL de notre serveur d'authentification. Notre frontal communique avec le middleware et il transmettra la demande au serveur d'authentification, et retournera la réponse.

Cette approche nous permet également de bloquer toutes les requêtes adressées à notre serveur d'authentification, à l'exception des requêtes provenant de l'URL de notre middleware. Cela rend notre serveur d'authentification beaucoup plus sécurisé.

Cela n'était pas possible auparavant, car notre frontal communiquait avec le serveur d'authentification. Puisque le frontal signifie l'ordinateur du client, nous n'avons pas pu appliquer de filtre IP.

4) Exposer les API publiques

Dans la partie précédente, nous avons appris que les middlewares peuvent être utilisés pour restreindre l'accès à notre API.

Regardons maintenant l'autre côté de l'équation: et si nous voulons donner un accès restreint à notre API? Peut-être sommes-nous un ingénieur logiciel dans une banque et la banque prévoit un hackathon. Nous aurions besoin de fournir un accès à notre API, non?

Mais comme nous sommes une banque, nous ne pouvons bien sûr pas donner accès à l'ensemble de l'API et autoriser toutes les opérations. Cela signifie que nous devons trouver un moyen de fournir un accès restreint.

À cette fin, nous pouvons implémenter un middleware qui n'expose que certains des points de terminaison et redirige les requêtes vers notre API réelle. Ensuite, nous fournissons cette API aux développeurs lors du hackathon.

Conclusion

Dans cet article, nous avons commencé par définir ce qu'est le middleware et essayé de catégoriser les cas d'utilisation des middlewares dans le développement Web.

Gardez à l'esprit que ce n'est pas une liste complète des cas d'utilisation, mais j'espère toujours que cela vous a été utile.

Merci pour la lecture. Si vous avez aimé l'article, je vous invite à consulter mon blog. Vous pouvez également vous abonner à ma liste de diffusion pour être averti lorsque je publie un nouveau message :)