racacax / XML-TV-Fr

46 stars 30 forks source link

Changer de code base vers du Python ou du NodeJS #61

Open racacax opened 3 months ago

racacax commented 3 months ago

PHP se meurt, n'est pas forcément adapté pour ce soft notamment pour la gestion des promesses et de plusieurs threads.

Est-ce intéressant de basculer vers une nouvelle codebase ? Investiguer...

Idées :

Utiliser une image Docker également. Avoir un ORM pourrait permettre également plus de possibilités au niveau du traitement et export de données.

Benoit382 commented 3 months ago

Php ne meurt pas, il represente "juste" 80% des sites internet :laughing: MAIS, en effet, il n'est pas adapté au multi-threading.

Pour la question de l'ORM, leur principale interet est de manipuler des base de donnée, or dans ton code, tout est fait pour faire du "OneShot" et n'as donc pas de base de donnée

Je vois que tu souhaite ajouter du "Vue.js", ce repo a pour vocation de générer un xml, pourquoi vouloir l'alourdir avec un framework front ? Meme question pour Django et Express, ce sont des framework web.

Pour des performances pure, il existe aussi go et rust. Je te conseillerais plutôt un language [fortement] typé avec un compilateur qui ne te laissera pas faire d'erreur (par exemple : Mauvaise classe Exception, erreur visible lors du build)

racacax commented 3 months ago

PHP se meurt dans le sens que le langage n'est plus forcément adapté aux standards d'aujourd'hui. Peu de nouveaux projets tournent avec PHP, la plupart sont juste des projets anciens maintenus ou des petits sites web. Le projet prendrait juste une autre tournure et serait divisé en plusieurs parties. Un projet principal générant le fichier XML, gérant tous les providers, ... Le projet actuel quoi.

Un autre projet (ou plusieurs) client permettant d'avoir une interface pour gérer tout ça. Tout ce qui tourne autour de Vue.Js, .. serait dans ce projet client. Dans le projet principal, il y aurait juste un framework/ORM.

L'ORM serait présent pour mieux gérer tout ce qui est conflit d'horaires, cache, ... mais aussi pour pouvoir étendre les possibilités avec les potentiels clients.

Pour le coup, la partie ORM est plus une éventualité. J'imagine qu'il y a tout a fait moyen de gérer tout ça sans ORM.

La possibilité d'utiliser Go/Rust, ça peut également être une idée (plus Go, étant donné que j'ai une petite expérience dessus).

Après pour le coup, c'est juste une idée à réfléchir, rien de concret. Le choix initial de PHP à l'époque avait été réalisé parce que c'était le langage avec lequel j'avais le plus d'expérience. Pour l'instant je ne fais pas face à de grosses limitations qui empêchent le projet de se développer et je ne considère pas rentable de migrer à l'heure actuelle. Mais plus tard, ..., peut-être. J'envisage d'augmenter la possibilité de multithreading du projet très prochainement (plusieurs chaines en même temps, ...), c'est pour ça que j'avais envisagé cette option. De mes recherches, c'est toujours faisable en PHP.