En 2018, nous avons officialisé le lancement de notre API Serveur (en REST/Json), permettant l’intégration des services Kinow au sein d’applications dites « serveur », par exemple un site internet.
Aujourd’hui, nous sommes fiers d’annoncer le lancement d’une nouvelle API Client, qui fonctionne en GraphQL.
1. Usage de l’API Serveur
Avec l’API Serveur, il est possible d’intégrer dans un site existant toutes les ressources de votre plateforme vidéo Kinow, comme par exemple la liste des vidéos du CMS ou les informations d’un compte utilisateur.
Cette API permet aussi de modifier à la volée ces données ou d’en créer de nouvelles, elle offre donc un accès dans un contexte administrateur avec des droits d’écriture sur l’ensemble des données de la plateforme.
Elle est aussi très utile pour les opérations de masses, comme la synchronisation des comptes utilisateurs avec un SSO externe.
Documentation API Serveur : https://api.kinow.com
2. Usage de l’API Client
L’introduction de la nouvelle API Client permet de se placer dans un contexte utilisateur, au sein d’une application cliente. En effet, les besoins sont différents entre un site internet hébergé sur un serveur sur lequel le client n’a pas accès au code, et une application mobile ou STB pour laquelle le client bénéficie d’un contrôle total.
Ainsi, l’API Client joue le rôle de proxy et va faire la passerelle entre l’application côté client et l’API Serveur : elle permet d’authentifier le client dans son propre contexte, en limitant ses droits d’accès aux données en fonction de ses permissions. L’utilisation de l’API Client évite le développement d’un serveur proxy intermédiaire entre l’application cliente et l’API Serveur.
Nous pouvons prendre comme exemple la consultation des vidéos d’un catalogue : l’API Client retourne à l’application de l’utilisateur uniquement le contenu auquel il a le droit d’accéder, en appliquant les restrictions d’accès (TVOD/SVOD) et les filtres de géolocalisation.
Documentation API Client : https://api-client.kinow.io
3. Fortes montées en charges
Kinow propose une infrastructure technique adaptée pour répondre à des pics d’activité très importants. L’API Client à destination des applications mobiles et set-top box est capable de gérer de fortes montées en charge et garantir une latence très faible pour l’utilisateur.
L’API Client est ainsi capable d’encaisser de façon simultanée des millions de requêtes utilisateurs.
4. Requêtes GraphQL
L’ensemble des requêtes à l’API Client de Kinow se font en GraphQL, qui offre une grande souplesse aux intégrateurs d’applications front. Il est ainsi possible de récupérer des données croisées ce qui limite grandement le nombre d’appels à l’API et donc le temps d’intégration.
5. Architecture serverless
L’API Client mise à disposition est structurée sur une architecture serverless, basée sur AWS Lambda.
Le serverless permet de concevoir et d'exécuter des applications et des services sans se soucier des serveurs. Kinow n’a donc pas besoin d'allouer, de dimensionner ou de gérer le moindre serveur, le dimensionnement flexible assurant une haute disponibilité automatisée, sans temps d’attente pour l’auto-scalling et offrant une tolérance aux pannes intégrées.
Le dimensionnement des ressources se fait automatiquement en exécutant le code en réponse à chaque déclencheur. Celui-ci s'exécute en parallèle et traite chaque déclencheur indépendamment. La charge de travail est ainsi dimensionnée de façon précise et en temps réel.
6. Proxy d’entrée
Un proxy en entrée, utilisant AWS API Gateway, permet de mettre en cache la sortie des appels API, afin d’assurer un temps de réponse optimal et éviter l’utilisation de ressources inutiles. Un tableau de bord permet à Kinow de suivre en temps réels les appels et de consulter les informations, les mesures de performances, la latence des données et les taux d’erreurs.
7. Moteur SQL
Le stockage et l’écriture d’informations se fait via le service AWS Aurora, qui est un moteur de base de données relationnel qui associe la vitesse et la fiabilité des bases de données NoSQL avec la richesse des bases de données relationnelles classiques comme MySQL/MariaDB.
Amazon Aurora offre plus de 99,99 % de disponibilité. Son stockage flexible sur SSD et auto-récupérant est créé pour le cloud et réplique six copies des données sur trois zones de disponibilité. Le basculement d'instance se fait généralement en moins de 30 secondes automatiquement vers l'un des 15 réplicas en lecture.
8. Lecture : mise en cache
L’ensemble des requêtes READ (lecture) sont mises en cache via un serveur NoSQL, AWS Elastic Search. Ainsi, le serveur SQL n’est presque jamais sollicité pour la lecture, ce qui limite donc l’utilisation des ressources.
Elastic Search est conçu pour offrir des performances constantes et rapides, quelle que soit l'échelle et la montée en charge associée. Le temps de latence moyen côté service est généralement de l'ordre de quelques millisecondes.
Notre système de webhooks, le Notification Manager, permet de notifier en temps réel tout changement en écriture opéré sur les données et rafraichir les clefs du cache reliées à la ressource ciblée.
9. Ecriture : file d’attente
L’ensemble des requêtes WRITE (écrite) sont mises en file d’attente via AWS SQS afin d’être traitées au fil de l’eau et éviter une surcharge inutile au serveur de base de données Aurora.
L’utilisation d’Amazon SQS nous permet de transmettre n'importe quel volume de données, à tout niveau de débit, sans perdre de messages ni avoir besoin que d'autres services soient toujours disponibles, renforçant ainsi la résilience globale du système : plusieurs copies de chaque message sont stockées de manière redondante dans plusieurs zones de disponibilité.