回答編集履歴
1
まともに答えました
test
CHANGED
|
@@ -1 +1,77 @@
|
|
|
1
1
|
Ruby（Rails）なんてやめてもっとマシな型のある言語使いなよ
|
|
2
|
+
|
|
3
|
+
### まともに答えます
|
|
4
|
+
|
|
5
|
+
> 1. フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
そのとおりです。SPA を作る時、MVC フレームワークとして価値が残る部分は ORM 部分だけです。そして Ruby には他にまともな ORM が存在しないため Rails の Active Record を API サーバーの事実上の ORM として使うということをやっています。密結合フレームワークの悪い部分がもろにでています。
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
> 2. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
Firebase はドキュメント型 DB です。サービスによって合う合わないがもろにでます。作るもの次第でしょう。とは言えわたしは RDB か、スケーラビリティをより重視するなら Spanner のような NoSQL をおすすめしますが。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
> ネイティブアプリ側のバックエンドはなんの言語
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
言い回しがよくわからないのでここは保留にしておきます。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
> 3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でDBの形式が異なることになりますが、どうやって整合性をとっているのか？
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
もしかして言語によって使える DB が決まるとお考えなのでしょうか？それならばやはり前提条件が間違っています。**DB と言語選択は理論上無関係**です。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
> 4. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
**SPA の開発に Rails way は要りません**。Rails のようなフレームワークで SPA の RESTful API を構築するには余計なものが付きすぎてきます。特に初学者であればコアな要素が何かわからなくなってしまうほど機能が充実しています。もっとプリミティブなライブラリの組み合わせで実現したほうがよいでしょう。
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
> 5. Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、そもそもそれは正しいのか？正しいとしたらこれが具体的にどれくらい大変なのか？
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
正しいです。小規模でも結構大変です。ですがそもそも論として Firebase 自体で十分スケールしますし、Firebase には Firebase の使い方というものがあります。会員情報、購入履歴などスキーマが変わらないものは RDB、アプリケーションのタグ付き投稿など変わりやすい情報は NoSQL など使い分けが必要でしょう。
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
### Ruby なんてやめてもっとマシな型のある言語使いなよ
|
|
54
|
+
|
|
55
|
+
具体例掛けと言われたので書きます。
|
|
56
|
+
|
|
57
|
+
#### Go
|
|
58
|
+
|
|
59
|
+
Go は初心者でもとっつきやすい上開発体験がものすごくよいのでおすすめです。関数名を入力するだけでモジュール名まで勝手に補完してくれます。Web フレームワーク、ORM もありますし何より Google 製ですから Firebase の SDK もあります。
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
#### TypeScript
|
|
64
|
+
|
|
65
|
+
フロントエンドを書く言語だと思われがちですが、バックエンドも書けます。しかも型の表現力が何気に高いのでより型安全に組めます。更に美味しいのは node.js の資産を活用できるので利用できる SDK がたくさん存在することです。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
#### Rust
|
|
70
|
+
|
|
71
|
+
型安全に加えイミュータビリティとメモリ安全性までついてきます。非常に強力で実行時エラーを最小限に抑えてくれます。Web フレームワークはそこそこ揃っていますが公式の Firebase SDK がないのでそこが苦労する点でしょうか。
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
#### 他にも
|
|
76
|
+
|
|
77
|
+
**最近の** Java や C# もがんばってるなんて話も聞くのでそちらもよいのかもしれません。Python も型が付き始めているので悪くないでしょう（PHP もそうらしいがそこはあまり知らない）。ただ Python は根本がスクリプト言語なのでコンパイル言語の型検査と比べるとどうしても後一歩という感じですが。
|