IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Crux : une approche expérimentale du développement d'applications multiplateformes en Rust avec une meilleure testabilité, une meilleure sécurité et de meilleurs outils

Le , par Jade Emy

52PARTAGES

2  0 
Crux est une approche expérimentale de la création d'applications multiplateformes avec une meilleure testabilité, une plus grande réutilisation du code et du comportement, une meilleure sûreté, une meilleure sécurité et plus de plaisir grâce à de meilleurs outils.

Elle divise l'application en deux parties distinctes, un Core construit en Rust, qui gère la plus grande partie possible de la logique métier, et un Shell, construit dans le langage natif de la plateforme (Swift, Kotlin, TypeScript), qui fournit toutes les interfaces avec le monde extérieur, y compris l'utilisateur humain, et agit comme une plateforme sur laquelle le Core s'exécute.


L'interface entre les deux est une FFI native (Foreign Function Interface) avec une vérification de type inter-langues et une sémantique de passage de messages, où des structures de données simples sont transmises à travers la frontière.

Aperçu de la conception


L'architecture est pilotée par les événements, basée sur l'approvisionnement en événements. Le noyau contient la majorité de l'état, qui est mis à jour en réponse aux événements qui se produisent dans le Shell. L'interface entre le noyau et le Shell est basée sur les messages.

La couche d'interface utilisateur est construite nativement, avec des frameworks d'interface utilisateur déclaratifs modernes tels que Swift UI, Jetpack Compose et React/Vue ou un framework basé sur WASM sur le web. La couche d'interface utilisateur est aussi fine qu'elle peut l'être, et toute autre logique d'application est exécutée par le noyau partagé. La seule restriction est que le Core ne doit pas avoir d'effets secondaires. Il s'agit à la fois d'une exigence technique (pour pouvoir cibler WebAssembly) et d'un objectif de conception intentionnel, afin de séparer la logique des effets et de les rendre plus faciles à tester de manière isolée.

Le noyau demande des effets secondaires au shell par l'intermédiaire de capacités communes. Le concept de base est qu'au lieu d'effectuer le travail asynchrone, le noyau décrit l'intention du travail avec des données et les transmet au shell pour qu'elles soient exécutées. Le Shell effectue le travail et renvoie les résultats au noyau. Cette approche est inspirée d'Elm et similaire à la manière dont d'autres langages purement fonctionnels gèrent les effets et les E/S (par exemple, la monade IO dans Haskell). Elle est également similaire à la manière dont les itérateurs fonctionnent en Rust.

Le Core exporte des types pour les messages qu'il peut comprendre. Le Shell peut appeler le Core et lui transmettre l'un des messages. En retour, il reçoit un ensemble de demandes d'effets secondaires à exécuter. Lorsque le travail est terminé, le Shell renvoie le résultat au Core, qui répond par d'autres requêtes si nécessaire.

La mise à jour de l'interface utilisateur est considérée comme l'un des effets secondaires que le noyau peut demander. L'ensemble de l'interface est fortement typée et les modifications apportées au noyau entraîneront des échecs de construction dans le shell.

Objectifs

L'objectif du test de cette architecture est de trouver une meilleure façon de construire des applications à travers les plateformes. Les objectifs généraux de Crux sont les suivants :
  • Construire la majorité du code de l'application une seule fois, en Rust
  • Encapsuler le comportement de l'application dans le Core pour le réutiliser
  • Suivre le modèle Ports et Adaptateurs, également connu sous le nom d'Architecture Hexagonale pour faciliter le déplacement des effets secondaires vers la périphérie, rendant le comportement facile à tester.
  • Séparer le comportement de l'apparence et de la conception de l'interaction.
  • Utiliser les kits d'outils d'interface utilisateur natifs pour créer l'expérience utilisateur la mieux adaptée à une plateforme donnée.



Source : Crux

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Le langage de programmation Rust gagne en popularité parmi les développeurs et fait son entrée dans le top 20, selon Tiobe. Python, Java, C et C++ s'accaparent à eux seuls de 55% de parts de marché

C-rusted : les avantages de Rust, en C sans les inconvénients, une analyse des trois chercheurs de l'Université de Parme en Italie

« Choisir Rust est opter pour une meilleure sécurisation des logiciels qu'avec le C, mais une efficacité énergétique et une performance d'exécution que seul le C offre », d'après l'équipe AWS

Une erreur dans cette actualité ? Signalez-nous-la !