[fr] À propos de la road map vers Cozy version 3


#1

Cette FAQ fait référence aux changements que nous avons annoncé dans Cozy dans le billet de blog “En route vers Cozy version 3”. Je vous conseille de lire ce dernier avant de lire le post ci-dessous.

Pourquoi passons-nous à Cozy 3.0 ?

Nous rencontrons depuis le départ un problème avec les instances Cozy : elles sont très consommatrices de ressources. Pour faire tourner un Cozy, il faut un minimum d’1 Go de RAM, et les ressources ne peuvent pas être mutualisées entre différentes instances Cozy. Pour faire tourner une instance par membre de votre famille par exemple, il faudrait que chacune embarque son propre serveur Web, sa base de données, etc. Nous voulons régler ce problème en mutualisant certaines ressources pour pouvoir héberger plus de serveurs en consommant moins. C’est valable tant pour celles et ceux qui hébergent leurs propres serveurs que pour les hébergeurs qui souhaitent proposer des offres basées sur Cozy.

Quels sont les avantages de cette nouvelle solution ?

L’objectif principal de la refonte de la stack est le suivant : nous souhaitons qu’ajouter une instance Cozy sur une stack ne coûte rien ou presque. Nous repartons sur des bases plus saines, en profitant de l’expérience acquise sur l’ancienne version et en nous débarrassant de la dette technique accumulée, notamment en termes de sécurité. Nous travaillons également sur un packaging beaucoup plus simple, moins coûteux à maintenir et mieux conçu. Repartir de zéro nous permettra aussi de mieux documenter ce que nous faisons dès le départ.

Quels sont les problèmes ?

La majorité des difficultés que nous anticipons sont liés à la transition entre l’ancienne version et la nouvelle. Comme nous recommençons à zéro, nous avons décidé de prioriser la fonctionnalité de synchronisation et gestion de fichiers et photos comme première brique de Cozy, sur laquelle viendront se greffer les autres applications. Dans un premier temps, vous ne retrouverez donc pas les fonctionnalités que vous aviez sur votre Cozy. Le statut des applications change également : nous nous concentrons sur le côté client, et Cozy ne pourra plus accueillir d’applications Node.js. Nous avons prévu une migration vers la nouvelle version aux alentours de juin 2017, et les nouvelles images pour les autohébergé.e.s devraient arriver en septembre 2017.

Quel avenir pour les applications ?

Nous avons prévu de privilégier les application ‘‘client-side’’ à l’avenir. Pour les applications développées sur ce modèle et donc utilisant la bibliothèque Cozy-browser-sdk, elles devront dorénavant utiliser une nouvelle bibliothèque, Cozy-client-js. Cozy-Client-js est très similaire à Cozy-browser-sdk et fonctionnera avec l’ancienne et la nouvelle version du back-end. Cozy-client-js est documentée et le tutoriel existant sera mis à jour prochainement.

Nous savons que le passage en client-side peut être un gros changement pour le petit nombre de développeurs qui ont créé des applications avec un composant server-side, mais la version 3 apporte de vrais avantages à terme : en intégrant nombre de fonctionnalités directement dans la stack, les applications pourront faire directement appel à des briques qu’il n’y aura plus besoin de coder, en plus des avantages apportés en terme d’afflux d’utilisateurs potentiels.

Certaines applications dont le développement était en cours, comme l’application email ont été mises en pause le temps de mener à bien cette transition vers Cozy 3.0.

Qu’est-ce que cela va changer pour l’autohébergement ?

Les autohébergé.e.s apprécieront sans doute le packaging de Cozy 3.0. Grosse nouveauté également : cela facilitera le déploiement multiple d’instances sur la même stack, ce qui permettra de gérer plus facilement plusieurs instances personnelles.

Si je souhaite m’auto-héberger, est-ce que je peux le faire maintenant ou est-ce que j’ai plus intérêt à attendre ?

