Où se discute le futur technique?

Barbapapa · Janvier 7, 2025, 12:28

Bonjour à toutes et à tous,

Ma question est (relativement) simple : existe t-il un forum particulier pour échanger sur des propositions sur l’architecture technique de Jeedom, et pourriez-vous me l’indiquer ?

J’ai cherché sur Github et chez Domadoo, mais n’ai rien trouvé.

Je suis un utilisateur de Jeedom depuis ~10 ans, mais il se trouve que j’ai toujours eu un problème existentiel avec PHP même si je suis prêt à lui reconnaitre au moins l’avantage de son caractère dynamique… Et je soupçonne, sans avoir investiguer le moins du monde, que PHP, ou la façon dont il est utilisé, pourraient être à l’origine d’évènement manqués (ce que je vois dans mes logs quasi quotidiennement, ou plutôt que je ne vois pas)…

Bref, j’aimerais discuter avec des gens intéressés sur la façon de transférer l’API Jeedom PHP vers un NodeJS.

Quatre raisons à cela :

je n’aime pas PHP (déjà dit) : il permet trop bien le mélange du code et de l’affichage dans le même script
je n’aime pas Python : je n’aime pas que les espaces soient signifiants, donc exit HA
je n’aime pas Java : un langage construit pas des ingénieurs pour des gens qui ont du temps à perdre et des ressources à consommer, donc exit OpenHab
et je trouve que Javascript est le langage adéquat pour ce qu’on veut faire

J’estime qu’il est possible de définir un serveur NodeJS qui implémenterait une API REST, ce qui pemettrait de migrer « en douceur » (et avec tous les guillemets d’usage) le core PHP…

Pour résumer, et maintenant que mon context est davantage développé, connaissez-vous un tel forum ?

Merci d’avance
Best regards
Pierre

nebz · Janvier 7, 2025, 12:38

Hello, pour ton info à la base le core était en nodejs
Et il serait plus interessant d’utiliser du mqtt. Mais bon tu parles de « API Jeedom en php » donc c’est pas concret ce que tu veux y mettre…

Et non pas de « forum » pour ça, on peut en discuter ici mais au final le dernier mot sera pour jeedom sas qui (je me trompe peut être) ne nous écoutera pas sur un changement de fond comme celui là, ils ont leur propre agenda qu’on ne connaît pas.

pifou · Janvier 7, 2025, 4:50

Bonjour,

Tien ça c’est intéressant, j’ignorais que le core eût été à l’époque en nodeJS, il y a une raison à cette migration en php ? D’ailleurs, je pense perso que nodejs est un langage plutôt orienté frontend, c’est étrange de mettre du javascript côté serveur… (mais bon je viens du monde java personne n’est parfait ) Après, il n’y a pas de mauvais langage, juste de mauvais développeurs.

Du coup puisqu’on lance le sujet, moi je pencherais plutôt sur meilleure séparation frontend / backend mais en conservant l’existant, on a 2 API qui ne sont pas REST mais JsonRPC et l’autre API HTTP = un backend PHP, et construire un frontend nodeJS Angular

Je doute aussi que Jeedom SAS nous suive sur ce genre de suggestion mais rien n’empêche d’en causer, et pourquoi pas ici.

nebz · Janvier 7, 2025, 5:04

Du tout c’est complètement backend justement ! C’est basé sur le moteur javascript de chrome pour faire des démons et des programmes backend.

Ca existe pas AngularJS

pifou · Janvier 7, 2025, 5:08

Ha mais non pas angularJS ça a 20 ans … angular ! et donc nodeJS

nebz · Janvier 7, 2025, 5:11

AngularJS front end (Bon ok et un peu de backend puisque mvc)
Angular back end (et front end aussi)

(Tout deux plus orienté web)

C’est deux sont plus basés sur le modèle mvc (modèle vue contrôleur)… comme Ruby on rails , symfony, laravel (auquel tu peux greffer AngularJS pour le frontend par ex)

Mais angular != NodeJS, c’est pas parce que le langage utilisé est JavaScript (ou typescript) que c’est la même chose !!!

NodeJS c’est fait pour faire tourner des vrais services comme python.

Et oui tu peux faire un serveur web avec python (et nodejs avec express par exemple) ou oui tu peux lui faire afficher du html avec des champs qui viennent d’une db… mais c’est pas fait pour ça

Barbapapa · Janvier 7, 2025, 10:23

