TSBOARD（TypeScriptで書かれたオープンソースのコミュニティビルダー）
(github.com/sirini)TSBOARDとは？
- TSBOARD は Type Safety BOARD の略で、TypeScriptで書かれたコミュニティビルダー兼掲示板です。
- ここ GeekNews で紹介されたことのある Bun ランタイムを使い、ElysiaJS というWebフレームワークでバックエンドを構成しました。そのため、一般的な掲示板エンジンと比べて動作速度が速いです。
- フロントエンドには Vue と Vuetify が使われています。ただし開発者の美的センスは心もとないレベルなので、いつか優れたデザイナーの方々の助けも得られないかという希望を込めて、ここに投稿することにしました。（+ もちろん優れた開発者の方々の助けも必要です！）
なぜ作ったのか？
- 私はWebプログラムを
PHPで始め、ゼロボードやグヌーボードの時代を経験した（今ではおじさんの）開発者です。 - 私の頭の中にある最後のJavaScriptの記憶は、
jQueryがなければゴミ（…）のような言語、という程度でした。 - しかし、継続的な標準仕様の改善と
Node.jsの登場、そしてMSのTypeScriptに遅ればせながら惚れ込んでしまいました。（実際、惚れ込むのが遅すぎた気もします） - そこで、もう一度Webプログラムを作ってみたくなり、いつも作っていた掲示板をTypeScriptだけで書いてみたい と思いました。
- さらに、（せっかくなら）使いやすく、より速く安全に動作するように作ってみたくて開発しました。
TSBOARDならではの強み
- TSBOARDはフロントエンドとバックエンドの両方がTypeScriptで書かれており、型安全性を最大限に確保しています。（もちろん完璧なものはありませんが、最も気を配ったのは型安全性です）
Node.jsベースのフルスタック開発をしたことがある方には理解しやすく、すぐに活用できる設計です。私自身もゼロから学びながら作ったため、他の方々のベストプラクティスを多く参考にしました。- 中小規模のコミュニティサイトを制作するのに必要な すべての機能が内蔵されています。開発時には Clien、Quasar Zone、Giggle Hardware、また最近新しくできた Damoang のような韓国の代表的なコミュニティサイトを参考にしていました。
欠点もあります。
- Bun ランタイムは仮想CPU上で正常に動作しません。安価に利用できる仮想サーバーホスティングでは十分に活用しにくく、Bun に依存している TSBOARD も同様です。
- TSBOARDはClient Side Rendering方式を採用しています。私は今でもPHPを愛している人間なので、むしろ Server Side Rendering という用語のほうが馴染みがありませんでした。いろいろな長所短所はありますが、まずは（自分にとって）新しい方式を試してみたかったこと、そしてサーバー負荷を減らす目的でTSBOARDを開発したため、これが誰かにとっては明確な欠点に映るかもしれません。
- 実のところ開発を始めてからすでに半年以上経っていますが、ようやく紹介できる程度にはなったものの、まだ至らない点が多くあります。この欠点は、これから出会う優れた皆さんの助けによって解消できることを期待しています。
まとめ：いつか有名なコミュニティサイトがTSBOARDを採用する日を夢見て
- グヌーボードがPHPからPythonへ移行するのを見て、Webプログラムも新しい試みを続けているのだなと感じました。XEから生まれた Rhymix もそうです。Webはいまもなおダイナミックで、開発も同じだと実感しています。
- 私もささやかながら、TSBOARDプロジェクトを通じてWebエコシステムに貢献したいという気持ちで紹介文を残してみます。
- いつか新しく誕生するコミュニティサイトがTSBOARDを採用する、その日を夢見ています。笑
長文を読んでいただき、ありがとうございます！
21件のコメント
2週間ほど前に投稿した記事に追加でコメントを残すのが役に立つかは分かりませんが（笑）、
GeekNewsでいただいたSEO関連のフィードバックをどう反映するか悩んだ末、
sitemap.xmlを実装して検索エンジン最適化を反映した内容を共有するため、コメントとして残します！結論だけ申し上げると、検索エンジンは
robots.txt>sitemap.xmlへのアクセスを通じて最終的にhttps://tsboard.dev/tsapi/seo/main.html （サンプルページ）のパスでデータを収集するようになります。
ユーザーが検索経由で流入した場合は、そのページから再びリンクをたどって元のサイトにアクセスできるようにしました。
詳しい内容は以下のリンクからご確認いただけます！
https://tsboard.dev/board/free/18
私も趣味で作っているプロジェクトをbunで動かそうかと考えていたのですが、仮想CPUでちゃんと動作しないとは驚きですね。それと、会員登録するときのパスワード条件に「大文字」と書いてあったので、小文字は含めなくてもいいのかと思ったら引っかかりましたね（笑）。「大文字・小文字」と書いたほうがよさそうです
念のため返信を残しておきます。Bunランタイムを検討中の方は、もう仮想CPUでの動作問題を心配する必要はありません…！ 1.1.31バージョンでテストしてみたところ、問題なく動作することを確認しました。 :)
ああっ、コメントありがとうございます。ご指摘いただいたパスワード条件の部分の修正も、必ず対応しておきます。haha
Bun は、私も何と言うか、そこまで深く使い込んだわけではないのですが、使いながらいろいろな意味で驚かされる経験をたくさんしました。Node.js では当然のようにできていた機能が、なぜか動かなかったことも多くありましたし（その中には、たとえばフォルダ作成時に
recursive: trueオプションがサポートされていない問題もありました）、驚くほど速度に執着している姿勢も随所に感じました（だからこそ、私はますます愛着を持たずにはいられなかったのですが）。今は Bundows と呼ばれているようですが、Windows での Bun ランタイムは теперь公式サポートされています。ただ、1.1 以前は対応していなかったので、WSL2 上で動かさなければなりませんでした。ご指摘の仮想 CPU での動作については、Bun が今後も対応しない可能性が高いと思います。AVX2 命令をサポートしない CPU 向けの配布版（baseline）までは提供されていますが、仮想 CPU 非対応については、Bun の開発言語である Zig の限界なのかもしれないものの、いろいろな意味で残念な状況ではあります。使っていて感じたのは、速度のために Bun もやはり何かを犠牲にしている部分があるのではないか、という程度です。
もしこのコメントをご覧になる未来の Bun ユーザーの方がいるかもしれないので、少しだけ付け加えると、いくつか制約があるにもかかわらず、Bun は魅力的な選択肢です。特に Web フレームワークとして ElysiaJS を選ぶのであれば、速度面では少なくとも物足りなさを感じることはないだろうと思っています。私がもう一度最初に戻ってランタイムを選び直す場面になったら……もう少し悩むとは思いますが、結局はいろいろな問題があっても、やはり Bun を選ぶ気がします。処理速度に狂気じみたほど執着しているところや、すでに答えがある JS ランタイムのエコシステムに挑戦する姿が、どこか心を動かすんですよね。haha
GitHub のコードを見ていて気になった点があったので、質問を残します。
個人的には、出てきてほしいと思っていた TS ベースの掲示板系が登場して、とても感銘を受けました！
v0.8.40アップデートで外部キー設定が反映されました！
https://tsboard.dev/board/free/18
あっ、コメントありがとうございます！
関係設定というのは、外部キーの設定がされていないことをおっしゃっているのですね！ 特に別の理由があったわけではなく、テーブル構造がある程度固まったら設定してみようと思っていたのですが、途中で別のことを処理しているうちに、まだ反映できていませんでした。すでにTSBOARDのテーブル間の依存関係や参照しているカラムはある程度安定してきたので、これからは外部キーの設定も行って、より整合性を保証できる形に変えていこうと思います！
NoSQLについては少し悩んだこともあったのですが……新しく学ぶことが、まずTypeScriptという言語からVue、Node.js/Bunなどあまりにも多かったので、変えないことにしました。リレーショナルデータベースは長い歴史があるぶん、今では古くなっているのも事実ですが、それでもまだ多くの場所で有用に活用され続けているのには理由があるのではないか、と考えていました。今このコメントを書いている時点ではそんな感じですが、もし今後何か必要性が出てきたら、MongoDBのようなものを検討してみるかもしれません。笑
TypeScriptベースの掲示板がまだなかったというのは、個人的には実は驚きでしたが、これも時間の問題ではないかと思います。TSBOARDとは違うスタイルの別のプロジェクトもたくさん生まれるといいですね！ 笑 コメントありがとうございました！
正直、以前のPHP系掲示板を思い浮かべてあまり期待していなかったのですが、デモサイト（https://tsboard.dev）を見て考えが変わりました。クオリティがとても高いですね。/
こういった点が必要なのではないかと思います！
エディタは直接実装されたのでしょうか？ すごい……。おそらくエディタエンジン（？）を使われたのだと思いますが、とてつもない職人気質を感じます
コメントありがとうございます！ tsboard.dev サイトのクオリティを高く評価していただき、重ねて感謝します。笑
ご指摘いただいた SSR 対応については、2段階に分けてロードマップを準備しており、まずは補完策を適用したうえで、後続バージョンでは CSR と SSR の方式を適切に組み合わせながら開発していこうと考えています。性能を十分に維持しつつ SEO にさらに最適化するには、何より私自身がもっと学ぶ必要もあるため、もう少し時間が必要そうです。あきらめずに継続していけば、私も他のすばらしい開発者の方々と出会い、もっと早く学べたり、もしかしたら助けをいただけたりするのではないかと期待しています。笑
未ログイン利用については、TSBOARD を作る際に開発期間の短縮や設計上のシンプルさを保つため、当初は考慮していませんでしたが、もう少し検討してみます！ 今この返信を書いている時点では、非会員を考慮するとなると変更点がかなり多く必要になるため、すぐの対応は難しそうです。^^;;;
エディタは tiptap エディタをベースに一つひとつ組み上げたのですが、思った以上にエディタ実装に時間を取られました。以前の記憶では CKEditor だったかな…？ ああいうものをそのまま持ってきて使えばよかった気もするのですが、最近はこうして一つひとつレゴを組み立てるように作らないといけないんですよね。T_T そこに TSBOARD の機能を統合しようとして、さらにかなり苦労しました。作りながら感じたのは、このエディタだけでも誰かが作ってくれたらいいのに、ということでした。笑 …もし tiptap ベースで使い勝手のよい（？）エディタが必要な方は、TSBOARD に私が実装しておいたコードを参照すると、もっと早く、もっと簡単に開発できるかもしれません。
予想以上に好意的に見てくださる方が多くて、紹介文を書くときに書くか書くまいか悩んでいた時間がもったいなかったと思えるほどです。TSBOARD はまだまだ至らない部分も多いですが、どうぞよろしくお願いいたします！
php で開発を始めて、私も TypeScript にすっかりハマっていろいろ試していた時期ですね。
なんだか同質感を覚えて、うれしいです。
はじめまして！ 私も似たような道のりを、なりゆきで歩んでいますね。haha PHPという言語はいまだにあちこちで叱られがちで、個人的には残念に思っていますが、TypeScriptを使ってみると、少しくらい叱られても仕方ないかなと思えてきます。haha yeppyshibaさんもTypeScriptで楽しいプロジェクトをたくさんやってみられるといいですね。 :)
とても素敵ですね 👍
ありがとうございます！！ まだ至らないプロジェクトですが、好意的に見ていただけて私もうれしいです。haha
いつかTSBOARDが必要になる時が来たら、自信を持っておすすめできるよう、これからもさらに一生懸命改善していきます。 :)
こういうものが欲しかったので……ありがとうございます。
コメントを残していただき、ありがとうございます！ もし今後いつかTSBOARDのようなWebプログラムが必要になったときに、一度思い出してテストしてみていただけるとうれしいです。必要なときにもっと快適にお使いいただけるよう、これからも引き続き一生懸命作っていきます！
おお…！ PHP時代のsiriniボードを覚えていますが、本当に久しぶりです。
当時は自分なりにシリニボードのスキンも開発して、セキュリティ脆弱性の報告もしたりしていたのですが、お元気にされていますか :)
コードを見ていて感じたのは、サーバー側のコードがどことなくPHPっぽさをかなり感じますね（笑）（PHPっぽいjsコード？）
ほかの方がおっしゃっていた通り、CSRだとSEOなどで不利になるという欠点があると思います。
こうした部分がうまく補完されるとよいですね（笑）
あっ、以前私を助けてくださった恩人の方だったんですね！ こうしてまたお会いできてうれしいです（笑）
あわせて、あの時も今も、誰でも思いつきそうな些細なものばかり作っている気がして、ちょっと恥ずかしいですね。 ^^;;
バックエンドのコードは、おっしゃる通り PHP スタイルが溶け込んでいます（笑）。私もたまに PHP で使っていた関数が JS にはないかな？ と毎回探してしまって、似た名前で関数名を付けて使ったりもします。もう少し JS/TS のコードに慣れて、リファクタリングを重ねていけば、もっと改善できるのではないかとも思っています。
SEO の部分は、おっしゃってくださった通り補強しないといけませんね。私の浅い考えでは RSS のような別の静的ページを追加することなのですが、いろいろ試してみようと思います。
それにしても、PHP4 時代の私を覚えていてくださる方がいるというのは、本当に驚きですし、ありがたいことですね！ 実はこの文章を書くかどうか、かなり悩んでいたんです。もっと多くの方に少しでも役立てるよう、頑張ってみます。TSBOARD もたくさん応援してください！
記事を読んで気になったことがあり、コメントを残します。（コードは見ていません）
バックエンドを Node.js compatible で開発しなかった理由が気になります（おっしゃっていたデメリットを相殺するには、やはりパフォーマンスがあまり出ないのでしょうか？）
CSR の場合、SEO はどのように対応する予定ですか？ コミュニティは検索流入も意識する必要があると思うのですが
こんにちは！コメントを残してくださってありがとうございます。（正直、無関心の中に埋もれると思っていたので感動しています）
ご質問いただいた内容は、私自身もかなり悩んだ部分なのですが、まあこういう考え方もあるのだな、くらいに見ていただければうれしいです。
あ、参考までに、私はPHP以降、実生活では一度もWeb開発を続けたことがありませんでした。Node.js改革の時代も、ReactがWebの世界を変えたときも関心を向けていなかったので、やや馴染みのない視点もあるかもしれません。
私は最初にTSBOARDを開発するとき、すでにNode.jsベースの（私の知らない）有名な掲示板やブログ、あるいは私が作ろうとしていたものと似たものがあるだろうと早合点していました。冒頭でも触れましたが、実生活でWeb開発をすることがなかったのもありますし、別途サイドプロジェクトというものをやったこともなかったので、なおさらそう思っていました。どうせNode.jsベースで出ている何かがあるはずだし、自分がまた新しいものをやるのはあまり意味がないだろう、と考えて、せっかく新しく学ぶならBunベースでやってみよう、と決めたのが今に至るまで続いています。
パフォーマンスの問題を考えると、実のところ、私が目標にしていた小規模コミュニティサイト（同時接続10人未満）では、Node.jsで十分だと思っています。Bunを検討する前にNode.js + Honoベースでもテストしてみましたが、正直私の考えでは問題ありませんでした。ただ、Bunが示していた圧倒的なパフォーマンスに加えて、そのBunを基盤にするElysiaJSのパフォーマンスが本当に印象的で、これを手放したくありませんでした。すでに誰かがNode.jsベースで優れた掲示板を作っているだろうと思っていた私は、その仮想の掲示板と競争するには、より高いパフォーマンスが必要だと考え、結局Node.js互換性を捨ててBun依存で設計することになりました。（今は少し後悔しています。Node.jsベースでGnuBoardやRhymix、XEのような有名な掲示板はなかった……んですよね。私が見つけられなかっただけでしょうか？？）
おっしゃる点はまったくその通りです。検索流入を得るには、いずれにせよGoogleクローラーが内容を読み取り、検索にマッチするようにしなければなりません。この部分はまだ実装していませんが、ユーザーが望む場合、ちょうどRSSフィードを公開するように、最新コンテンツを静的な形で別途共有したらどうかと考えています。JSON形式で外部公開すれば、収集側がより簡単にデータを更新できるのではないか？ という考えもあるので、もう少し検討してみます。（RSSも考えていたのですが、最近はこれをあまり使わないみたいなんですよね？？ 私がWebから離れすぎていたのかもしれません 涙）
SEOの補完策とは別に、CSRにした理由は、サーバー負荷をもう少し積極的に減らしたかったからです。最近できたダモアン（これ、コミュニティ名をそのまま公開していいのか分かりませんが）というサイトの場合も、トラフィック負荷やサーバー負担がかなり大きいと聞いています。コミュニティビルダーというものを考えたとき、SEOも重要ですが、まずはコストに直結する問題から解決すべきだと考えて、CSRを優先的に選択しました。今でもPHPを愛している私としては、むしろSSRのほうが馴染みがありますが、クライアントがもう少し積極的にコンピューティングパワーを使えば、サーバーがもう少し余裕を取り戻せるのではないか？ という考えで選んだものだと見ていただければと思います。
少しでも疑問が解消されていればうれしいです。また、私がした選択には長所と短所がはっきりあるので、TSBOARDが正解だとは実のところ思っていません。いろいろなトレードオフを考慮し、私の短い考えの中で下した決定だと思っていただければと思います。今後TSBOARDがもう少し広く活用されるようになれば、いつでも考えを変えて別の試みをしてみることもあるかもしれません。
設計がすでにCSR前提になっているので、SSRに変えるとなると、ほぼ再開発レベルの作業が必要になりそうですT_T
最近の検索クローラーはJSもある程度改善して処理するとはいえ……やはりプレーンなHTMLにはかなわない気がします。
通常のブラウザはCSRで処理しつつ、検索ボット（GoogleBot、Yetiなど）の場合はSSRで処理する方式もありそうです。
個人的には、そのような方式は一時しのぎだと思っていて、結局SEOをしっかりサポートするにはSSRが正解ではないかと思います。
CSRだとしても、結局リクエスト量が多くなればバックエンドに負荷がかかるでしょうし、キャッシュ設計やさまざまな仕組みを通じてバックエンド負荷を減らすのがよい方向ではある気がします^^;
TSBOARDについては、おっしゃる通りCSR基準ですべて実装されているため、少なくともv1.y.zバージョンではCSR only基準で進める必要がありそうです。いくつか補足すると、最初の画面にすべての投稿が表示される構造なので、最初の画面だけSSR方式を適用する、あるいはおっしゃる通りボットがplain HTML側をクロールできるように別ページを追加する、といった対応が必要そうですね。改善策はv0.9.z系のバージョンで反映できるよう検討してみます！
あ、もしかするとTSBOARDはCSR方式だから検索されないのでは？ と考える方がいらっしゃるかもしれないので少し心配で補足しますが、Googlebotの場合はCSR方式で作られたウェブサイトの内容も取得できる程度にはすでに改善されているそうです！ （Googleだからこそ可能……？）SEOに不利な方式であることは確かですが、まったく無理、というわけではないので、そこまで心配しなくても大丈夫だと思います。
CSR、SSRだけでなく、その中間のような方式もあるでしょうから、もう少し検討してSEOを改善することを目標にv2.0.0ロードマップも策定してみます。（まだ先の話ではありますが笑）アドバイスをいただきありがとうございます。至らないプロジェクトではありますが、TSBOARDをよろしくお願いします！