Chez Bedrock nous fournissons des applications de streaming (ASVOD, AVOD) pour plusieurs clients en France et en Europe, chaque application étant déployée sur de nombreux appareils (ordinateur, mobile, set top box, tv connecté, consoles de jeux, tv stick etc …). Il était devenu très difficile de gérer la création et l’évolution de ces nombreuses applications qui requêtaient et formataient chacune elles-mêmes les données dont elles avaient besoin.
Pour cela, en 2018, nous avons décidé de nous lancer dans la création d’un Back For Front afin d’unifier et faciliter les interactions backend et frontend. Au cours de cette conférence nous passerons en revue :
Aujourd’hui notre API Gateway BFF opère 92 frontends délivrant 1.5 milliards de vidéos par an pour 45 millions d’utilisateurs actifs (MaU). Venez découvrir notre retour d’expérience sur la mise en place d’un tel projet.
_ Bonjour à tous. Bienvenue à cette conférence intitulée BFF, notre best friend forever pour développer plein d'applications front-end. Je vais commencer par une introduction pour présenter l'entreprise et me présenter.
Je suis développeur depuis plus d'une dizaine d'années. J'ai rejoint M6 Web en 2014. Je suis Team Leader chez Bedrock. C'est la même chose les deux, je vais vous en parler juste après. Je fais un clin d'œil à Olivier qui devait être là.
Un avertissement : La conférence, il y a plein de points intéressants qui nécessiteraient des conférences pour eux-mêmes, il y a des trucs où vous serez frustrés un petit peu. Il va se passer pas mal de choses. Je vous souhaite bonne chance à vous et à moi. C'est ma première conférence.
(applaudissements)
Bedrock, c'est une entreprise qui crée et qui maintient une plate-forme de streaming vidéo. Plusieurs de mes collègues sont passés déjà. C'est à destination des broadcasters des chaînes de télévision. Comme M6, RTL. Salto. Nous sommes rendus utilisés par plusieurs broadcasters à travers l'Europe. Sur différents business modèles. Typiquement, de la VOD. De l'advertising ou des modèles avec souscription.
Ce sont des comportements différents. Ce sera important pour la suite.
Quelques chiffres sur Bedrock et les applications. Ce que je voudrais qu'on retienne, aujourd'hui, c'est 45 millions d'utilisateurs. Qui utilisent nos applications. En France, c'est un iPad sur deux qui avait l'application 6play en 2019. Beaucoup de volume qui est géré par toutes les applications.
Quelques statuts au niveau de l'entreprise. Vous avez pu le voir sur différentes présentations. Quand je suis arrivé en 2014, nous étions 40. Maintenant, nous sommes 400. Nous ne comptons plus en développeurs, mais en teams. Au front, nous avons plus de 100 développeurs qui sont là. Plus que 19 équipes.
Pourquoi autant de DEF front ? Il y a beaucoup d'applications à maintenir et à développer. Les applications mobiles embarquées. Les tablettes, les TV. Mais aussi les set-top boxes. Ce que vous retrouvez directement dans votre box Free ou Orange.
Comment on construit les applications ? Avant de vous en parler, je vais faire un point sur ce que c'était avant. Ici, vous avez le site de 6play tel qu'il était, 6play V4. Dans les années 2018. Vous voyez un menu sur le côté et un autre menu en haut. Du contenu qui s'affiche au milieu. Toutes ces applications sont construites sur un modèle classique. Le front. Il connaît les API back-end. Chaque phase appelle les API back-end. Ça donne des applications qui ont des organisations figées. Tout est construit dans l'application.
Le fait que tout soit construit dans l'application, nous avons beaucoup de logique directement dans chaque application. Ici, le menu sur la gauche, c'est un endpoint dédié d'une API. Le jour où c'est endpoint n'est plus maintenu, toutes les applications qui sont dans la nature, elles ne peuvent pas changer. C'est difficile.
Pour construire un front-end, nous avons un exemple. Un codebase commun, et de la personnalisation pour chacun de nos clients. Il faut bâtir toutes ces applications pour chacune des 20 spécifiques. Les modèles de télés, et de téléphones. Chaque bundle qui présente chacune des applications. Ça fait plus que 100 applications différentes. Chaque fois, il faut les rebâtir. Certains stores peuvent prendre plusieurs mois pour valider les applications. Nous sommes encore... nous voulons faire quelque chose de nouveau.
Avant, nous avions les applications front-end qui construisaient les interfaces en se basant sur plein d'API back, on devait connaître les spécifications, des données qu'on ne savait pas d'où elles venaient. Ça devenait de la logique qui était dupliquée dans chacun des fronts. Ça pouvait mener à des interprétations différentes.
Nous devions changer de paradigme pour pouvoir développer plus rapidement des changements. Et développer, leader par le back-end. Pour simplifier et accélérer ces changements, l'idée était de faire un configurateur d'interfaces qui étaient gérées par le back-end. Nous avons le client qui choisit comment éditorialiser la page. Ça se transcrit dans l'application. La construction en elle-même de la page n'est plus décidée par l'application, mais par l'équipe de contributions.
Pour faire cela, le client choisit chacune des strates. L'interface globale que vous retrouvez sur l'application, c'est le layout. L'équipe de contributions va choisir chacun des blocs, c'est la link que vous retrouvez ici. Il va choisir ce qu'il met dedans. "Je voudrais avoir les informations sur la page sur le programme sur lequel je suis. Les recommandations de tous les épisodes." Ça, le rendu en front, il sera déterminé ensuite par ce qu'on appelle des templates." Le contributeur va choisir : Pour afficher ma ligne, je vais mettre un grand carré et des petits carrés verticaux. Chaque rendu est défini par l'équipe de contributions. C'est l'application qui pilote cela.
La génération contenue qui est pilotée par le back-end va inclure toute la personnalisation. Nous voyons la page d'un programme qui est Kaamelot, le rendu est généré par le back-end. Nous allons avoir la personnalisation. On voit qu'il est dans mes favoris. Il est dans la reprise de lecture. Parce que j'ai consommé 50 % de la vidéo. Le front, il n'a plus à savoir qu'il doit appeler une API pour savoir quelle est la consommation de la vidéo. Les informations sont envoyées par le back-end.
En plus de cela, l'utilisation de l'iode* et la personnalisation va nous permettre de faire de la segmentation. Nous allons nous retrouver avec le choix d'émettre des options. Nous aurons une option par défaut qui est affichée pour tous les utilisateurs. On peut dire : Les utilisateurs de plus de 40 ans, nous allons leur mettre un layer différemment. Des contenus qui sont plus adaptés. Ou qu'ils vont plus consommer.
Avec la nouvelle architecture, on se retrouve avec des applications front-end qui ont une seule API à appeler. Elle va appeler toutes les API back que nous avions tout à l'heure, mais elle va prégénérer le contenu dans un format unifié avec ce que j'ai dit tout à l'heure, le layout. Chaque strate, c'est un bloc. Les vignettes, ce sont des items. Ce langage qu'on va créer, ça va faire une abstraction, et le front n'aura plus à se soucier de qui on va appeler derrière. Ça va aussi nous permettre côté back-end de changer des API et de faire ces changements instantanément sans que les front n'aient à se soucier des API qui pourraient être remplacés par de nouvelles versions.
Quelques exemples du rendu. Sur différentes devices. Vous avez des rendus sur des PC et télévisions. Nous avons des mobiles. C'est la théorie. Est-ce que ça marche en vrai ? Oui. C'est en production chez nous depuis 2019 sur le Web. Et depuis 2019 et 2020. Sur toutes les applications. C'est utilisé chez nous. Le principe de layout.
La conférence s'appelle BFF. Qu'est-ce qui a changé entre-temps. Pourquoi est-ce qu'aujourd'hui, on appelle pas le projet layout ?
Avant d'aller plus loin, je vais donner des définitions. Afin que nous soyons raccord sur ce qui se passe. Parce que ce ne sont pas des définitions qu'il faut prendre dans l'absolu. C'est pour que vous compreniez de quoi on parle ensuite.
La première, ce sera la notion d'API gateway. C'est un point d'entrée unique pour toutes les applications front-end. Les applications front n'ont plus à connaître plein d'API rest backend. Elles ont un seul point d'entrée.
La deuxième définition, c'est la notion de Back For Front. BFF, ce n'est pas juste best friend forever. L'idée, c'est de gérer la logique une seule fois dans le back-end plutôt que plusieurs fois dans le front. Nous disons : Plutôt que de dupliquer les logiques deux fois et d'avoir des erreurs et des différences de comportement, toutes les logiques vont être présentes une seule fois et gérées par une seule entité. Nous voyons bien que le layout se transforme et devient le BFF.
Pour faire tout cela, il ne va plus se contenter de générer uniquement la page, mais d'autres choses. Le menu que vous aviez en haut sur 6play avant, c'est lui aussi qui va le gérer, il y a un niveau endpoint sur le BFF, ça s'appelle la navigation. Ça permet de générer les menus. Plutôt que d'appeler chaque API, nous allons avoir un niveau d'abstraction et des navigations groups. On pourra générer le menu pour chaque front sans qu'ils aient à se poser des questions.
Le Player, c'est important, il va se transformer aussi en layers. On a introduit un autre type d'item. Il fournit des asset video pour la vidéo. Le Player que l'on trouve ici, nous avons un premier bloc qu'on a ici. Il permet de lire la vidéo. Sur le côté, nous avons un autre bloc qui s'affiche verticalement pour présenter la suite de ce qui arrive.
Avoir un BFF et gérer les comportements, ça va permettre de contrôler le comportement des utilisateurs. Typiquement, il y a des choses qu'on ne veut pas laisser faire à tous nos utilisateurs. Nous allons vérifier que lorsque l'utilisateur demande à afficher une page, il est bien connecté et a bien un profil sélectionné. Sinon, il va devoir sélectionner un profil pour continuer à naviguer. Pareil, nous allons voir s'il a souscrit à une offre. Enfin, nous pouvons afficher la page qu'il souhaitait.
Il y a d'autres choses que le BFF fait, mais c'est un BFF qui est en devenir. Mais ce sera le téléchargement, quand l'utilisateur veut télécharger une vidéo pour la consommer online, il va fournir les informations à fournir dans l'application quand vous serez hors-ligne.
Pour continuer, nous allons parler un petit peu de cas de ce qui nous est arrivé. Comment c'est d'avoir un BFF dans la vie réelle. Mais comme tout à l'heure, je vais vous donner une définition. SPOF. Single Point of Failure. Quand dans un système, vous avez un événement que s'il arrête de fonctionner, il met en péril tout le système, c'est un SPOF. À un moment, il nous est arrivé un truc pas très chouette.
Je vais vous parler de l'Euro 2020. C'est un événement qui a eu lieu en 2021 à cause du Covid. Et c'est un événement où il y avait des matchs de foot qui était diffusés sur M6. Tout passait par le BFF pour diffuser les matchs de foot. Je vais expliquer quelques notions de cloud. Mais Pascal en a parlé déjà. On utilise du cloud et des clusters. Pour faire simple, l'application est sur des pods, des petits serveurs. Quand quelqu'un demande à afficher une page, un pods traite la requête et lui envoie une réponse. Quand plein de gens essayent de traiter une page, les pods se remplissent, il y a de plus en plus de réponses à traiter. Les pods arrivent assez vite. Quelques minutes. Mais quand il y a des millions de gens qui essayent de voir un match de foot en même temps, c'est très long.
Ici, vous voyez ce qui s'est passé. Le trafic. Le premier petit pic, c'est une soirée normale. Quand des gens viennent le soir. On voit la consommation qui monte. Le pic à droite, c'est le match de foot le samedi soir. L'échelle n'est pas très visible. On a l'impression que ça monte doucement. Mais pas du tout. Il y a un truc dont on ne se rend pas compte. Ce n'est pas une courbe qui progresse. Ce sont des murs. Nous appelons ça des murs de connexion. En l'espace de deux minutes, la consommation et le trafic sur nos sites a fait fois cinq. Cinq fois le nombre des personnes qui viennent voir le match de foot. En quelque temps, nous avons fait fois 20.
Ça a deux effets principaux qui vont ralentir l'application. En premier, en violet, c'est le queuing. En gros, toutes les requêtes, en attendant que les pods arrivent, elles attendent. En attendant que la requête soit traitée, elle va peut-être attendre une seconde avant d'être traitée. L'utilisateur attend au minimum une seconde avant que la requête soit traitée. En plus de cela, c'est la courbe globale du temps de réponse. En vert, on voit que PHP ralentit. Il ralentit à cause du throttling. Quand un pod traite trop de requêtes, il va ralentir. Il y a plus de CPU. Le temps de réponse va être plus long.
C'est un des premiers problèmes qui peut arriver. Un deuxième, il y a une dépendance qui peut aussi ne pas suivre le scaling du BFF. Qu'est-ce qui se passe quand une de ces dépendances, typiquement, une journée... nous travaillons tous ensemble. Une de ces dépendances qui meurt, qu'est-ce qui se passe pour le BFF ? Comment il peut se comporter ?
Ce sont des problèmes qui peuvent causer la mort du BFF. Nous n'arrivons plus à répondre dans un temps raisonnable aux applications front. Notre but, en tant que BFF, c'est de répondre de manière intelligible et rapide aux applications front.
Nous avons mis en place plusieurs solutions. La première, c'est l'idée d'avoir un layout caché. Devant le cluster, nous avons un CDN. dans le cas d'un événement où nous savons qu'il y aura des millions d'utilisateurs qui vont venir, on dit : Attendez. Appelez une version alternative. Le cluster, il ne fait pas grand-chose. Mais il enlève la personnalisation. Cette réponse va bien quand les gens n'ont pas besoin de personnalisation. Il la met en cache. La première personne qui arrive, prend la réponse cachée, les autres derrière, c'est le CDIN qui ramasse. Les autres réalisateurs auront les mêmes réponses que le premier. Le cluster est épargné. Les réponses délivrent rapidement.
L'autre contournement qu'on a pu mettre en place, le pré-scaling. Je sais qu'il y a un événement qui arrive, à 20 heures, il y aura beaucoup de monde. À 19h55, j'ajoute plein de pods en prévision. On a le temps de voir la charge monter. Nous avons de la réserve.
Ce sont des solutions qui fonctionnent bien. Mais elles sont très manuelles. Je n'ai pas envie de savoir quand les clients ont des événements et de devoir programmer des choses à mettre en place chaque fois que quelqu'un fait un match de foot.
L'étape d'après, ça a été de dire : Ça suffit. On va essayer de faire en sorte que tout soit automatique. La première solution, utiliser du Stale Cache. Quand dans le BFF, nous appelons des API qui fournissent du contenu, on va mettre une étape de cache. Si l'API a eu à suivre parce qu'on a trop de requêtes, une coupure réseau, etc., on utilise la précédente réponse qu'on avait en cache. C'est chouette. Nous sommes indépendants de l'état de santé de l'API qui est derrière. Mais il faut qu'on ait le contenu dans le cache. Si le contenu est tout neuf, nous ne l'avons pas dans le cache. Nous ne pouvons pas l'afficher.
Une autre solution : Avoir un comportement dégradé. Nous allons essayer au minimum d'exploiter les données des API qu'on consulte. Plutôt que de se demander : Quels sont les paiements qu'a faits l'utilisateur ? D'exploiter les données directement ? On va se poser des questions bêtes ? Est-ce qu'il a payé ? Au niveau de notre métier, quand on dit qu'on ne sait pas qu'il a payé, dans le doute, il a payé. On se pose des questions les plus simples possibles. Les questions métier.
Je vais introduire une autre définition. C'est le circuit breaker. C'est un pattern qu'on a utilisé. Qu'est-ce que ça veut dire ? Arrêter de faire quelque chose quand on sait que ça va échouer. Comment est-ce qu'on le sait ? Nos Monitor ont deux API. Quand on détecte que l'API qu'on appelle a un ratio trop important pour nous, il a échoué, on se dit : Ça ne sert à rien. Il ne va pas réussir. Plutôt que d'essayer de l'appeler, on va arrêter de l'appeler. On va utiliser le comportement dégradé ou le Stale Cache. Ça implique d'avoir déjà une idée de la consommation ou des degrés qu'on peut tolérer dans l'erreur des API. Ça va permettre à l'API qui est derrière pour lui laisser du répit pour scaler et répondre vite derrière.
La dernière solution dont je vais parler, celle que j'appelle le fallback. C'est d'avoir un crow qui va mettre en dehors du cluster des réponses préenregistrées et personnalisées des pages du cluster. Quand l'utilisateur appelle pour afficher une page, le CDN appelle le cluster. Si le cluster n'est plus en mesure de répondre parce qu'il a des soucis de réseau ou quoi que ce soit, nous allons contacter S3, un service de stockage de fichiers, et demander si la page est disponible et si elle a été prégénérée ? Nous pouvons avoir toujours une réponse disponible même si elle est dégradée. On peut continuer à naviguer. En plus, ça nous permet d'avoir un layout d'erreur. Si le cluster ne répond plus du tout pendant un certain temps, nous pouvons afficher quelque chose à l'utilisateur. Ce n'est pas aux applications d'avoir à gérer le message d'erreur.
Voilà. C'est le BFF en général. Et la résilience. Maintenant, nous voyons que nous pouvons toujours répondre quelque chose au front. Mais ensuite : Quels sont les impacts de tout cela ? Changer tout le design que l'on voyait avant d'avoir un layout et que les applications appellent sha et maintenant, qu'est-ce que ça change ?
Un truc qui a souvent été le cas dans l'entreprise, nous avions une petite guerre entre les gens qui faisaient du PHP et les gens qui faisaient du JavaScript. Avec ce changement de paradigme et l'idée d'avoir un Back For Front, ça a changé la donne. Nous sommes dans une co-construction. Nous faisons un meeting une fois toutes les deux semaines avec tous les leaders des applications front. L'idée, c'est de co-construire l'API et de réévaluer le besoin. L'idée, c'est de simplifier le boulot des fronts au maximum. J'ai des témoignages des leads front et des effets que ça eu. Le Player est plus performant, il se lance plus vite. Un deuxième témoignage, en plus de la performance, le fait d'avoir centré toutes les règles métier, c'est beaucoup de code. Ils n'ont plus à s'en soucier. Nous pourrions caricaturer cela en nous disant que chaque application front ne fait plus que du CSS. On pourrait leur envoyer du HTML. Elles se contentent d'afficher. C'est réducteur, mais c'est l'idée. Se dire : L'application, son principal objectif, c'est de se concentrer sur UX et UI. Ne pas se concentrer sur l'application des règles métier. En plus de cela, ça a renforcé la collaboration avec les API du back. Avant, c'était développé dans un coin. Les front venaient consulter indépendamment. L'avantage, c'est qu'il y a qu'un seul interlocuteur. Puisqu'il y a qu'un seul utilisateur de l'API, on peut faire évoluer les choses très rapidement. On peut se mettre d'accord : On change les paramètres demain. On fait les déploiements simultanément. Les API sont indépendantes et peuvent évoluer vite.
Le problème du pattern, c'est que le BFF au milieu, il vient comme un goulot d'étranglement. Tout doit passer par le projet pour être mis à la disposition des applications front. Tout n'est pas aussi sombre que ça en a l'air. Une fois qu'on a fait les branchements et qu'on donne les réponses, ils sont libres de faire évoluer les réponses et on fait passe-plat sur beaucoup de données.
Je vais conclure. Mais avant de conclure, il y a pas mal de choses dont je voudrais parler. La suite.
Un petit résumé. Nous avons vu avec le Back For Front 1u'on peut faire pas mal de choses. On peut créer des front qui sont configurables. Configurer les règles métier. Gérer l'absence de données. Et la perte de notre propre API. On va faciliter le développement des applications. Elles vont se concentrer sur leur API et le X. Ça renforce la co-construction des API. Entre le BFF et le back. Ça entraîne des complexités parce que le BFF est un SPOF. Quand on est chef, et quand il y a de la charge, c'est celui qui encaisse. Un point important, c'est ce qu'au fur et à mesure qu'on développe le BFF, il y a de plus en plus de complexités. Il y a toutes ces règles métiers à incorporer. Plein de API Byte à incorporer.
Ça va faire écho à la conférence qu'il y a eue avant. Il y a eu beaucoup de refactoring au fil du temps. Le Scope a beaucoup changé depuis le passage du layout au BFF.
Il y a pas mal de pistes pour améliorer le BFF. La première chose qu'on aimerait faire, c'est de faire du versionning. Quand vous parlez d'une Symfony, c'est du CMV, avoir un numéro de version. Quand on fait évoluer le projet aujourd'hui, on se retrouve à ajouter ou supprimer des champs. Les nouvelles applications peuvent mettre des mois à arriver en ligne. Vous-même, vous avez une application sur votre téléphone, rien ne vous force à la mettre à jour. Beaucoup d'utilisateurs utilisent de vieilles versions. De vieilles versions du BFF qui sont appelées. Utiliser du versionning, ça permettrait de faire du long term support. De dire : Cette version de l'API est supportée pendant deux ans. On peut faire des versions mineures qui vont ajouter de nouvelles features. "J'ai migré sur cette nouvelle version. Je vais devoir faire l'effort de migrer et supprimer les champs utilisés par les nouvelles versions." L'importance d'avoir un LTS, c'est parce que ce sont des applications qui peuvent rester longtemps en prod et que nous n'avons pas la main pour les faire évoluer.
En plus de cela, nous aimerions faire la gestion de formulaires. Jusqu'ici, tout ce que je vous ai dit, c'est ce que le BFF se contente d'afficher des informations aux applications front. Tout va dans un seul sens. L'utilisateur demande d'afficher une page. Jamais dans l'autre sens. Une problématique qui va se poser et qui sera intéressante : Comment on intègre le traitement des données ? L'affichage des formulaires ? Il faut que je rentre tous les champs des formulaires, que je les entre aux différents API du back pour traiter les données. C'est une problématique à laquelle on pense encore. Ce sont des idées pour la suite.
Le dernier point qui sera important pour nous, avec l'événement de l'Euro 2020, ça nous a posé problème. Nous avons des OX qui nous poussent là-dessus. Certitude de décoréller la partie BFF d'API Gateway. BFF, c'est la concentration des règles métier. L'API Gateway, c'est celui qui va gérer tout le pic de trafic. Le BFF peut rester d'un côté et gérer le cache. L'API Gateway récupère le cache, on voit la réponse aux applications du front.
Pour faire cela, aujourd'hui, nous n'avons pas beaucoup d'options. Road runner, même si ça n'a pas donné des choses mirobolantes pour l'instant. Nous n'avions pas encore FrankenPHP. On fera des tests. Une piste probable, ce sera probablement de réécrire API Gateway dans un autre langage comme Go. Ou Bref. Ce sont des pistes. Nous n'avons pas d'idées pour l'instant. Nous avons essayé des choses. Mais rien ne nous permet d'être résilients. Nous avons dû inventer toutes ces règles de fallback pour être sûrs de répondre aux API en temps et en heure avec une réponse éligible au maximum possible.
J'ai été un petit vite, je pense. Je vais vous remercier de m'avoir écouté. Avant de finir la conférence, j'aimerais insister sur le fait que nous sommes un blog technique. Je survole des choses que nous faisons. Sur le blog, nous allons plus en détail sur les choses que nous faisons. J'ai une petite live sur tout les GIF qui ont été utilisés. De quel site ou de série ils sont issus. S'il y en a qui ont des questions, vous pouvez les poser.
(applaudissements)
_ Nous avons cinq minutes pour des questions.
_ Bonjour, merci pour la conférence. Est-ce que BFF, on peut l'associer à SSR ?
_ Je pense que c'est corrélé. Ça appelle au BFF. Ça s'applique quel que soit le type d'application. Du mobile, de l'embarqué, n'importe quoi.
_ Salut. Merci pour la conf. Vous avez mis combien de temps pour faire le switch ?
_ Le switch n'a pas été fait instantanément. Il a été fait petit à petit. Nous avons mis en place les gardes initiales. Ça a été co-développé. Et si on faisait la navigation et si on faisait le téléchargement ? Il y a plein de choses qu'on aimerait faire dans le BFF et qu'on ne fait pas encore.
_ Une autre question ?
_ Devant.
_ Bonjour. Tu as parlé du téléchargement des assets et des vidéos. Avec BFF, nous n'avons pas le risque devant le téléchargement de
la vidéo qui double la bande passante une fois vers le BFF ?
_ Le BFF va seulement donner l'information d'où se trouve la vidéo. Le téléchargement ne passe pas par BFF. Nous avons des assets qui gèrent la vidéo.
_ Est-ce que nous n'avons pas une espèce d'énormes retours en arrière sur la période où nous étions full API avec tout un code iOS ou Android, et après des applications front ? Nous revenons vers des Webb view où toutes les applications sont des navigateurs simplifiés qui appellent un site sur serveur et des problématiques de cache traditionnelle ? Vous l'avez traité d'une manière Smart et industrialisée, mais sur des problématiques complexes ?
_ Le BFF, son seul métier : Comment est-ce que j'agrège d'autres métiers ? Mais il ne va pas traiter les paiements ou la problématique de vidéo. Est-ce qu'une vidéo est terminée ? C'est tous les autres API back-end dont c'est le rôle. Le métier est dispatché à travers tous les services différents. Il a un rôle de vue. Pour acheter une vidéo, l'utilisateur n'a pas regardé cinq épisodes. Mais 50 %. Le BFF, ce n'est pas son métier. Nous le réduisons au minimum pour éviter cet effet.
_ Nous avons le temps pour une dernière question.
_ Merci. Vous appelez plusieurs API, chaque bloc était indépendant et appelait les API d'une manière parallèle. Mais est-ce que vous avez des pertes de performances du fait que vous appelez... vous avez des API plus gros. Parce que vous appelez tous pour
pouvoir acheter* bloc ?
_ Nous utilisons le moteur Tornado, il y a eu des conférences de Benoit Viguier qui a expliqué comment ça se passe. Nos appels, rien n'est séquentiel. Nous parallélisons donc un maximum de choses. Nous restons dans des temps de réponse raisonnables. Un appel au BFF, nous faisons entre 10 et 20 appels à différents API.
_ Merci, Valentin. Nous nous retrouvons dans la salle à côté.
(applaudissements)
Tweets