オンラインコミュニティプラットフォームである「OSIRO」を開発して8年以上が経過しました。
開発を進める間に、Railsだけでなくフロントエンド技術やWebも色々進化してきましたが、
8年間一貫してRailsとVueを使ってきました。しかし、いくつかの課題に直面しフロントエンドのリニューアルを決意しました。本記事では、VueとRailsのプロダクトをWebComponentsとTurbo、そしてRailsでのislands Architectureに書き換えている過程を紹介します。
VueとRailsが無秩序になってきた
OSIROでは8年間、一貫してRailsでAPIを作りながらRailsのViewの中でVueをレンダリングする形で開発を進めてきました。サービスのUIは一度大幅なリニューアルを行いましたが、それも5年ほど前の話です。この間、技術的な大幅な見直しは行っておらず、次第に無秩序な状態になってきました。
主な課題
- 本来はVueでなくても実現できる要件を将来的なSPA化を見越してVueにしていたコードがそのままだった
- RailsのViewで条件分岐していたり、
v-ifを使ってフロントエンドで条件分岐をしていたりしていた。 - 画面の要件上、数ページはSPAで動かすのが困難で、フルSPAはそもそも難しかった[1]
とはいえVue, VueRouterのSPA開発に魅力も感じなかった
OSIROには2種類の画面を提供しており、
エンドユーザー向けの「フロント画面」とコミュニティオーナー向けの「管理画面」です。
2年ほど前に「管理画面」をリニューアルし、VueとVueRouterを使ったSPAで実装することを決断しましたが、以下の問題に直面しました。
ここでの主な課題
- APIにも権限周りのコードを書く必要があり、フロントエンドでも同様の実装をする必要があった.
- バックエンドエンジニアにとっては二度手間感があり、開発効率が低下した。
- JSのユニットテストがなく、品質保証はほぼE2Eテストに頼っていたため、網羅的にはテストできていなかった。
分業しない開発体制にしたい
エンジニアが5名の体制で、まだまだプロダクトも市場も発展途上ということもあって、できるだけ機能改善やプロダクトの利便性向上に力を入れたいと考えていました。
そのため、バックエンドとフロントエンドでの分業を可能な限り避ける方針をこれまで取ってきましたし、今後も続けたいと考えています。
フロントエンドに詳しいエンジニアや専業フロントエンドエンジニアが在籍していないこともあり、可能な限り技術スタックをシンプルに保ち、分業をしなくてもよい枯れているフロントエンドアーキテクチャ[2]にすることで分業をしない開発スタイルにまた一歩近づけるのではないかと思っています。
islands Architectureの導入
複雑なUXの画面（例: タイムライン機能やチャット機能）については、Vueを使って部分的にSPAを実装しています。RailsとVueのコラボレーションを秩序正しく行うために、dev.to(Forem)を参考にしたislands Architectureを導入しました。
より詳しい内容については前に記事にまとめていますが、
私達のプロダクトレイアウトや開発組織にマッチングしていると思い、採用していくことを決めました。
TurboとWebComponentsの活用
シンプルな画面で、少しJSでインタラクティブな動きをつけたい場合には、TurboとWebComponentsを利用しています。
Hotwireでは本来Stimulus.jsを使うレイヤーをWebComponentsに置き換えています。
これはislandsを定義する際にWebComponentsを利用していることと、追加のライブラリに依存することがないのが決め手で、よりシンプルなスタックを目指してWebComponentsにすることを決めました。[3]
WebComponentsについての評価点やどのように使っているのかを詳しく下記記事にも掲載していますので、こちらも合わせてご覧ください。
これらの実装方法のメリットとデメリット
メリット
従来通り、SSRをRailsで行う仕組みは変わらないのでインフラの構成に変更はなくシンプルなRailsアプリケーションのままで運用が可能です。
ある程度モックなどがそろっているRSpecが利用できるのでテストが容易になり、ある程度ビジネスロジックがバックエンドに集中することになるので、そういった意味では実装のしやすさも個人的には感じています。
またリニューアルといいつつも利用する技術も大きく変わるわけではないこともあってスモールスタートができました。
デメリット
サーバーサイドレンダリングを行うために、フロントエンドエンジニアもerbやRailsのHelperを書く必要があります。
また、UIライブラリとVanillaJSの使い分けも必要で、各画面や機能ごとに最適な方法を選択する必要があります。[4]
また、Turboについての知見があまりないことがデメリットかもしれません。
Turboはシンプルなものに対してのみ利用する。そもそもTurboを多用しない。
ややこしいことはしないという割り切り持てば問題ないかなーと思っています。
さいごに
弊社では、他のベンチャー企業ともHotwireとも異なるフロントエンドアーキテクチャの戦略を取ろうとしています。もし、RailsとWebComponents、islands Architectureを組み合わせた開発体制に興味があれば、ぜひカジュアル面談でお話しましょう！よろしくお願いします！
Discussion