Railsプロジェクトにおけるフロントエンドの選定

こんにちは！ UZUMAKIに最近ジョインしたじゅんやです。

かれこれ数年間Railsを触っていますが、Railsプロジェクトを始める際、フロントエンドをどうしようかというのは毎回悩みます。

・VueやReactを使うべきか、、

・フロントエンドとバックエンドをつなぐ部分はRESTにするかGraphQLを採用するか、、

・SPAにするのかしないのか、、、

などなどいろいろ悩むことがあると思いますが、その悩みを少しでも解決できるよう、今回の記事では以下のことについて書いていきます。

１、直近3年間で私自身が経験してきたRailsプロジェクトの３つのパターンについて

２、フロントエンドを選定する際、何を考えるべきか

今回書いていくのは基本的には私の経験に基づいた話なので、他にも色々なパターンや色々な意見があると思います。

ですので、あくまで「こんなパターンもあるんだな」「こういう意見もあるんだな」程度で見ていってください！笑

直近3年間で7-8個ほどRailsプロジェクトに携わってきましたが、私が触ってきたプロジェクトは以下の３つのパターンに分けられます。

① Rails + jQuery

② Rails + Vue

③ Rails + GraphQL + React

最近は②か③のパターンがほとんどで、フロントエンドをjQueryを使ってゴリゴリ書くみたいなことはありません。

が、以前別会社で働いていた時のプロジェクトではそのようなプロジェクトもあったので、一応そちらも含めて比較していきます。

まずjQueryを使ってフロントエンドのDOM操作をするパターン①についてですが、こちらは個人的にはあまりお勧めできません。

jQueryで全てを完結しようとすると、コードが複雑になりがちで、あとから修正する時にコードを読み解くのが大変です。(もちろん書く人にもよりますが、、)そのため、UIが複雑なWebサービスの場合はjQueryをメインにするという選択肢は外した方がいいかと思います。

特に新規のRailsプロジェクトでは外したほうがいいかと思います。Rails本体もデフォルト設定からjQueryを切り離しました。

とはいえ、特にプロトタイプなど利用期間が限定される長期的なメンテが必要のないサービスの場合は、DHHが提唱したHotwireはまだまだ枯れていないので、2021年9月時点では情報の多いjQueryを利用するのもいいかもしれません。

またチームメンバーがjQueryに慣れた人ばかりで、VueやReactにアレルギーがある場合は、初期の開発速度を重視してjQueryを選択するという可能性もあります。

ただそのような場合も、長期的に考えるとやはりjQuery一本でやるのは辛いのではないかな、、、と個人的には思います。

続いて2つ目ですが、Rails + Vueというパターンです。

私は個人開発ではこのパターンを採用しています。

またこれまでの多くのプロジェクトがこのパターンでした。

ちなみに私が携わってきたプロジェクトはどれもSPAではありません。

また、管理ページなどUIが複雑でない部分にはVueを使わずにRailsのView(erb)を普通に使っています。

そしてVueはあくまで複雑なUIのページのみに使っています。

このパターンのメリット、というよりRailsのViewとVue(もしくはReact)の併用のメリットですが、やはりRailsのViewの手軽さ&資産を最大限使えるという点です。

チームメンバーがRailsに慣れていないのであればこのメリットはありませんが、もしチームメンバーがこれまでにRailsのプロジェクトに多く触っており、RailsのView周りの知見を多く持っている場合はそれを生かさない手はありません。

またUIが複雑な部分に対してはVue(もしくはReact)で対処できますし、jQueryに比べたらUIが複雑になっても困ることはありません。

一方デメリットとしては、フロントエンドを実装するメンバーもRailsのことをある程度理解していないといけない点です。

先ほども言いましたが、UIが複雑でないページはRailsのヘルパーメソッドを使ったerbなどを使うので、その際にRailsに関する知見は多少なりとも必要になります。

また、これはGraphQLを使うパターン③との比較になりますが、GraphQLを使わないこのパターンだと、フロントエンドとバックエンドが疎結合にはならないので、片方の修正を行う際にもう片方の修正も行う必要が度々あります。(もちろん場合によりますが)

