回答編集履歴
2
テストびついて追記。
answer
CHANGED
|
@@ -6,6 +6,8 @@
|
|
|
6
6
|
バックエンドは全てGrapeでAPIを作り、jsonでのやりとりでした。ですから、Rails側はcontroller, viewは全く使いませんでした。API担当側は画面を意識しない分、内部の実装に専念できました。
|
|
7
7
|
フロント側も、APIが返す想定のjsonのモックを使って画面を実装していったので、時折ハマリがちなRailsの環境構築のストレスも無く、それぞれ独立して作業しやすかったです。
|
|
8
8
|
|
|
9
|
+
画面系のテストの際は、サーバ側（API）を立てなくとも、モックのjsonとの組み合わせでエラーメッセージやバリデーションといったe2eテストがしやすかったです。
|
|
10
|
+
|
|
9
11
|
特に、フロントでの入力バリデーションのための仕組みが一通りそろっていたので、入力内容に精度を求められる業務系Webアプリには大変有効だと思います。サーバサイドに送信してから全部やりなおし、といった残念なことを減らせるため、効率を求められる業務システムには向いていると思います。
|
|
10
12
|
多言語化対応もしやすかったです。
|
|
11
13
|
|
1
誤字修正。
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
ですが、過去にフロントがFlex, バックエンドがSOAPといった内容を担当したことがあったので、Angularはその作り方にとても良く似ていて、スッと入れました。
|
|
5
5
|
|
|
6
6
|
バックエンドは全てGrapeでAPIを作り、jsonでのやりとりでした。ですから、Rails側はcontroller, viewは全く使いませんでした。API担当側は画面を意識しない分、内部の実装に専念できました。
|
|
7
|
-
フロント側も、APIが返す想定のjsonのモックを使って画面を実装していったので、時折ハマリがちな
|
|
7
|
+
フロント側も、APIが返す想定のjsonのモックを使って画面を実装していったので、時折ハマリがちなRailsの環境構築のストレスも無く、それぞれ独立して作業しやすかったです。
|
|
8
8
|
|
|
9
9
|
特に、フロントでの入力バリデーションのための仕組みが一通りそろっていたので、入力内容に精度を求められる業務系Webアプリには大変有効だと思います。サーバサイドに送信してから全部やりなおし、といった残念なことを減らせるため、効率を求められる業務システムには向いていると思います。
|
|
10
10
|
多言語化対応もしやすかったです。
|