1 of 33

WebAssembly n’est pas qu’une affaire de frontend

Benjamin Coenen

@bnj25

2 of 33

2

Benjamin Coenen

bnj25

bnjjj

3 of 33

https://www.apollographql.com/blog/announcement/backend/announcing-apollo-router-v1-0/

4 of 33

Summary

Historique
WebAssembly
Frontend side
Ecosystème et cas d’usages backend
Outils et libs
Exemples

5 of 33

Historique

Première version en 2015
Créé et maintenu par le W3C
Plus performant que JavaScript
Support d’autre langage que JavaScript dans le browser
Mozilla, Google, Fastly

6 of 33

WebAssembly

7 of 33

WebAssembly: langage à pile

Exemple opération: 5 + 2

8 of 33

WebAssembly: langage à pile

9 of 33

WebAssembly: langage à pile

10 of 33

WebAssembly: langage à pile

11 of 33

WebAssembly: langage à pile

12 of 33

WebAssembly: langage à pile

Credit to Laetitia Langlois

13 of 33

WebAssembly: 5 types

14 of 33

WebAssembly: formats

.wasm →Binary format
.wat →WebAssembly Text

15 of 33

WebAssembly

Du coup le vrai interêt de webassembly quand même c’est que plusieurs langages peuvent compiler vers du wasm. C’est aussi la promesse de base quand wasm est sortie c’était de pouvoir avoir un gain de perf par rapport à Javascript mais aussi de pouvoir écrire en n’importe quel langage et que ça s’exécute dans votre navigateur. Pas encore tous les langages ne compile vers du WASM mais ça évolue plutôt bien. Ici par exemple on a les plus populaire on va dire. Ce qui est compliqué c’est de compiler un langage garbage collecté vers du wasm qui lui ne possède pas de garbage collector. Par exemple avec go il faut utiliser tinygo, je n’ai jamais vraiment utilisé mais à la base tinygo c’est aussi pour dev du go sur des microcontroleurs, du coup je pense que quand on compile avec tinygo (qui est un compilateur go pour des environnements spécifiques) vers du wasm ça aussi compile l’équivalent du runtime de go avec son gc directement en wasm. ASYNC

16 of 33

Frontend side

17 of 33

Frontend side: communication entre JavaScript et Wasm

Je me souviens au début et même en discutant avec certaines boites quand ils ont vu arriver webassembly et le fait que ce soit stable dans le navigateur ils se sont dit “ok super du coup comme c’est plus performant, les soucis qu’on a avec notre front pcq c’est fait avec un framework qui va tourner en boucle, faire le café et consommer beaucoup de ressource bhen grace à WASM on va réécrire la plupart en Go par exemple, le compiler vers WASM et le tour est joué. Sauf que c’est pas universelle cette loi et généralement ceux qui ont tenté ce move s’en sont rapidement rendu compte. Car en fait rappelez vous tout à l’heure je vous ai dit dans webassembly on a accès qu’à 5 types, du coup si on lui passe une string de js a wasm bhen il va falloir la convertir, chaque fois que des objets ou des types un peu plus évolués vont vouloir discuter entre eux ou s’échanger de la donnée il va y avoir cette phase de transformation qui dans certains cas pourra être assez couteuse. Bon ici dans l’exemple je montre comment on utiliserait la fonction add de tantôt pour l’appeler depuis le javascript.

18 of 33

Frontend side

Benchmark et perf https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/

19 of 33

Backend side: cas d’usage

Function As A Service (FAAS)
Smart contract
Création de module WebAssembly pour l’exécuter depuis d’autres langages
Création de plugins pour étendre des outils
Représentation intermédiaire pour compilateur

Dans FAAS on a besoin d’éxecuter du code qui nous appartient pas, dans plusieurs langages différents. Du coup là avec WASM on a ce runtime qui est capable de run du wasm et comme le wasm peut être généré depuis differents langages forcément il y a un vrai use case ça répond bien au besoin. Par contre le défaut c’est que WASM c’est sandboxé on en reparle après. Par contre comme on parle d’environnement restreint et sandbox niveau sécurité c’est pas mal, y a moins de risque et donc c’est aussi un candidat parfait pour éxecuter des smarts contracts dans la blockchain puisqu’un smart contract ça va être executé sur des machines qui ne nous appartient pas, et celui qui a cette machine n’a pas evnie que vous accédiez à son disque dur, son réseau et ses data tout ça. Les 2 derniers use case sont intimement liés puisqu’en fait l’idée c’est que grace au wasm on puisse réutiliser une lib ou une partie de code écrite dans un langage A depuis un langage B, comme ça pas besoin de réécrire du code déjà écrit dans un autre langage.

20 of 33

Backend side: projets existants

21 of 33

Backend side: projets existants

HIPPO

Deislab

22 of 33

Backend side: projets existants

23 of 33

Tools and libraries: runtimes (liste non-exhaustive)

Frontend

Backend

Wasmtime

24 of 33

Environnement sandboxé

X

25 of 33

Environnement sandboxé

V

