Unhosted

Aventures Unhosted

Une traduction approximative du Journal de bord officiel du No Cookie Crew

d’après Unhosted Adventures
by Michiel B. de Jong

7. Ajout de stockage distant aux applications Web Unhosted

Applications stockant des données utilisateur sur votre serveur personnel

Jusqu'à présent nos applications web Unhosted se sont appuyées sur la boîte de dialogue “Enregistrer sous…” du navigateur pour enregistrer les fichiers. Nous avons mis en place notre propre serveur personnel, mais ne l'avons utilisé que pour héberger un profil et exécuter Sockethub pour pouvoir relayer les messages sortants aux serveurs fédérés. Cette semaine, nous allons jeter un œil à RemoteStorage, un protocole permettant aux applications web Unhosted d'utiliser votre serveur personnel comme stockage “cloud”.

Le protocole par lequel un client interagit avec un serveur RemoteStorage est décrit dans draft-dejong-remotestorage-00, un document de travail de l'IETF actuellement en version -00. Il est basé sur le protocole http, TLS, et les en-têtes CORS.

Un serveur RemoteStorage vous permet de stocker, récupérer et supprimer des documents dans une structure de répertoire, en utilisant respectivement les “verbs” http PUT, GET et DELETE. Il répondra avec les en-têtes CORS dans la réponse http, de manière à ce que votre navigateur n'interdise pas à votre application web de faire des demandes à la base de stockage.

En tant que développeur d'application, vous n'aurez pas à écrire ces requêtes http vous-même. Vous avez à votre disposition la bibliothèque remoteStorage.js.

Recyclage des données utilisateur

La bibliothèque remoteStorage.js est divisée en modules (documents, musique, images, …), un module pour chaque type de données. Votre application ne pourra normalement demander l'accès qu'à un ou deux de ces modules (éventuellement en lecture seule). La bibliothèque se charge ensuite d'afficher un widget en haut à droite de la fenêtre, celui-ci permet d'obtenir l'accès aux parties de stockage correspondantes à l'aide du système d'allocation de flux OAuth2 :

Connexion RemoteStorage