Si vous êtes pressé.es et que vous souhaitez utiliser Cozy immédiatement, vous pouvez installer la V1. Vous pourrez migrer à l’avenir vers la prochaine version. Si vos besoins tournent essentiellement autour de la synchronisation de fichiers, et que vous pouvez attendre un peu, alors nous vous suggérons d’attendre la sortie de la Bêta de Cozy version 3 : à ce moment-là vos retours seront très précieux pour le projet.

Quand et comment passera-t-on de l’ancienne version à Cozy 3.0 ?

Nous ne sommes pas encore en mesure de donner une date précise pour la migration. Nous sommes en train de développer un moyen d’exporter ses données d’un ancien Cozy vers un seul gros fichier, qu’on pourra ensuite réimporter dans le Cozy 3.0. C’est le même mécanisme qui permettra de déménager son instance Cozy d’un serveur vers un autre.


#4

Bonjour,

concernant le beta programm, combien de temps cela va durer dans la forme ou il est en se moment?
Je veux dire par la, quand est ce que les hébergés du beta programme passerons a un forfait payant.
Il a été mentionné que lorsque que l’on passera a une release…
Au passage de la v3, sera t’il toujours en beta ? ou en release?

Je vous souhaite une bonne continuation.


#5

Bonjour @cemoi71,

Nous n’avons toujours pas de date pour la fin de la « gratuité » des instances de test.

Une chose est sûre, nous avons toujours besoin de tests et de retours. Et nous allons en avoir encore plus besoin pour « essuyer les plâtres » de la prochaine version.

Pour l’heure, nous suspendons l’offre de test : les Cozynautes qui disposent d’un serveur de test peuvent continuer à l’utiliser et, lorsque la version suivante de Cozy sera utilisable, vous servirez de cobayes pour l’essayer (il sera évidemment possible de demander à récupérer vos données pour les installer sur votre propre serveur si vous voulez continuer à utiliser la version actuelle de Cozy). Nous ne créons plus de serveurs de test avec cette version. Les gens actuellement en liste d’attente vont devoir patienter quelques mois et seront les premier⋅e⋅s à se voir proposer un serveur gratuit pour tester la prochaine version.

En tout état de cause, de longs mois s’écouleront avant que la V3 ne soit considérée comme stable et que nous envisagions le passage à une version payante. Et à ce moment là, vous serez informé⋅e⋅s longtemps à l’avance de vos options : basculer sur une offre payante ou récupérer vos données pour les (faire) héberger ailleurs.

Nous vous informerons dès que nous aurons du nouveau sur le sujet :smile:


#6

Merci beaucoup pour ces précisions.
Et bonne continuation.


#7

Je suis développeur Ruby on Rails et je m’y connais peu en Nodejs. Cette technologie m’intéresse et notamment à travers le projet cozy cloud et d’autres technologies tels que electron (Github).
Je me pose actuellement la question de savoir si il est toujours aussi pertinent de développer une application en Nodejs avec Express ou Meteor après votre retour sur les performances de Nodejs.

J’aimerai savoir pourquoi ne pas avoir développé un cozy multi compte dans votre code js ? Je présume que c’est pour des raisons de sécurités, mais je pense que beaucoup d’applications les gèrent et non pas besoin de lancer autant de serveurs qu’il n’y a de comptes. C’est peut-être pour d’autres raisons, quelles sont-elles ?

J’hésite à passer sur la technologie Nodejs, qui est bien pratique car elle propose à travers Nodejs et certains frameworks (Meteor) :

  • un seul langage côté client et serveur
  • lentency compensation (affiche la création d’un record avant qu’il soit créé par le serveur)
  • distributed data protocol (tout ce met à jour en temps réel à sur la partie client à travers la base de données)
  • accès à la database sans passer par une api json (techno ajax) pour communiquer avec cette dernière.

Le problème avec des langages côtés serveurs, c’est qu’il est difficile de les coupler avec le langage client. On est souvent en train d’écrire 2 fois la même chose. Prenons la création d’un formulaire avec sa validation. Avec Rails par exemple, la validation s’écrit dans le model. Ce qui fait que la création d’un enregistrement est conditionné à la création/modification de celui-ci. Je peux donc créer un enregistrement à travers un formulaire web ou à travers la console ruby, les validations se feront de là même manière. Si je souhaite créé une partie vue en javascript, il va falloir que je réécrive ces validations ou que je passe par un système qui fasse appel au serveur en ajax pour vérifier si mes champs sont corrects. Ce n’est pas une solution viable pour moi.

Même chose si je souhaite faire du data binding à travers la base de données, vuejs, reactjs ne permettent pas facilement ce genre de choses il me semble.

Ma question est celle-ci, est-ce que pour vous, la performance et la réactivité (un langage serveur [performance serveur] + un langage client) prime sur la facilité, la convivialité, la stabilité d’un code unique (un seul langage serveur et client) ?

C’est la question que je me pose actuellement, comment avez vous délibéré sur ce sujet ?

Merci pour réponse.


#8

La validation ne doit JAMAIS être exclusivement faite côté client. Parce que le client peut modifier tout ce qu’il veut et contourner l’ensemble des vérifications s’il en a envie. Donc injecter des données invalides voire compromises.
Une validation côté serveur reste donc OBLIGATOIRE, la validation côté cliente étant plus là pour le côté ergonomie (ne pas avoir à saisir 40× le même formulaire, être notifié immédiatement d’une erreur de saisie) et n’est pas fonctionnelle (au sens spécification du terme).

C’est un problème que j’ai souvent rencontré et qui me saoûle aussi souvent quand je fais du développement web…
La seule partie obligatoire étant la validation côté serveur pour raison de sécurité, j’aimerais bien n’avoir qu’elle à coder, mais ça conduit à des comportements très éloignées de ce à quoi les gens s’attendent (mode web 1.0).
RoR a été je trouve un bon compromis sécurité/ergonomie sans duplication, avec un système qui fonctionne « out-of-the-box » pour notifier proprement des erreurs sans rendre fou l’utilisateur (pré-remplissage des valeurs saisies, coloration des champs erronées…). Mais on reste très loin du web 2.0 auquel on s’est (trop ?) habitué avec 2 chargements de page…

Je n’ai pas beaucoup fréquenté NodeJS pour du dev web, mais je pense que le problème reste identique avec obligatoirement 2 validations à développer, celle côté modèle/serveur pour la sécurité et celle côté vue/client pour l’ergonomie. Le code est peut-être plus facilement mutualisable entre les 2 mondes étant donné que c’est le même langage, mais les concepts sont quand même franchement différents et codés différement (gestion de l’i18n côté client, de l’atomicité côté serveur).


#9

Merci pour ta répone @aeris, ça me conforte dans ce que je pense déjà.
Concernant mon autre question, peux tu m’en dire un peu plus ?

  • J’aimerai savoir pourquoi ne pas avoir développé un cozy multi compte dans votre code js ? Je présume que c’est pour des raisons de sécurités, mais je pense que beaucoup d’applications les gèrent et non pas besoin de lancer autant de serveurs qu’il n’y a de comptes. C’est peut-être pour d’autres raisons, quelles sont-elles ?

#10

À confirmer par la team dev, mais c’est surtout pour des questions de propriété des données.
Il serait très difficile d’extraire les données d’une seule personne pour les réintégrer dans un autre Cozy, la migration d’un cozy à un autre serait très douloureuse et donc tu serais lié à ton prestataire initial. Au même titre que tu es aujourd’hui bloqué chez Google essentiellement parce qu’il n’y a pas de processus simple de migration.
Les bases de données standard rendraient même le processus totalement impossible à cause des conflits de clefs étrangères ou d’unicité des indexes qui empêchent l’extraction simple de toutes les données d’un utilisateur (il faudrait déveloper des exporteurs ad-hoc pour chaque application utilisée) et sa réintégration dans une base contenant d’autres données (conflit de clef ou d’identifiants).

Si on veut conserver une facilité de migration, il faut séparer physiquement les données de chaque utilisateur dans une base de données dédiée qu’on migrera telle quelle vers le nouveau cozy.
La plupart des technos existante sont incompatible avec un tel système, les ORM standard (Hibernate, ActiveRecord, SQLAlchemy…) ne supportant qu’une unique base de données.
Du coup, migration de données ⇒ mono base de données ⇒ mono utilisateur ⇒ 1 stack complète par utilisateur dans le monde de NodeJS.

La réécriture de Cozy v2 en Go (et la chance d’utiliser CouchDB qui permet de gérer plusieurs bases de données sur une même connexion sans se prendre la tête) permet de mutualiser plus de composants pour justement éviter une stack complète par utilisateur.


#11

Hello @thooams,

La réponse n’est pas technique mais philosophique. Cozy est un serveur personnel. Un⋅e utilisateurice, un serveur. Avoir un Cozy multiutilisateur rajouterait beaucoup de complexité, il faudrait une gérer les comptes, les droits d’accès, etc. Nous avons choisi la simplicité (et la sécurité) en décidant que chaque instance serait mono-utilisateurice. Par ailleurs, un des axes de développement de Cozy était de permettre à chacun et chacune d’avoir son propre serveur, par exemple sur un ordinateur de type Raspberry. Nous avons depuis compris que beaucoup de Cozynautes souhaitaient pouvoir héberger plusieurs cozy, pour leurs proches. C’est une des raisons des changement actuels pour faciliter le multi-instances.


#12

Ok les gars, j’ai bien compris l’idée. En tout cas, Cozy est un très beau projet. Perso, j’avais lancer 2 instances dans 2 containers différents avec Docker et c’est vrai que ça consommait effectivement pas mal de mémoire. J’ai du laisser cette solution de côté un peu à cause de ça. En tout cas, j’ai hâte de voir la suite. Continuez comme ça !!! Bravo à toute l’équipe Cozy.

Ps : j’aurais utilisé Crystal à la place de Go mais c’est mon côté rubyiste qui parle ;).


#13

Merci pour la visibilité sur la Roadmap.
Je suis actuellement autohebergé et une mes appli vitales est “Term” …est ce qu’elle sera portée sur la v3 ? merci :slight_smile:


#14

Hello @nicolash,

Malheureusement, non, Term ne fait pas partie des applications qui seront disponibles dès le lancement de la V3. Dans un premier temps, seules des applications purement clientes, communiquant avec le serveur Cozy via son API, pourront être installées sur Cozy V3. Et nous nous concentrons sur la fourniture d’API et le portage d’applications en rapport avec le cœur du projet Cozy : les données personnelles.

Nous espérons pouvoir dans le futur permettre d’installer n’importe quelle application sur Cozy, mais ça n’est pas notre priorité. Si ton besoin principal est d’avoir un serveur d’applications, je te conseille de regarder des projets dont c’est le cœur, comme YunoHost, Sandstorm, libre.sh, Puffin

Je suis bien conscient de l’utilité de Term pour nombre d’autohébergés. Ceci dit, une telle application est indépendante de Cozy, n’accède pas directement à ses données. Si c’est la seule application tierce dont tu as besoin, rien ne t’empêche de l’installer sur le serveur où tu hébergeras ton Cozy v3.


#15

Merci pour ta réponse, dès que j’aurais trouvé la bonne appli “ssh en html5” je l’installerais en effet à côté du cozy, je vais jeter un oeil sur ce qui est le mieux mais si t’as des conseils car “Term” ssh html5 sous google hormis ce projet : https://github.com/liftoff/GateOne
j’ai pas vu grand chose et je sais pas s’il s’agit de la même chose (pas eu le temps encore de tester).

edit : https://github.com/alpha14/cozy-term, ça pourrait fonctionner à côté ? de manière indépendante ?


#16

En alternative, il existe AJAXTerm : https://blog.mossroy.fr/2014/10/18/ajaxterm-acces-ssh-minimaliste-via-le-navigateur-apres-correction-css/


#17

Hello @nicolash,

cozy-term est basé sur tty.js qui n’a pas été mis à jour depuis longtemps, mais parmi ses descendants on trouve xterm.js, qui a l’air assez populaire.

Tu peux également jeter un œil à Hyper, un projet récent et dans le vent. J’avoue n’en avoir utilisé aucun, donc je ne peux pas te les recommander.