Pourquoi les gens font-ils REST API au lieu de DBAL?
Au cours des deux dernières sociétés, je me suis rendu à, RESTE Il existe des API pour interroger les données via la webapp - c'est-à-dire au lieu de faire faire la webapp SQL directement, il appelle une API [REST et cela fait le SQL et retourne le résultat.
Ma question est - pourquoi est-ce fait ?
S'il devait être exposé à des tiers, je pourrais comprendre. Mieux vaut exposer une API REST limitée que la base de données complète. Mais dans ces deux sociétés, ce n'est pas le cas.
Il m'a été suggéré que ces REST API facilitent le basculement entre DBM S. Mais n'est-ce pas là l'intérêt d'une couche d'abstraction de base de données ( DBAL )? Peut-être que vous utilisez un ORM comme DBAL ou peut-être pourriez-vous simplement écrire du SQL brut et demander à votre DBAL de traduire les données spécifiques à la DB si nécessaire (par exemple, traduire LIMIT for MySQL to TOP for MSSQL ).
De toute façon, cela me semble inutile. Et je pense que cela rend également le diagnostic des problèmes plus difficile. Si un rapport sur la webapp donne les mauvais chiffres, vous ne pouvez pas simplement vider la requête SQL - vous devez vider l'URL REST puis aller dans le projet qui sert de REST API et retirez le SQL de cela. C'est donc une couche supplémentaire d'indirection qui ralentit le processus de diagnostic.
Si vous autorisez un client à accéder directement à la base de données - ce qu'il ferait, même avec une couche d'abstraction de base de données, alors:
- Vous obtenez un couplage entre leur code et le vôtre - en particulier, il existe un couplage très fort entre la structure de votre base de données et leur code;
- Votre client peut faire des choses assez indésirables sur votre base de données - qu'il s'agisse de mettre à jour des données qu'il ne devrait pas, d'écrire une requête qui prend trop de temps, de bloquer quelque chose parce qu'il n'acquiert pas correctement les verrous ...
- Si vous avez fait un choix moins qu'optimal dans votre structure de base de données, alors sortir de ce choix peut être très difficile, surtout si vous n'avez pas un bon moyen de faire migrer vos clients vers de nouvelles structures.
Autrement dit, je ne touche pas du tout à la partie REST - isoler votre base de données derrière une API est tout simplement un choix plus judicieux si l'équipe qui gère la base de données et les équipes qui l'utilisent ne le sont pas en synchronisation, car elle permet à ces parties d'évoluer à leur propre rythme.
Vous avez raison, il n'y a aucun avantage évident à introduire une couche API REST entre une application Web et une base de données, et cela a un coût en complexité et en frais généraux de performance.
La raison pour laquelle vous obtenez des réponses contradictoires est la confusion sur ce qu'est le "client" dans votre architecture.
Dans votre architecture (si je comprends bien), vous avez des navigateurs qui interagissent avec une seule application Web, qui à son tour interagit avec la base de données. L'introduction d'une couche API REST entre l'application Web et la base de données n'a aucun avantage. Tous les avantages déclarés (mise en cache, isolation de la base de données, etc.) peuvent être obtenus avec des couches d'accès aux données dans le code.
Mais il existe certaines autres architectures où une API REST est logique:
Si plusieurs clients accèdent à la base de données, c'est-à-dire pas une seule application Web, mais plusieurs applications Web indépendantes accédant à la même base de données. Il peut être avantageux de créer une interface commune REST pour permettre le partage du modèle de données, la mise en cache, etc. Bien sûr, vous pouvez obtenir certains avantages en partageant les mêmes bibliothèques DAL, mais cela ne fonctionnera pas si le les applications sont développées dans différentes langues et sur différentes plates-formes, ce qui est courant dans les systèmes d'entreprise.
Si plusieurs applications de bureau accèdent directement à la base de données. Il s'agit de l'architecture classique à deux niveaux, qui est tombée en disgrâce par rapport aux applications Web. L'introduction d'une couche REST vous permet de centraliser la logique d'accès aux données et surtout elle permet un contrôle plus strict de la sécurité, car il est risqué d'avoir plusieurs clients distribués accédant directement à la même base de données.
Si vous avez du code JavaScript qui récupère directement les données du serveur, vous avez besoin de quelque chose comme une API REST dans tous les cas.
Attention: gros message, quelques opinions, vague conclusion "faites ce qui vous convient le mieux"
Généralement, cela se fait comme un moyen d'implémenter une "architecture hexagonale" autour de votre base de données. Vous pouvez avoir des applications Web, des applications mobiles, des applications de bureau, des importateurs en bloc et un traitement en arrière-plan qui consomment tous votre base de données de manière uniforme. Vous pouvez certainement accomplir la même chose dans une certaine mesure en écrivant une bibliothèque riche pour accéder à votre base de données et en faisant en sorte que tous vos processus utilisent cette bibliothèque. Et en effet, si vous êtes dans une petite boutique avec un système très simple, c'est probablement une meilleure voie à suivre; C'est une approche plus simple et si vous n'avez pas besoin des capacités avancées d'un système plus compliqué, pourquoi payer pour la complexité? Cependant, si vous travaillez avec un grand nombre de systèmes sophistiqués qui ont tous besoin d'interagir avec votre base de données à grande échelle, il y a beaucoup d'avantages à mettre un service Web entre vos applications et vos données:
Indépendance et maintenance de la plateforme
Si vous avez une base de données et que vous écrivez une bibliothèque Python pour interagir avec cette base de données, et que tout le monde tire dans cette bibliothèque pour interagir avec la base de données, c'est très bien. Mais disons que tout à coup, vous devez écrire une application mobile, et cette application mobile doit maintenant également parler à la base de données. Et vos ingénieurs iOS n'utilisent pas Python, et vos Android ingénieurs n'utilisent pas Python. Peut-être que l'iOS les gars veulent utiliser les langages d'Apple et les ingénieurs Android veulent utiliser Java. Ensuite, vous seriez coincé à écrire et à maintenir votre bibliothèque d'accès aux données dans 3 langues différentes. Peut-être iOS et Android décident d'utiliser quelque chose comme Xamarin pour maximiser le code qu'ils peuvent partager. Parfait, sauf que vous devrez probablement encore porter votre bibliothèque d'accès aux données sur .NET. Et ensuite, votre entreprise vient d'acheter une autre entreprise qui est L'application Web est un produit disparate mais connexe, et l'entreprise souhaite intégrer certaines des données de la plate-forme de votre entreprise dans le nouveau acquis la plateforme de la filiale. Seul problème: la filiale était une start-up et a décidé d'écrire l'essentiel de son application dans Dart. De plus, pour quelque raison que ce soit (des raisons probablement indépendantes de votre volonté), l'équipe mobile qui pilotait Xamarin a décidé que ce n'était pas pour eux, et qu'elle préférait utiliser les outils et les langages spécifiques aux appareils mobiles pour lesquels ils développeraient. Mais pendant que vous étiez dans cette phase, votre équipe avait déjà livré une grande partie de votre bibliothèque d'accès aux données dans .NET, et une autre équipe de la société écrivait des trucs fous d'intégration Salesforce et a décidé de faire tout cela dans .NET depuis là était déjà une bibliothèque d'accès aux données pour .NET et cela semblait être une bonne idée car le mobile prévoyait initialement d'utiliser également .NET.
Alors maintenant, en raison d'une tournure très réaliste des événements, votre bibliothèque d'accès aux données est écrite en Python, .NET, Swift, Java et Dart. Ils ne sont pas aussi gentils que vous le souhaiteriez non plus. Vous ne pouviez pas utiliser un ORM aussi efficacement que vous le souhaiteriez, car chaque langue a des outils ORM différents, vous avez donc dû écrire plus de code que vous ne l'auriez souhaité. Et vous n'avez pas pu consacrer autant de temps à chaque incarnation que vous l'auriez souhaité, car il y en a 5. Et la version Dart de la bibliothèque est particulièrement poilue parce que vous avez dû rouler votre propre truc transactionnel pour certains, car les bibliothèques et le support n'étaient tout simplement pas vraiment là. Vous avez essayé de faire valoir que, pour cette raison, l'application Dart n'aurait dû avoir qu'une fonctionnalité en lecture seule pour votre base de données, mais l'entreprise avait déjà décidé que les fonctionnalités qu'elles prévoyaient valaient la peine. Et il s'avère qu'il y a un bogue dans une partie de la logique de validation qui existe dans toutes ces incarnations de votre bibliothèque d'accès aux données. Vous devez maintenant écrire des tests et du code pour corriger ce bogue dans toutes ces bibliothèques, obtenir des révisions de code pour vos modifications dans toutes ces bibliothèques, obtenir de l'assurance qualité sur toutes ces bibliothèques et publier vos modifications sur tous les systèmes en utilisant tous ces bibliothèques. Pendant ce temps, vos clients sont mécontents et se sont tournés vers Twitter, enchaînant des combinaisons de vulgarités que vous n'auriez jamais imaginé pouvoir être conçues, et encore moins ciblées sur le produit phare de votre entreprise. Et le propriétaire du produit décide de ne pas comprendre du tout la situation.
Veuillez comprendre que dans certains environnements, l'exemple ci-dessus est tout sauf artificiel. Tenez également compte du fait que cette séquence d'événements peut se dérouler au cours de quelques années. En règle générale, lorsque vous arrivez au point où les architectes et les hommes d'affaires commencent à parler de la connexion d'autres systèmes à votre base de données, c'est à ce moment-là que vous souhaiterez mettre un REST API devant) de la base de données "sur votre feuille de route. Considérez si au début, quand il était clair que cette base de données allait commencer à être partagée par quelques systèmes, qu'un service Web/API REST a été placé devant. La correction de votre bogue de validation être beaucoup plus rapide et plus facile, car vous le faites une fois au lieu de 5. Et la publication du correctif serait beaucoup plus facile à coordonner, car vous ne dépendez pas de la libération de plusieurs autres systèmes pour que vos modifications soient disponibles.
TLDR; Il est plus facile de centraliser la logique d'accès aux données et de maintenir des clients HTTP très fins que de distribuer la logique d'accès aux données à chaque application qui a besoin d'accéder aux données. En fait, votre client HTTP peut même être généré à partir de métadonnées. Dans les grands systèmes, l'API REST vous permet de conserver moins de code
Performances et évolutivité
Certaines personnes peuvent penser que parler directement à la base de données au lieu de passer d'abord par un service Web est plus rapide. Si vous n'avez qu'une seule application, c'est certainement vrai. Mais dans les grands systèmes, je ne suis pas d'accord avec le sentiment. Finalement, à un certain niveau d'échelle, il sera très avantageux de placer une sorte de cache devant la base de données. Vous utilisez peut-être Hibernate et souhaitez installer une grille Infinispan en tant que cache L2. Si vous disposez d'un cluster de 4 serveurs costauds pour héberger votre service Web séparément de vos applications, vous pouvez vous permettre d'avoir une topologie intégrée avec réplication synchrone activée. Si vous essayez de mettre cela sur un cluster de 30 serveurs d'applications, la surcharge d'activation de la réplication dans cette configuration sera trop importante, vous devrez donc soit exécuter Infinispan en mode distribué ou dans une sorte de topologie dédiée, et Hibernate doit soudainement sortir sur le réseau pour lire dans le cache. De plus, Infinispan ne fonctionne qu'en Java. Si vous avez d'autres langues, vous aurez besoin d'autres solutions de mise en cache. La surcharge réseau liée au fait de devoir passer de votre application à votre service Web avant d'accéder à la base de données est rapidement compensée par la nécessité d'utiliser des solutions de mise en cache beaucoup plus compliquées qui s'accompagnent généralement d'une surcharge propre.
En outre, cette couche HTTP de votre REST API fournit un autre mécanisme de mise en cache précieux. Vos serveurs pour votre REST API peuvent mettre des en-têtes de mise en cache sur leurs réponses, et ces réponses peut être mis en cache au niveau de la couche réseau, qui évolue exceptionnellement bien. Dans une petite configuration, avec un ou deux serveurs, le mieux est d'utiliser simplement un cache en mémoire dans l'application lorsqu'elle communique avec la base de données, mais sur une grande plate-forme avec de nombreuses applications exécutées sur de nombreux serveurs, vous souhaitez tirer parti du réseau pour gérer votre mise en cache, car lorsqu'il est correctement configuré, quelque chose comme squid ou vernis ou nginx peut évoluer à des niveaux insensés sur un matériel relativement petit. Des centaines de milliers ou des millions de demandes par seconde de débit est beaucoup moins cher à faire à partir d'un cache HTTP qu'à partir d'un serveur d'applications ou d'une base de données.
En plus de cela, avoir une tonne de clients pointant tous vers votre base de données, au lieu de les avoir tous pointés vers quelques serveurs qui à leur tour pointent vers la base de données, peut rendre le réglage de la base de données et le regroupement de connexions beaucoup plus difficiles. En général, la majeure partie de la charge de travail réelle sur un serveur d'applications est liée à des applications; attendre que les données reviennent de la base de données est souvent long, mais généralement peu coûteux en calcul. Vous pouvez avoir besoin de 40 serveurs pour gérer la charge de travail de votre application, mais vous n'avez probablement pas besoin de 40 serveurs pour orchestrer la récupération des données de la base de données. Si vous dédiez cette tâche à un service Web, le service Web s'exécutera probablement sur beaucoup moins de serveurs que le reste de l'application, ce qui signifie que vous aurez besoin de beaucoup moins de connexions à la base de données. Ce qui est important, car les bases de données ne fonctionnent généralement pas aussi bien lorsqu'elles desservent des tonnes de connexions simultanées.
TLDR; Il est plus facile de régler, de mettre à l'échelle et de mettre en cache votre accès aux données lorsque cela se produit à l'intérieur d'un seul service Web dédié que lorsque cela se produit dans de nombreuses applications différentes en utilisant différentes langues et technologies
Réflexions finales
S'il vous plaît ne vous détournez pas de cette pensée "Oh wow, je devrais toujours utiliser REST APIs pour obtenir mes données" ou "Ce idiot essaie de dire que nous le faisons mal parce que notre application Web parle directement à la base de données, mais nos trucs fonctionnent bien! ". Le point principal que j'essaie de faire valoir est que différents systèmes et différentes entreprises ont des exigences différentes; Dans de nombreux cas, mettre une API REST devant votre base de données n'a vraiment aucun sens. Il s'agit d'une architecture plus compliquée qui nécessite de justifier cette complexité. Mais lorsque la complexité est justifiée, il y a une tonne d'avantages à avoir l'API REST. Pouvoir peser les différentes préoccupations et choisir la bonne approche pour votre système est ce qui fait un bon ingénieur.
De plus, si l'API REST gêne le débogage, il y a probablement quelque chose de mal ou de manquant dans cette image. Je ne crois pas que cette couche d'abstraction ajoutée rend intrinsèquement le débogage plus difficile. Quand Je travaille avec de grands systèmes à plusieurs niveaux, j'aime m'assurer d'avoir un contexte de journalisation distribué. Peut-être lorsqu'un utilisateur lance une demande, générer un GUID pour cette demande et enregistrer le nom d'utilisateur de cet utilisateur et la demande qu'il a faite. Ensuite, transmettez-le GUID lorsque votre application communique avec d'autres systèmes. Avec une agrégation et une indexation appropriées des journaux, vous pouvez interroger l'intégralité de votre plateforme pour l'utilisateur signalant le problème. , et ont une visibilité sur toutes leurs actions et ils parcourent le système pour identifier rapidement où les choses ont mal tourné. Encore une fois, c'est une architecture plus compliquée, donc vous devriez probablement avoir une infrastructure plus compliquée en place pour faciliter la prise en charge de cette architecture.
Sources: http://alistair.cockburn.us/Hexagonal+architecturehttps://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Si je comprends bien ce qu'est un DBAL , alors la réponse est qu'une interface REST vous permet d'utiliser n'importe quelle langue pour ses clients, tandis qu'une DBAL est une bibliothèque qui vous permet d'utiliser une seule langue pour ses clients.
Ceci, à son tour, peut être un avantage pour une entreprise où il existe de nombreuses équipes de développement et qui ne maîtrisent pas toutes la même langue. Permettre à leur logiciel d'interroger directement la base de données équivaudrait à des fonctionnalités, mais comme vous le dites, il vaut mieux exposer une API REST limitée que la base de données complète).
En termes plus abstraits, vous répondez vous-même à la question:
C'est donc une couche supplémentaire d'indirection qui ralentit le processus de diagnostic
... puisqu'il y a cet célèbre aphorisme qui dit: "Tous les problèmes en informatique peuvent être résolus par un autre niveau d'indirection". :)
Ce n'est pas parce que vous êtes dans la même entreprise que vous devez tout exposer à tout le monde. REST Les API sont un moyen de définir une relation limitée consommateur/fournisseur entre les équipes d'une entreprise, avec un contrat clair. Amazon a été n pionnier dans cette forme d'organisation .
Les API fournissent également une couche d'abstraction, vous permettant d'utiliser un ensemble spécifique d'expressions idiomatiques - vous ne voulez pas nécessairement parler à vos consommateurs dans les mêmes termes que ceux utilisés dans votre base de données. De plus, vous ne voulez pas nécessairement parler à chaque consommateur de la même manière.
Vous pensez que REST est pour les requêtes de base de données et ce n'est pas le cas. REST représente l'état de quelque chose en ce moment. Utiliser REST modifie ou récupère une représentation mais c'est tout. Si cet état devient disponible par la base de données, cela n'a pas d'importance et personne ne s'en soucie car COMMENT cette représentation ne fait pas partie de REST = et les requêtes de base de données non plus.
DBAL ne se préoccupe que d'accéder aux données, mais dans la plupart des applications, vous n'êtes pas seulement concerné par l'accès aux données, mais également par la réalisation de tous les effets secondaires d'une opération.
Par exemple, un système de commerce électronique. Lorsqu'une commande arrive dans le système, vous souhaitez envoyer un e-mail au client pour sa réception, vous souhaitez vous connecter à votre système comptable pour mettre à jour le bilan, vous souhaitez vous connecter au processeur de paiement pour traiter la carte de crédit, vous voudriez soumettre les détails de la commande au service de détection de fraude pour vérifier si un paiement par carte est susceptible de devenir un rejet de débit (courant dans les commandes frauduleuses), vous voudriez vous connecter au système d'entrepôt pour expédier la commande , vous souhaitez vous connecter à vos propres fournisseurs pour commander plus de stocks lorsque vos fournitures sont faibles, vous souhaitez exécuter des algorithmes d'apprentissage automatique pour fournir des recommandations de produits de vente croisée, vous souhaitez vous connecter à votre CRM pour déclencher un signalement concernant les commandes qui ont échoué, vous souhaitez enregistrer la commande auprès de votre service d'analyse pour les rapports et les alertes, etc., etc., etc.
La plupart de ces opérations doivent être effectuées sur un système de confiance, c'est-à-dire sur le serveur, et ces opérations secondaires ne sont pas liées à la base de données et sont souvent trop complexes à développer sur la couche DBAL.