en microservices pour que ce soit plus performant et moins galère à configurer
hein
Communautés principales de l'instance
Nous rejoindre sur Matrix: https://matrix.to/#/#jlai.lu:matrix.org
Une communauté pour discuter de tout et de rien:
Les mots d'ordre sont : respect et bienveillance.
Les discussions politiques sont déconseillées, et ont davantage leur place sur
Les règles de l'instance sont bien entendu d'application.
Fils hebdomadaires"
"Demandez-moi n'importe quoi"
Communautés détendues
Communautés liées:
Loisirs:
Vie Pratique:
Communautés d'actualité
Société:
Pays:
Communauté de secours:
en microservices pour que ce soit plus performant et moins galère à configurer
hein
En gros nextcloud a besoin d'un redis, d'un cache acpu aussi bien configurés que la base de données pour être vraiment bien performant mais même avec ça ça reste limite. En comparaison, owncloud a été réécrit en go+microservices et le niveau de perf pour la synchro de fichier (elle passe par un service dédié) semble plus performant que nextcloud. Par ailleurs, j'ai vu une bibliothèque rust rpc qui peut aussi fonctionner sur un seul hote en multiprocess
Mais tes micro service il faut aussi un container pour chaque service, en quoi cela simplifie la configuration ?
Et je t'assure pour que ce genre de chose, la performance n'est pas causé par si c'est des micro service ou pas, pire, un monolith bien fait consommera moins de ressources et sera plus rapide si tu host le service sur une seule machine.
Pas nécessairement, owncloud ocis peut tourner sur un seul docker. De plus, j'ai vu un framework rust qui permet de gérer la partie RPC en mémoire locale donc niveau perf, la pénalité est très faible en cas d'exécution sur un seul hôte. De ce que j'ai pu lire également, le client local de nextcloud passe par webdav et passe donc par les même process que l'application web. En comparaison, Seafile qui sépare l'appli web et la partie synchro de fichier peut atteindre une meilleure bande passante (j'ai vu la même chose rapportée pour owncloud infinite scale). Enfin, la partie gestion de la configuration se gère côté développement et on pourrait imaginer un flag pour mettre en mode hôte unique et ça impliquerait moins de galère (je pense à tous les caches possibles pour nextcloud à configurer selon l'importance du nombre d'utilisateurs, la gestion des crons...)
Si tu gères le Rust, ça te dirait éventuellement de jeter un œil aux multi communautés pour Lemmy ?
https://github.com/LemmyNet/lemmy/issues/818
Ça pourrait vraiment changer la donne
Ça fait pas mal de lecture XD Après j'ai choisis rust mais je partirais de notions élémentaires en Rust, ce serait aussi pour me forcer à utiliser quelque chose qui change de python (que j'ai beaucoup utilisé jusqu'à présent)
un client fediverse multi support
Intéressant...
un peu à la façon du nouveau {teams,outlook}
Pitié non ! Pas ça.
avec la possibilité d’un onglet par type de réseau (micro blogging, forum lemmy, funkwhale, peertube, pixelfeed, matrix (c’est pas fediverse je sais mais bon))
Ça me plairait bien.
Je confirme pour être obligé d'utiliser les deux outils cités ci-dessus au boulot, quelle purge! Lent, completement bloated niveau interface (la partie fichiers/ equipe est juste une honte en matière d'ergonomie), le glisser deposer qui te fait croire qu'il fonctionne en discussion alors que non pas du tout. Outlook c'est pas mieux un bon Thunderbird fait bien le boulot pour moi, je l'utilise même pour des modèles car il prend correctement en charge les standards contrairement à l'autre. Bref j'ai encore pleins de choses à dire mais c'est pas le sujet.
Les projets ça va, ça vient le plus important je pense c'est de ne pas être seul pour éviter au max de se demotiver trop vite (avoir des retours voir au mieux des devs). Le client fediverse c'est parfait je pense pour coller à ça, surtout ici. :)
Teams c'est le pire, l'autre jour j'ai du installer troix naviguateurs différents pour en trouver un qui fonctionne ! Et l'onglet devoir j'ai du changer de pc pour qu'il s'ouvre !!!
LE client marche mieux, faut pas utiliser dans un brouteur! /s
A priori je dirais 2. Cela me parait intéressant en termes de fonctionnalités et plus simple d'après les commentaires.
me parait hyper ambitieux. Mais hyper intéressant.
Si tu as une bonne idée de l'ergo fonce! L'outil comble un trou. Et pour l'ergo si tu es pas sur, (je tique sur teams que je detste) tu peux des le début ouvrir vers supporter des skins. Surtout, a moins de vouloir t'y mettre a 100% pendant 6 mois, le seul projet a taille gerable.
Ça sous entend de faire aussi la sélection et skin des outils. Ça me parait encore plus ambitieux que le premierfpremier faut faire ça a plusieurs et se caler de la gestion de projet. Faut avoir une vraiment bonne idée du résultat en particulier en terme de performances, bugs et sécurité.
Le troisième a l'air intéressant