Hello,
Oui, dans mon esprit, il s’agirait de full JS, à la fois pour le frontend et le backend.
Pour reprendre un example déjà donné, un serveur NodeJS+Express fonctionne très bien, à la fois pour servir un frontend et un backend et une API REST, et autant de démons qu’on veut (ou quasiment). Voir tous les frameworks qui existent en full JS (Meteor, par ex., pour n’en citer qu’un).
D’ailleurs le frontend pourrait lui-même être constitué de un ou plusieurs plugin(s), théoriquement interchangeables suivant les goûts (et les capacités) de chacun.
En revanche, je vois MQTT davantage comme un bus d’informations, une sorte de bac à évènements, que comme une API - mais peut-être ais-je une vision un peu surannée de la chose
Et je dois dire - mais vous l’avez probablement déjà compris - que j’apprécie beaucoup Javascript. En particulier son paradigme « tout est un objet » qui fait écho pour moi à celui d’unix où « tout est un fichier »…

scalz · Janvier 8, 2025, 10:25

Enorme taff de porter le core jeedom en effet.

Mais tant qu’à rêver, voici ce que j’utilise depuis 6-7 ans qui a complètement remplacé les langages et frameworks que j’utilisais dans le passé.

Voici ce que j’utilise à présent pour tous mes devs:

pour le backend (core et mini-services): Dart. Il y a qq frameworks backend qui sont tops.
pour le frontend crossplatform: Dart. Flutter est un kit/framework UI pour Dart.
pour les scripts CI/CD etc: Dart
évidemment MQTT en bus de comm
db: postgres + influxdb

Avantages:

100% Dart → un seul langage unique, et typé, pour tout faire y compris le frontend. pas besoin de changer de contexte entre du js, html et css par exemple. Et donc forcément, c’est très simple aussi de partage du code/repos entre le backend et le frontend.
aussi facile à utiliser et lire que du js ou python
spécialisé pour développer des applications
super expérience dev
compilable nativement AOT si besoin → déploiement facilité, pas de venv, de version de npm etc
consomme peu de ressources
moderne et évolue vite

Mais il faut pratiquer Dart pour comprendre ce que je veux dire

Bref, c’est plus ou moins ce que je dev de mon coté, j’ai déjà créé pas mal de briques. J’ai déjà le frontend pour ça… (JeeMate).

Je pense que cela sort du cadre de votre projet jeedom. De plus je pense qu’il y a plus de dev web ici qui préfèreront probablement ne pas changer leur langage préféré
Ceci dit, si mon post peut piquer la curiosité et ouvrir l’horizon chez certains, cela fera un outil de plus dans votre boite à outils.

pifou · Janvier 8, 2025, 1:45

Mais tout à fait, loin de moi l’idée de réduire nodeJS à Angular, mais c’est juste que tu ne peux pas faire du Angular sans node JS. Comme tu ne peux pas faire du Spring sans Java. Ni du Symfony sans PHP ce sont juste des frameworks dans leur langage respectif.

Dart je ne connaissais pas, mais, pour le coup ça me semble strictement égal à nodeJS (en tout cas équivalent) puisque les 2 compilent en javascript. Par exemple, je suppose que tous les frameworks nodeJS sont convertit en Dart par une simple compilation, par ex: AngularDart ! (et vice-versa …)

Alors moi perso je ne suis pas fan de PHP. Trop permissif mais malgré tout il permet de faire de l’objet et on aurait pu imposer une norme « tout objet » mais ça n’a pas été fait. Mais il ne s’agit pas de changer de langage préféré juste de progresser et d’apprendre de nouveaux langages
Après, l’argument suivant viendra du nombre de développeurs connaissant le langage (hélas) et ça sera compliqué de lancer un projet de migration en Dart car tu risque d’être un peu seul, alors que nodeJS est plus répandu.

nebz · Janvier 8, 2025, 1:49

c’est CE raccourci que tu fais qui me gène… il y a peu de comparaison dans les autres langages (python, java etc) donc difficile de faire une comparaison informatique pour t’expliquer…

Javascript est seulement l’alphabet ici… mais avec le même alphabet tu peux écrire plusieurs langues, mais dire que l’allemand c’est la même chose que l’espagnol c’est pas vrai… même si c’est le même alphabet. Exactement la même chose ici ! pas la même grammaire ! et ils se comprennent pas.

scalz · Janvier 8, 2025, 3:18

yes je me doute bien qu’il y a plus de devs web par ici.

Dart a justement été créé pour « remplacer » node+js à l’époque
Mais nodejs était trop populaire, ce n’était pas suffisant pour faire la diff.
Puis Flutter (kit graphique) a été créé à partir de Dart. Et là ça a explosé en terme de popularité et d’évolutions. Un écosysteme opiniated et crossplatform n’utilisant qu’un seul langage unique.
Flutter a été dev par des ingé Google ayant bcp influencé le moteur JS et les specs CSS.
Cela a été créé dans le but de créer des apps à la différence d’un « document web ».

