@Boimb : je connais Koa, mais ça n’a pas super pris, et au final:
- Express nu est tout aussi performant
- promised based => au final express aussi si tu rajoute un petit middleware maison qui fait 1 ligne.
- express a 1000x plus d’intégrations et ça c’est pratique
Regarde le travail que j’ai fais sur le gladys-gateway, c’est 100% à base de async/await, c’est super propre =>
ahaha nice!
Je serais plus chaud d’harmoniser avec le Gladys Gateway! Pour être honnête, j’en ai pas parlé, mais j’ai conçu le Gladys Gateway Frontend pour qu’il puisse tourner aussi bien via le Gateway qu’en direct sur Gladys. Il y a un peu d’adaptation à faire mais pas énorme, en gros la partie E2E encrypted est faite dans un module séparé, le gladys-gateway-js qui abstrait tout, et donc on peut très bien utiliser le front sans ce module.
Notre propre template a moins que quelqu’un dans ce forum ait comme métier d’être designer front-end avec de belles années d’expérience et un portfolio qui claque, je suis pas chaud. C’est un vrai boulot à temps plein de concevoir un template CSS, il y a des tonnes de petits edge case de responsive à gérer, et croyez moi pour arriver au niveau de AdminLTE ou du template que j’ai utilisé pour le Gateway, il faut être une machine de guerre de frontend, et surtout il faut avoir la garantie que cette personne reste dans le projet sur les prochaines années pour aider à maintenir ^^ Je préfère les templates!
*Mon avis là dessus
Le projet est certes excitant, mais c’est quand un même un très très gros projet ^^
Surtout que si on refait le front/le back, c’est l’occasion de repenser pas mal de choses que je referais pas forcément pareil aujourd’hui, avec l’expérience des dernières années sur le projet, les nouveautés technologiques, toussa toussa, donc pour moi c’est pas qu’une réécriture de code.
A mon avis en 1 mois à plusieurs à fond la partie code est pliée. la partie la plus longue va être la conception :
- Base de donnée : c’est l’occasion de construire nous même la DB et donc de repenser éventuellement certaines tables qu’avec l’expérience je referais pas forcément de la même façon.
- Backend: Si on repense la stack, c’est le moment de changer pas mal de petits trucs pour que Gladys soit plus rapide, j’ai pas mal d’idées
- Architecture des module interne: Comment faire pour que Gladys soit plus résiliente à l’installation d’un module foireux? Maintenant qu’on pourra gérer nous même le démarrage des modules (vu qu’on va pouvoir écrire le code nous même, on sera plus dépendant de sails), on va pouvoir détecter les modules foireux et donc éliminer à 100% les erreurs 502 liés aux installations pourries.
- UX : Avec l’expérience des dernières années, se poser les bonnes questions sur l’interface: Qu’est ce que l’utilisateur essaie de faire dans Gladys? Quels screens sont importants/inutiles? Quels screens sont incompréhensibles ? Beaucoup de réflexions là dessus à avoir, de recherches utilisateurs, et de tests.
La next step
Si vous voulez on peut commencer un groupe de réflexion là dessus (j’ai l’impression d’être un cadre de 40 ans qui parle, désolé 
), mais pour l’instant moi je suis à 100% sur le Gladys Gateway qui est ma priorité tant qu’il n’est pas sorti! A part des petits merge de PR à droite à gauche, je suis uniquement focus sur le Gladys Gateway, sinon il sortira jamais 
Deuxième chose à prendre en compte, je vais sûrement commencer le temps partiel dans la semaine qui arrive, genre semaine là ou semaine d’après, pour la simple et bonne raison qu’il faut que j’ai des sous pour manger Donc mes disponibilités vont se réduire à nouveau. Malheureusement tant que le Gateway n’est pas sorti pour que les revenus sur le projet augmente, je dois travailler à côté.
Mais je suis super chaud pour ce projet, je rêve de virer sails, grunt et AngularJS croyez moi 