Cet article correspond est une version nettoyée de ma prise de note pendant le JUG Summer Camp 2021. J'y ai participé cette année à la fois dans le public et en tant que speaker 😀 Encre merci à l'équipe du JUG Summer Camp de m'avoir laissé présenté mon talk ! 😎

Je vous mets aussi le lien vers la playlist Youtube avec tous les talks : https://www.youtube.com/watch?v=7VnJ_NiiHas&list=PL4Z_Bm3ccVwfmPFuR-QZMg2YLdL0WnGbZ

REST next level : écrire des APIs web orientées métier – Julien Topçu

On vise en général à avoir le maximum du métier côté backend.

  • on veut exposer ce métier dans le front pour l'utilisateur
  • REST n'a que les 4 mots clés CRUD (Create Read Update Delete) pour exposer les actions métiers
  • c'est un peu comme si le souffleur au théâtre devait passer par un gamin de 4 ans pour expliquer la scène aux acteurs

"Je veux rechercher les trains qui desservent ma destination" != "je veux créer une ressource recherche"

Problèmes :

1. nouns vs verb

  • classiquement : on perd de la sémantique dans les urls
  • on se bloque avec des conflits de noms
  • on pallie parfois les limitations de REST avec des tricks bof (/rebooking alors que c'est bof)
  • Pour palier à ça on va imbriquer : POST /bookings/{id}/rebook
  • en vrai aucun souci à mettre des noms et des verbes, tant que le verbe ne contredit pas le verbe http (exp: GET /bookings/create est interdit)
  • le front ne doit avoir à savoir comment fonctionne le backend, uniquement la logique de comment l'utiliser

2. confondre modèle et métier

  • on ne doit pas exposer les modèles du back si ce n'est pas l'intension métier
  • "je sélectionne un train et un tarif" != "je crée une sous-ressource sélection sur ma recherche"
  • pour avoir une bonne UX : on va présenter au front quelque chose de différent de la logique backend

3. trahison de l'encapsulation

  • à l'ancienne : le modèle est souvent anémique : le modèle est composé de POJO vide qui permettent des états inconsistants
  • avec DDD : il y a des méthodes sur le modèle qui expose des fonctions métiers qui permettent d'éviter les états incohérents, faire du code défensif, avoir du métier non encapsulé
  • on expose totalement l'état interne des classes modèles
  • pour faire mieux on peut passer de PATCH /searches/{id}/selection à POST /searches/{id}/spaceTrains/{number}/fares/{code}/select
  • comment on fait côté front ?

4. API anémique

  • on donne pas l'information de l'ordre des appels
  • c'est le front qui implémente de le workflow, le back ne le connaît pas et rien empêche le front de faire n'importe quoi
  • du coup une partie du métier est côté front et il faut le recoder pour chaque client

Il faut réapprendre à utiliser le HATEOAS :

  • _links pour naviguer dans l'API
  • avec des urls pour chaque action
  • on a plus besoin d'avoir un front qui sait construire les urls
  • le back gère tout
  • on reste stateless : tout est dans le payload des requêtes avec les urls qui portent les informations
  • le back peut changer sans toucher au front qui connait les actions mais pas les url ni les verbes http

Dans l'exemple : il utilise HAL pour créer ses _links

Avis : J'ai trouvé ce talk très intéressant, très bien présenté, et le sujet très bien amené. J'avais déjà vu des articles autours de HATEOAS, mais là c'est très clair et très simple on a envie de foncer !

IaaS (Interuption As A Sageness) – David Aparicio

Post Mortem : billet écrit après la résolution d'un incident pour expliquer le problème, comment il a été identifié, la structure, la timeline, comment il a été diffusé, le niveau d'impact

First Blood

  • 1947 : Le premier bug de Grace Hooper
  • un vrai insecte (bug) dans un ordinateur
  • encore ce genre de problème arrive : inondation de fibre

"Elliot Alderson"

  • histoire arrivée plusieurs fois
  • junior qui arrive dans une boite, nouvelle machine, installation en suivant la doc
  • d'un seul coup incident de prod, les seniors sont sur le sujet
  • le junior à drop les bases de prod par accident
  • la doc contenait les credentials de prod à côté de ceux de dev…
  • histoire arrivée connue : AWS (2012), Gitlab (2017), DigitalOcean (2017)

Il était une fois... (en 2020)

  • histoire vécue par David
  • astreinte legacy
  • restart d'un des nœuds du data lake et plus de souci
  • mais l'incident se reproduit
  • vocabulaire : problème = incident qui se reproduit
  • en fait c'était une saturation du pool de connexion
  • solution KISS : sonde qui inspecte le service, si pas de réponse, restart automatique du service

CDN

  • panne global d'un CDN Fastly

Le retour du legacy

  • nouvel incident de data lake en 2021
  • vieille version de Java (8) et Hadoop
  • backend BDD trop lourde pour ce qu'était capable d'être traité

Blast Effect

  • Apache Zookeeper
  • créé en même temps d'Hadoop
  • très utilisé par les systèmes distribués
  • Key-Value store hiérarchisé
  • très bon résultats aux tests Jepsen
  • permet de suivre les changements sur un path
  • zookeeper est bloqué parce que le GC est saturé (trop de tâche GC, trop de pause)
  • on peut d'éviter ce genre de cas avec du circuit breaker, de l'API alternative, du timeout, éviter trop de retry, etc.

Same JVM, shoot again

  • Criteo en 12/2018
  • limite software de fonctionnement de HDFS (filesystem de Hadoop)
  • besoin de faire le ménage sur Hadoop

NewsBlur

  • attaque chez NewsBlur
  • erreur : version de dev push en prod
  • restauré via backup

Github

  • problème de split entre les 2 replicats de la base

Avis : Ce talk n'a pas l'air présent dans la playlist, je pense que c'est dû à la coupure de courant qu'il y a eu pendant la présentation. En tout cas ce talk était plutôt sympa à suivre, car on voit qu'au fond il y a des erreurs qui sont commises partout, même dans les plus grandes boites qu'on pense intouchables, alors qu'au fond une erreur peu vite arriver.

Construire un outil de CLI userfriendly – Nicolas Lepage

  • ps aux => bof car on comprend pas aux, y'a pas de tiret donc pas super standard
  • grep des options longue explicite
  • pacman (archlinux) => -Syu pas super explicit
  • git super exemple :
    • des commandes en mot sans tiret
    • des options avec des tirets
  • docker pareil que git
  • mais git checkout fait trop de chose par exemple (remplacé par git switch et git restore)
  • catption : outil de Nicolas pour créer des meme de chat github.com/nlepage/catption
  • comment rendre plus sympa :
    • possibilité d'intégrer au système
    • possibilité de le rendre configurable via fichier de config (exemple : dossier par défaut avec des photos de chat)
    • un peu d'interactivité
      • exemple : si on oublie d'indiquer le paramètre de texte, on peut proposer de saisir le texte
        • mais ici si l'entrée ou la sortie standard ne sont pas attachés à un terminal on active pas
    • conseiller / guider l'utilisateur (git status par exemple)
    • log sympa : emoji, couleur, …
  • utiliser des packages pour aider à la création des cli comme Cobra et/ou Viper et/ou is-atty en go

Avis : Nicolas nous d'abord un petit tour d'horizon de plusieurs CLI avec les avantages et inconvénients de leur fonctionnement. Il vient ensuite proposer plusieurs méthodes pour créer un CLI pratique à utiliser. La problématique est simple, la réponse est bien formulée, rien à dire de plus !

‌

HTTPS comment ça marche ? – Quentin Aubert

  • http : HyperText Transfer Protocol

    • au dessus de TCP

  • TLS se greffe entre HTTP et TCP

  • TLS :

    • confidentialité : chiffrement symétrique (rapide, puissant, mais apporte d'autres failles (clé unique))
    • clé session : chiffrement asymétrique (2 clés par users), pour l'échange de clé (distribution sécurisé, chacun sa clé, lent et lourd)
    • certification : chaine de certification et signature (Authentique, Infalsifiable, Non réutilisable, inaltérable, irrévocable)
    • intégrité : HMAC

Avis : J'ai pris peu de note car je connais plutôt bien ce sujet, mais Quentin l'a très bien expliqué, donc si vous avez besoin d'une piqûre de rappelle, n'hésitez pas à aller voir son talk 😉

Java à la vitesse de la lumière avec le Graal ! – Anthony Pena

C'est mon talk, je vous renvoie vers mon article retranscription si vous voulez plus d'info : https://k49.fr.nf/graalvm-on-y-va-ou-pas/

Créer et distribuer un plugin pour Kubernetes en quelques minutes ? Easy ! – Gaëlle Acas et Aurélie Vache

  • tout kubernetes est extensible
  • les plugins permettent d'augmenter la productivité
  • pas limité à un langage, on peut utiliser n'importe quel langage qui permet de faire un cli
  • il suffit de créer un exécutable dans notre $PATH
  • le nommer kubectl-
  • krew = package et partage de plugin kubectl
    • c'est un plugin kubectl
    • permet d'installer un plugin local
    • pour publier il suffit de créer une release, écrire le manifest, faire une PR sur l'index de krew
    • manifest krew est un yaml avec une description du plugin
    • on peut créer un index privé facilement
  • quelques plugins pratiques :
    • kubectl view-secret
    • kubectl view-cert
    • kubectl view-utilization
    • kubectl neat (pour épurer un peu les infos kube)
  • best pratice
    • pas de nom réservé par les commandes kubectl
    • choisir un nom explicite
    • favoriser la création de plugin en go (facile de créer de base un binaire, krew-release-bot, go releaser)
  • Aurélie fait des sketchnotes pour expliquer les concepts de kubernetes + des vidéos courtes (2min)
  • bit.ly/plugin-kubectl-jug

Avis : je fais un peu de kubernetes dans ma mission, mais j'utilise peu kubectl, eh bien avec ce talk j'ai quand même eu envie de créer un plugin pour tester !

Ce qui rend les développeurs heureux en 2021 – Damien Cavaillès

  • début de conf en mode gym question tout le monde debout
  • créateur de We Love Devs (welovedevs.com)
  • enquête We Love Devs à faire
  • difficile de résumer en soit, aller voir la conf

Avis : C'est un talk qui résume beaucoup de fait et chiffre autour du bien être des développeurs, etc. C'est compliqué de vraiment faire une prise de note utile, autant aller voir directement le replay !

GitPod : IDE as a service -- Philippe & Horacio

  • IDE remote

    • GitPod est passé de Eclipse Theia à VS Code
    • remote
    • workspace

  • plus besoin d'un laptop surpuissant et couteux

  • juste une image docker à lancer

  • par défaut prévu pour Github, Gitlab et BitBucket mais c'est possible de l'installer en SaaS ou on-premises

  • on peut partager un workspace facilement

  • GitPod vs Github Codespace

    • consomme plus de ressource (CPU et RAM)
    • Open Source
    • self-hosted possible
    • snapshots (ne pas avoir besoin de commit+push pour garder le contenu de ton repo)
    • prebuilds

Avis : Je ne suis pas très fan des IDE dans le cloud ou ce qui s'en rapproche. Après la démo que Philippe et Horacio je ne me dis pas que je vais lâcher mes grosses machines mais au moins je pense que je vais regarder pour les moments où je fais des formations histoire de gagner du temps à la mise en place (c'est d'ailleurs le cas d'usage d'Horacio mais plutôt côté workshop)

L’expérience développeur par Quarkus 2.0 – Guillaume Le Floch et Jean-Phi Baconnais

  • Quarkus CLI
    • aide à la création du projet
    • aider à gérer les extensions du projet
    • quarkus dev => lancer en mode dev
      • changement à chaud de l'application (via un restart automatique de l'app)
      • /q/dev
        • liste des extensions
        • la config (voir et éditer à la volé)
  • dev services
    • va configurer automatiquement un conteneur avec les éléments qui vont bien si on précise pas ce qu'il faut (mais qu'on a Docker)
  • continuous testing
    • run des unit tests en continue au moment du reload
    • uniquement les tests impactés par notre dev

