Merci pour cette clarification ... même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.
Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.
Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:
Le premier réside en la possibilité de faire du crowdsourcing.
Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?
L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.
Enfin 2 petites questions.
* Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
* pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?
[^] # Re: Donnez votre avis sur la nouvelle architecture de Cozy
Posté par El Titi . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 4.
Merci pour cette clarification ... même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.
Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.
Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:
Le premier réside en la possibilité de faire du crowdsourcing.
Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?
L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.
Enfin 2 petites questions.
* Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
* pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?