個人開発の技術選定についてお伺いしたいです

Question

前提の前提

初心者です。Webアプリを作ろうとしています。

内容は大喜利サイトで、様々なジャンルのお題と回答が存在する。また、ランキング機能やいいね機能などを組み込む予定です。

技術選定としては
フロントエンド HTML+CSS+JavaScript
バックエンド Rails
データベース MySQL
その他 Docker CircleCI

を考えています。

まずはWebアプリで作ろうと考えていますが、サービスが大きくなるのを予想してネイティブアプリを作るのも検討しています。その場合の技術選定としては

Flutter+Firebase

を考えています。

前提

調べているうちに、Webアプリ側のフロントエンド(HTML+CSS+JavaScript)はJavaScriptフレームワークのReactやVue.jsで置換可能だという話が出てきました。SPAはユーザーが頻繁にページ遷移をする滞在時間の多いアプリに適しているとのことで適しているとのことですが、開発速度が遅くなることやSEO対策の不備、これまではRails Wayに乗っかっていればよかった意識しない部分の設計周りをしっかりやらなければならない。というデメリットも存在します。
https://www.oro.com/ja/technology/001/

それを踏まえてもユーザー体験を優先させた方がいいなと感じたためReactを採用しようと考えました。そうなるとRailsはapiモードでAPIサーバーとしての使い方が主になります。一方でAPIモードでRailsを使うとなると、Railsを採用するメリットがあまりなくなるという話をたまにTwitterや技術記事で耳にします。

また、よく聞くのがReactとFirebaseの組み合わせです。0→10の開発ではFirebaseの組み合わせがいいとの話も伺います。ネイティブアプリもFlutter+Firebaseの組み合わせで開発ができるため、Webアプリの技術スタックはReactとFirebase。ネイティブアプリはFlutter+Firebaseで、バックエンドはFirebaseで統一してしまった方がソースを書く手間が二度手間にならずに済むというメリットがあるなと考えています。

しかし、Firebaseはサービスをスケールさせていくにつれてつらみが出てくるとの話を聞きます。Firebaseを0→10まで使う前提の技術として据えた時に、サービスをスケールさせた後の10→100を担うバックエンド言語はRailsやGoなどを採用するのかなとうっすら思っています。FirebaseはNoSQLですが、RailsやGoは主にRDBを採用した言語だと認識しております。つまり、①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えました。この考えが正しければ死ぬほどめんどくさいなと思いました。

質問

ここで質問です。

1. フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？
2. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でDBの形式が異なることになりますが、どうやって整合性をとっているのか？
4. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？
5. Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、そもそもそれは正しいのか？正しいとしたらこれが具体的にどれくらい大変なのか？

以上の5点をお伺いできればなと思っております。

Comments

[退会済みユーザー]

URL はリンクの挿入を使用すると、回答者の手間が減ります。

[m.ts10806]

>初心者です。
「初心者アイコン」をつけるのにとどめてください。
要件とは別の話なので、タイトルや本文には不要です。

[m.ts10806]

何でもいいからもっと簡易なもの（漫画雑誌の読みきりレベルのもの）を作ってやってみればいいと思います。

[hentaiman]

手を動かさず頭でっかちなってても無駄だからとりあえず作れば良いと思いますよ

Answer 1

前提条件から間違ってると思います

RailsアプリケーションをAPIサーバーにしたいのですよね？
そうするなら、アプリとDBが直接通信することはないはずです。
なので、「アプリとWEBでDBが...」などの疑問は前提から存在しません。

以下詳細

SPAはユーザーが頻繁にページ遷移をする滞在時間の多いアプリに適しているとのことで適しているとのことですが、開発速度が遅くなることやSEO対策の不備、これまではRails Wayに乗っかっていればよかった意識しない部分の設計周りをしっかりやらなければならない。

SEO系は最近は改善傾向にあります。
あとは、大きなデメリットとして「重く」「遅く」なりうることも大きな懸念材料です。

