Jekyll2024-03-01T14:39:31+00:00https://tech.bedrockstreaming.com/feed.xmlBedrock Tech BlogBlog technique de BedrockAu-delà des industries : Le pouvoir de l’état d’esprit #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/au-dela-des-industries-le-pouvoir-de-l-etat-d-esprit<blockquote>
<p>Je souhaite explorer l’idée selon laquelle le succès n’est pas défini par une industrie, une discipline ou un secteur spécifique, mais repose plutôt sur notre état d’esprit. À travers mes expériences personnelles variées - en cosmétique, marketing, e-commerce, ainsi que dans le domaine des bars, restaurants et de l’industrie - je mets en avant l’idée que les principes du succès sont universels. Cette présentation souligne l’importance de la mentalité, de la persévérance, des stratégies adoptées et d’une méthode, indépendamment du secteur professionnel.
L’objectif est d’inspirer et de redéfinir la perception du succès, en dépassant les barrières spécifiques à chaque domaine.</p>
</blockquote>
<blockquote>
<p>En résumé, c’est une approche universelle vers la réussite qui est essentielle, quel que soit le secteur d’activité</p>
</blockquote>
<p>Par <strong>Serge Menassa</strong></p>Serge MenassaJe souhaite explorer l’idée selon laquelle le succès n’est pas défini par une industrie, une discipline ou un secteur spécifique, mais repose plutôt sur notre état d’esprit. À travers mes expériences personnelles variées - en cosmétique, marketing, e-commerce, ainsi que dans le domaine des bars, restaurants et de l’industrie - je mets en avant l’idée que les principes du succès sont universels. Cette présentation souligne l’importance de la mentalité, de la persévérance, des stratégies adoptées et d’une méthode, indépendamment du secteur professionnel. L’objectif est d’inspirer et de redéfinir la perception du succès, en dépassant les barrières spécifiques à chaque domaine.Comment j’ai retrouvé le sens de la vie grâce à WebAssembly #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/comment-j-ai-retrouve-le-sens-de-la-vie-grace-a-web-assembly<blockquote>
<p>Le jeu de la vie est un drôle de jeu qui a la particularité de n’avoir pas de joueur. Il se joue de lui-même et produit des configurations qui semblent évoluer de manière autonome, sans intervention extérieure. A partir de règles très basiques, des structures d’une très grande complexité peuvent émerger d’une manière qui évoque l’apparition de la vie sur Terre à partir d’éléments inertes, d’où le nom mystérieux de jeu de la vie.</p>
</blockquote>
<blockquote>
<p>Comme ce jeu se joue idéalement sur des plateaux sans limite de taille, la question des performances de l’implémentation est capitale. Pour du développement web, cet exemple permet à la fois de voir les limites de JavaScript pour effectuer un grand nombre de calculs et de présenter une solution complémentaire à la réduction de la complexité algorithmique : une implémentation en WebAssembly qui permet de déléguer la charge de calcul à un langage compilé plus performant, Rust.</p>
</blockquote>
<p>Par <strong>Théo Gianella</strong></p>Théo GianellaLe jeu de la vie est un drôle de jeu qui a la particularité de n’avoir pas de joueur. Il se joue de lui-même et produit des configurations qui semblent évoluer de manière autonome, sans intervention extérieure. A partir de règles très basiques, des structures d’une très grande complexité peuvent émerger d’une manière qui évoque l’apparition de la vie sur Terre à partir d’éléments inertes, d’où le nom mystérieux de jeu de la vie.Du code à l’image : Aller et Retour #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/du-code-a-l-image-aller-et-retour<blockquote>
<p>Pourquoi l’intelligence artificielle doit-elle s’entraîner pour devenir meilleure, et comment fait-elle ? C’est quoi un réseau de neurones ? Comment Dall-E arrive-t-il à dessiner de si belles images ?</p>
</blockquote>
<blockquote>
<p>Depuis peu, l’intelligence artificielle fait énormément parler d’elle. Pourtant, derrière les termes de “Deep learning” et de “Réseau de neurones”, il est rare de comprendre exactement ce qui se passe dans la machine. Et si on explorait ça ?</p>
</blockquote>
<blockquote>
<p>Découvrons ensemble, dans une présentation ne demandant strictement aucune compétence technique, les bases de l’apprentissage de ces intelligences, afin de comprendre un peu plus ce qui se passe derrière les rouages et toute cette magie !</p>
</blockquote>
<blockquote>
<p>N’hésitez surtout pas à venir même sans la moindre connaissance technique, le but de cette conférence est que même votre grand-mère puisse y venir, et en ressortir en étant capable d’expliquer ce qu’est une IA !</p>
</blockquote>
<p>Par <strong>Etienne Doyon</strong></p>Etienne DoyonPourquoi l’intelligence artificielle doit-elle s’entraîner pour devenir meilleure, et comment fait-elle ? C’est quoi un réseau de neurones ? Comment Dall-E arrive-t-il à dessiner de si belles images ?Le leader imposteur #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/le-leader-imposteur<blockquote>
<p>Je ne suis <strong>pas expert</strong> de mon métier et ce n’est pas parce que j’en parle facilement que je pense le devenir un jour.
Je n’ai jamais su être un leader, et tous les <strong>leaders m’impressionnent</strong>.
Je pense que <strong>les autres sont meilleurs</strong> que moi et que je ne pourrai pas être leur égal.
J’ai été nommé <strong>par chance</strong> à un poste de <strong>leader</strong> alors que je n’en avais pas la légitimité.
Et…je n’ai <strong>jamais eu confiance en moi</strong> (j’aurais peut-être du commencer par ça)</p>
</blockquote>
<blockquote>
<p>Ceci est une histoire, MON histoire, et je vais vous parler de mon syndrome de l’imposteur.
Comment vivre avec, mes conseils, mes craintes et mes peurs…mais surtout comment vous pouvez vous aider et aider ceux qui le possède également.</p>
</blockquote>
<p>Par <strong>Mathieu Mure</strong></p>Mathieu MureJe ne suis pas expert de mon métier et ce n’est pas parce que j’en parle facilement que je pense le devenir un jour. Je n’ai jamais su être un leader, et tous les leaders m’impressionnent. Je pense que les autres sont meilleurs que moi et que je ne pourrai pas être leur égal. J’ai été nommé par chance à un poste de leader alors que je n’en avais pas la légitimité. Et…je n’ai jamais eu confiance en moi (j’aurais peut-être du commencer par ça)Le LFT du LFT - PUB LFT #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/le-lft-du-lft<blockquote>
<p>Comment aider les LFTs ?</p>
</blockquote>
<p>Par <strong>la LFTeam</strong></p>LFTeamComment aider les LFTs ?Mon premier jeu sur BGA #LFT 02/02/242024-02-02T00:00:00+00:002024-02-02T00:00:00+00:00https://tech.bedrockstreaming.com/mon-premier-jeu-sur-bga<blockquote>
<p>Introduction au jeu de société Velonimo et à la plateforme de jeux en ligne Board Game Arena, suivie d’un retour d’expérience de l’implémentation de ce jeu sur cette plateforme en tant que développeur Web.</p>
</blockquote>
<p>Par <strong>Oliver Thébault</strong></p>Oliver ThébaultIntroduction au jeu de société Velonimo et à la plateforme de jeux en ligne Board Game Arena, suivie d’un retour d’expérience de l’implémentation de ce jeu sur cette plateforme en tant que développeur Web.Journal de l’alternant - Comment j’ai perdu mes dépendances pnpm2024-01-10T00:00:00+00:002024-01-10T00:00:00+00:00https://tech.bedrockstreaming.com/2024/01/10/journal-de-l-alternant-comment-jai-perdu-mes-dependences-pnpm<p>À Bedrock, on m’a chargé de faire un POC (<a href="https://fr.wikipedia.org/wiki/Preuve_de_concept">proof of concept</a>) pour tester les avantages et les limites d’un double run entre notre app côté web (sur <a href="https://tech.bedrockstreaming.com/2017/05/17/spa-mode-isomorphism-js.html">une base maison React Server Side Rendering</a>) en déléguant des pages progressivement vers une app <a href="https://nextjs.org/">Next.js</a>. Étant tout nouveau dans le dev et encore plus nouveau sur le projet, ma vie ces derniers temps est une suite d’obstacles, d’essais, d’erreurs et de triomphes (pas toujours, mais souvent) bien mérités. Je suis habitué à faire des erreurs plus lunaires les unes que les autres, mais je vais m’attarder dans cet article sur une erreur qui m’a retourné le cerveau. Au menu : erreurs soudaines, dépendances disparues et désespoir… Bonne lecture.</p>
<p>Je suis alternant depuis un an à Bedrock et je travaille pour la première fois sur notre projet web interne. C’est un projet qui est très complexe, avec lequel vient énormément d’historique (premières briques écrite en 2014) et dont la lecture du code relève parfois autant de l’histoire que du développement.</p>
<h1 id="en-route-pour-laventure">En route pour l’aventure</h1>
<blockquote>
<p>D’ailleurs à Bedrock, si on arrive à maintenir notre application web dans la durée, c’est grâce aux <a href="https://tech.bedrockstreaming.com/2021/09/06/web-best-practices.html">bonnes pratiques qu’on essaie de respecter au mieux</a>.</p>
</blockquote>
<p>En bref, je n’ai qu’une connaissance très superficielle du projet et des outils qu’il intègre.</p>
<p>Dans mes habitudes de code, il peut parfois m’arriver d’oublier de vérifier que le code que j’écris ne vienne pas casser les tests en place dans le code. Heureusement, notre CI qui nous est chère ne manque jamais de me rappeler mon manque de rigueur. Cette fois-là, je casse un test à cause d’une erreur tellement anodine que je ne parviens pas à m’en rappeler. Je peux juste vous dire que j’ai eu le réflexe d’aller dans mon terminal de lancer le runner de test jest à l’aide de notre package manager <a href="https://pnpm.io/fr/">pnpm</a> dans une commande qui ressemble à : <code class="language-plaintext highlighter-rouge">pnpm test TEST_QUI_CASSE</code>. Le test est rouge pour une raison qui me semble venir d’un problème de dépendances. Ayant beaucoup trituré mes <code class="language-plaintext highlighter-rouge">node_modules</code>, je me dis que repartir sur des bases propres ne devrait pas faire de mal au projet. Je décide donc, sans savoir ce qui m’attend, de lancer l’innocente commande : <code class="language-plaintext highlighter-rouge">pnpm install</code></p>
<p>J’observe que pnpm fait son travail, met à jour des dépendances, je devais effectivement avoir joué un peu trop avec mes <code class="language-plaintext highlighter-rouge">node_modules</code>.</p>
<p>Je relance le test et là quelle ne fut pas ma surprise quand mon terminal, sans trembler, m’a affiché <code class="language-plaintext highlighter-rouge">Command: "jest" not found</code>.</p>
<p>Je commence à penser que je ne viens pas seulement de casser un test, mais j’ai également cassé <a href="https://jestjs.io/fr/">jest</a>. À ce moment-là, je venais de ressortir d’une bataille avec des dépendances et donc je venais de me familiariser avec le <code class="language-plaintext highlighter-rouge">node_modules</code> <code class="language-plaintext highlighter-rouge">.pnpm</code> et autre <code class="language-plaintext highlighter-rouge">.bin</code> . C’est dans ce dernier dossier que je me rends compte qu’effectivement, il y manque l’exécutable jest.</p>
<p>En fait, il y manque également d’autres outils que je m’attendais à trouver comme <a href="https://prettier.io/">prettier</a> et <a href="https://eslint.org/">eslint</a>.</p>
<p>Je me dis que la portée de mon problème vient de s’étendre de jest à mes <code class="language-plaintext highlighter-rouge">node_modules</code>. 🫠</p>
<p>Désespéré, je tente une recherche globale des mots clés : <strong>prettier</strong> et <strong>eslint</strong>. Je finis par trouver une correspondance intéressante dans le fichier <code class="language-plaintext highlighter-rouge">.npmrc</code>.</p>
<p>Voilà à quoi ressemble le fichier à ce moment-là :</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>public-hoist-pattern[]=*@testing-library/jest-dom*
public-hoist-pattern[]=*@testing-library/react*
public-hoist-pattern[]=*@testing-library/user-event*
public-hoist-pattern[]=*enzyme*
public-hoist-pattern[]=*jest*
public-hoist-pattern[]=*redux-mock-store*
public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*
</code></pre></div></div>
<p>Je peux sentir qu’il s’agit d’une véritable piste parce que dans ce fichier sont listées toutes les dépendances qui sont cassées sur ma machine.</p>
<h2 id="comprendre-la-configuration-de-pnpm">Comprendre la configuration de pnpm</h2>
<h3 id="hoisting-des-dépendances">Hoisting des dépendances</h3>
<p>Pour comprendre la configuration <code class="language-plaintext highlighter-rouge">public-hoist-pattern</code> il faut d’abord comprendre comment sont formés les <code class="language-plaintext highlighter-rouge">node_modules</code> par pnpm. Il ne va mettre dans le dossier <code class="language-plaintext highlighter-rouge">node_modules</code> en racine uniquement les dépendances directes du projet, toutes les sous-dépendances seront placées dans un dossier caché <code class="language-plaintext highlighter-rouge">.pnpm</code> et un lien symbolique sera créé.</p>
<blockquote>
<p>Je vous invite à lire la <a href="https://pnpm.io/symlinked-node-modules-structure">documentation écrite par pnpm</a> afin de comprendre leur système de dépendances.</p>
</blockquote>
<p>Cela peut parfois poser des problèmes avec des libraries qui utilisent des dépendances fantômes. C’est pourquoi pnpm laisse quand même du contrôle sur ce comportement.</p>
<blockquote>
<p>On parle de dépendance fantôme pour désigner toutes les dépendances qui ne sont pas désignées dans le <code class="language-plaintext highlighter-rouge">package.json</code> root mais qui sont quand même nécessaire pour le bon fonctionnement de l’application.</p>
</blockquote>
<p><code class="language-plaintext highlighter-rouge">public-hoist-pattern</code> permet d’indiquer les dépendances qu’on veut forcer à être dans le dossier <code class="language-plaintext highlighter-rouge">node_modules</code> racine plutôt que dans<code class="language-plaintext highlighter-rouge">node_modules/.pnpm</code>.</p>
<p>La ligne <code class="language-plaintext highlighter-rouge">public-hoist-pattern[]=*jest*</code> veut donc dire qu’on ajoute jest aux dépendances qui sont accessibles depuis la racine et ainsi l’exécutable dans <code class="language-plaintext highlighter-rouge">node_modules/.bin</code> . Cela permet par exemple de déléguer la configuration et l’import de jest dans un package enfant du repository.</p>
<h3 id="retour-à-lhistoire-lets-debug">Retour à l’histoire… let’s debug</h3>
<p>A cet instant je suis convaincu que c’est le fichier <code class="language-plaintext highlighter-rouge">.npmrc</code> qui est responsable de l’erreur <code class="language-plaintext highlighter-rouge">Command: "jest" not found</code>. Je ne vois rien d’anormal dans ce fichier qui pourrait me mettre la puce à l’oreille, c’est alors que je me dis que peut être pnpm ne lit pas la bonne configuration. En lisant la documentation, je tombe sur la commande parfaite : <code class="language-plaintext highlighter-rouge">pnpm config get</code>. Cette commande permet d’afficher la configuration que résout pnpm. La sortie de cette commande m’a mis sur une nouvelle piste puisque c’est là que j’ai vu apparaître la ligne problématique : <code class="language-plaintext highlighter-rouge">shamefully-hoist=false</code>.</p>
<p>Je tente de chercher dans le projet où est écrite cette ligne. Aucune trace de cette maudite ligne. Je retourne tout le projet à la recherche d’une ligne de code qui pourrait ajouter cette ligne de configuration. Je me mets à lire toute la documentation pnpm pour pouvoir comprendre d’où cette ligne peut venir. Après avoir désinstallé et réinstallé pnpm, node et redémarré mon PC, je tente dans un dernier espoir de créer un dossier <code class="language-plaintext highlighter-rouge">test-a-laide</code> dans lequel je reclone le projet. Malheureusement, rien n’y fait.</p>
<p>C’est à ce moment que je me dis que si le problème ne vient pas de mes outils ni de la configuration locale, il faut peut-être que j’aille chercher dans ma configuration globale. En effet, en ouvrant cette dite configuration <code class="language-plaintext highlighter-rouge">~/.npmrc</code>, je m’aperçois que c’est de là que vient la ligne <code class="language-plaintext highlighter-rouge">shamefully-hoist=false</code>. C’est un soulagement, j’ai enfin trouvé d’où cette ligne mystique venait.</p>
<blockquote>
<p>Je suis encore à la recherche de la réponse à la question : pourquoi diable, ai-je mis cette configuration dans mon <code class="language-plaintext highlighter-rouge">.npmrc</code> global. Je pense me souvenir l’avoir fait en me disant que je voulais m’assurer que pnpm se comporte en faisant des symlinks (l’intention n’était pas mauvaise, mais la conséquence pas joyeuse).</p>
</blockquote>
<p>On peut lire dans la documentation de pnpm que : <em>Setting shamefully-hoist to true is the same as setting <code class="language-plaintext highlighter-rouge">public-hoist-pattern</code> to *.</em></p>
<p>En d’autres termes <code class="language-plaintext highlighter-rouge">shamefully-hoist</code> à une influence sur le hoisting de toutes les dépendances du projet.</p>
<p>J’ai deux problèmes avec la documentation à ce sujet :</p>
<ul>
<li>Tout d’abord, il n’est pas explicité le cas inverse à savoir si on met <code class="language-plaintext highlighter-rouge">shamefully-hoist=false</code> alors ça revient à écraser toutes les configurations de <code class="language-plaintext highlighter-rouge">public-hoist-pattern</code></li>
<li>Le comportement, qu’il soit un bug ou un cas à la marge, de la configuration globale de <code class="language-plaintext highlighter-rouge">shamefully-hoist</code> qui écrase la configuration locale de <code class="language-plaintext highlighter-rouge">public-hoist-pattern</code> n’est pas spécifié</li>
</ul>
<p>Bref, après avoir déduit que c’était cette ligne qui cassait mon hoisting, je retire la ligne et je lance un pnpm install. Bingo ! Je récupère toutes mes dépendances perdues.</p>
<h2 id="enseignements">Enseignements</h2>
<p>J’essaie a posteriori de déchiffrer pourquoi j’ai eu ce problème et comment faire en sorte que cela n’arrive pas. Je pense être tombé sur un comportement étrange de pnpm. Je ne sais pas s’il s’agit d’un bug ou d’une feature. En effet, intuitivement, j’aurais tendance à dire qu’une configuration globale de <code class="language-plaintext highlighter-rouge">shamefully-hoist</code> ne devrait pas override la configuration locale de <code class="language-plaintext highlighter-rouge">public-hoist-pattern</code>. Je suis prêt à entendre que le comportement est attendu et voulu, mais dans ce cas je pense qu’un peu plus de documentation à ce sujet ne peinera personne. À cet égard j’ai ouvert <a href="https://github.com/pnpm/pnpm/issues/7312">une issue</a> sur le Github de pnpm.</p>
<p>Je retire plusieurs enseignements de cette aventure :</p>
<ul>
<li>Douter de la configuration qui est lue par les outils</li>
<li>La documentation ne contient pas toujours tous les comportements</li>
<li>Il faut penser à voir plus loin que son fichier local de config et penser aux potentielles surcharges…</li>
</ul>["j_poissonnet"]À Bedrock, on m’a chargé de faire un POC (proof of concept) pour tester les avantages et les limites d’un double run entre notre app côté web (sur une base maison React Server Side Rendering) en déléguant des pages progressivement vers une app Next.js. Étant tout nouveau dans le dev et encore plus nouveau sur le projet, ma vie ces derniers temps est une suite d’obstacles, d’essais, d’erreurs et de triomphes (pas toujours, mais souvent) bien mérités. Je suis habitué à faire des erreurs plus lunaires les unes que les autres, mais je vais m’attarder dans cet article sur une erreur qui m’a retourné le cerveau. Au menu : erreurs soudaines, dépendances disparues et désespoir… Bonne lecture.Bedrock aux API Days Paris (2023)2023-12-20T00:00:00+00:002023-12-20T00:00:00+00:00https://tech.bedrockstreaming.com/api-days-paris-2023<p>Cette année Bedrock a envoyé 7 de ses collaborateurs et collaboratrices (i.e. nous, les auteurs de cet article) à l’édition 2023 des conférences “API Days” à Paris.</p>
<p>L’événement a eu lieu au CNIT à La Défense (juste en face du marché de Noël) et a duré 3 jours, du Mercredi 06/12/23 au Vendredi 08/12/23.</p>
<p><img src="/images/posts/api-days-paris-2023/la-defense.png" alt="La Défense à Paris" /></p>
<p>En plus des 11 paires de chaussettes différentes 🧦 que nous avons réussi à débusquer en parlant aux différents partenaires sur place… En tout, <a href="https://www.apidays.global/paris/#schedule">ce sont plus de 100 talks, répartis dans 9 salles, qui nous ont été présentés</a>.</p>
<p>Voici, un résumé de quelques-uns des talks que nous souhaitions mentionner sur ce blog 👇</p>
<h2 id="making-the-most-of-your-openapi-spec">Making the Most of Your OpenAPI Spec</h2>
<blockquote>
<p>Conférence présentée par Alexander Broadbent (Principal Engineer - SAPI)</p>
</blockquote>
<p>Cette conférence expliquait, en détail, une technique “design-first” permettant d’éradiquer les erreurs de “désynchronisation” entre la documentation d’une API et son comportement réel, tout en générant une partie du code.</p>
<p><img src="/images/posts/api-days-paris-2023/what-we-are-doing.png" alt="What we are doing" /></p>
<p><img src="/images/posts/api-days-paris-2023/how-we-are-winning.png" alt="How we are winning" /></p>
<p>Cette technique peut se résumer en quelques points :</p>
<ul>
<li>la documentation OpenAPI est la source de vérité et décrit l’intégralité des endpoints de l’application (celle-ci peut être fragmentée en plusieurs fichiers)</li>
<li>un outil (<a href="https://github.com/Redocly/redoc">redocly</a>) regroupe tous les documents OpenAPI dans un même fichier</li>
<li>un outil (<a href="https://github.com/drwpow/openapi-typescript">openapi-typescript</a>) génère le typage Typescript correspondant au fichier OpenAPI</li>
<li>un outil (<a href="https://github.com/seriousme/fastify-openapi-glue">fastify-openapi-glue</a>) applique le typage Typescript généré sur le code des différents endpoints de l’API <a href="https://fastify.dev/">Fastify</a> afin de s’assurer que le code produit par les développeurs est conforme à la documentation</li>
</ul>
<p>Et pour les détails d’implémentation, le repository GitHub de la démo d’Alexander est disponible ici : <a href="https://github.com/AlexBroadbent/openapi-demo">https://github.com/AlexBroadbent/openapi-demo</a></p>
<h2 id="forget-typescript-choose-rust-to-build-robust-fast-and-cheap-apis">Forget TypeScript, Choose Rust to build Robust, Fast and Cheap APIs</h2>
<blockquote>
<p>Conférence présentée par Zacaria Chtatar (Backend Software Engineer - HaveSomeCode)</p>
</blockquote>
<p>Cette conférence au titre subversif expliquait pourquoi Zacaria, développeur Typescript/NodeJS à ClubMed, en est arrivé à s’intéresser très fortement au langage de programmation Rust… Au point d’en faire la promotion, en anglais (respect), aux API Days.</p>
<p>La première partie de sa conférence parlait du langage de programmation Typescript, en dressant une liste de ses qualités (fullstack, très largement déployé en entreprise, écosystème riche, …) et de ses défauts (gestion d’erreur optionnelle, typage éphémère, runtime principal peu performant, …). Cette première partie s’est achevée par un message clair : “Typescript is not enough”.</p>
<p><img src="/images/posts/api-days-paris-2023/typescript-is-not-enough.png" alt="Typescript is not enough" /></p>
<p>La suite et fin de la présentation, quant à elle, était une introduction à Rust.</p>
<p><img src="/images/posts/api-days-paris-2023/introducing-rust.png" alt="Introducing Rust" /></p>
<p>Bien que nous étions surpris de voir que <a href="https://survey.stackoverflow.co/2023/#section-admired-and-desired-programming-scripting-and-markup-languages">le langage de programmation préféré des développeurs</a> de ces 8 dernières années, et sur lequel <a href="https://foundation.rust-lang.org/members/">les plus grosses entreprises tech du monde misent aujourd’hui</a>, avait encore besoin d’être mis en avant en 2023… Zacaria a effectivement eu raison d’en remettre une couche, car encore trop peu d’entreprises françaises ont pris conscience des avantages qu’offre Rust.</p>
<p>Cependant, cette 2ème partie de conférence avait un goût de déjà vu pour nous car un de nos collaborateurs a déjà donné le même genre de conférence à Bedrock durant <a href="https://tech.bedrockstreaming.com/lft/">nos LFT</a> 2 années auparavant (en partant de PHP plutôt que de Typescript)… Ceci étant, grâce à nos 2 ans d’expérience de Rust en production et pour les raisons évoquées par Zacaria durant son talk, Bedrock est en mesure de témoigner sa satisfaction d’avoir pris le temps de réécrire certaines des API les plus critiques de Bedrock en Rust. Et nous espérons que de nombreuses entreprises oseront suivre notre exemple, afin de permettre aux développeurs soucieux de la qualité de leur travail comme Zacaria, de disposer de ce merveilleux langage de programmation.</p>
<p>Et si vous ne comprenez toujours pas l’intérêt de Rust, <a href="https://www.youtube.com/watch?v=eSo3e3ugn5g">le talk de Zacaria est disponible en replay sur Youtube</a>.</p>
<h2 id="real-life-rest-api-versioning-strategies-and-best-practices">Real-Life REST API Versioning: Strategies and Best Practices</h2>
<blockquote>
<p>Conférence présentée par Alexandre Touret (Senior Software Architect - Worldline)</p>
</blockquote>
<p>La gestion des versions dans le contexte des API au sein d’une entreprise peut souvent s’avérer être un défi complexe et délicat. En effet, les interfaces de programmation applicative (API) constituent le cœur des interactions entre différents services et applications au sein d’un écosystème numérique. La nécessité de versionner ces API devient impérative pour garantir une évolution harmonieuse tout en préservant la compatibilité avec les systèmes existants.</p>
<p>Worldline fait partie des entreprises avec une architecture technique complexe, exposant à des clients finaux un modèle métier en constante évolution.
Ce problème fait très fortement écho avec le business model de Bedrock.</p>
<p>Dans sa conférence, Alexandre a présenté son retour d’expérience sur comment versionner une API. Et comment l’exercice est loin d’être un long fleuve tranquille. Voici les points clés que nous avons retenus :</p>
<h4 id="toutes-les-apis-ne-nécessitent-pas-dêtre-versionnées">Toutes les APIs ne nécessitent pas d’être versionnées</h4>
<p>Le versioning c’est compliqué. C’est un fait. Autant l’appliquer sur des APIs où ce principe est vraiment utile. Il est effectivement peut-être moins utile de versionner une API interne, non exposée sur internet ou avec un périmètre fonctionnel très limité ou stable.
Voici les questions proposées par Alexandre qui peuvent nous aider dans notre décision : ai-je besoin de versionner ? Combien de versions dois-je gérer en parallèle ? Est-ce que ma plateforme est compatible ? Quels sont les impacts sur ma configuration, mon modèle de données, <strong>mon système d’authentification</strong> (Alexandre a bien insisté sur ce point. Il ne faut pas négliger l’authentification dans la problématique du versioning) ?</p>
<h4 id="le-versioning-sapplique-aussi-sur-une-architecture-en-micro-service">Le versioning s’applique aussi sur une architecture en micro service</h4>
<p>On a tendance à croire que seules “les grosses API” sont concernées par le versioning mais Alexandre nous a montré qu’il n’en est rien. Un micro service, aussi micro (voir macro) qu’il soit, gère à lui tout seul un périmètre fonctionnel. Il est donc légitime qu’il puisse évoluer au fil des versions.</p>
<h4 id="comment-gérer-le-versioning">Comment gérer le versioning</h4>
<p>Plusieurs solutions, directement dans l’URL, via header (plus facile avec une API existante)
Alexandre a fortement déconseillé d’utiliser le versioning par content type. À la fois peu lisible et difficilement maintenable.</p>
<p><img src="/images/posts/api-days-paris-2023/api-versioning.png" alt="Comment gérer le versionning" /></p>
<h4 id="limpact-du-versioning">L’impact du versioning</h4>
<p>Versionner une API change en profondeur nos manières de travailler. Et ce à plusieurs niveaux :</p>
<ul>
<li>Le code source, la technique. Il est indéniable que le code source ainsi que l’architecture technique de vos projets s’en verra impactés. L’impact ne s’arrête pas au code en lui-même, mais sur tout ce qui gravite autour. Nos bases de données, nos scripts, nos configurations serveur ou nos images docker par exemple</li>
<li>Le produit. Nos API exposent le métier de notre produit. L’impact n’est donc pas que technique, mais aussi fonctionnel / produit. Une évolution de version technique entraine des breaking change et inversement. Il est donc très important, les équipes et produit travaillent de pair pour évoluer ensemble</li>
<li>La livraison. Avoir plusieurs versions d’un API complexifie la mise en production de cette dernière. Il faudra très certainement revoir nos pipelines d’intégration et de déploiement. Ce point est, lui aussi, à ne pas négliger et nécessitera un travail commun au sein des équipes techniques</li>
</ul>
<h4 id="lobservabilité">L’observabilité</h4>
<p>Alexandre nous a aussi parlé de l’importance d’avoir de la visibilité sur ce qu’il se passe en production, et tout particulièrement à la maille des différentes versions de nos API.</p>
<p>L’observabilité est quelque chose de plus en plus répandu dans notre métier. Mais le versioning porte le concept encore un cran au-dessus.</p>
<p>Il est primordial d’être capable d’assurer une bonne observabilité de nos APIs à la maille :</p>
<ul>
<li>De la version</li>
<li>Des clients (via des API Keys dédiées)</li>
</ul>
<p>Une bonne observabilité est la clé pour définir une bonne stratégie et être capable d’anticiper le dé commissionnement de versions obsolètes. Ce point est selon moi très important.</p>
<p>Il est très (très) compliqué de maintenir un nombre trop élevé de versions pour une même API. Sans parler d’obsolescence programmée, il faut trouver le bon niveau de maintenance pour éviter de tomber dans le piège de la dette technique. Pas facile comme sujet !</p>
<p>Pour finir, je tiens à remercier Alexandre pour sa conférence vraiment intéressante. Bourrée d’exemples concrets. J’ai vraiment senti une vraie maîtrise du sujet. Bravo ! Cette conférence est mon coup de cœur de l’API Days Paris 2023.</p>
<h2 id="our-ongoing-journey-from-rest-to-graphql-on-android">Our Ongoing Journey From REST To GraphQL On Android</h2>
<blockquote>
<p>Conférence présentée par Julien Salvi (Lead Android Engineer - Aircall)</p>
</blockquote>
<p>Durant cette présentation, Julien Salvi, Lead Android Engineer chez Aircall nous fait un retour d’expérience sur la migration de l’équipe Android d’une API REST à une API GraphQL. Ce choix a été motivé par plusieurs raisons :</p>
<ul>
<li>Une problématique globale sur le scaling de leur API REST</li>
<li>L’efficacité et l’agrégation des données des API GraphQL</li>
<li>La recherche d’une alternative Serverless</li>
<li>L’objectif de limiter les perturbations pour les clients</li>
</ul>
<p>Leur aventure débute mi 2020 et est toujours en cours.</p>
<p><img src="/images/posts/api-days-paris-2023/graphql-api-journey.png" alt="GraphQL API journey" /></p>
<p>Pour répondre à ces demandes, les équipes ont dirigé leur choix vers GraphQL pour créer leur nouvelles API, qui a plusieurs avantages selon Julien notamment:</p>
<ul>
<li>La possibilité pour les clients de récupérer seulement les données dont ils ont besoin, cela évite l’over-fetching et l’under-fetching</li>
<li>Les clients peuvent récupérer de multiples ressources dans une seule requête</li>
<li>GraphQL propose un moyen d’établir une connection constante entre le client et le serveur, ce qui augmente la scalabilité en temps réel</li>
<li>Le fort typage de GraphQL permet une communication claire, réduisant ainsi les erreurs</li>
<li>L’amélioration de la performance globale grâce au batching des requêtes</li>
</ul>
<p>L’équipe Android utilise le service <a href="https://aws.amazon.com/fr/appsync/">AppSync d’AWS</a>, facilitant le filtrage, permetttant de faire du realtime, assurer une scalabilité et une bonne intégration avec ElasticSearch et DynamoDB.</p>
<p>Après les premières migrations vers les API GraphQL, le conférencier insiste sur l’importance du monitoring, qui chez eux est présent que ce soit pour les queries ou les mutations.</p>
<p>Voici les points à retenir de leur expérience</p>
<p><img src="/images/posts/api-days-paris-2023/key-takeaways.png" alt="Key takeaways" /></p>
<p>Pour finir, revenons sur un de leur point à surveiller, Julien nous évoque l’importance de la collaboration entre les équipes front et backend qui est également selon nous très importante, notamment pour optimiser l’efficacité des API. On peut citer comme actions par exemple, se mettre d’accord sur les meilleurs timeout à adopter sur les API ou aussi créer les schémas OpenApi ensemble.</p>
<h2 id="why-api-contracts-matters">Why API Contracts matters</h2>
<blockquote>
<p>Conférence présentée par Stéve Sfartz (Principal Architect - Cisco)</p>
</blockquote>
<p>Cette présentation par le Principal Architect de Cisco nous explique pourquoi, dans une stratégie API First, le besoin d’avoir des contrats ainsi qu’un cycle de vie de l’API est primordial pour la cohérence du système.</p>
<p>Ils formalisent leur contrats d’API via OpenAPI Spécification, un standard pour les contrats d’API REST, en complément de documents OpenAPI, pour former la définition de l’API. A côté de cette définition, on trouve la gestion du cycle de vie (lifecycle) de l’API, pour informer des deprecated, du changelog et des Breaking Changes lors des versions majeures (semantic versionning).</p>
<p><img src="/images/posts/api-days-paris-2023/api-contract-definition-and-lifecycle.png" alt="Definition and Lifecycle for an API" /></p>
<p>Lors de la mise en place de ces contrats pour les API à cisco, une qualité (qu’ils appellent aussi Health Contract) y a été associée pour avoir une vue d’ensemble de la documentation des API. Ayant environ 2000 API, cette qualité ne peut pas être évaluée à la main au cas par cas, et passe donc par des outils d’analyse tels qu’un linter Spectral, pour éviter les erreurs et automatiser la génération de ce statut.</p>
<p><img src="/images/posts/api-days-paris-2023/api-contract-quality.png" alt="API Contract Quality" /></p>
<p>Vient ensuite la gestion du drift entre la documentation et le code (par exemple si une annotation est oubliée, une route non documentée) : la vérification du drift doit être faite lors de la CI/CD.</p>
<p>La conférence se conclut sur une question simple : “Quelle est la source de vérité pour vos API ?”. La réponse est bien évidemment le code, mais une documentation générée automatiquement permet justement de s’en rapprocher grandement. A Bedrock, nos API GraphQL ont leur documentation (schéma) généré automatiquement à partir du code lors du merge d’une PR, ce qui permet d’éviter les oublis de mise à jour.</p>
<h2 id="lets-bring-science-into-api-docs">Let’s bring science into API docs</h2>
<blockquote>
<p>Conférence présentée par Lana Novikova (Technical Writer - JetBrains)</p>
</blockquote>
<p>Au cours de cette conférence, Lana Novikova explore comment fusionner les principes scientifiques avec une communication technique efficace dans la documentation des API.
Elle partage également ses connaissances sur la façon dont les développeurs et développeuses consomment l’information en ligne, en mettant en lumière les liens avec différents styles cognitifs, le tout appuyé par des articles scientifiques. Elle explique de manière concrète comment ces principes peuvent être appliqués dans la documentation des API et comment ils peuvent contribuer à améliorer l’expérience des développeurs et développeuses.
<a href="https://www.youtube.com/watch?v=9SdGWU867bs">Sa conférence est une extension d’un précédent talk qu’elle a donné en 2022 à la “Write The Docs Australia”</a></p>
<p>La première étude que nous présente Lana s’intitule <a href="https://www.cs.mcgill.ca/~martin/papers/tse2013a.pdf">“Patterns of Knowledge in API Reference Documentation”</a>.
Elle parle de la nature et de l’organisation des connaissances contenues dans la documentation de référence de centaines d’API au sein de deux plateformes technologiques : Java SDK 6 et .NET 4.0. L’étude a, entre autres, consisté à élaborer une taxonomie des types de connaissances et a pu dresser la liste de 12 types de connaissances distinctes dans la documentation de l’API :</p>
<p><img src="/images/posts/api-days-paris-2023/taxonomy-of-knowledge-types.png" alt="Taxonomy of Knowledge Types" /></p>
<p>À travers cette étude, nous pouvons donc évaluer le contenu de la documentation de notre API en fonction des types de connaissances et ainsi développer des modèles de documentation adaptés aux connaissances communément associées aux différents types de composants de l’api. De plus, aujourd’hui, des projets comme <a href="https://thegooddocsproject.dev/">the good docs project</a> existent et proposent des templates de documentation basés sur ces données scientifiques.</p>
<p>La deuxième étude exposée dans cette conférence a comme titre <a href="http://sigdoc.acm.org/wp-content/uploads/2019/01/CDQ18002_Meng_Steinhardt_Schubert.pdf">“How Developers Use API Documentation: An Observation Study”</a>. Sa méthodologie consiste à l’observation active, via des screencasts et des protocoles verbaux, des activités des personnes participantes pendant le test. Les chercheurs et chercheuses ont évalué le taux de réussite, le temps passé sur les tâches et l’utilisation de la documentation et des catégories de contenu. L’objectif principal est d’observer comment les développeurs et développeuses abordent les tâches avec une API qu’elles ne connaissent pas. Il s’agit également d’analyser comment les développeurs et développeuses utilisent les ressources d’information proposées par la documentation de l’API. Cela permet de caractériser les stratégies adoptées par les développeurs et développeuses lorsqu’elles commencent à travailler avec une nouvelle API. La conclusion que Lana nous partage est qu’en moyenne, les personnes participantes ont utilisé la documentation de l’API environ 49 % du temps (Min : 31 %, Max : 68 %). La catégorie de contenu à laquelle il est fait référence le plus souvent est “API reference”, suivie de “Recipes page”.</p>
<p><img src="/images/posts/api-days-paris-2023/content-categories-of-the-api-documentation.png" alt="Content categories of the API documentation used for the test" /></p>
<p><img src="/images/posts/api-days-paris-2023/proportion-of-time-spent-on-individual-content-categories.png" alt="Proportion of time spent on individual content categories" /></p>
<p>Il se dégage que le temps que les personnes participantes consacrent aux différentes catégories de contenu varie considérablement d’une personne à l’autre. Sur la base de ces données, les chercheurs et chercheuses ont défini trois types de personnages de développeurs logiciels à la recherche d’informations ainsi que leurs approches lorsqu’ils opèrent celles-ci: Systematic learners, Opportunistic learners et Pragmatic learners. Pour les personnes curieuses d’approfondir le sujet, ces personae sont basés sur une autre étude intitulée <a href="https://www.researchgate.net/publication/30815675_What_is_an_End_User_Software_Engineer">“What is an end user software engineer?”</a>.</p>
<p>Lana Novikova conclut en mettant l’accent sur le fait qu’il faut respecter les différentes stratégies adoptées par les développeurs et les développeuses lorsqu’elles abordent une nouvelle API et nous propose d’appliquer ces conseils :</p>
<ul>
<li>Pour les “opportunistic learners”, donner des exemples de code complets et exhaustifs en donnant la possibilité de masquer tout le reste et de relier le texte au code.</li>
<li>Pour les “systematic learners”, fournir des informations importantes de manière redondante et donner des connaissances de base pertinentes.</li>
<li>Pour les “pragmatic learners” (et les autres), donner un moyen technique pour commencer à utiliser une API.</li>
</ul>
<p>Je tiens personnellement à souligner qu’il est rare d’assister à une conférence aussi complète se basant sur autant de données scientifiques. Je ressors de cette conférence agréablement surpris de la qualité de tout ce qui a été proposé et des ressources mises à disposition. Je vous laisse avec <a href="https://speakerdeck.com/lananovikova10/lets-bring-science-into-api-docs-c9bd5a57-df28-4fa3-9388-d2d9d9a044bd">un lien contenant toutes les slides de la présentation de Lana Novikova</a> qui expliquera bien mieux le propos que mon résumé. Bravo à elle et à son travail, en espérant voir de plus en plus de conférences de ce genre à l’avenir.</p>
<h2 id="le-mot-de-la-fin">Le mot de la fin</h2>
<p>Si on vous a donné envie d’en savoir plus :</p>
<ul>
<li>le <a href="https://www.apidays.global/paris/">site officiel de la conférence</a></li>
<li>la majorité des <a href="https://www.youtube.com/watch?v=NdlhxIVlSEM&list=PLmEaqnTJ40OryW56Qo3c-C7hXcaR89xii">talks sont disponibles sur Youtube</a></li>
<li>certains speakers ont mis à disposition <a href="https://fr.slideshare.net/APIdays_official/presentations">les slides de leur talk</a></li>
</ul>
<p>Bonnes fêtes de fin d’année !</p>
<p><img src="/images/posts/api-days-paris-2023/team.jpg" alt="Team API Days Paris 2023" /></p>["g_bouyge", "j_hardeman", "k_phan", "n_alscher", "o_thebault", "o_weber", "t_geindre"]Cette année Bedrock a envoyé 7 de ses collaborateurs et collaboratrices (i.e. nous, les auteurs de cet article) à l’édition 2023 des conférences “API Days” à Paris.Bedrock at 2023 AWS re:Invent Las Vegas2023-12-18T00:00:00+00:002023-12-18T00:00:00+00:00https://tech.bedrockstreaming.com/2023/12/18/aws-reinvent-lasvegas-2023<p>AWS re:Invent 2023 was a showcase for GenAI. It was the announcement of Amazon Q, Amazon’s new AI assistant, that attracted the most interest, designed to meet the specific needs of businesses.</p>
<p>Alongside these announcements, we had the opportunity to attend talks by some of the major players in streaming, such as Prime Video, Peacock, Netflix and Spotify. Their presentations offered valuable insights into their challenges, successes and lessons learned, enriching our own understanding of the sector.</p>
<h2 id="how-amazon-scales-resilience-to-new-heights">How Amazon scales resilience to new heights</h2>
<p><img src="/images/posts/2023-12-18-aws-reinvent-lasvegas-2023/aws-reinvent-2023-resilience.jpg" alt="Practice like you play" /></p>
<p>Olga Hall, Director of Live Events Availability & Resilience at Amazon Prime Video, and Lauren Domb, Chief Technologist, WWP Federal Financial Services, WW Chaos Engineering Lead at AWS, <a href="https://www.youtube.com/watch?v=r3J0fEgNCLQ">discussed the importance of resilience in the streaming industry</a>.</p>
<p>They highlighted the high cost of downtime and the impact on companies’ ability to serve their customers. We’re talking about an average of $300,000 per hour across the industry.</p>
<p>In their view, preparing engineering teams for peak loads and streaming is very similar to preparing sports teams for major events. So they created a “resilience playbook”, a series of strategies and tactics inspired by the most successful sports teams, to help their teams become resilient in the face of the unpredictable.</p>
<p>They also shared their experience of broadcasting Thursday night soccer matches on Prime Video, highlighting how they had to manage unpredictable conditions, such as weather-related match delays, which extended the duration of the peak workload.</p>
<p>Availability is considered the number 1 feature at Amazon Prime Video. All projects and workflows are listed, budgeted and included in the list of expected features, with availability always at the top of the list.
To guarantee the availability of their services, they run load tests three times a week in each region, scaled for peak usage. This enables them to detect bugs before they affect users, and ensure that their systems are ready to handle the highest loads.</p>
<p>At Bedrock Streaming, we share this focus on resilience. Our applications incorporate circuit breakers, we run load tests very regularly and practice chaos engineering.
These practices at Amazon Prime Video offer an interesting perspective on how we might further improve our resilience at Bedrock Streaming. We were particularly impressed by the resilience score per application approach. This is definitely something we’ll be exploring in conjunction with a feature flipping by service approach.</p>
<h2 id="surviving-overloads-how-amazon-prime-day-avoids-congestion-collapse">Surviving overloads: How Amazon Prime Day avoids congestion collapse</h2>
<p>Jim Roskind, Distinguished Engineer at Amazon.com, and Ankit Chadha Solution Architect at AWS <a href="https://www.youtube.com/watch?v=fOYOvp6X10g">shared their experiences and knowledge at the conference</a>. Formerly of Google, where he oversaw Google Chrome metrics and performance, Jim now works for Amazon with a singular mission: to buy less of AWS products. This approach, aimed at reducing IT costs, is supported by AWS, which wants to teach all its customers how to optimize their spending.</p>
<p>However, this quest for efficiency and cost reduction is not without risks. One of Jim’s main concerns is congestion collapse, a phenomenon that can lead to a drop in productivity and even paralyze a system. To help us understand this phenomenon, Jim presented a series of pragmatic examples and theories on congestion collapse.</p>
<p>What is congestion collapse?</p>
<p>Congestion collapse occurs when demand exceeds a system’s capacity. This leads to the build-up of queues, reduced productivity and, in extreme cases, the complete cessation of productive work. This phenomenon is not uncommon and can occur in a variety of situations, from highways to web servers.</p>
<p>Jim shared some examples to illustrate this phenomenon, the main one was about
Amazon Prime Day 2018. Even giants like Amazon aren’t immune to congestion collapse.
He hadn’t anticipated customer interest in a particular product. They had a massive demand for a product display and the service ended up being unavailable. At this point, traffic increased again sharply as customers began reloading the page. Above all, it highlights the fact that, as their services are slow to respond, the answers are no longer relevant, leaving us with a system that is 100% loaded and no longer doing anything useful.</p>
<p>These examples show that congestion collapse is a real problem that requires constant attention and planning.</p>
<p>At bedrock we’ve also encountered congestion collapse. For example, during busy events such as soccer matches, we’ve already encountered the case where a massive influx of users would cause the platform to become unavailable, at which point all the users would press F5 at the same time, drastically increasing the traffic on an already struggling platform. Moreover, requests are queued up and we end up answering requests issued 1 or 2 min earlier, and therefore answering people who have surely already left.</p>
<p>Jim mentions this issue, which has happened at amazon.com.</p>
<p>They were able to implement 2 solutions in particular.</p>
<ul>
<li>
<p>The first, when the servers can no longer respond, is to display a page with a message warning the user to wait a while and try again in a while. This had a surprisingly noticeable effect. Users were no longer repeatedly pressing the F5 button.</p>
</li>
<li>
<p>Secondly, they have implemented mechanisms to detect massive retries and thus avoid transmitting traffic to their backend. In particular, they have implemented this in the WAF service.</p>
</li>
</ul>
<p>At Bedrock Streaming we already display a page in case of trouble, but we can improve it to suggest to the user to wait before retrying. Moreover, we use Cloudfront and WAF on almost all our services. We have a few rules on WAF that allow us to deny traffic that seems illegitimate, but we’re going to work on a new rule to avoid transmitting untimely user retries in the event of an overloaded system.</p>
<h2 id="netflix-caching">Netflix caching</h2>
<p><em>“Who in this room is a netflix user?” (90% of the room raises its hand)</em>: no doubt Prudhviraj Karumanchi, software engineer & Sriram Rangarajan, Senior Distributed Systems Engineer at Netflix, conference speakers, know how to introduce their talk and remind us that they are the market giants. <a href="https://www.youtube.com/watch?v=85TiFrDhCR4">During their conference</a>, they presented how Netflix uses the EVCache solution for multi-region cache replication.</p>
<p>Netflix likes to say that one of its missions is to spread joy. This involves two aspects: offering users a fully personalized homepage and
benefiting from a scalable, low-cost architecture (so that Netflix’s techies are happy too).</p>
<p><img src="/images/posts/2023-12-18-aws-reinvent-lasvegas-2023/aws-reinvent-2023-netflix.jpg" alt="Quoting Marie Kondō, Netflix engineers remind us that one of their missions is to "spread joy"" /></p>
<p>This conference addressed many of the issues we are familiar with: a home page that calls on a large number of microservices to display content to the user, scaling issues, cost management…</p>
<p>The heart of the conference detailed the architecture implemented by Netflix teams to replicate cache across multiple regions using EVCache, Kafka and SQS.</p>
<p>It was also interesting to see that at Netflix, as with us, it’s important to build with costs in mind: after analyzing the costs of their inter-region traffic, they finally decided to remove their network load-balancer to make their architecture more cost-efficient.</p>
<p>A long part of the conference was dedicated to the observability of the replication stack: our teams have also done a lot of work on this issue in recent years, so it was interesting to compare our practices on the subject of observability.</p>
<p>While we don’t yet work on the same scale as Netflix, attending this conference allowed us to reinforce our idea that caching is essential in the architecture of a platform such as Bedrock Streaming. And it gives us new ways for reflection…</p>
<h2 id="takeaways-from-reinvent2023-the-newcomers-point-of-view">Takeaways from Reinvent2023. The newcomers’ point of view</h2>
<p>It’s often said that “what happens in Vegas stays in Vegas”, but for some of us, this edition of Re:invent was our first time at a conference of this magnitude. So it’s hard not to share some of our feedback with you!</p>
<p>First of all, a word about Vegas, the city of excess which hosts Re:invent every year, and which has been transformed for us into an open-air R&D ground! From Fremont Street to the brand-new Sphere, there are screens EVERYWHERE in this city, which has aroused our curiosity as video streaming professionals…
<img src="/images/posts/2023-12-18-aws-reinvent-lasvegas-2023/aws-reinvent-2023-google.jpeg" alt="A troll masterpiece: Google has been advertising on the sphere for the duration of Reinvent" /></p>
<p>On the eve of Reinvent, the city is transformed: tourists give way to speakers from all over the world, advertising screens talk of nothing but cloud solutions, scalability and artificial intelligence… It’s an incredible phenomenon to behold!</p>
<p>With over 70,000 participants, nothing can be left to chance in the organization of Reinvent. It’s impressive to see (Vegas traffic jams aside) how smoothly the whole conference runs. A sort of “human load-balancing” has even been arranged so that each speaker can have lunch in record time!</p>
<p>The keynotes organized during Reinvent (5 in all) are events within events! The expected crowds are so huge that several overflow rooms are planned in addition to the main ballroom where the speaker is based.
We were able to attend two of them: Adam Zelipsky’s (CEO of aws) - for which the speakers were greeted by a fantastic rock band at 7:30 a.m., a guaranteed wake-up call - and Werner Vogels’ (CPO & VP of amazon.com), where this time the welcome was provided by a fantastic string quartet.</p>
<p>While Adam Zelisky’s conference was undoubtedly a masterpiece (production, new services announced, influential clients such as Lidia Fonseca, chief digital and technology officer at Pfizer, speaking), it was Dr. Vogels’ conference that impressed us the most.</p>
<p>Based on <a href="https://thefrugalarchitect.com/">the laws of the “frugal architect”</a>, this keynote spoke to everyone: technicians, business people, product managers… It took up the elementary concepts of what should motivate our design of IT solutions: cost awareness, the indispensable balance between commercial and technical needs, or the danger of never questioning oneself, quoting Grace Hopper: “One of the most dangerous phrases in the English language is: <em>‘We’ve always done it this way’</em>”
We encourage you to watch <a href="https://www.youtube.com/watch?v=UTRBVPvzt9w">the replay of this keynote</a>, a must-see!</p>
<p><img src="/images/posts/2023-12-18-aws-reinvent-lasvegas-2023/aws-reinvent-2023-werner.jpg" alt="Screenshot of one of the excellent edits made for the keynote of Werner Vogels" /></p>
<p>Beyond the gigantism of the event, let’s look at what we’ve taken away from our participation in Reinvent. Attending a conference is always an opportunity to take a step back on our current work themes: we attended many conferences on resilience, scalability and new architectures:</p>
<ul>
<li>it enabled us to compare our practices with those of major players in the sector (Prime, Spotify, Peacock…),</li>
<li>to transpose these themes into a context completely different from our own (“<a href="https://www.youtube.com/watch?v=fGyvsNE4vh8">1.5 million requests per second—a story from the Brazilian elections</a>”)</li>
<li>or to appreciate the work we’ve done over the year, which sometimes goes beyond what’s presented at conferences (“<a href="https://www.youtube.com/watch?v=JpemUkU8INA">Use new IAM Access Analyzer features on your journey to least privilege</a>”)</li>
</ul>
<p>For all these reasons, no doubt Bedrock Streaming teams will be betting on Reinvent again next year!</p>["a_ferez", "v_chabrier"]AWS re:Invent 2023 was a showcase for GenAI. It was the announcement of Amazon Q, Amazon’s new AI assistant, that attracted the most interest, designed to meet the specific needs of businesses.Android 14 is out2023-12-05T00:00:00+00:002023-12-05T00:00:00+00:00https://tech.bedrockstreaming.com/2023/12/05/android-14<p>Here’s what it means for users and developers.</p>
<p>With each new OS version, new things, upgrades, deprecations and changes are introduced, affecting the way we use and develop our apps.
Google keeps going in the direction of more privacy, more accessibility and more control over what the apps can do to maximize security and integrity.
Android 14 is no exception and here’s what I compiled on different topics that I will try to vulgarize to keep everyone on board.</p>
<h3 id="technical">Technical</h3>
<p>Technical changes build over features and APIs already introduced in previous versions, mostly Android 12 and 13.
They tend to modernize tools by catching up with some Java features and semantics, helping manufacturers and improving the developers’ IDE to embrace those changes.
Due to the nature of the changes, this is the topic that has to remain…technical, sorry for that.</p>
<ul>
<li>Mobile screens are getting bigger with more ratios to support, we’re moving further and further away from the binary world of phone vs tablet. To ensure the best experience on this wide range of devices, Android 14 introduces the <code class="language-plaintext highlighter-rouge">Large Screen Compatibility Mode</code> to help manufacturers improve the experience on their devices.</li>
<li>Updates to OpenJDK17 may require a bit of attention from apps using <code class="language-plaintext highlighter-rouge">Regex</code> that are not close enough to openJDK’s new semantics, throwing exceptions when confronted to an invalid groupe reference.</li>
<li>Generating a <code class="language-plaintext highlighter-rouge">UUID</code> from a string sees the validation become stricter and will now lead to exceptions due to deserialization issues. More than ever, it’s time to unit test UUID generation.</li>
<li>A bit of additional ruling may be needed to fix Proguard issues when shrinking / obfuscating code involving the <code class="language-plaintext highlighter-rouge">ClassValue</code> class coming with <code class="language-plaintext highlighter-rouge">API34</code>.</li>
<li>The new <code class="language-plaintext highlighter-rouge">Back APIs</code> are now strengthened by built-in animations and support for custom ones.</li>
<li>Making the <code class="language-plaintext highlighter-rouge">ForegroundService</code> type explicit is now mandatory, if the implementation was already properly done back in the Android 10 days when it was introduced, congratulations, nothing to do here.</li>
<li>Foreground services are also encouraged to be migrated to user-initiated jobs. A new <code class="language-plaintext highlighter-rouge">RUN_USER_INITIATED_JOBS</code> permission is introduced and new methods on the <code class="language-plaintext highlighter-rouge">JobInfo</code> builder allow to set the <code class="language-plaintext highlighter-rouge">userInitiated()</code> status along with the estimated amount of bytes the job will expect from the network. Scheduling the job is now done with the app foregrounded and the notification icon system remains the same so the user knows something is going on even if the app is backgrounded post launch.</li>
</ul>
<h3 id="battery-and-performance">Battery and performance</h3>
<p>Without a single ounce of surprise, Google continues its effort to improve battery life and takes steps towards sanctioning bad actors that publish battery-draining or unstable apps.
Today, not crashing is no longer enough, developers should take steps to push their app to their full potential and that means power management and performance monitoring.</p>
<ul>
<li>Bad behaviours like <code class="language-plaintext highlighter-rouge">ANRs (screen freezes)</code> or <code class="language-plaintext highlighter-rouge">background crashes</code> now more aggressively flag the guilty apps and put them at the bottom of the priority list where apps are fighting for resources, meaning they’ll also be the first to go if the system needs some. No more filtering out <code class="language-plaintext highlighter-rouge">ANRs</code> and non-fatal crashes on Crashlytics, everything matters now.</li>
<li>While on the subject of fighting for resources, let’s also note that now, <code class="language-plaintext highlighter-rouge">context-registered broadcasts</code> are now queued when the app is backgrounded and the system will deliver them when the app is awake or system conditions allow it.</li>
<li>Another change to the cached state (aka when the app is backgrounded) impacts background tasks that can no longer be triggered unless one of the app components is awake. This change pushes devs to use framework’s <code class="language-plaintext highlighter-rouge">JobScheduler</code> and <code class="language-plaintext highlighter-rouge">WorkManager</code> more as they aren’t impacted by this change.</li>
<li>Still with <code class="language-plaintext highlighter-rouge">Jobscheduler</code>, jobs don’t just fail silently anymore if they don’t respond in time but trigger an <code class="language-plaintext highlighter-rouge">ANR</code>, it is advised to move to <code class="language-plaintext highlighter-rouge">WorkManager</code> with its out of the box async support.</li>
<li>If a job requires a special network state to be triggered, the <code class="language-plaintext highlighter-rouge">ACCESS_NETWORK_STATE</code> permission is now mandatory. Without it, a <code class="language-plaintext highlighter-rouge">SecurityException</code> will be raised.</li>
<li><code class="language-plaintext highlighter-rouge">Intents</code> keep getting more and more headache prone as the implicit and pending intents now can only be delivered to exported components. If you need to reach an unexported component, explicit intent is your go-to solution. Note that mutable pending intents now need to specify a component or it will throw an exception.</li>
</ul>
<h3 id="notifications">Notifications</h3>
<p>Finding the right balance between informative presence and in-your-face nuisance has always been a challenge for notifications and it seems Google keeps pushing to make them less invasive and easier for the user to dismiss or delay them.</p>
<ul>
<li>The <code class="language-plaintext highlighter-rouge">Fullscreen Intent</code> notifications that we see when our clock rings or when we receive a phone call are luckily already rarely used.
They are now more restricted and available only to apps declaring <code class="language-plaintext highlighter-rouge">Call</code> or <code class="language-plaintext highlighter-rouge">Alarm</code> features, meaning we shouldn’t see bad actors abusing this feature that would allow them to bypass the lock screen amongst other things.</li>
<li>Non-dismissible <code class="language-plaintext highlighter-rouge">foreground notifications</code> are now dismissible in some cases but will remain non-dismissible
<ul>
<li>on top of the <code class="language-plaintext highlighter-rouge">Lock Screen</code> to prevent it from being swiped by anyone accessing a device behind the owner’s back.</li>
<li>from the <code class="language-plaintext highlighter-rouge">Clear all</code> feature to prevent misclicks.</li>
</ul>
</li>
</ul>
<h3 id="privacy-and-security">Privacy and security</h3>
<p>This is, once again without surprise, where a lot of the changes happen and it is aligned with Google’s vision and goals when it comes to give users back the control of their data and permissions.
Some of them seem so obvious that it’s surprising to see them in action only now. Maybe the EU pressure with GDPR starts to pay off? Maybe…</p>
<ul>
<li>Android 14 introduces new places where the data sharing purposes are displayed. Until now, we could only check them from the PlayStore app page.
Now, it will also be displayed in the <code class="language-plaintext highlighter-rouge">runtime permission popups</code>, starting with those related to location to remind why the data is necessary and with whom it will be shared.</li>
<li>It will now be impossible to install apps that don’t target at least the <code class="language-plaintext highlighter-rouge">API 23</code> to prevent bad actors from exploiting security breaches discovered inside older Android versions.
Be aware that installed apps won’t be removed and the system won’t warn you when starting one of those apps, maybe a new feature for Android 15?</li>
<li><code class="language-plaintext highlighter-rouge">Dynamic Code Loading</code> now requires to flag the file as read-only to avoid any tampering or code injection. In any case, DCL should be avoided when possible and only trusted files should obviously be loaded this way.</li>
<li>When saving a file inside the app storage, the system attributes to the file an owner id, this id being the app package name that saved it.
This feature allows apps to know which file they can open without requesting the external read permission. The issue was that by querying this id, other apps could access the owner ids that weren’t them and deducting the owner’s installed apps list.
To fix this, the name is now redacted, increasing again a little bit the user data protection, the list of the installed apps being considered a sensitive data by Google.</li>
<li>If an app features <code class="language-plaintext highlighter-rouge">screen</code> or <code class="language-plaintext highlighter-rouge">audio recording</code>, it is now required to be granted the user consent to do so before each session start and therefore be able to handle permission denied scenarios.</li>
<li>Zip files are also impacted as a fixed vulnerability with the <code class="language-plaintext highlighter-rouge">path transversal reading</code> now triggers an exception if some characters are found inside it. (Contains <code class="language-plaintext highlighter-rouge">..</code> Or starts with <code class="language-plaintext highlighter-rouge">/</code>)</li>
<li>Even though already required, the <code class="language-plaintext highlighter-rouge">BLUETOOTH_CONNECT</code> permission was not yet enforced to access the profile state, it is now the case.</li>
<li>Users are no more required to grant access to all <code class="language-plaintext highlighter-rouge">images</code> or <code class="language-plaintext highlighter-rouge">videos</code> to share or display a single media, Android 14 now upgrades the permission popup with an option to select only the media the app is allowed to access.</li>
<li>Apps can now react to a user <code class="language-plaintext highlighter-rouge">screenshot</code> event, they can’t manipulate the content but developers can now add a callback bound to the activity lifecycle.
Sensitive screens should still be protected with the secure flag.</li>
<li>Starting activities from the background with a <code class="language-plaintext highlighter-rouge">pending intent</code> or through another app in the foreground now requires the app to opt-in to this feature inside said activity and is no longer a default behaviour.</li>
</ul>
<h3 id="accessibility">Accessibility</h3>
<p>It is no secret that mobile devices are now owned by more and more people every year, which includes people with a range of disabilities or personalities that may make an app usage more challenging.
Android 14 helps them with new and upgraded features to ease their journey with a mobile device.</p>
<ul>
<li>A step is taken towards low-vision users’ direction, the changes and impacts to the <code class="language-plaintext highlighter-rouge">font scaling</code> should be negligible to developers already properly using <code class="language-plaintext highlighter-rouge">SP</code> as their size units but a full testing pass with the scaling enabled should be scheduled to be safe and tweak improvable screens.</li>
<li>New tools inside Android studio are added to help developers handling <code class="language-plaintext highlighter-rouge">per-app language</code> more efficiently and easily.</li>
<li><code class="language-plaintext highlighter-rouge">Grammatical Inflection API</code> is introduced, offering developers working on apps with gendered languages new tools. It adds a layer of complexity to the strings files by having three gender-files by gendered language. In those files are added only the strings affected by gender inflections like <code class="language-plaintext highlighter-rouge">Vous êtes déconnecté</code> for masculine, <code class="language-plaintext highlighter-rouge">Vous êtes déconnectée</code> for feminine or <code class="language-plaintext highlighter-rouge">La déconnection est effective</code> for neutral in french. More work for developers and translators but an overall better experience for users.</li>
</ul>
<hr />
<p>All in all, Android 14 is an update faithful to the Google roadmap.
Users today are very different than users 10 years ago. They care more about their data and their privacy; the Mobile ecosystem and business is also a lot more professional.
It’s important for us developers to be aware of those changes in order to continuously improve the experience, be it related to our core business or simply to keep the user engaged in a safe environment.</p>
<p>When this article is released, Android 14 should be freshly out and developer teams hands deep in the migration tasks.
I hope you enjoyed the information and see you soon for more Android related articles!</p>
<ul>
<li><a href="https://developer.android.com/about/versions/14/behavior-changes-all">Changes potentially affecting all apps</a></li>
<li><a href="https://developer.android.com/about/versions/14/behavior-changes-14">Changes affecting apps targetting Android 14</a></li>
<li><a href="https://developer.android.com/about/versions/14/features">New features introduced by Android 14</a></li>
<li><a href="https://developer.android.com/sdk/api_diff/34/changes">APIs changelog</a></li>
<li><a href="https://developer.android.com/about/versions/14/summary">Overview</a></li>
</ul>["c_goffoy"]Here’s what it means for users and developers.