mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-29 03:52:38 +02:00
137 lines
No EOL
7 KiB
HTML
137 lines
No EOL
7 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<title>PyconFR 2015 — Cliquet - Alexis Métaireau</title>
|
|
<meta charset="utf-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link rel="stylesheet" href="https://blog.notmyidea.org/theme/css/main.css" type="text/css" />
|
|
<link href="https://blog.notmyidea.org/feeds/all.atom.xml" type="application/atom+xml" rel="alternate" title="Alexis Métaireau ATOM Feed" />
|
|
</head>
|
|
<body>
|
|
<section id="links">
|
|
<li>
|
|
<a class="" href="https://blog.notmyidea.org/" id="site-title">Blog</a>
|
|
</li>
|
|
<li><a class="" href="https://blog.notmyidea.org/pages/projets.html">Projets</a></li>
|
|
</section>
|
|
|
|
|
|
|
|
|
|
|
|
<header>
|
|
<h1 class="post-title">PyconFR 2015 — Cliquet</h1>
|
|
<time datetime="2015-10-17T00:00:00+02:00">17 octobre 2015</time>
|
|
|
|
|
|
</header>
|
|
<article>
|
|
<div class="admonition note">
|
|
<p class="first admonition-title">Note</p>
|
|
<p class="last">Voici quelques notes prises durant la PyconFR 2015, à Pau. N’hésitez pas
|
|
à les completer si besoin.</p>
|
|
</div>
|
|
<p>Speaker: Mathieu Leplatre (@leplatrem), Mozilla</p>
|
|
<p>Toolkit <span class="caps">HTTP</span>, pour éventuellement faire des microservices.</p>
|
|
<ol class="arabic simple">
|
|
<li>Origines</li>
|
|
<li>Protocole</li>
|
|
<li>Toolkit</li>
|
|
<li>Conversation</li>
|
|
</ol>
|
|
<div class="section" id="origines">
|
|
<h2>Origines</h2>
|
|
<p>Stockage de données, Cloud Services, Mozilla.
|
|
Le boulot, c’est de faire des APIs. On nous demande de faire des APIs, tout
|
|
le temps.</p>
|
|
<p>Souvent, les mêmes questions sont à l’ordre du jour. Heartbeat, codes
|
|
d’erreurs, etc. L’inventaire de tout ce qui est attendu d’une <span class="caps">API</span>, au dela de
|
|
ce qui est la valeur ajoutée du service.</p>
|
|
<p>Définition d’un protocole. Définir une <span class="caps">API</span> <span class="caps">REST</span> n’est pas aussi évident qu’il
|
|
y parait. Il faut définir les formats de <span class="caps">JSON</span>, les status, etc.</p>
|
|
<p>La réutilisation de certaines protocoles existants était possible (Sync, en
|
|
production depuis quelques années).</p>
|
|
<p>Réutiliser du code nous permettait et faire un template pour démarrer plus
|
|
facilement, pour se concentrer sur le métier de l’<span class="caps">API</span>. Puisque les besoins ne
|
|
sont pas toujours les mêmes, avoir une boite à outil permet de choisir ce que
|
|
l’on souhaite.</p>
|
|
</div>
|
|
<div class="section" id="protocole">
|
|
<h2>Protocole</h2>
|
|
<ul class="simple">
|
|
<li>Création d’un protocole qui respecte les bonnes pratiques. <span class="caps">CORS</span>, avoir les
|
|
bons codes de status, arrêter de se poser toujours les mêmes questions.
|
|
Contrairement à ce qu’on imagine, la spécification <span class="caps">HTTP</span> n’est pas si facile
|
|
à suivre. Plutôt que d’écrire un document, un toolkit à été créé.</li>
|
|
<li>Les ops ont besoin de quelques endpoints: un heartbeat (monitoring) des
|
|
endpoints de batch, un endpoint “hello”, pour connaitre le type de service,
|
|
ses URLs etc.</li>
|
|
<li>La service renvoie toujours un <span class="caps">JSON</span> avec la description de l’erreur. Cela
|
|
permet d’avoir tout le temps la même gestion des erreurs. Utilisation du
|
|
header “backoff” qui permet de demander aux clients d’arreter de faire des
|
|
requetes durant une durée spécifée par le serveur.</li>
|
|
<li>Pour les resources “<span class="caps">REST</span>”, quelques règles sont définies: quel est le format
|
|
du <span class="caps">JSON</span>, quel est la syntaxe du querystring pour filtrer, ordonner, gérer les
|
|
opérations concurentes, etc.</li>
|
|
<li>Comment la validation fonctionne ? La pagination ? La définition des
|
|
permissions ? Les erreurs.</li>
|
|
</ul>
|
|
<p>Définir le protocole une seule fois permet de se mettre d’accord avec les Ops.
|
|
On ne créé pas une <span class="caps">RFC</span> pour l’instant, il faut qu’on valide ce qu’on a fait,
|
|
il est necessaire de valider notre approche.</p>
|
|
</div>
|
|
<div class="section" id="toolkit">
|
|
<h2>Toolkit</h2>
|
|
<p>La stack en place est basée sur Pyramid et Cornice. Autre chose aurait pu petre
|
|
utilisé. Mais pyramid à été choisi pour son approche simpliste et qui permet de
|
|
rajouter de la complexité au fur et à mesure.</p>
|
|
<p>Cliquet propose de faire l’ensemble du boilerplate, la lecture du protocole, et
|
|
vous permet de créer les backends souhaités.</p>
|
|
<p>Il est possible de choisir les methodes <span class="caps">HTTP</span> acceptables, les URLs à utiliser
|
|
etc. Tweaker l’<span class="caps">API</span> est possible, la chose qui reste toujouts stable est le protocole.</p>
|
|
<p>le toolkit vise à faire quelque chose de pluggable. Tout est controllable
|
|
depuis la configuration.</p>
|
|
<p>Pour le deploiement, cela veut dire que le monitoring est déjà connecté, et il
|
|
est possible de changer la configuration depuis un fichier <cite>.ini</cite>.</p>
|
|
<p>Il est aussi possible de faire du profiling en ajoutant deux lignes de code,
|
|
qui permet de générer des graphs qui permettent d’identifier les goulots d’étranglement.</p>
|
|
</div>
|
|
<div class="section" id="microservices">
|
|
<h2>Microservices ?</h2>
|
|
<ul class="simple">
|
|
<li>Cliquet apporte une manière standard de surveiller, deployer, configurer des services.</li>
|
|
<li>Il est possible de se focaliser sur la logique de l’application, en faisait
|
|
une abstraction des backends, etc.</li>
|
|
<li>Le fait de figer l’<span class="caps">API</span> permet d’avoir des clients génériques que l’on peu
|
|
réutiliser d’une application à l’autre.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="section" id="cliquet-est-utilise-pour">
|
|
<h2>Cliquet est utilisé pour</h2>
|
|
<ul class="simple">
|
|
<li>Kinto, un service générique de stpclage de données.</li>
|
|
<li>Syncto, un proxy pour Sync en utilisant le protocole.</li>
|
|
<li>La liste de lecture, service qui à été shutdown.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="section" id="questions">
|
|
<h2>Questions</h2>
|
|
<ul class="simple">
|
|
<li><strong>Qu’est-ce qui est pluggable ?</strong> Les choix qui sont fait dans cliquet
|
|
concernent le protocole. Le toolkit est lui fait de manière “pluggable”. Il
|
|
est par exemple possible de changer le backend, l’authentification, le cache
|
|
ou les permissions.</li>
|
|
<li><strong>Quelles sont les parties non standard? Est-il prévu de representer ça via
|
|
une <span class="caps">RFC</span> ?</strong> Le seul sujet qui pourrait etre utile dans une <span class="caps">RFC</span> serait de
|
|
définir les headers attendus pour la validation et l’écriture
|
|
concurrentielle. L’ensemble de ce qui est proposé est standard.</li>
|
|
<li><strong>Existe-il un client JavaScript, comme pour Kinto ?</strong> Actuellement, non. Par
|
|
contre, Kinto.js est prévu pour que la partie commune entre les APIs (le
|
|
protocole) peut etre extrait.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
</article>
|
|
|
|
</body>
|
|
</html> |