Le système d'allocation de flux est spécial dans le sens ou il ne nécessite pas une communication de type serveur-à-serveur, c'est pourquoi il peut être utilisé par les applications web Unhosted, malgré leur absence de serveur back-end. Le “va-et-vient” de OAuth se compose de deux redirections : l'une vers une page de dialogue hébergée par le fournisseur de stockage, et l'autre revenant à l'URL de l'application Web Unhosted. Au retour, le fournisseur de stockage va ajouter un jeton d'accès au fragment d'URL en le plaçant après le [#] comme signature. Ce qui signifie que le jeton n'est même pas envoyé au serveur statique permettant ainsi de desservir l'application web Unhosted. Bien sûr, l'application pourrait contenir du code permettant d'y inscrire des données, mais alors une telle usurpation de jeton serait détectable.

Par défaut, OAuth exige que chaque partie utilisatrice s'inscrive auprès de chaque fournisseur de services, et les spécifications RemoteStorage indiquent que les serveurs “PEUVENT obliger l'utilisateur à enregistrer les applications comme clients OAuth avant la première utilisation”, mais dans la pratique, la plupart des serveurs RemoteStorage permettent à leurs utilisateurs une totale liberté dans leur choix des applications avec lesquelles ils se connectent.

En tant que développeur d'application, vous n'avez pas à vous soucier des tenants et aboutissants des “allées-et-venues” de OAuth qui se produisent lorsque l'utilisateur connecte votre application à sa solution de stockage. Il vous suffit d'utiliser les méthodes proposées par les modules.

Comme il n'existe pas encore une foule de modules, et que ceux qui existent ne disposent pas encore d'une foultitude de méthodes en leur sein, vous êtes susceptibles d'être amené vous aussi à l'écriture et/ou à la contribution (partielle) de certains modules. Vous trouverez les marches-à-suivre sur remotestorage.io.

La synchronisation dans le nuage doit être transparente

En tant que développeur d'application, il vous suffit d'appeler les méthodes proposées par les différents modules remoteStorage.js. L'application n'est pas concernée par la synchronisation de l'ensemble des données, que ce soit par, son instance remotestorage, d'autres applications en cours d'exécution sur le même appareil, des applications s'exécutant sur d'autres appareils, ou encore par la copie régulière des données sur le serveur RemoteStorage. Toute la machinerie de synchronisation est, pour ainsi dire, “derrière” chaque module, et chacun se chargera d'informer l'application lorsque des données appropriées se présenteront.

Puisque toutes les données mises en attente par votre application doivent être envoyées au serveur RemoteStorage de l'utilisateur, et que des changements peuvent surgir à tout moment, et sans prévenir, il nous a paru, jusqu'à maintenant plus facile de développer des applications en utilisant une variation basée sur ce qu'emberjs appelle le “modèle en V” (“the V-model”).

Des actions telles que les clics de souris et l'appui par l'utilisateur sur les touches sont reçues dans votre application par des éléments du DOM. Habituellement, cet élément DOM est en mesure de déterminer lui-même comment il doit mettre-à-jour leurs apparences en conséquence. Mais dans le “modèle en V”, ces actions ne font que passer à travers.

L'élément DOM, en premier lieu, doit laisser son état inchangé, passant l'action du contrôleur au code javascript lequel met alors en œuvre la logique applicative et détermine ce que le résultat — attendu suite à l'action produite par l'utilisateur — devrait être (sur le plan de l'état des données). Ce changement d'état est alors effectué par l'appel d'une méthode dans l'un des modules RemoteStorage. Et jusque là, rien n'a encore changé à l'écran.

Si nous devions suivre complètement le “modèle en V”, alors le changement devrait d'abord descendre directement au serveur de stockage, pour ensuite remonter (suivant la forme d'une lettre V), jusqu'à ce qu'il atteigne à nouveau les éléments du DOM et mette-à-jour leurs états visuels.

Mais nous voulons que nos applications soient réactives, même avec de mauvaises connexions réseau. De toute manière, attendre un aller-retour http complet avant de proposer un retour aux actions des utilisateurs serait généralement trop long, même dans de bonnes conditions réseau.

C'est pourquoi les modules RemoteStorage reçoivent les événements de changement liés aux opérations sortantes au moment où l'information sort sur le réseau, et non pas après que la requête http soit terminée. Pour plaisanter, nous appelons ce concept Synchronisation Asynchrone : l'application n'a pas besoin d'attendre que la synchronisation soit terminée ; la synchronisation avec le serveur se passe en mode asynchrone, en arrière-plan.

Deux façons simples de se connecter dès le lancement

Nous avons mentionné que la spécification RemoteStorage utilise OAuth pour permettre à un module remoteStorage.js d'avoir accès, dès le lancement, à la partie du stockage de l'utilisateur qui lui assignée. Pour permettre à la bibliothèque remoteStorage.js de prendre contact avec le serveur RemoteStorage de l'utilisateur, l'utilisateur saisit son adresse RemoteStorage dans le widget en haut à droite de la page. Une adresse RemoteStorage ressemble à une adresse email, en ce qu'elle prend la forme “utilisateur@chez” (“user@host”). Mais ici, le “chez” (“host”) est bien évidemment votre fournisseur RemoteStorage, et pas votre fournisseur de messagerie, et “utilisateur” (“user”) est le nom d'utilisateur que vous avez chez ce fournisseur.

Le protocole qui est utilisé pour découvrir les détails liés à la connexion de cette chaîne “utilisateur@chez” (“user@host”) est appelé webfinger. Par chance, webfinger prend en charge les en-têtes CORS, du coup il peut être interrogé depuis une application web Unhosted, et ce, sans avoir besoin de passer par un serveur. En réalité, nous avons fait “campagne” — avec succès — pour cette prise en charge l'an dernier lorsque nous avons réalisé à quel point celle-ci était vitale pour les applications Web Unhosted. C'est plutôt sympa de voir que les processus entourant actuellement les standards ouverts pour le web nous ont permis d'inscrire cette question à l'ordre du jour.

Voici donc à quoi cela ressemble pour l'utilisateur :

  1. Cliquez sur “connect remoteStorage”
  2. Tapez l'adresse “user@host” de votre compte RemoteStorage dans le widget
  3. Identifiez-vous auprès de votre fournisseur RemoteStorage (à l'aide de votre compte Persona ou d'un autre)
  4. Passer en revue les demandes des modules de l'application
  5. Si tout semble correct, cliquez sur “Accepter”
  6. Vous voilà alors de retour au sein de l'application et vos données commencent à apparaître

Nous l'avons nommé “app first flow” (“premier flux d'application”). Les étapes 4 et 5 devraient ressembler à-peu-près à ça (illustration depuis 5apps) :

