Le modèle de composants Wasm et le codegen idiomatique

Arcjet regroupe WebAssembly avec notre SDK de sécurité en tant que code. Cela aide les développeurs à implémenter des fonctionnalités de sécurité communes telles que la détection des informations personnelles et la détection des robots directement dans leur code. Une grande partie de la logique est intégrée dans Wasm, ce qui nous offre un bac à sable sécurisé avec des performances quasi natives et fait partie de notre philosophie autour de la sécurité locale d'abord.

La possibilité d'exécuter le même code sur toutes les plates-formes est également utile à mesure que nous développons la prise en charge de JavaScript vers d'autres piles technologiques, mais elle nécessite une abstraction importante pour traduire entre les langues (notre Wasm est compilé à partir de Rust).

Le Modèle de composant WebAssembly est la construction puissante qui permet cela, mais une construction ne peut être aussi bonne que les implémentations et les outils qui l'entourent. Pour le modèle de composant, cela est plus évident dans la génération de code pour les hôtes (environnements qui exécutent le modèle de composant WebAssembly) et les invités (modules WebAssembly écrits dans n'importe quel langage et compilés dans le modèle de composant ; Rust dans notre cas).

Le modèle de composant définit un langage de communication entre les hôtes et les invités qui est principalement composé de types, de fonctions, d'importations et d'exportations. Il essaie de définir un langage large, mais certains types, tels que les variantes, les tuples et les ressources, peuvent ne pas exister dans un langage de programmation généraliste donné.

Lorsqu'un outil tente de générer du code pour l'un de ces langages, les auteurs doivent souvent faire preuve de créativité pour mapper les types de modèles de composants à ce langage à usage général. Par exemple, nous utilisons jco pour générer des liaisons JS et cela implémente des variantes en utilisant un objet JavaScript sous la forme de { tag: string, value: string }. Il existe même un cas particulier pour le résultat<_ _> tapez où la variante d'erreur est transformée en erreur et levée.

Cet article explore comment le modèle de composant Wasm permet des intégrations multilingues, les complexités de la génération de code pour les hôtes et les invités, et les compromis que nous faisons pour obtenir un code idiomatique dans des langages comme Go.

Génération de code hôte pour Go

Chez Arcjet, nous avons dû construire un outil pour générer du code pour les hôtes écrit dans le langage de programmation Go. Bien que notre SDK tente de tout analyser localement, cela n'est pas toujours possible et nous avons donc une API écrite en Go qui augmente les décisions locales avec des métadonnées supplémentaires.

Go a une syntaxe et un système de types très minimes de par sa conception. Jusqu’à très récemment, ils n’avaient même pas de génériques et ils ont encore des limites importantes. Cela rend le codegen du Component Model to Go complexe de diverses manières.

Par exemple, nous pourrions générer un résultat<_ _> comme :

type Result[V any] struct {
    value V
    err error
}

Cependant, cela limite le type qui peut être fourni en position d'erreur. Nous aurions donc besoin de le coder comme :

type Result[V any] struct {
    value V
    err error
}

Cela fonctionne mais devient fastidieux à utiliser avec d'autres Go idiomatiques, qui utilisent souvent la convention val, err := doSomething() pour indiquer la même sémantique que le type de résultat que nous avons défini ci-dessus.

De plus, la construction de ce résultat est fastidieuse : Result[int, string]{value: 1, err: ""}. Au lieu de fournir le type de résultat, nous souhaitons probablement faire correspondre des modèles idiomatiques afin que les utilisateurs de Go se sentent naturels en consommant nos liaisons générées.

Cartographie idiomatique ou directe

Le code peut être généré pour paraître plus naturel au langage ou il peut s'agir d'un mappage plus direct avec les types de modèles de composants. Aucune des deux options ne correspond à 100 % des cas d'utilisation, c'est donc aux auteurs de l'outil de décider laquelle est la plus logique.

Pour l'outillage Arcjet, nous avons choisi l'approche idiomatique Go pour l'option<_> et résultat<_ _> types, qui correspondent respectivement à val, ok := doSomething() et val, err := doSomething(). Pour les variantes, nous créons une interface que chaque variante doit implémenter, telle que :

type Result[V any, E any] struct {
    value V
    err E
}

Cela établit un bon équilibre entre la sécurité du type et l'emballage inutile. Bien sûr, il existe des situations où l'emballage est nécessaire, mais celles-ci peuvent être traitées comme des cas extrêmes.

Les développeurs peuvent avoir du mal avec des modèles non idiomatiques, conduisant à un code verbeux et moins maintenable. L'utilisation de conventions établies rend le code plus familier, mais nécessite des efforts supplémentaires pour sa mise en œuvre.