また、よく聞くのがReactとFirebaseの組み合わせです。0→10の開発ではFirebaseの組み合わせがいいとの話も伺います。ネイティブアプリもFlutter+Firebaseの組み合わせで開発ができるため、Webアプリの技術スタックはReactとFirebase。ネイティブアプリはFlutter+Firebaseで、バックエンドはFirebaseで統一してしまった方がソースを書く手間が二度手間にならずに済むというメリットがあるなと考えています。

というより、React採用するならReactNative採用する方がいいのでは？とは思いました。Firebaseをどう活用するのかは知りませんが、DB的な使い方をするならRailsを経由するのではないでしょうか？直接やり取りすることはあるのでしょうか？おそらくないと思いますが。

フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？

開発次第です。
Railsのメリットがどれを指しているのか不明なのでなんとも。

サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？

質問内容的にRails経由させるはずなので、どちらでもいいのでは？

FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でDBの形式が異なることになりますが、どうやって整合性をとっているのか？

RailsをAPIとして使うとのことなのでアプリからDBに直接何かすることはないと思います。

ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？

どちらでも。

Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、そもそもそれは正しいのか？正しいとしたらこれが具体的にどれくらい大変なのか？

DBとデータをやり取りするところ全てを書き換えてテストできるかどうかにかかってると思います。

Comments

[kyoya0819]

> DBとデータをやり取りするところ全てを書き換えてテストできるかどうかにかかってると思います。

想像してみて、
「無理そう」若しくは「頑張ればいけそう」ならやめることをお勧めします。その場合大抵無理です。
「いけそう」でも無理なことは多くあります。

結論、どうしても「いける！」なら止めはしませんが、規模によっては泥沼な作業が待ってます。FirebaseとRDBに対応したORMを自力開発するか、どっかから取ってくるかしたらまだ楽かと。その場合セキュリティ的なリスクは高いことをお忘れなく。

Answer 2

記述にある範囲において、技術選定に進めるほどの要件が固まっていないように見えます。
技術選定の前に要件定義だと思いますよ。
既存の同様なサービスの研究から始めてみては？

要件定義～システム設計ができる人材になれる記事

多くの場合、コスト要件でインフラが縛られインフラの制限で使用言語が縛られます。

あと、

Ruby（Rails）なんてやめてもっとマシな型のある言語使いなよ

なんて回答がありますが、かのマリー・アントワネットも
「rubyがダメならphpを使えばイイじゃない」
って言ってるんで、個人開発には php を推します。

Answer 3

Ruby（Rails）なんてやめてもっとマシな型のある言語使いなよ

まともに答えます

1. フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？

そのとおりです。SPA を作る時、MVC フレームワークとして価値が残る部分は ORM 部分だけです。そして Ruby には他にまともな ORM が存在しないため Rails の Active Record を API サーバーの事実上の ORM として使うということをやっています。密結合フレームワークの悪い部分がもろにでています。

1. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？

Firebase はドキュメント型 DB です。サービスによって合う合わないがもろにでます。作るもの次第でしょう。とは言えわたしは RDB か、スケーラビリティをより重視するなら Spanner のような NoSQL をおすすめしますが。

ネイティブアプリ側のバックエンドはなんの言語

言い回しがよくわからないのでここは保留にしておきます。

1. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でDBの形式が異なることになりますが、どうやって整合性をとっているのか？

もしかして言語によって使える DB が決まるとお考えなのでしょうか？それならばやはり前提条件が間違っています。DB と言語選択は理論上無関係です。

1. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？

SPA の開発に Rails way は要りません。Rails のようなフレームワークで SPA の RESTful API を構築するには余計なものが付きすぎてきます。特に初学者であればコアな要素が何かわからなくなってしまうほど機能が充実しています。もっとプリミティブなライブラリの組み合わせで実現したほうがよいでしょう。

1. Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、そもそもそれは正しいのか？正しいとしたらこれが具体的にどれくらい大変なのか？

正しいです。小規模でも結構大変です。ですがそもそも論として Firebase 自体で十分スケールしますし、Firebase には Firebase の使い方というものがあります。会員情報、購入履歴などスキーマが変わらないものは RDB、アプリケーションのタグ付き投稿など変わりやすい情報は NoSQL など使い分けが必要でしょう。

Ruby なんてやめてもっとマシな型のある言語使いなよ

具体例掛けと言われたので書きます。