この点を考慮すると、大規模開発になればなるほど、このパターンだと苦しむ可能性があります。

また、Webサービスオンリーであればこのパターンでもいいですが、もし今後アプリ化する予定などある場合は、このパターンよりはSPA化しておいた方が良いかと思います。

※Vueの導入についての注意点

Vueを導入する際、Railsプロジェクトに備わっているWepackerをそのまま使うパターンと、Webpackを使って完全にRailsからVueを切り離すパターンの2パターンがあります。

比較的規模が大きすぎずシンプルな場合はWebpackerでも良いです。

一方SPAの規模が大きくなりそうな場合はWebpackを使ってRailsから切り離した方が賢明です。というのも、Webpackを使うことでフロントエンドのエコシステムに乗ることができ、トラブルが合った場合にもStackoverflow等で問題を調べることができます。

どちらにするのかはよく検討する必要があります。

続いて３つ目のパターンですが、バックエンドはRails、フロントエンドはReact、そしてその間をGraphQLで繋ぐというパターンです。

このパターンは最近触り始めたプロジェクトで採用されていました。

(ちなみにこのプロジェクトは途中からジョインしたため、私自身は技術選定には一切関わっていません。)

このパターンのメリットですが、何よりGraphQLを挟むことでバグが出づらいことが挙げられます。

GraphQLを挟むと、フロントエンドとバックエンドははっきりと分離されますし、それだけでなくGraphQLではスキーマによってバックエンドがどのような値をどのような型で返すかが定義されています。

小規模の開発ではあまりこのメリットは享受できませんが、規模が大きく慣ればなるほどこのスキーマのありがたみを感じることができます。 (ちなみにこれに関してはGraphQLだけでなく、gRPCでも同様のメリットを得られます。)

また、フロントエンドからのリクエストもGraphQLのクエリを使うことになりますが、これによって似たような画面の似たようなリクエスト(ただしちょっとちがう！)の際にも、フロントエンドの方ではクエリ言語で分かりやすく書けますし、何よりバックエンド側ではその小ささな差異を気にする必要がなくなります。

バックエンドはあくまでスキーマ通りに返すことだけを意識すればよく、どのデータを使うかはフロントエンドのクエリ言語の方で取捨選択ができます。

これはフロントエンドのクライアントが多い場合に特に有効です。ユーザ向けのWeb,　iOSアプリ、Androidアプリ、管理者用のWebなど4パターン分のAPIを作り維持管理していくのは骨が折れます。 それを回避できるというのは、バックエンドの実装の労力をかなり下げることにつながります。

一方このパターンのデメリットですが、GraphQLを挟むために"普通"のRailsプロジェクトに比べて手間がかかる点が挙げられます。

当たり前ですが、普通にRails newをしてもGraphQLは使えません。graphql gemを使ったり、サーバー側の修正や変更が色々必要になります。

(Rails + GraphQLのプロジェクトの始め方などについてはこの記事では解説しません。)

Railsは手っ取り早く素早くサービスを作れるというのがウリの一つだと思いますが、GraphQLを採用するとそのウリが少し弱まります。

ここまで３つのパターンを紹介してきましたが、当たり前ですが他にも色々なパターンがあります。

その中でも最近Railsエンジニアから注目を集めているのがHotwireです。

Railsの生みの親であるDHHがHotwireの開発に携わっています。

Hotwireは、近年フロントエンドが複雑になりすぎてるから、もっとシンプルに(Javascriptを極力少なく)しようというようなコンセプトから成り立っています。

Javascriptをほとんど書くことなく、それでいてSPAライクなサービスを作ることができるのがHotwireです。

(Javascriptが完全にゼロになるわけではありません。)

Hotwireの細かな話は別記事に譲るとして、Hotwireを今後どのようなプロジェクトで採用できるのかについて少しだけ書いていきます。

まずフロントエンドのみしか触れないエンジニアが多くいるようなプロジェクトではHotwireは向きません。

Hotwireを使うと、フロントエンドとバックエンドが密になり、両方のコードをかける必要があります。