Avis : J'aime bien Quarkus pour plein de raisons, et j'avoue que j'étais passé à côté d'une partie de ce que Guillaume et Jean-Phi ont montrés. Beaucoup d'aides au développement sont présentes de base sans aucune configuration et c'est très agréable pour le développement !

Conception de langage : communiquer avec la machine – @monsieurbadia

  • talk à revoir, beaucoup d'information, la forme est importante aussi

  • un compilateur à 3 parties :

    • frontend (suffisant pour un langage interprété)
    • middle-end (optionel)
    • backend

  • le frontend est composé d'un pipeline

    • tokenizer = génère des tokens
    • parser = génère un AST
    • analyzer / type checker = va valider les types
    • interpreter = va gérer les scopes

  • on peut aller voir le site astexplorer pour explorer l'AST de n'importe quel langage

Avis : Mes notes sont assez légères mais clairement c'est un talk que je vais revoir. Il est assez dense en information, et la forme du talk est aussi intéressante que le fond je trouve. On sent que William maitrise son sujet et qu'il a pas mal joué avec les concepts !

Connaissez-vous vraiment JWT ? – Karim Pinchon

  • un jeton / token

    • chaine de caractère
    • pour l'auth

  • pas une chaine de caractère toute simple

    • des références à des éléments du SI
    • valeurs : qui porte des informations

  • JWT : token par valeur

    • relativement réduit en taille

  • jwt.io

    • permet de jouer avec les tokens jwt

  • un token JWT :

    • 3 parties
      • 1ère partie base 64 entête
      • 2ème partie base 64 payload
      • 3ème partie hmac de signature
    • entête :
      • liste de propriété (prédéfinie)
      • rarement toutes utilisés
    • payload
      • liste de propriétés
      • public claims (définis au IANA)
      • private claims

  • JOSE : (Javascript Objet and Serialized Encryption)

    • JSON Web Encryption
    • JWT
    • JSON Web Algorithm
    • JSON Web Key

  • les attaques

    • jeton non sécurisé
      • on peut ne pas sécuriser un token…
      • certaines lib s'appuyait directement sur les indications du token pour savoir quel algo utiliser
    • changer la sécu asymétrique par une symétrique
      • abus des implémentations

  • paradoxe de JWT:

    • il faut faire confiance au token pour valider le token…

  • conseils

    • ne pas tout accepter : s'assurer qu'on accepte que les algos qu'on considère comme fiable par exemple
    • préférer l'asymétrique
    • utiliser une lib existante et éprouvée
    • ne vous battez pas pour révoquer les JWT
      • normalement on a pas besoin
      • si besoin, le bon choix c'est réduire la durée de vie
      • changer de clé de signature/chiffrement
    • un token JWT ne doit rien contenir de confidentiel
      • ne pas logger les jetons
    • que des données nécessaire et rien de plus
    • que du HTTPS

  • les alternatives

    • a-t-on besoin d'alternatives ? OUI
    • clevercloud/biscuit
    • paragonie/paseto (plateform-agnostic security tokens)
    • rescrv/libmacaroons (cookies with contextual caveats for decentralized authorization in the cloud)
    • tuupola/branca

Avis : Je n'ai pas souvent eu l'occasion de manipuler des tokens JWT, mais je suis assez d'accord avec Karim sur le fait que c'est assez complexe et qu'on peut facilement se tromper si on fait sa propre implémentation, autant prendre une solution toute faite. En tout cas j'ai pu revoir les bases des tokens JWT grâce à Karim, et découvrir beaucoup d'éléments que j'avais totalement loupé sur le sujet, merci Karim, c'est certain ça me servira !

Conclusion

Je publie mon REX plus d'un mois après la conférence, mais j'ai fini par prendre le temps de le faire ! Je suis habitué à des conférences beaucoup plus grosses (DevFest Nantes, dotJS) mais clairement le JUG Summer Camp c'est une conférence à faire au moins une fois ! C'est très sympa, c'est une conférence toute petite, on peut vraiment croiser tout le monde et c'est très convivial !

Merci à l'équipe du JUG Summer Camp pour l'organisation, et merci à tous les speakers !