TSBOARD (constructeur de communauté open source écrit en TypeScript)
(github.com/sirini)Qu'est-ce que TSBOARD ?
- TSBOARD signifie Type Safety BOARD : c'est à la fois un constructeur de communauté et un forum écrits en TypeScript.
- Le backend a été construit avec le runtime Bun, déjà présenté ici sur GeekNews, et avec le framework web ElysiaJS. Grâce à cela, il fonctionne plus rapidement qu'un moteur de forum classique.
- Côté frontend, Vue et Vuetify ont été utilisés. En revanche, comme le sens esthétique du développeur laisse quelque peu à désirer, j'écris ce post avec l'espoir de pouvoir un jour recevoir l'aide de généreux designers. (+ et bien sûr, l'aide de généreux développeurs est aussi la bienvenue !)
Pourquoi l'avoir créé ?
- J'ai commencé les applications web avec
PHP, et je suis un développeur qui a connu l'époque de Zeroboard et Gnuboard. - Mon dernier souvenir de JavaScript, c'était à peu près : un langage bon à jeter sans
jQuery(...). - Mais j'ai fini par tomber, tardivement, sous le charme des améliorations continues des standards, de l'arrivée de
Node.js, et du TypeScript de Microsoft. (À vrai dire, j'ai l'impression d'être tombé amoureux bien trop tard.) - J'ai donc eu envie de refaire une application web, et surtout de réécrire en TypeScript pur le type de forum que j'avais toujours développé.
- En plus, je voulais en faire quelque chose de facile à utiliser, plus rapide et plus sûr, et c'est ainsi que le projet est né.
Les points forts propres à TSBOARD
- TSBOARD est écrit en TypeScript à la fois pour le frontend et le backend, ce qui garantit au maximum la sûreté des types. (Rien n'est jamais parfait, mais c'est l'aspect auquel j'ai accordé le plus d'attention.)
- Pour ceux qui ont déjà fait du développement full-stack basé sur
Node.js, le design est facile à comprendre et immédiatement exploitable. Comme je l'ai moi-même construit tout en apprenant depuis zéro, je me suis beaucoup appuyé sur les bonnes pratiques d'autres développeurs. - Toutes les fonctionnalités nécessaires à la création d'un site communautaire de petite ou moyenne taille sont intégrées. Pendant le développement, je me suis inspiré de grandes communautés coréennes comme Clien, QuasarZone, GiggleHD, ou encore Damoang, apparu plus récemment.
Il y a aussi des inconvénients.
- Le runtime Bun ne fonctionne pas correctement sur des CPU virtuels. Il est donc difficile de l'exploiter convenablement sur des hébergements de serveurs virtuels à bas coût. TSBOARD dépend lui aussi de Bun, donc il est concerné de la même manière.
- TSBOARD utilise une approche Client Side Rendering. Comme quelqu'un qui a toujours gardé de l'affection pour PHP, même le terme Server Side Rendering m'était plutôt étranger. Cette approche a ses avantages et ses inconvénients, mais je voulais avant tout essayer quelque chose de nouveau et j'ai développé TSBOARD dans l'objectif de réduire la charge serveur ; pour certains, cela pourra clairement être perçu comme un défaut.
- En réalité, cela fait déjà plus de six mois que le développement a commencé, mais il reste encore beaucoup de points perfectibles, au point que ce n'est que maintenant que je peux enfin le présenter. J'espère pouvoir compenser ces faiblesses grâce à l'aide des personnes bienveillantes que je rencontrerai à l'avenir.
Conclusion : en rêvant du jour où des communautés célèbres adopteront TSBOARD
- En voyant Gnuboard passer de PHP à Python, j'ai eu le sentiment que les applications web continuaient elles aussi à tenter de nouvelles approches. C'est aussi le cas de Rhymix, né de XE. Le web reste dynamique, et le développement aussi.
- À ma petite échelle, je laisse cette présentation avec l'envie de contribuer à l'écosystème web à travers le projet TSBOARD.
- Je rêve du jour où une nouvelle communauté adoptera TSBOARD. haha
Merci d'avoir pris le temps de lire ce long message !
21 commentaires
Je ne sais pas si ajouter un commentaire au billet publié il y a environ deux semaines sera vraiment utile, haha.
En réfléchissant à la manière d’appliquer les retours liés au SEO reçus sur GeekNews,
j’ai implémenté
sitemap.xmlafin de prendre en compte l’optimisation pour les moteurs de recherche, et je laisse donc ces informations en commentaire pour les partager.Pour aller droit au but, les moteurs de recherche accèdent d’abord à
robots.txtpuis àsitemap.xml, et finissent par collecter les données à l’adressehttps://tsboard.dev/tsapi/seo/main.html (page d’exemple).
Lorsqu’un utilisateur arrive via une recherche, il est ensuite redirigé depuis cette page vers le site d’origine via des liens.
Vous pouvez consulter les détails via le lien ci-dessous !
https://tsboard.dev/board/free/18
Moi aussi, j’envisageais de faire tourner avec bun un projet que je développe comme hobby, donc c’est assez surprenant d’apprendre que ça ne fonctionne pas correctement sur un CPU virtuel. Et lors de l’inscription, comme il était écrit « majuscule » dans les conditions du mot de passe, j’ai cru qu’il n’était pas nécessaire d’inclure de minuscules, mais je me suis fait avoir haha. Il vaudrait sans doute mieux écrire « majuscules et minuscules ».
Au cas où, je laisse une réponse. Pour celles et ceux qui envisagent le runtime Bun, vous n’avez désormais plus à vous inquiéter des problèmes de fonctionnement sur CPU virtuel... ! Après un test sur la version 1.1.31, j’ai pu confirmer que cela fonctionne sans difficulté. :)
Ah, merci pour votre commentaire, et je veillerai aussi à corriger la partie sur les conditions du mot de passe, comme vous l’avez mentionné. haha
Pour Bun, je ne dirais pas non plus que je l’ai utilisé en profondeur, mais en m’en servant j’ai eu beaucoup d’expériences surprenantes à plusieurs égards. J’ai souvent rencontré des cas où des fonctionnalités qui marchaient naturellement sous Node.js ne fonctionnaient pas, pour une raison ou une autre (par exemple, il y avait aussi le problème de l’absence de prise en charge de l’option
recursive: truelors de la création de dossiers), mais j’ai aussi souvent été frappé par son obsession presque étonnante pour la vitesse (ce qui m’a d’ailleurs rendu le projet encore plus attachant).Maintenant, ils appellent ça Bundows, et le runtime Bun est désormais officiellement pris en charge sur Windows, mais avant la version 1.1 ce n’était pas possible, donc il fallait le faire tourner sur WSL2. Quant au fonctionnement sur CPU virtuel que vous évoquiez, il est peu probable que Bun le prenne en charge à l’avenir non plus. Il existe bien une distribution (baseline) pour les CPU qui ne prennent pas en charge les instructions AVX2, mais l’absence de prise en charge des CPU virtuels reste décevante à bien des égards, que ce soit ou non une limite de Zig, le langage dans lequel Bun est développé. En l’utilisant, j’ai simplement eu l’impression que Bun aussi avait sacrifié certains aspects au profit de la vitesse, c’est à peu près tout.
Au cas où de futurs utilisateurs de Bun tomberaient sur ce commentaire, j’ajouterais encore ceci : malgré ses nombreuses contraintes, Bun reste une option séduisante. En particulier, si vous choisissez ElysiaJS comme framework web, je pense que vous n’aurez au moins rien à regretter côté performances. Si je devais repartir de zéro et choisir à nouveau un runtime... j’y réfléchirais un peu plus, mais malgré les différents problèmes, je pense que je choisirais quand même Bun au final. Son obsession presque maladive pour la vitesse, et sa manière de défier un écosystème de runtimes JS où tout semblait déjà joué, ont quelque chose de très stimulant. haha
En regardant le code sur GitHub, j’ai quelques questions et je me permets de les poser.
Personnellement, j’ai été très impressionné de voir sortir un système de board basé sur TS, comme j’espérais en voir un !
Le paramétrage des clés étrangères a été pris en compte dans la mise à jour v0.8.40 !
https://tsboard.dev/board/free/18
Oh, merci pour votre commentaire !
Quand vous parlez de définition des relations, vous voulez dire que les clés étrangères ne sont pas configurées, n’est-ce pas ? Il n’y avait pas de raison particulière à cela : je pensais essayer de les mettre en place une fois la structure des tables un peu plus arrêtée, mais comme j’ai dû gérer d’autres choses entre-temps, je n’ai pas encore pu l’intégrer jusqu’à présent. Maintenant que les dépendances entre les tables de TSBOARD et les colonnes de référence se sont en grande partie stabilisées, je vais aussi mettre en place les clés étrangères et faire évoluer le tout vers une approche garantissant mieux l’intégrité !
J’ai brièvement réfléchi à NoSQL... mais comme il y avait déjà énormément de nouvelles choses à apprendre — à commencer par le langage TypeScript, puis Vue, Node.js/Bun, etc. — j’ai décidé de ne pas changer. Les bases de données relationnelles sont anciennes, avec toute leur longue histoire, mais je me suis aussi dit qu’il devait bien y avoir une raison si elles restent encore aujourd’hui très utiles dans tant d’endroits. C’est comme ça que je vois les choses au moment où j’écris ce commentaire ; si jamais un besoin apparaît plus tard, je pourrais aussi envisager quelque chose comme MongoDB. haha
Le fait qu’il n’existait pas encore de forum basé sur TypeScript est en réalité assez surprenant pour moi personnellement, mais je me dis que ce n’est peut-être qu’une question de temps. J’aimerais bien voir naître beaucoup d’autres projets, dans un style différent de TSBOARD ! haha Merci encore pour votre commentaire !
Honnêtement, en repensant aux anciens types de forums en PHP, je n’en attendais pas grand-chose, mais en voyant le site de démo (https://tsboard.dev), j’ai changé d’avis. La qualité est vraiment excellente.
Je me dis que ce sont peut-être des points nécessaires !
L’éditeur, vous l’avez implémenté vous-même ? Impressionnant. J’imagine que vous avez sans doute utilisé un moteur d’éditeur (?), mais on sent un sens du détail incroyable.
Merci pour votre commentaire ! Merci encore davantage d’avoir apprécié la qualité du site tsboard.dev. haha
Concernant la prise en charge du SSR que vous avez évoquée, j’ai préparé une feuille de route en deux étapes. Mon idée est d’appliquer d’abord des mesures de compensation, puis, dans une version suivante, de poursuivre le développement en combinant de façon appropriée les approches CSR et SSR. Pour mieux optimiser le SEO tout en conservant des performances suffisantes, il faut avant tout que j’apprenne encore davantage moi-même, donc j’aurai sans doute besoin d’un peu plus de temps. J’espère qu’en persévérant sans abandonner, je pourrai aussi rencontrer d’autres développeurs talentueux, apprendre plus vite et peut-être recevoir leur aide. haha
Pour le mode non connecté, je ne l’avais pas envisagé lors de la création de TSBOARD afin de raccourcir la durée de développement et de conserver une certaine simplicité dans la conception, mais je vais y réfléchir davantage ! Au moment où j’écris cette réponse, cela semble difficile à court terme, car prendre en compte les utilisateurs non membres demanderait beaucoup de changements. ^^;;;
L’éditeur a été assemblé minutieusement sur la base de l’éditeur tiptap, mais l’implémentation de l’éditeur m’a pris bien plus de temps que prévu. Dans mes souvenirs, avant, il y avait CKEditor, peut-être… ? J’ai l’impression qu’on pouvait simplement l’intégrer tel quel, alors que de nos jours il faut tout assembler pièce par pièce, un peu comme des LEGO. T_T Et j’ai encore plus galéré pour y intégrer les fonctionnalités de TSBOARD. En le développant, je me suis dit que ce serait vraiment bien que quelqu’un crée cet éditeur à ma place. haha... Si certains ont besoin d’un éditeur correct basé sur tiptap, je pense qu’en vous référant au code que j’ai implémenté dans TSBOARD, vous pourrez développer plus vite et plus facilement.
Il y a finalement plus de personnes que je ne l’imaginais qui voient le projet d’un bon œil, au point que je me dis que le temps passé à hésiter sur le fait d’écrire ou non un post de présentation était du temps perdu. TSBOARD a encore beaucoup d’insuffisances, mais j’espère malgré tout pouvoir compter sur votre soutien !
J’ai commencé le développement avec php, et c’est justement une période où moi aussi, séduit par TypeScript, j’essaie beaucoup de choses.
Je ressens une sorte d’affinité, donc ça me fait plaisir.
Ravi de vous lire ! Moi aussi, je me retrouve un peu par hasard sur un parcours assez similaire. Haha. C’est dommage, à titre personnel, de voir que le langage PHP se fait encore critiquer à droite à gauche, mais après avoir utilisé TypeScript, je me dis qu’il mérite peut-être quand même un peu ces reproches. Haha. J’espère que vous pourrez vous aussi réaliser plein de projets amusants en TypeScript, yeppyshiba. :)
C’est vraiment génial 👍
Merci !! C’est encore un projet modeste, mais je suis heureux que vous l’ayez apprécié. Haha.
Le jour où vous aurez besoin de TSBOARD, je vais continuer à l’améliorer encore davantage pour pouvoir vous le recommander en toute confiance. :)
C'est exactement le genre de chose qui me manquait... merci.
Merci pour votre commentaire ! Si jamais vous avez un jour besoin d’un programme web similaire à TSBOARD, j’espère que vous penserez à lui et que vous accepterez de le tester. Je vais continuer à y travailler avec sérieux pour que vous puissiez l’utiliser encore plus facilement quand vous en aurez besoin !
Oh... ! Je me souviens du board sirini à l’époque de PHP, ça faisait vraiment très longtemps.
À l’époque, j’avais même développé un skin pour Sirini Board et signalé des failles de sécurité ; j’espère que vous allez bien :)
En regardant le code, ce que j’ai ressenti, c’est que la partie serveur a beaucoup une vibe PHP, haha (du code JS avec une vibe PHP ?)
Comme quelqu’un d’autre l’a mentionné, si c’est du CSR, il y aura sans doute l’inconvénient d’être défavorisé pour le SEO, entre autres.
J’espère que ce point pourra être bien compensé, haha.
Ah, vous étiez donc le bienfaiteur qui m’avait aidé autrefois ! Ça me fait plaisir de vous retrouver comme ça haha.
De plus, à l’époque comme aujourd’hui, j’ai un peu honte d’avoir l’impression de ne créer que des choses assez banales auxquelles tout le monde pourrait penser. ^^;;
Comme vous l’avez dit, le code backend porte en effet une influence du style PHP haha. Il m’arrive encore parfois de me demander s’il n’existe pas en JS une fonction que j’utilisais en PHP, puis de finir par en créer une avec un nom de fonction similaire. Je me dis qu’avec davantage d’habitude en code JS/TS et en continuant à refactoriser, ça pourra encore s’améliorer. haha
Pour la partie SEO, comme vous l’avez indiqué, il va falloir que je l’améliore. Dans ma réflexion encore limitée, j’envisageais d’ajouter d’autres pages statiques comme un flux RSS, mais je vais essayer différentes choses.
Cela dit, savoir qu’il y a quelqu’un qui se souvient de moi à l’époque de PHP4, c’est vraiment surprenant et je vous en suis très reconnaissant ! En fait, j’ai beaucoup hésité avant d’écrire ce billet. haha;; Je vais essayer de faire en sorte que cela puisse aider, même modestement, davantage de personnes. Continuez à soutenir TSBOARD !
J’ai une question après avoir lu l’article, donc je laisse un commentaire. (Je n’ai pas regardé le code.)
Je me demande pourquoi vous n’avez pas développé le backend pour qu’il soit compatible Node.js (les inconvénients que vous avez mentionnés ne sont-ils pas suffisamment compensés, ou les performances restent-elles vraiment trop faibles ?)
S’il s’agit de CSR, comment comptez-vous gérer le SEO ? Pour une communauté, il me semble qu’il faut aussi prêter attention au trafic issu des moteurs de recherche.
Bonjour ! Merci d’avoir laissé un commentaire. (Pour être honnête, je pensais que ça passerait inaperçu, donc ça me touche.)
J’ai moi aussi beaucoup réfléchi aux points que vous avez soulevés, donc j’aimerais que vous lisiez ça simplement comme une autre manière de voir les choses.
Ah, au passage, après PHP, je n’ai plus continué le développement web une seule fois dans ma vie active. Je ne me suis donc pas intéressé à l’époque de la révolution Node.js ni au moment où React a changé le monde du web, donc mon point de vue peut paraître un peu inhabituel. Haha.
Quand j’ai commencé à développer TSBOARD, je supposais qu’il existait déjà quelque chose de célèbre, basé sur Node.js, un forum, un blog ou en tout cas un outil similaire à ce que je voulais créer. Comme je l’ai dit au début, je n’avais pas à faire de développement web dans ma vie active, et je n’avais jamais vraiment fait de side project non plus, donc ça a sans doute joué. Je me suis dit qu’il devait forcément déjà exister quelque chose en Node.js, et que refaire encore une nouvelle solution n’aurait pas beaucoup de sens. Puisque j’allais apprendre quelque chose de nouveau, j’ai donc décidé de partir sur Bun, et c’est ainsi que j’en suis arrivé jusqu’ici.
Si on réfléchit à la question des performances, pour le petit site communautaire que je visais au départ (moins de 10 utilisateurs simultanés), je pense honnêtement que Node.js suffit largement. Avant d’examiner Bun, j’avais aussi fait des tests avec Node.js + Hono, et de mon point de vue, ça ne posait pas vraiment de problème. Cependant, les performances écrasantes annoncées par Bun, ainsi que celles d’ElysiaJS, qui repose sur Bun, m’ont vraiment impressionné, et je ne voulais pas renoncer à cet avantage. Comme je pensais qu’il existait déjà quelque part un excellent forum basé sur Node.js, j’ai estimé qu’il me fallait de meilleures performances pour rivaliser avec ce forum imaginaire, et j’ai fini par abandonner la compatibilité Node.js pour concevoir le projet avec une dépendance à Bun. (Maintenant, je le regrette un peu. En fait, il n’y a pas… de grand forum célèbre basé sur Node.js, comme GNU Board, Rhymix ou XE. Ou alors c’est moi qui n’ai pas su le trouver ??)
Vous avez entièrement raison sur ce point. Pour obtenir du trafic via les moteurs de recherche, il faut de toute façon que le crawler de Google puisse lire le contenu et l’associer correctement dans les résultats. Cette partie n’est pas encore implémentée, mais je réfléchis à la possibilité, si l’utilisateur le souhaite, de partager séparément les contenus récents sous une forme statique, un peu comme on expose un flux RSS. Je me dis aussi que si on l’expose à l’extérieur sous forme de JSON, les collecteurs pourraient peut-être mettre les données à jour plus facilement. Je vais encore y réfléchir. (Je pensais au RSS, mais j’ai l’impression que la plupart des gens ne l’utilisent plus aujourd’hui ?? Ça fait peut-être trop longtemps que je n’ai pas fait de web, snif.)
Indépendamment des mesures de compensation pour le SEO, si je suis parti sur le CSR, c’est parce que je voulais réduire plus activement la charge côté serveur. Dans le cas du site Damoang, apparu récemment (je ne sais pas si je peux citer ouvertement le nom de cette communauté), je crois comprendre que la charge de trafic et la pression sur le serveur sont déjà assez importantes. Quand on pense à un community builder, le SEO est certes important, mais je me suis d’abord dit qu’il fallait résoudre en priorité les problèmes directement liés aux coûts, donc j’ai choisi le CSR en premier. Moi qui continue d’aimer PHP, le SSR m’est en réalité plus familier, mais je me suis dit que si le client utilisait plus activement sa propre puissance de calcul, le serveur pourrait retrouver davantage de marge. C’est dans cet esprit qu’il faut voir ce choix.
J’espère que ça a un peu répondu à vos interrogations. Par ailleurs, les choix que j’ai faits ont chacun des avantages et des inconvénients très clairs, donc je ne pense pas que TSBOARD soit la réponse absolue. Disons plutôt que j’ai pris ces décisions après avoir considéré plusieurs trade-offs, avec ma réflexion encore limitée. Si TSBOARD est davantage utilisé à l’avenir, je pourrai très bien changer d’avis et tenter d’autres approches à tout moment. Haha.
La conception est déjà adaptée au CSR, donc pour passer au SSR, il faudrait probablement un travail presque équivalent à une réécriture complèteT_T
Les crawlers de recherche récents gèrent certes un peu mieux le JS, mais... malgré tout, j’ai l’impression qu’ils ne pourront jamais égaler du HTML brut.
Avec un navigateur classique, on peut rester en CSR, mais pour les robots d’indexation (GoogleBot, Yeti, etc.), il pourrait aussi y avoir une approche consistant à utiliser le SSR.
Personnellement, je pense que ce genre d’approche relève du dépannage temporaire, et qu’au final, si on veut bien prendre en charge le SEO, le SSR est sans doute la bonne réponse.
Même en CSR, si le volume de requêtes augmente, cela finira par créer une charge côté backend, et il me semble que la bonne direction est plutôt de réduire cette charge backend grâce à une bonne stratégie de cache et à divers mécanismes ^^;
Dans le cas de TSBOARD, comme vous l’avez dit, tout a été réalisé sur une base CSR, donc il semble qu’au moins pour les versions v1.y.z, il faudra travailler selon une approche CSR only. Pour apporter quelques améliorations, comme la structure affiche tous les articles dès le premier écran, on pourrait par exemple appliquer le SSR uniquement à cette première page, ou bien, comme vous l’avez suggéré, ajouter une page séparée afin que les bots puissent crawler la partie en HTML brut. Nous allons essayer d’intégrer des mesures correctives dans la branche de version v0.9.z !
Ah, au cas où certaines personnes pourraient penser que « TSBOARD n’apparaît pas dans la recherche parce qu’il fonctionne en CSR ! », je préfère préciser un point : dans le cas de Googlebot, il paraît que les choses se sont déjà suffisamment améliorées pour qu’il puisse aussi récupérer le contenu de sites web construits en CSR ! (possible parce que c’est Google... ?) Il est certain que ce n’est pas l’approche la plus favorable pour le SEO, mais ce n’est pas non plus quelque chose qui « ne fonctionne pas du tout », donc je pense qu’il n’y a pas trop lieu de s’inquiéter.
Il existe sans doute, entre le CSR et le SSR, d’autres approches intermédiaires ; je vais donc y réfléchir davantage et établir aussi une roadmap v2.0.0 avec pour objectif d’améliorer le SEO. (Même si c’est encore un sujet assez lointain, haha.) Merci pour vos conseils ; le projet a encore des insuffisances, mais je vous recommande chaleureusement TSBOARD !