Dart c’est OOP. Quand on utilise Flutter on code donc en Dart. Et pour faire simple on dit souvent qu’en Flutter « tout est widget », et donc tout widget est un objet.

C’est de +en+ utilisé par les entreprises sur de nouveaux projets.

Dart compile vers du code machine (natif). et c’est intéropérable avec d’autres langages.

Ainsi un frontend Windows sera compilé vers du code machine Windows, idem pour Linux, Android etc.

Pour du frontend web, forcément cela sera compilé vers du JS/html/css (jamais eu besoin de angulardart…).
Mais plus performant, et qui devient « à la mode », on peut aussi compiler vers web-wasm (comme d’autres le font: kotlin, swift etc).

Et la compilation du frontend ne requiert ni de changer de framework ni de codebase. Flutter se suffit à lui seul.
Par exemple, pas besoin de switcher ou avoir une dépendance ElectronJS pour du desktop, ReactJS pour du web ou encore ReactNative pour du mobile, contrairement à ce que font souvent les frameworks « full js ».

Tout script, mini app CLI, fullstack, peut etre compilé vers le natif. Le runtime Dart (très petit) est dans ce cas inclus dans l’executable. Dart supporte AOT et JIT.

Très facile à apprendre quand on connait typescript, java, c# ou encore python.

Bref, je m’arrete là, je partage juste mon xp (après +30ans à tester moultes lang/frameworks).
Avis aux curieux, il faut etre curieux dans la vie, et encore plus quand on est dev ^^

Bon courage dans ce projet s’il prend jour, même si je pense que c’est bien plus simple de repartir from scratch et de faire qq chose de propre plutot que de faire un portage…
HA, Jeedom etc ont été écrits il y a plus de 10ans maintenant, avec les technos de l’époque, en rustinant parfois si besoin. Je pense qu’il y a moyen de nos jours de faire plus « simple » et moderne avec les nouvelles tech mais je me trompe peut etre.

Barbapapa · Janvier 8, 2025, 6:14

Humm… Ca vaut au moins la peine de s’y intéresser quelques heures
Je vais aller jeter un oeil sur la doc et sur quelques repos Github…
Mais à première vue ne « vendrais-tu » pas un peu le truc ?
Par exemple, je vois que Dart compile vers du JS ou du WEB-ASM (WasmGC exactement). Je ne vois pas de mention de code machine natif.
Et qu’entends-tu par interopérables avec d’autres langages ? Si c’est au travers d’une API, ça me semble évident. Mais veux-tu dire qu’on peut utiliser des modules JS dans Dart par exemple ? Ou bien qu’on peut construire une librairie (un .so sous linux, un .dll sous windows) ?
Mais je vais surtout m’intéresser aux possibilités de load dynamique côté server : peut-on avoir une appli - appelons-là « core » - qui découvre et charge dynamiquement d’autres bouts d’applis, par exemple un accès sgbd particulier, une UI, etc… ? Peut-il y avoir un partage de données en mémoire, ou faut-il passer par du REST ou par autre chose ?

Bon, ben je vais regarder tout ça en tout cas. C’est intéressant. Tu as peut-être un repo que je pourrais consulter ?

Barbapapa · Janvier 8, 2025, 6:18

Et repartir from scratch, pourquoi pas ? Mais ça représente beaucoup de code avant d’avoir un équivalent Jeedom (resp. HA, resp. mettez votre appli favorite). Et donc un long délai avant la première mise en production !
Mais cela dit, ça n’empêche aucunement de penser une nouvelle architecture. A priori, je penserais à quelque chose tiré des archis micro-services. Même si le mot est un peu dévoyé, l’idée reste d’avoir des modules indépendants qui collaborent…
Et discutons toujours, même si ça ne se fait pas - et pourquoi pas !? - ça reste intéressant !

pifou · Janvier 9, 2025, 10:02

Oui il nous l’a un peu sur-vendu son dart je trouve
Repartir from scratch, pas possible, c’est trop gros trop complexe, on arriverait à un ersatz simplifié… C’est pas le tout de faire qqchose de propre et clean, il faudrait reprendre toute la richesse des fonctionnalités de Jeedom ça prendrait un temps fou!
L’approche « micro-service » me parait plus faisable: par exemple on refait un frontend connecté sur le core existant; ou bien un moteur de tâches en mode cli; ou encore, une autre nouvelle API REST indépendante du core existant.
Et puis brique après brique on refait le monde. L’avantage est que chaque brique n’est pas forcément dans le même langage que les autres, chacune étant indépendante. Du coup chaque dev s’impliquera là où il a le plus d’affinité, et ça c’est bien aussi!