Go

Go は初心者でもとっつきやすい上開発体験がものすごくよいのでおすすめです。関数名を入力するだけでモジュール名まで勝手に補完してくれます。Web フレームワーク、ORM もありますし何より Google 製ですから Firebase の SDK もあります。

TypeScript

フロントエンドを書く言語だと思われがちですが、バックエンドも書けます。しかも型の表現力が何気に高いのでより型安全に組めます。更に美味しいのは node.js の資産を活用できるので利用できる SDK がたくさん存在することです。

Rust

型安全に加えイミュータビリティとメモリ安全性までついてきます。非常に強力で実行時エラーを最小限に抑えてくれます。Web フレームワークはそこそこ揃っていますが公式の Firebase SDK がないのでそこが苦労する点でしょうか。

他にも

最近の Java や C# もがんばってるなんて話も聞くのでそちらもよいのかもしれません。Python も型が付き始めているので悪くないでしょう（PHP もそうらしいがそこはあまり知らない）。ただ Python は根本がスクリプト言語なのでコンパイル言語の型検査と比べるとどうしても後一歩という感じですが。

Comments

[m.ts10806]

回答になってないのと、個人の感覚すぎるという点で低評価しました。

[kyoya0819]

> Ruby（Rails）なんてやめてもっとマシな型のある言語使いなよ

で？というお話。

[hentaiman]

ちなみに「Rubyをやっている人や齧っている人」が低学習コストで移行のし易い言語ってなんですか？ヤメロ言うだけじゃなく代替案を伺ってみたく。
自分もrubyはクソ仕様のゴミ言語だと思ったのでrubyヤメロという意見には共感しますが。

[Zuishin]

そこで C# ですよ。

Blazor でフロントとバックを同じ言語で。

https://docs.microsoft.com/ja-jp/aspnet/core/blazor/?view=aspnetcore-5.0

Uno Platform で Windows、Mac、Android、iPhone、ウェブアプリを同じコードで。

https://www.google.com/amp/s/forest.watch.impress.co.jp/docs/news/1227/439/amp.index.html

[Zuishin]

Go なんて使うのやめてもっとマシな(以下略)

Java や C# がウェブ開発で「最近」頑張ってるというのは謎ですね。そこに並んだ最近の言語よりずっと昔から広く使われているので、サーブレットとか ASP.NET を知らないだけだと思います。

[A_kirisaki]

> Zuishin さん
あ、「型について」がんばってるって意味でした。これは失礼。

[Zuishin]

どちらも、型は最初からあります。

[A_kirisaki]

> Zuishin さん
var で変数宣言時の型推論効くようになったからマシになったよね、というのがわたしが知る範囲での頑張りですね。

[Zuishin]

var はローカル変数を推論して記述の見た目を変えるだけなので、まともな型システムと比較するようなものではないと思います。

[Zuishin]

C# の場合、var が導入されたのはほぼほぼ匿名クラスとラムダ式への対応です。型システムというよりも、関数型への布石と言えると思います。

[A_kirisaki]

> Zuishin さん
記述が長いだけで OCaml 相当の型推論はあるので Go よりはある方だと思います。

[hentaiman]

移行対象にRustが上がるとは・・・ぬるい言語に浸かって来た自分にとってはRustの難易度高過ぎると思ったけどrubyから移行する人向けには合ってるんでしょうか

[A_kirisaki]

> hentaiman さん
メソッドチェーン書けるのでむしろありかなと思ってます。言うてコンパイラめちゃくちゃ優しいのでエラーメッセージ読む習慣さえ付けば基本的な機能は十分扱えると思います。コンパイル通ればだいたい動くし。

[gentaro]

> メソッドチェーン書けるので

これこの言語選定の話にどういう関係があるんだろう。

自分もRubyを学んでいる「初心者」を名乗る人にRustが良い移行先だとはあんまり思えないけどなぁ。普及度や日本語の学習用リソースの充実度合いも含めて。周囲に相談できる人も少なそうだし。

会社とかで周囲の人に気軽に聴ける環境ならまぁ、という気はするけど、それにしても一通りちゃんと動く成果物を作るまでにかかる学習コストが高すぎると思うわ。