5apps remoteStorage

Une autre façon de connecter une application web unhosted et un compte remoteStorage au lancement est possible si vous disposer d'un “lanceur d'applications” déjà associé à votre compte RemoteStorage. Vous pouvez l'utiliser en installant par exemple l'application ownCloud. Les applications vont tout simplement apparaître sous forme d'icônes dans l'interface web de votre serveur de stockage, et puisque vous aller les lancer depuis celle-ci, il ne vous sera pas nécessaire de saisir votre adresse RemoteStorage à l'ouverture de l'application.

Nous l'avons nommé “storage first flow” (“premier flux de stockage”), François l'a inventé quand il était à Berlin cet été. L'écran de lancement pourrait s'apparenter un peu à l'écran d'accueil d'un smartphone, avec une icône par application (illustration depuis ownCloud) :

ownCloud storage first flow

Une sélection d'applications

La bibliothèque remoteStorage.js a été publiée sous sa première version bêta (étiquetée 0.7.0) la semaine dernière, et nous avons réuni un certain nombre d'applications qui utilisent cette version de la bibliothèque. Jusqu'à présent, j'utilise les applications “music”, “editor” et “grouptabs” pour, respectivement, écouter ma musique (réellement), éditer du texte, et pour mes besoins d'archivages peer-to-peer.

Il existe aussi une application minimale pour la rédaction appelée Litewrite, une application de signets vidéo appelée Vidmarks, un explorateur de fichier RemoteStorage, et un certain nombre d'applications de démonstration. Si vous n'avez pas encore de compte RemoteStorage, il est possible d'en obtenir un auprès de 5apps ou de heahdk. Pour plus d'options et plus d'infos sur RemoteStorage en général, voir remotestorage.io.

Après avoir utilisé l'application todo pour ajouter certaines tâches à votre espace de stockage distant, essayez l'application unhosted time tracker. Vous verrez qu'elle récupère votre liste de tâches depuis votre stockage distant même si vous avez ajouté celles-ci en utilisant une application différente. Ceci démontre donc avec brio la manière dont remoteStorage sépare les données que vous allez stocker des applications que vous aller utiliser.

Le stockage à distance est bien sûr une pièce essentielle du puzzle pour l'utilisation des applications web Unhosted, en effet celles-ci n'ont pas leur propre sauvegarde de données côté serveur (“per-app server-side database backend”). Le protocole RemoteStorage et la bibliothèque remoteStorage.js sont deux choses sur lesquelles certains d'entre nous ont vraiment travaillé dur ces dernières années, et enfin, depuis la semaine dernière, nous sommes en mesure de l'utiliser concrètement au travers de quelques applications. Nous sommes donc très enthousiastes à propos de cette publication récente, et j'espère que vous l'apprécierez autant que nous! :)

Commentaires bienvenus!

Suivant: Collecte et organisation de vos données (traduction en cours)