なので、基本的にはプロジェクトに携わるエンジニアが全員Railsに慣れていて、かつ規模の大きくないプロジェクトの場合のみ選択肢に入ってくるかと思います。

上で挙げた３つのパターンだと、パターン①(Rails + jQuery)のかわりにはなりそうです。またプロジェクトによってはパターン②(Rails + Vue)のかわりにもなるかもしれません。

ここまで私が直近3年で経験してきたRailsプロジェクト3パターン + α について書いてきましたが、じゃあ結局どうしたらいいのか、ということについてここから書いていきます。

まず「どのようなプロジェクトもこのパターンにすべきだ」というような絶対的な解はありません。

ただ絶対的な解はないものの、以下の三つの観点からどのようなフロントエンドを選定すべきかを考えることはできます。

(本当はそもそもRailsなの？という部分も考える必要がありますが、今回はあくまでRailsを使うことは確定しているという条件下での話です。)

１. プロジェクトの規模

２. UIの複雑さ

３. メンバーのスキル

まずプロジェクトの規模についてですが、プロジェクトの規模が大きく慣ればなるほど、バグは出やすくなります。

規模の大きいものであればあるほど、フロントエンドとバックエンドはしっかり分けるべきです。

そういう意味では、規模の大きいものはGraphQLを使うというのは選択肢に入ってくるかと思います。

(ちなみにその場合ReactなのかVueなのかは、メンバーのスキルによる部分が大きいのかなと個人的には考えています)

逆に規模の小さいものであれば、GraphQLを使うと余分な手間がかかってしまう可能性があるので、そのような場合は上記のパターン②(Rails + Vue)のような構成がいいのではないかなと思います。

もしくはHotwireを使うという選択肢も今後は視野に入ってくるかもしれません。

続いてUIの複雑さですが、これも規模の大きさとほぼ同じ考え方になります。

パターン①(Rails + jQuery)はUIがよっぽとシンプルな場合のみにしておきましょう。

また、今の段階ではUIが複雑なものでHotwireを使うのはリスキーかもしれません。

ちなみにDHHがCTOをつとめる会社のサービス(hey.com)はHotwireを使っています。

どれぐらいのUIまでHotwireで(現実的に)いけるんだろうというのは、hey.comを見ると参考になるかもしれません。

最後にメンバーのスキルですが、フロントエンドを選定する際にはこれが結構重要になってきます。

Railsが得意なエンジニア集団での開発であれば、HotwireでRailsのレールのど真ん中を走るという手も今後はあり得るかもしれませんし、パターン②(Rails + Vue)のようにポイントポイントでVueを使うというパターンもあり得ます。

ちなみに私が携わってきたプロジェクトでパターン②(Rails + Vue)が多かったののは、メンバーのスキルによる部分が大きかったです。(できるだけRailsの資産を使いたい派のメンバーが多かったから)

一方チームメンバーの一部はフロントエンドのみ、また別の一部の人たちはバックエンドのみしか触れませんというような場合にはパターン③(Rails + GraphQL + React)、もしくはWebpackを導入してSPAにして完全にバックエンドとフロントエンドを分離させるべきです。

もちろんこの３点以外の観点でも、技術の将来性なども考慮すべきではあります。

また今回は私自身がここ3年間で触れてきたプロジェクトを中心に書いてきましたが、他のパターンも山ほどあります。

こういう場合はもっとこっちのパターンの方がいいよという意見等ありましたらぜひこのブログにコメントください！

以上、Railsプロジェクトにおけるフロントエンドの選定の話でした。

名前: 黒田　淳也

Twitter: @BoNingennnN

Github: https://github.com/junya-junya

XではUZUMAKIの新しい働き方や日常の様子を紹介！ぜひフォローをお願いします！

noteではUZUMAKIのメンバー・クライアントインタビュー、福利厚生を紹介！

UZUMAKIではRailsエンジニアを絶賛募集中です。

↓の記事を読んでご興味を持っていただいた方は、ぜひ応募よろしくお願いします！

是非応募宜しくおねがいします！