Nous avons décidé d'emprunter la voie idiomatique pour minimiser les frictions et faciliter la tâche de notre équipe afin que nous sachions à quoi s'attendre lors des déplacements dans la base de code.

Conventions d'appel

L'une des plus grandes décisions que les auteurs d'outils doivent prendre est la convention d'appel des liaisons. Cela inclut de décider comment/quand les importations seront compilées, si le module Wasm sera compilé lors de l'installation ou de l'instanciation, et du nettoyage.

Dans la base de code Arcjet, nous avons choisi le modèle usine/instance pour optimiser les performances. Compiler un module WebAssembly coûte cher, nous le faisons donc une fois dans le constructeur NewBotFactory(). Les appels Instantiate() ultérieurs sont alors rapides et peu coûteux, permettant un débit élevé dans les charges de travail de production.

type BotConfig interface {
    isBotConfig()
}

func (AllowedBotConfig) isBotConfig() {}

func (DeniedBotConfig) isBotConfig() {}

Les consommateurs construisent cette BotFactory une seule fois en appelant NewBotFactory(ctx) et l'utilisent pour créer plusieurs instances via la méthode Instantiate.

func NewBotFactory(
    ctx context.Context,
) (*BotFactory, error) {
    runtime := wazero.NewRuntime(ctx)

    // ... Imports are compiled here if there are any

    // Compiling the module takes a LONG time, so we want to do it once and hold
    // onto it with the Runtime
    module, err := runtime.CompileModule(ctx, wasmFileBot)
    if err != nil {
            return nil, err
    }

    return &BotFactory{runtime, module}, nil
}

L'instanciation est très rapide si le module a déjà été compilé, comme nous le faisons avec runtime.CompileModule() lors de la construction de la fabrique.

Le BotInstance possède des fonctions qui ont été exportées à partir de la définition du modèle de composant.

func (f *BotFactory) Instantiate(ctx context.Context) (*BotInstance, error) {
    if module, err := f.runtime.InstantiateModule(ctx, f.module, wazero.NewModuleConfig()); err != nil {
            return nil, err
    } else {
            return &BotInstance{module}, nil
    }
}

En général, après avoir utilisé une BotInstance, nous souhaitons la nettoyer pour nous assurer de ne pas perdre de mémoire. Pour cela, nous fournissons la fonction Close.

func (i *BotInstance) Detect(
    ctx context.Context,
    request string,
    options BotConfig,
) (BotResult, error) {
   // ... Lots of generated code for binding to Wazero
}

Si vous souhaitez nettoyer l'intégralité de la BotFactory, celle-ci peut également être fermée :

type Result[V any] struct {
    value V
    err error
}

Nous pouvons rassembler toutes ces API pour appeler des fonctions sur ce module WebAssembly :

type Result[V any, E any] struct {
    value V
    err E
}

Ce modèle de construction d'usines et d'instances nécessite plus de code à utiliser, mais il a été choisi pour obtenir autant de performances que possible dans les chemins chauds du service Arcjet.

En front-loadant le coût de compilation, nous garantissons que dans les chemins chauds du service Arcjet - où la latence compte le plus - le traitement des demandes est aussi efficace que possible. Ce compromis ajoute une certaine complexité au code d'initialisation, mais il s'avère rentable avec une surcharge considérablement inférieure par requête - voir notre discussion sur les compromis.

Compromis

Chaque fois que nous devons intégrer deux langages ou plus, cela implique de nombreux compromis à faire, que ce soit en utilisant FFI natif ou le modèle de composants.

Cet article traite de quelques-uns des défis que nous avons rencontrés chez Arcjet et du raisonnement qui sous-tend nos décisions. Si nous construisons tous sur le même ensemble de primitives, telles que le modèle de composants et WIT, nous pouvons tous exploiter le même ensemble de primitives de haute qualité, telles que wit-bindgen ou wit-component , et créez des outils adaptés à chaque cas d'utilisation. C’est pourquoi travailler vers des normes aide tout le monde.

Le modèle de composant WebAssembly offre une abstraction puissante pour l'intégration multilingue, mais la traduction de ses types dans des langages comme Go introduit des défis de conception subtils. En choisissant des modèles idiomatiques et en optimisant sélectivement les performances (par exemple en utilisant un modèle d'usine/d'instance), nous pouvons offrir une expérience de développement naturelle tout en maintenant l'efficacité.

À mesure que les outils autour du modèle de composants évoluent, nous pouvons nous attendre à des approches de codegen plus raffinées qui simplifient davantage ces intégrations.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!