Réflexion sur une v2 about brownbaglunch

[dadoonet]

Bonjour

Avant de parler technique, j'aimerais qu'on discute des besoins. Je vais donc exprimer ici "mes" besoins, ce qui ne veut pas dire que ce soit complet et que cela s'applique à tout le monde.
Puis je vais exprimer "ma" vue technique, hautement discutable :)

Besoins

Simplification de l'ajout/modification/suppression des speakers et talks

Aujourd'hui nous passons par un système de PR qui oblige un "admin" à valider les modifications avant de pouvoir les rendre visibles.
Avoir un selfcare qui permet à chacun de gérer ses informations rendrait le service encore plus fluide.

Pour cela, il faut techniquement envisager un système d'authentification permettant de donner les droits au speaker de modifier son profil et ses talks. Et des droits plus étendus d'admin éventuellement pour que les admins puissent également intervenir.

Internationalisation

J'ai lancé dans ma boite le même principe de BBL dans d'autres pays. J'aimerais donc beaucoup pouvoir leur proposer également ce service dans les autres pays.
Deux possibilités pour cela, rendre brownbaglunch.fr complètement international, autrement dit on y verrait les speakers de tous les pays, avec gestion des talks en plusieurs langues, ...
Ou on documente notre plateforme et on permet à chacun de faire un fork par pays.
Je préfère de loin la première solution. Notamment pour mes propres besoins, l'idée de pouvoir parler dans des pays autres que la France à l'occasion de déplacements me plait beaucoup. Pour cela, il faut faire venir d'autres speakers, d'autres entreprises sur notre site.

Recherche geo localisée

J'aimerais que chaque speaker indique sur une carte sa localisation et son rayon de couverture. Non pas en terme de texte comme actuellement mais avec de vraies coordonnées géographiques (lat, lon, range). Ou en dessinant un polygone sur une carte pour cibler la zone d'action du speaker.

Ainsi, une entreprise qui cherche qui elle peut inviter, pourrait plus facilement trouver les speakers qui peuvent venir dans leurs locaux.

Alerting

Une entreprise pourrait vouloir être informée lorsqu'un nouveau talk/speaker est disponible dans sa région. Notamment utile pour les entreprises qui font des BBLs très régulièrement. En couplant, du texte libre, des tags, de la localisation, on devrait pouvoir fournir ce service.

Notes / Revues / Avis

Pas nécessairement fan des notes, mais peut-être que de laisser la possibilité aux entreprises de commenter le ressenti sur la session serait utile. Libre ensuite au speaker de publier ou non un avis.
Cela a un inconvénient toutefois. Les nouveaux speakers risqueraient peut-être d'être moins visibles...

Entreprises

De la même façon que nous avons des speakers, nous avions commencé à ajouter des entreprises hosts, de façon à ce que les speakers puissent venir proposer leurs sujets.
On peut poursuivre cette idée avec également un selfcare. Peut-être nécessitant pour le coup une gestion un peu plus fine des droits. Plusieurs employés pouvant gérer l'accueil, quid des départs, ...

Reporting

Nous pouvons envisager du reporting en fonction des data que nous avons. Et partager cela sur notre site web. L'évolution du nb de speakers, les visites sur notre site, le nb de talk, par ville... Bref à imaginer.

API

Bien que semblant technique, je pense que nous devons d'abord penser en terme d'API afin de rendre notre site intégrable dans d'autres services, ...
Donc avoir des API propres me semble utile.
Un autre service auquel je pense est en fait notre frontend. Web aujourd'hui, mobile demain ?
Faisons en sorte que notre front n'utilise que des API documentées et publiées.

Technique

Plateforme

Nous avons aujourd'hui deux entreprises qui nous fournissent effectivement une plate-forme où nous pouvons déployer nos services:

• CleverCloud: nous y avons un webhook qui tourne mais qui n'est pas maintenu (my bad): https://github.com/brownbaglunch/java-webhook. Il y avait également une version NodeJS avant: https://github.com/brownbaglunch/webhook
• Elastic: nous fournit un cluster elasticsearch et Kibana complet. Nous pouvons y offrir donc la partie stockage de data, recherche, statistiques et alerting.

Languages

Il faut choisir le language le plus adapté en fonction de la couche (back ou front ou API).
Pour la back, j'ai une préférence pour Java pour plusieurs raisons:

• Le nombre de dev qui peut contribuer du coup à ce projet, sa maintenance, son évolution
• Les frameworks existants (Quarkus, Spring boot, Keycloack, VertX, ...)
• Le support par clevercloud de Java
• Ma propre expérience (mais ça ne compte pas ici)

Pour le front, je ne suis pas un dev front, donc je préfère que les nombreux experts ici proposent effectivement leurs visions. Sachant qu'avec des API, on pourra de toute façon aussi avoir plusieurs "front" suivant le terminal (web, mobile...)

[abelards]

• OK pour changer le gros JSON mais qui d'autre l'utilise ? (des applis mobiles ?)
• OK pour des fonctions dynamiques mais ça pose la question d'avoir un serveur.

Je pense qu'on peut répondre à beaucoup de griefs tout en restant "simples", avec un générateur de site statique.

• on peut tout laisser sur GitHub
• on peut conserver l'ancien JSON
• on peut proposer de nouvelles pages
• la modif de profil se fait sur un seul markdown ou autre

Je connais Jekyll mais je serais ravi de tester Hakyll, Hugo, Hyde ou Middleman.
J'imagine que si 180ko de JS est un souci, on ne veut pas de gros framework front ?

[linsolas]

Hello,

Merci pour tes retours.
On peut rester simple en effet. On peut imaginer que l'intégration d'un nouveau bagger se fasse par une issue Github - en utilisant le bon template - qui serait ensuite traitée par une Github App (je suis devenu expert en développement de Probot 😉 ) pour faire la modification sur le fichier JSON.

De cette façon, on pourrait même imaginer avoir 1 JSON un peu global, et un fichier ensuite par bagger pour le détail (à voir si ça fait du sens, l'idée n'étant pas de requêter 300 petits fichiers JSON pour remplacer 1 gros). Ca peut être intéressant si on utilise ce fichier par bagger que dans la page dédiée au bagger...

Le framework n'est pas forcément un souci, on peut faire du React (PReact) pour gérer le site si on veut, après tout on a mis déjà plein de trucs en place (dont VueJS pour la page baggers.html).

[ygrenzinger]

Si on se concentre sur l'aspect perf et éviter le gros JSON difficile à découper, un site statique comme le propose @abelards permettant de découper mieux le contenu est pas bête ;)

Ptet que GatsbyJS peut être intéressant ? https://www.gatsbyjs.org/packages/gatsby-plugin-local-search/?=search
https://www.gatsbyjs.org/docs/adding-search/

Pour aller plus loin, avec tous les besoins auquel pense @dadoonet , clairement ça serait intéressant de poser de solide bases :)

A voir si on peut intégrer la gestion du back / users directement dans un ES (sorte de CMS API) et mettre le reste dans un gatsbyjs

Je propose des idées. Je dis ptet des conneries :)

[dadoonet]

Hello all!

D'autres avis ?