質問編集履歴
6
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -70,7 +70,7 @@
|
|
|
70
70
|
|
|
71
71
|
2. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
72
72
|
|
|
73
|
-
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でどうやって整合性をとっているのか？
|
|
73
|
+
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でDBの形式が異なることになりますが、どうやって整合性をとっているのか？
|
|
74
74
|
|
|
75
75
|
4. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？
|
|
76
76
|
|
5
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -70,7 +70,7 @@
|
|
|
70
70
|
|
|
71
71
|
2. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
72
72
|
|
|
73
|
-
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。どうやって整合性をとっているのか？
|
|
73
|
+
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。そうなるとWeb側とネイティブアプリ側でどうやって整合性をとっているのか？
|
|
74
74
|
|
|
75
75
|
4. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？
|
|
76
76
|
|
4
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -68,7 +68,7 @@
|
|
|
68
68
|
|
|
69
69
|
1. フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？
|
|
70
70
|
|
|
71
|
-
2. サービスを意地でもスケールさせるのを前提で考えた時、移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
71
|
+
2. サービスを意地でもスケールさせるのを前提で考えた時、データや言語の移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
72
72
|
|
|
73
73
|
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。どうやって整合性をとっているのか？
|
|
74
74
|
|
3
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -68,7 +68,7 @@
|
|
|
68
68
|
|
|
69
69
|
1. フロントエンドにReactを採用した時、Railsのメリットが失われるというのは本当か？
|
|
70
70
|
|
|
71
|
-
2. スケールさせる前提で考えた時、
|
|
71
|
+
2. サービスを意地でもスケールさせるのを前提で考えた時、移行の煩雑さを考えるとWeb側でもネイティブ側でもFirebaseは最初から採用しない方がいいのか？またその場合、ネイティブアプリ側のバックエンドはなんの言語で記載した方がいいか？
|
|
72
72
|
|
|
73
73
|
3. FirebaseはNoSQLでFlutterと一緒に採用されているケースが多いが、Web側でRDBライクなRailsやGoを採用している話もちょくちょく聞きます。どうやって整合性をとっているのか？
|
|
74
74
|
|
2
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
|
|
55
55
|
|
|
56
56
|
|
|
57
|
-
しかし、Firebaseはサービスをスケールさせていくにつれてつらみが出てくるとの話
|
|
57
|
+
しかし、Firebaseはサービスをスケールさせていくにつれてつらみが出てくるとの話を聞きます。Firebaseを0→10まで使う前提の技術として据えた時に、サービスをスケールさせた後の10→100を担うバックエンド言語はRailsやGoなどを採用するのかなとうっすら思っています。FirebaseはNoSQLですが、RailsやGoは主にRDBを採用した言語だと認識しております。つまり、①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えました。この考えが正しければ死ぬほどめんどくさいなと思いました。
|
|
58
58
|
|
|
59
59
|
|
|
60
60
|
|
1
あ
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -74,7 +74,7 @@
|
|
|
74
74
|
|
|
75
75
|
4. ReactとRails、ReactとFirebaseだとRailsWayから外れてもRailsを採用した方がいいのか。それとも、0→10が得意なFirebaseを採用した方が良さげか？
|
|
76
76
|
|
|
77
|
-
5. Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、これが具体的にどれくらい大変なのか？
|
|
77
|
+
5. Firebaseをスケールさせていくと①NoSQLに入ったデータの移行と②RDBを組み、データを移植する。という作業が必要になるのかなと考えているのですが、そもそもそれは正しいのか？正しいとしたらこれが具体的にどれくらい大変なのか？
|
|
78
78
|
|
|
79
79
|
|
|
80
80
|
|