Barbapapa · Janvier 10, 2025, 8:16

Oui, il le vend bien
Mais il faut dire que la doc au moins est prometteuse : effectivement, les dernières versions laissent Dart importer du JS, compiler en executables, produire des librairies…
Un langage fortement typé : j’en ai perdu l’habitude.
Et la gestion des classes est plutôt complète, dérivation et implémentation des classes, interfaces, mixins, la totale !
Mais, je cite :
Dart is a client-optimized language […]
Dart is designed for a technical envelope that is particularly suited to client development.
Non qu’on ne puisse pas faire de serveur, ce n’est juste pas la cible du langage.

Et pour en revenir à nos moutons, comment discutent nos microservices ?
De HTTP à Consul (https://www.consul.io/), du plus évident au plus complexe, synchrones ou asynchrones, peut-être même MQTT même si je ne crois pas que la serialization texte soit compatible avec tous les besoins…

scalz · Janvier 10, 2025, 9:36

@Barbapapa @pifou
Je ne vous vends rien. Peu m’importe en fait que vous utilisez ou non.

Juste que ce que certains font avec python, ou js, ou java, on peut faire exactement la meme chose avec d’autres langages, dont Dart qui a de nombreux avantages

Je partageais simplement mon xp, car franchement je pourrais en parler des heures et vous montrer des tas de choses que j’ai faites avec; ça va du backend avec db, micro services, déployés sous docker, à du client crossplatform, en passant par des CLI (mini apps en ligne de commande pour remplacer par exemple du bash etc pour faire du CI/CD ou autres choses).

Là vous commentez sans connaitre. Je connais bien mieux l’écosysteme que lorsque j’ai commencé et que je faisais comme vous, lire des articles ci et là, parfois obsolètes.
Car Dart a été créé à la base pour remplacer node+js, donc pas que pour du client. Et certifiié sans bloat npm
C’est une erreur très fréquente de croire que Dart n’est pas fait pour du backend et que ça ne sert que pour du client style Flutter.
Juste 2 examples de packages/frameworks pour du backend qui sont très appréciés dans la commu: serverpod, supabase.
J’adore aussi le site pub dev qui gère toutes les dépendances Dart, super pratique

Concernant repartir from scratch ou non, ça aussi vous faites bien comme vous voulez
Cela dépend de l’objectif, refaire jeedom, ou bien refaire une analyse plus simple et moderne afin repartir de zero sans fil à la patte.
En se basant sur une archi micro services en effet c’est ce que je fais de mon coté. Sauf que je n’ai pas besoin de tous les plugins jeedom, surtout en 2025… (pour enfoncer un clou, je n’ai pas besoin de toute la boite à outils, seulement du marteau).

Si on essaie de visualiser globalement la masse de travail pour porter le core jeedom et tout ce que cela implique autour, je ne pense pas que cela soit moins energivore que de partir de zero, mais ça n’empeche pas que c’est tjs un challenge interessant pour celui qui a envie:)
D’ailleurs ce dont vous parlez a plus ou moins déjà été tenté il y a qq années par nextdom…

Bref, arretons de parler de Dart ici, c’était juste une suggestion. Si vous souhaitez discuter de dev info, technos etc, je suis dispo sur mon discord

scalz · Janvier 10, 2025, 11:22

Bon, ben je vais regarder tout ça en tout cas. C’est intéressant. Tu as peut-être un repo que je pourrais consulter ?

Non pas de repo publique, ça m’évite notamment d’être « dérangé » par des demandes externes. Je pourrais partager des choses, mais seulement si la personne maitrise Dart et que c’est pour contribuer

kwizer15 · Janvier 11, 2025, 7:43

Bonjour Pierre,

Je comprends votre frustration avec PHP ! Cependant, la réécriture complète d’un système aussi complexe que Jeedom présenterait plus de risques que d’avantages, particulièrement pour l’écosystème de plugins communautaires qui fait la force de Jeedom.

Le PHP moderne (avec des frameworks comme Symfony) a beaucoup évolué et offre maintenant une architecture propre comparable aux autres langages. Le problème n’est peut-être pas tant le langage que l’architecture actuelle du core de Jeedom.

Je suggérerais plutôt de moderniser progressivement l’existant :

Commencer par mettre en place des tests automatisés et des outils d’analyse qualité
Revoir l’architecture pour la rendre plus modulaire
Éventuellement intégrer de nouvelles technologies là où elles apportent une réelle valeur ajouté.

La stabilité et la maintenabilité du code me semblent être des priorités plus importantes que le choix du langage.

Cordialement