Nous sommes une startup technologique - Virtual Lab qui développe des solutions utilisant des technologies avancées VR / AR. Nous disposons d’un vaste portefeuille de produits et de solutions personnalisés. Aujourd’hui, nous aimerions vous présenter le projet VR ICU® – une plate-forme de formation pour le personnel médical de l’uci, créée à l’ère du Covid pour les besoins des hôpitaux.

Version IAM 2.8.1

InterSystems API Manager (IAM) version 2.8.1 est désormais généralement disponible. En plus d'une multitude d'améliorations des performances et de corrections de bogues, cette version ajoute de nouvelles fonctionnalités importantes, notamment :

Dans cette série d'articles en trois parties, il est montré comment vous pouvez utiliser IAM pour ajouter simplement de la sécurité, selon les normes OAuth 2.0, à un service précédemment non authentifié déployé dans IRIS.

InterSystems API Management (IAM) - c'est une nouvelle fonctionnalité de la plate-forme de données InterSystems IRIS, qui vous permet de surveiller, de contrôler et de gérer le trafic vers et à partir des API basées sur le Web au sein de votre infrastructure informatique. Au cas où vous l'auriez manqué, voici le lien vers l'annonce. Et voici un article expliquant comment commencer à travailler avec IAM.

Dans cet article, nous allons utiliser InterSystems API Management pour assurer l'équilibrage de charge d'une API.

Dans notre cas, nous avons 2 instances InterSystems IRIS avec /api/atelier REST API que nous voulons publier pour nos clients.

Il y a de nombreuses raisons différentes pour lesquelles nous pourrions vouloir faire cela, par exemple :

• Équilibrage de la charge pour répartir la charge de travail entre les serveurs.
• Déploiement bleu-vert : nous avons deux serveurs, l'un "prod", l'autre "dev" et nous pouvons vouloir passer de l'un à l'autre.
• Déploiement canary: nous pourrions publier la nouvelle version sur un seul serveur et y transférer 1% des clients.
• Configuration de haute disponibilité
• etc.

Une session concurrente dans IRIS : SQL, Objects, REST, et GraphQL

Kazimir Malevitch, "Athlètes" (1932)

"Mais bien sûr, vous ne comprenez pas ! Comment celui qui a toujours voyagé en calèche peut-il comprendre les sentiments et les impressions du voyageur en express ou du pilote dans les airs ?"

Kazimir Malevich (1916)

Introduction

Nous avons déjà abordé le sujet des raisons pour lesquelles la représentation objet/type est préférable à SQL pour la mise en œuvre des modèles de domaine. Et ces conclusions et ces faits sont aussi vrais aujourd'hui qu'ils l'ont toujours été. Alors pourquoi devrions-nous faire un pas en arrière et discuter des technologies qui ramènent les abstractions au niveau global, où elles se trouvaient à l'ère pré-objet et pré-type ? Et pourquoi devrions-nous encourager l'utilisation d'un code spaghetti, qui donne lieu à des bogues difficiles à repérer et qui ne repose que sur les compétences virtuoses des développeurs ?

Plusieurs arguments sont favorables à la transmission de données via des API basées sur SQL/REST/GraphQL plutôt qu'à leur représentation sous forme de types/objects: