À propos de la pile technique front / About our frontend stack


#1

Ami·e·s Cozynautes,

tl;dr : nous modifions nos choix d’architecture front pour favoriser l’usage de Preact au sein des applications web Cozy, qui devient de facto la brique View de référence pour nos apps à venir.

Il y a quelques semaines, nous publiions un document d’architecture sur la refonte de Konnectors (qui deviendra MyAccounts dans Cozy v3). Dans ce document, suite à plusieurs tests, benchmarks, brainstormings, et consultations prises auprès des chats de @Clochix et d’@aeris, nous tracions la voie de ce qui allait - probablement - devenir le futur des apps dans Cozy v3 : des apps client-side, utilisant l’utilitaire cozy-client-js, avec un workflow de packaging standardisé, et utilisant Vue.js comme couche View.

Vite, Marty, à la DeLorean

Pour expliquer ce revirement dans nos choix, il convient de faire un petit retour rapide en arrière. Cozy est un projet qui a déjà quatre ans (que le temps file, mes bon·ne·s ami·e·s), et qui est passé par plusieurs stades organiques d’évolution. Sans parler de la partie backend, la pile front a elle aussi subi des changements, certains plus radicaux que d’autres.

Back to 2012, nous ne disposons pas de grand-chose pour faire des apps web efficaces (bye bye jQuery), performantes et légères (exit donc Ember et Angular). Backbone est là depuis quelques temps, et il a le mérite d’étre un outil simple, robuste, avec une courbe d’apprentissage rapide. Le choix se portera donc sur Backbone.

Mais Backbone, qui exploite un pattern MVC dans le navigateur ne remplit réellement que les parties MC. Pour la partie Vue, il se contente de renvoyer le contexte courant dans sa méthode de render, et rien de plus. Autant dire que quiconque s’est un jour frotté à Backbone s’est senti comme une poule face à un couteau devant la gestion des vues…

Rapidement, un besoin s’est fait sentir de disposer d’utilitaires pour gérer nos vues de modèles et de collections, a minima pour faciliter leur développement dans les zones communes. Nous avons donc écrit différents petits outils capable de nous faciliter la vie (parce que KISS DRY), probablement imparfaits, mais qui avaient le mérite de remplir 80% de nos usages. Les premières front apps legacy de Cozy ont été développées sur ce modèle.

2014 maintenant… Cozy grandit, et nous décidons de nous doter d’un client mail web, que nous attaquons from scratch. Nous sommes conscient·e·s de son enjeu technique, et très clairement Backbone nous semble trop limité pour nous permettre d’obtenir une app suffisamment solide. À cette époque apparaît une nouvelle brique technique porteuse de beaucoup de promesses : React. Il lui manque encore beaucoup de choses : il n’existe encore aucune implémentation réelle disponible de Flux, les concepts des Stores sont encore très théoriques, et Redux n’existe même pas encore dans la tête de son papa. Nous choisissons de partir sur cette brique extrêmement jeune mais tellement prometteuse. S’en suivra ce que les cozynautes de la première heure connaissent déjà : nous seront confrontés à pas mal de déboires, et cette application subira de nombreuses migrations pour évoluer au fil de ses briques sous-jacentes.

2015 : Nous faisons le choix de repenser notre stack front, qui commence à devenir trop hétérogène pour être sérieusement maintenable dans l’écosystème de la plateforme que représente Cozy. Il nous faut un candidat, Contacts est vieillissant, et c’est une application simple dans ses cas d’usage, profitons-en. Nous partons donc sur une réécriture. Un peu refroidi·e·s par l’expérience de React que nous avons encore du mal à stabiliser sur Emails (et qui nous paraît surdimensionnée par rapport au besoin de Contacts), nous cherchons une nouvelle brique View. Deux candidats sont possibles : une solution à base de Backbone (qui nous permet de conserver nos habitudes) boostée aux stéroïdes pour la partie Vue : ce sera Marionette ; ou une jeune pousse qui semble réellement moderne : Vue.js. Mais Vue.js est encore jeune, nous ne sommes pas sûr de sa pérennité et de sa communauté, et nous choisissons la sécurité, nettement plus rationnelle dans le contexte d’évolution de Cozy : ce sera donc Backbone + Marionette, qui devrait constituer le choix de facto pour les nouvelles apps (le proxy, cozy-music…)

Bye Konnectors, Bonjour MyAccounts !

Nous voici de retour en 2016, les voitures ne volent toujours pas (au grand désespoir de mon fils), mais on parvient à poser une sonde sur un bout de caillou à l’autre bout du système solaire de façon autonome avec un code écrit il y a 10 ans (alors que moi j’ai toujours undefined is not a function dans ma console, mais passons, je ne dois pas avoir le niveau de la NASA…)

Avec l’arrivée de Cozy v3, nous entamons le changement le plus audacieux que Cozy ait connu depuis sa naissance, et c’est le moment de remettre les choses à plat. Dans ce chantier, il y a Konnectors qui va devenir MyAccounts et dont la partie cliente va être entièrement réécrite. La refonte de Contacts avec le couple Backbone + Marionette nous a appris une chose : la performance, notamment sur de grandes collections, reste compliqué avec ces technos. Elles sont efficaces, mais leurs concepts commencent à dater. Peut-être pourront nous trouver une solution plus robuste dans les frameworks modernes. Il est toujours exclu de s’aliéner une solution trop monolithique (exit Angular2, encore une fois, #désopasdéso). React continue son bonhomme de chemin, mais le déployer partout systématiquement nous semble un poil exagéré. En revanche, Vue.js avance, passant en v2, améliorant ses perfs, avec une communauté grandissante et un bon support. Là où sa jeunesse l’avait écarté un an plus tôt, il nous semble maintenant prêt à être exploité en production. Dont acte : ce sera Vue.js pour les prochaines apps (et les refontes à venir), à commencer par Konnectors.

Oui mais non…

Entre-temps, l’équipe de la team front de Cozy grandit, et de nouveaux venus font leur entrée. La question (comme toujours) du choix des technos front revient sur le tapis, et apparaît celui que nous n’avions pas encore identifié : Preact. Preact, c’est un outil de couche View, compatible avec l’API de React, mais plus léger, plus rapide, plus efficace, et développé par une communauté et non par Facebook. Nous décidons de lui donner une chance et de le mettre dans la balance face au choix récent de Vue.js. Concrètement, les deux outils font la même chose, et l’arbitrage va se jouer sur des détails…

La performance

Vue.js reste bien plus performant que React, et un peu plus que Preact. Mais dans nos usages, face aux performances de Preact, ce gain est négligeable. Nous décidons de ne pas en tenir compte.

JSX

Vue.js et Preact s’opposent sur la syntaxe de rédaction du rendu : templates vs JSX. Si le premier est extrêmement déclaratif, le second a le mérite de la concision. L’idée sous-jacente est également celle de distribuer des composants dans Cozy-Ui, souples et faciles à maintenir. De plus, JSX semble avoir la reconnaissance d’une bonne partie de la communauté des développeur.se.s web. Nous choisissons donc JSX.

Note : Vue.js est parfaitement capable d’utiliser une méthode render utilisant du JSX en lieu et place des templates (qui est son choix par défaut). C’eût été une solution efficace que de distribuer des composants Vue.js écrits en JSX et de laisser les développeurs d’app au plus haut-niveau choisir, composant par composant, quel mode de rendu choisir. Mais cela ne risquait-il pas de provoquer une certaine confusion ?

Composant fonctionnel

Pour obtenir une architecture et un arbre de composants suffisamment résistant, l’idée est de n’avoir qu’un seul composant top-level responsable du maintien d’un état, et de n’utiliser que des composants fonctionnels en-dessous, c’est-à-dire des composant ne faisant qu’un rendu sur la base des props passés en argument. Sur ce point, Preact remporte la palme de l’élégance face à Vue.js, voyez plutôt :

// Composant de list-items en Preact

export default List = ({ items }) => (
  <div class="list-container">
    { items.length
    ? <ul>
        { items.map(item => <li key={ item.id }>{ item.name }</li>) }
      </ul>
    : <p>No items found.</p> }
  </div>
)
// Composant de list-items en Vue.js

export default {
  functional: true,
  props: ['items'],
  template: `<div class="list-container">
    <ul v-if="items.length">
      <li v-for="item in items">{{ item.name }}</li>
    </ul>
    <p v-else>No items found.</p>
  </div>`
}

Dans le cas de Preact, la déclaration, les props, et le rendu sont implicites, là où Vue.js impose de déclarer explicitement les props et la nature fonctionnelle du composant.

La communauté

Ça semble évident à dire, mais Cozy est un projet Libre et Open-source, la communauté doit être une de nos préoccupation essentielle. La récente étude sur l’état de JavaScript et notamment les framework frontend montre que React reste un environnement prisé des développeurs. La proportion de ses utilisateur.trice.s dépasse d’ailleurs celle de Vue.js, même s’ils semblent tous deux provoquer le même attrait. Se rapprocher des choix du plus grand nombre semble être, pour nous, le meilleur moyen d’attirer de nouveaux contributeurs et de nouvelles contributrices à l’écosysteme riche que représente Cozy.

Go Preact, Go !

Pour toutes ces raisons, nous avons remis en question le choix initial de Vue.js pour favoriser une solution React-like qui ne soit pas React (a la fois pour des questions d’éthique, de licence et d’éco-responsabilité). Preact semble être le candidat idéal, et nous misons donc sur son adoption dans nos nouveaux projets.

Nous sommes réellement navré.e.s de ce faux-départ concernant Vue.js, et promis, on fera mieux la prochaine fois ! Ami·e·s contributeur·rice·s, vous êtes réellement celleux pour qui nous développons Cozy, et avec qui nous ambitionnons de grandes choses. Notez que si votre préférence va à Vue.js, aucun souci ! Les composants Cozy distribués par Cozy-Ui pourront être utilisés par Vue.js, les apps développées avec fonctionneront sans souci sur Cozy, et cozy-client-js est un outil agnostique qui pourra fonctionner avec des briques comme vue-resource. Aucun problème pour poursuivre sur votre lancée, et même si nous n’assurerons pas de support officiel par manque de temps, l’équipe continue de compter quelques fans de Vue.js qui ne manqueront pas de vous aider :wink:.

Si vous avez des questions, ou si vous souhaitez en discuter, ce fil de discussion est là pour ça. Nous avons besoin de vous !


Dear Coziers,

tl;dr : we are changing our architecture choices for the front stack and finally push to use Preact in cozy web applications, which becomes the de facto View module for our next developments.

Some weeks ago, we published a document about the Konnector refactor task (which will become MyAccounts in Cozy v3). In this document, after many tests, benchmarks, reflexions, and consultations with @Clochix’s and @aeris’ cats, we made the choice of what will - probably - become the futur of Cozy v3’s apps : client-side apps, using the cozy-client-js library, with a standardized packaging workflow, and using Vue.js as a view layer.

Marty, go to the DeLorean!

To explain this change in our choices, we must do a quick flash-back. Cozy is a four-year-old project (damned, that goes quickly my friends!), and it went through many organic evolution steps. The backend part changed, the front stack changed too, and some changes were more important than others.

Back to 2012, we didn’t have many choices to build webapps that were efficient (bye bye jQuery), performant and lightweight (exit Ember and Angular). Backbone had been here for a long time, and was simple, robust, with a quick learning curve. We chose Backbone.

But Backbone, which exposes a MVC pattern inside the browser only fits the MC parts. For the view, it simply returns the context from its render method, and nothing more. Whoever one day tried Backbone may have been at a complete loss with its views system…

Quickly, we needed to have some utils to deal with our model’s and collection’s views, a minima to improve their development in common parts. So we wrote small interfaces to make our developer’s lives easiers (because KISS DRY), probably imperfects, but they filled 80% of our needs. First legacy front apps in Cozy were developped using this model.

2014 now… Cozy grow up, and we decide to build an email client app, that we start from scratch. We are conscious of its technical difficulty, and Backbone is clearly not the choice for this kind of context. It is too limited to get something strong. At this time, a new library appears that promises a lot: React. It lacks a lot of things: no real implementation of Flux, the concepts of Stores are too far theorical, and Redux doesn’t exist, even in its father’s mind. We choose the young library because it is promising. Then occurs what early coziers already know: we faced many problems and refactors to get this app evolves at the same rythm as its underlying libraries.

2015: We choose to rethink our front stack, which start to become too heterogeneous to be clearly sustainable in the Cozy ecosystem. We need a candidate, and Contacts is oldish, it’s a simple app in its use-cases, so let’s go! We start a completely new version. A little bit disappointed by the React experiment that we still have difficulties to stabilize on Emails (and which seems to be a little bit oversized for Contacts), we seek for a new view layer. Two candidates: a solution based on Backbone (which we know really well) on steroids for the view
part: Marionette ; or another new young modern stack: Vue.js. But Vue.js is too young, we can’t bet on it and on its community, so we choose the security in the Cozy’s context: it’ll be Backbone + Marionette, which may be the base stack for our new apps (proxy, cozy-music…)

Bye Konnectors, Hello MyAccounts!

So we’re back on 2016, cars don’t fly (which makes my little son sad), but we can land a probe on a little rock at the end of our solar system in an autonomous way with a 10-year-old code (but I still have “undefined is not a function” in my console, but nevermind, I probably don’t have some NASA’s skills…)

With Cozy v3, we start one of the most ambitious task since Cozy have been born, it’s time to rethink our tools. In it, we have Konnectors, which will become MyAccounts, and its client part will be completely rewritten. The Contact revamp taught us one thing about the Backbone + Marionette couple: performance, especially in long collections, remains really complicated with them. They are efficient, but their concepts are quite oldish. Maybe we can find a more robust solution in modern frameworks. It’s always a no-go to use a monolitic solution (exit Angular@, so-so-sorry). React goes on its trip, but use it everywhere seems a little bit overloaded. But Vue.js is always here, with a v2, more efficient in performances, with a growing community, and a good support. When we drop it because of its youth one year before, it now seems to be ready for production. So on: it’ll be Vue.js for next apps, starting with Konnectors.

Yep, but nope…

In the meantime, the Cozy frontend team grew up, and new developers come in. The question (as usual) of libraries choice comes back again, and a new comer appears: Preact. Preact is a view layer, compatible with the React API, but lightweight, more efficient, faster, and developped by a community rather than Facebook. We decide too give it a chance, and to compare it to Vue.js. Litteraly, both are doing the same things, let me show you…

Performance

Vue.js is still more performant than React, and a little bit more than Preact. But in our contexts, compared to Preact results, is negligible. We choose to neglect this.

###JSX

Vue.js and Preact oppose two philosophies: Templates vs JSX. If the former is purely declarative, the latter is more concise. The underlaying idea is to distribute components via Cozy-Ui, simple and easy to maintain. Besides, JSX seems to be validated by a large part of the webdevs community. So we choose JSX.

Note: Vue.js is able to use a render method using JSX in place of templates (which is its default choice). This can be an efficient solution to distribute VUE.js components written in JSX and let top-level webdevs choosewhich mode is preferable, component by component. But isn’t this a confusing way at term?

Functional components

To have an architecture and a solid components tree, the main idea is to have a single top-level component responsible to maintain the app state, and use only functional components behind, meaning components that only do a rendering based on props passed as argument. On this point, Preact clearly wins the match:

// list-items component w/ Preact

export default List = ({ items }) => (
  <div class="list-container">
    { items.length
    ? <ul>
        { items.map(item => <li key={ item.id }>{ item.name }</li>) }
      </ul>
    : <p>No items found.</p> }
  </div>
)
// ist-items components w/ Vue.js
export default {
  functional: true,
  props: ['items'],
  template: `<div class="list-container">
    <ul v-if="items.length">
      <li v-for="item in items">{{ item.name }}</li>
    </ul>
    <p v-else>No items found.</p>
  </div>`
}

With Preact, props and rendering are implicitely declared, when Vue.js needs to explicitely declare them and its functional nature.

Community

It seems clear, but Cozy is a Libre and Open-source project, and our community is essential. A recent survey about JavaScript State and frontend frameworks shows that React stay one of the mainstream environnement choosen by webdevs. The ratio of React devs is highly more important than the Vue.js one, even if they seems to be both attractive. So choosing the solution prefered by many of us seems to be, for our team, the best way to get more and more contributors to our rich ecosystem.

Go Preact, Go!

For all of this, we choose to rethink our Vue.js initial choice in favor of a React-like solution which isn’t React (for ethics, licensing and eco-responsability reasons). Preact seems to be an ideal candidate, and we bet on it for our new projects.

We are really sorry for this false start about Vue.js, and we promise to do it better next time. Contributors friends, you really are whom we are developing Cozy for. Note that if you prefer to use Vue.js, do it! Cozy components distributed via Cozy-Ui will be usable in Vue.js components, apps developed using Vue.js will work on Cozy without any issue, and cozy-client-js is a agnostic library wich can work with Vue.js tools like vue-resource. No problem to continue on your way and even if we won’t officially support it due to a lack of time, our team still have Vue.js fans that will be pleased to help you :wink:.

If you have questions, or simply want to discuss about it, this thread if the place for. We need you!


#2

Why didn’t bench Inferno.js vs Preact?

Both libraries have very close features, and Inferno.js seems to be faster.


#3

Hello @Aleph-G,

Inferno.js and Preact are 2 exciting projects. They have close features and I can confirm that Inferno.js is faster in benchmarks. But Preact seems a bit more advanced in stability and devtools. So, we will start with Preact. But we will try to keep our options open to switch later to Inferno.js if it makes sense.


#4

All the experimentation Cozy has been doing over the years is fine and great. However, if we want to attract new community developers who can create great apps that will attract new users, I don’t think the Cozy team really needs to provide a single all-encompasing framework. We just need a stable platform to build on. Rather than trying to get everyone to agree on a single UI framework, you should provide an easy API for working with the backend and database.

Recommending a UI framework may help potential contributors who aren’t decided how they want to work. But I think it will also be important to emphasize the fact that app contributors can use whatever framework or workflow they want.


#5

I totally agree with @Terrycloth, a stable platform and a well documented API is what developers need in order to build new apps or port existing ones.


#6

Hi @Terrycloth,

You’re absolutely right, and that’s the goal of cozy-client-js: to provide a easy-to-use library for working with the backend API.

However, with the transition to the new backend stack, we need to update a whole bunch of applications within a short time: that’s why we felt the need to decide on a common stack. We hope it’ll help us to deliver faster. But contributors can use whatever framework they want of course.


#7

Merci pour ce post, c’est marrant de voir que tout le monde se pose ou s’est posé les mêmes questions :slight_smile:

Ce serait chouette d’avoir un thread du même type sur la partie backend et data-loading (entre frontend et backend), notamment les arbitrages techniques qui ont été faits sur les points suivants:

  1. Manière de requêter/modifier les données du serveur
  2. Manière de requéter/modifier les données en local
  3. Réactivité entre les données du serveur et du client
  4. Real Time Collaboration (éditions concurrentes et résolution de conflits via OT, CRDT, Flip, …)
  5. Gestion de la sécurité et de la validation des données
  6. Migration vers ou support d’autres bases de données = Pérennité des applications clientes

Sur pas mal de ces points (réactivité, collaboration) je n’ai rien vu dans la doc de cozy-client-js, est-ce que ce ne sera pas présent, est-ce que ce n’est pas décidé ?
Je pense que c’est par les usages (beaucoup plus que par l’ethique ou la philosophie) que le projet cozy (ou n’importe quel projet similaire) peut espérer sortir les gens et les petites entreprises des clouds propriétaires, et j’imagine mal pouvoir concurrencer google sur les usages si la réactivité et la collaboration n’est pas prévue de base.

Concernant la pérennité des applications clientes qui seront développées pour la v3 (afin de limiter les problèmes de portage d’application que tu cites dans le futur), est-ce qu’un language de query indépendant de la base de donnée choisie a été envisagé ? Je pense notamment à GraphQL.

Et, pour englober ces deux derniers points, je pense à Apollo client, qui a en commun avec le client cozy de se concentrer sur les datas et leur circulation entre le client et le backend, et qui gère à la fois la réactivité et la possibilité d’aggréger les données de plusieurs bases différentes, et donc d’être plus indépendant des choix technologique du backend.

Ca m’intéresse de connaître vos arbitrages sur ces sujets.


#8

Bonjour @williamledoux,

je vais essayer de répondre point par point.

1 Manière de requêter/modifier les données du serveur

On propose une API Rest pour ça. La plupart des données sont stockées dans couchdb et on a repris l’interface http de Couchdb. Elle a fait ses preuves et c’est, à ma connaissance, la solution la plus aboutie pour arriver à un mode déconnecté. On peut, par exemple, utiliser une base pouchdb en local et la synchroniser avec le couchdb distant quand on a du réseau.

On a également d’autres points d’API, en JSON-API. Ils servent pour gérer les fichiers binaires et la création de tâches asynchrones (envoi de mails ou les konnectors par exemple).

2 Manière de requéter/modifier les données en local

On peut souhaite faire les requêtes directement au serveur, soit comme je l’évoquais plus haut, synchroniser les données via un pouchdb local et faire ses requêtes/modifications dessus. Plus fort, on va essayer de faire en sorte que cozy-client-js puisse passer d’un mode à l’autre très facilement. Ainsi, l’application de gestion des fichiers sera disponible en mode web, en requêtant directement le serveur, et on va l’embarquer dans un cordova pour le mobile, et ça passera par un pouchdb pour fonctionner même en offline. Avec le même code. Et un jour, on en fera une Progressive Web App (quand la techno sera un peu plus mûre).

3 Réactivité entre les données du serveur et du client

C’est un sujet en cours de réflexion. On va s’appuyer sur le change feeds de couchdb pour proposer aux applications d’être notifiées via un canal en WebSocket des changements en quasi temps-réel.

4 Real Time Collaboration (éditions concurrentes et résolution de conflits via OT, CRDT, Flip, …)

Ce n’est pas vraiment une priorité pour Cozy. On est un cloud personnel, la collaboration n’est pas au coeur de nos priorités (on ne peut pas tout faire). Ceci dit, couchdb est une bonne base pour aller dans cette direction. Et on aura du partage de cozy à cozy qui va permettre aux utilisateurs des 2 côtés du partage de modifier les données.

5 Gestion de la sécurité et de la validation des données

Pour la gestion de la sécurité, on a pas mal de choses. Je pense que ta question porte plus spécifiquement sur ce que l’on a appelé les permissions. C’est décrit ici : https://cozy.github.io/cozy-stack/permissions.html. En résumé, chaque application doit déclarer les données qu’elle va utiliser et l’utilisateur devra accepter à l’installation de l’app ces permissions. Un peu comme android. Et on aura des permissions optionnelles bientôt.

Pour la validation des données, c’est un sujet que l’on a en tête, mais pas encore eu le temps d’aborder.

6 Migration vers ou support d’autres bases de données = Pérennité des applications clientes

Les applications clientes ne parlent pas directement à la base de données. Elles passent par une API documentée du serveur. On pourrait donc envisager de changer de base de données sans impacter les applications clients. Ceci dit, on utilise beaucoup de mécanismes que l’on retrouve que dans CouchDB. Ça serait beaucoup de boulot de réimplémenter le protocole de réplication par exemple (et sans lui, on fait une croix sur le offline).

est-ce qu’un language de query indépendant de la base de donnée choisie a été envisagé ? Je pense notamment à GraphQL.

Oui, ça a été envisagé. Mais il faudrait vraiment tordre GraphQL pour le faire fonctionner avec CouchDB, il a des limitations importantes. En particulier, la gestion d’un mode hors-ligne est importante pour nous et colle mal à graphql.

Et, pour englober ces deux derniers points, je pense à Apollo client

Je ne connais pas bien Apollo client, mais il m’a l’air très limité sur le temps réel et la collaboration : ça a l’air hostile le code à mettre en place pour gérer un éventuel conflit. Et comme dit plus haut, pas de prise en charge d’un mode hors-ligne.


#9

Merci @nono !

Après la lecture de la doc de cozy stack, je comprend mieux les réponses. Il reste un truc qui m’a fait lever un sourcil en lisant qu’il était envisagé de séparer chaque type de document dans une base séparée. J’explique ma question.

Pour moi cozy ne peut espérer arracher des utilisateurs à Google qu’en proposant des usages meilleurs ou inexistants.
Une partie des usages qui tarderont à arriver sur les google apps sont ceux qui sont trop intrusifs pour qu’on les confie à un tiers, ou qui nécessitent conjointement des données qui sont éparpillées (pour de bonnes raisons).

Un exemple: avoir des tags commun entre toutes mes données, ce qui me permet de voir ou filtrer en un clin d’oeil les données relatives à, par exemple, mon projet “Potager”, que ce soit un mail, un document, une photo, un contact dans mon carnet ou même une opération bancaire ou une facture.

Plus simplement, pouvoir référencer une facture dans une opération bancaire, ou un contact dans un commentaire de photo ou un document.

Ce genre d’usage inter-type de donnée me semble être un atout concurrentiel majeur pour cozy car il est le seul à avoir à la fois les données nécessaires et la légitime confiance de son utilisateur.

A quel point sera t il plus difficile de faire ce genre de jointure avec des bases séparées ?


#10

Bonjour @williamledoux,

la base de données que nous utilisons, CouchDB, n’a pas de jointures. Il est possible de travailler sur des documents de plusieurs types avec des relations. Le fait que les données soient dans plusieurs bases peut compliquer en partie cet usage, mais c’est très limité.

Plus simplement, pouvoir référencer une facture dans une opération bancaire, ou un contact dans un commentaire de photo ou un document.

Par exemple, ce cas d’usage peut être couvert de la même façon que les données soient dans une seule ou plusieurs bases de données couchdb.

Un exemple: avoir des tags commun entre toutes mes données, ce qui me permet de voir ou filtrer en un clin d’oeil les données relatives à, par exemple, mon projet “Potager”, que ce soit un mail, un document, une photo, un contact dans mon carnet ou même une opération bancaire ou une facture.

On pourrait faire ça avec CouchDB (y compris avec plusieurs bases de données), mais on pense plutôt gérer ce genre de cas grâce au moteur d’indexation et recherche “full-text”.

Ce genre d’usage inter-type de donnée me semble être un atout concurrentiel majeur pour cozy car il est le seul à avoir à la fois les données nécessaires et la légitime confiance de son utilisateur.

Tout à fait, c’est un point qui nous semble important à nous aussi !