Mais comme l’idée maintenant c’est aussi de pouvoir l’utiliser côté backend il y a un autre spec qui est sorti dans l’environnement de wasm. Wasi c’est une spec, qui normalise une API/ABI (Application Binary Interface) pour pouvoir communiquer avec les IO de l’environnement dans lequel il se trouve et donc être moins sandboxé. C’est juste indiqué les prototypes de fonctions qui vont être appelées si on essaie de lire un fichier, ou de faire un appels réseaux etc. On implémente ces fonctions externes et ça nous permet de faire le pont entre l’OS et le runtime. Souvent c’est implémenté au niveau du runtime donc nous on a pas à s’en soucier. Après il y a d’autres types de specs un peu plus spécifiques à certaines plateformes et très expérimentale. Par exemple pour krustlet ils ont pareil une spec d’abi pour pouvoir faire des calls http et tout ça. Et c’est implémenté directement au niveau de krustlet.Glibc

26 of 33

Environnement sandboxé: exemple

27 of 33

Bindings

Cas d’usage: utilisation dans un autre langage

(func $concat (type $t10) (param $p0 i32) (param $p1 i32) (param $p2 i32) (param $p3 i32) (param $p4 i32) (param $p5 i32) (param $p6 i32)

#[no_mangle]

pub extern "C" fn concat(mut first: String, second: String) -> String {

first.push_str(&second);

first

}

ptr, len0 = _encode_utf8(first, realloc, memory, caller)

ptr1, len2 = _encode_utf8(second, realloc, memory, caller)

ret = self._concat(caller, ptr, len0, ptr1, len2)

assert(isinstance(ret, int))

load = _load(ctypes.c_int32, memory, caller, ret, 0)

load3 = _load(ctypes.c_int32, memory, caller, ret, 8)

ptr4 = load

len5 = load3

list = _decode_utf8(memory, caller, ptr4, len5)

DISCLAIMER: c’est encore assez expérimental et pas forcément en version stable ce que je vais vous montrer ici. La montrer un exemple de function rust qui fait un concat entre 2 string et retourne la nouvelle string. Montrer dans exemple code python qu’on l’appelle. Expliquer le problème du fait qu’il n’y a que 5 types scalaires en WASM et donc pas de string. Du coup ça fait qu’en fait quand on fonctionne comme ça ça transforme la string bytes et ça la met en bytes en WASM. Donc ce qu’on passe à la fonction wasm c’est pas une string mais un pointeur et une taille pour représenter une string. Si on reprend cette représentation de wasm c’est très douloureux à utiliser. C’est pareil pour du Javascript pour info, si il n’y avait pas d’outils qui existaient ce serait pareil. C’est là qu’intervient des libs appelées bindgen, ça génère du code de bindings. Dans le cas de WASM y a une spec/norme qui est lancée par la bytecodealliance qui voit le jour qui s’appelle wit. En fait wit se base sur une syntaxe et un fichier wit qui va décrire les fonctions qu’on va bind.

28 of 33

Bindings générés via wit-bindgen

wit-bindgen, exemple de fichier .wit

Fichier bindings.py généré

+

#[no_mangle]

pub extern "C" fn concat(mut first: String, second: String) -> String {

first.push_str(&second);

first

}

concat: function(first: string, second: string) -> string

input = bindings.Input(store, linker, my_module)

print(input.concat(store, "hello", "world"))

29 of 33

Exécution au niveau de python

Runtime WASM

Lecture dans la mémoire du runtime via pointeur

30 of 33

Fichier wit auto généré grâce à witgen

Fichier .wit généré avec witgen

#[no_mangle]

#[witgen]

pub extern "C" fn concat(mut first: String, second: String) -> String {

first.push_str(&second);

first

}

concat: function(first: string, second: string) -> string

Fichier bindings.py généré

+

input = bindings.Input(store, linker, my_module)

print(input.concat(store, "hello", "world"))

Personnellement je n’aime pas devoir apprendre une nouvelle syntaxe ou maintenir un fichier en plus quand j’écris ou modifie du code. Du coup un petit peu d’autopromo si jamais demain vous voulez vous lancer dans l’aventure ou tester ce que je raconte, comme moi je suis fainéant j’ai écrit une librairie en rust qui permet d’autogénéré un fichier.wit en fonction des fonctions qu’on veut exporter dans notre code en WASM. Donc si je résume maintenant plus besoin d’écrire ce fichier wit ni de le maintenir il est autogénéré grâce à witgen et qui va prendre ce fichier wit pour aussi généré les bindings en python. La boucle de génération de l’enfer est bouclée. Pour info ce systeme aussi fonctionne directement avec wasm-bindgen mais wasm-bindgen ne génère que du code javascript compliant pour browser donc pas forcément super utile dans notre use case de backend.

31 of 33

Exemple wit-bindgen et witgen

32 of 33

Toolings

wasm-opt → optimise le wasm généré
wasm2wat → transforme le format .wasm en .wat pour débug
emscripten → compile du wasm vers du js compliant asm.js

33 of 33

Merci

bnj25

bnjjj