質問編集履歴
4
補足
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -9,8 +9,10 @@
|
|
|
9
9
|
|
|
10
10
|
もしくは、「要はバランスだよね」おじさん的な感じになるのでしょうか！？
|
|
11
11
|
|
|
12
|
-
前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側で一
|
|
12
|
+
前提、ビジネスロジックはバック側に持たせるで良いと思うのですが、画面依存させないAPI(リソース単位のAPI)を提供しているとどうしても、フロント側でリソースAの情報の一部と、リソースBの情報の一部をそれぞれ組み合わせて、加工、判断、計算をしないといけないような場面が出てきてしまうと思っています。
|
|
13
13
|
|
|
14
|
+
例えば、ログインユーザーのロールがXYZというロールで、かつ、帳票が生成済みの場合であれば、ダウンロードボタンを表示、または、活性化させたいような場合、ユーザーリソースに含まれるロール情報と、帳票情報に含まれるステータスの両方をみて、ダウンロード可能かどうかをフロント側で判断しないといけないと思います。
|
|
15
|
+
|
|
14
16
|
EvansのDDD本にはアンチパターンとしてSmart UIなる表現がありますし、最近、ツイッター界隈ではフロントエンドはJSON色付け係に徹するべなる主張も見かけまして、SPA開発におけるAPIやフロントエンド側のStore設計はどうあるべきなのか、混乱してきたのが質問の背景になります！
|
|
15
17
|
|
|
16
18
|
※ EvansのDDD本にあるSmart UIのUIはViewとControllerの両方を含んだプレゼンテーション層を指していると解釈しています。
|
3
補足
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -42,7 +42,7 @@
|
|
|
42
42
|
- 既に取得済みのAPIレスポンスをキャッシュして使い回すことができる場合がある（キャッシュして問題ないものに限る）
|
|
43
43
|
|
|
44
44
|
### デメリット
|
|
45
|
-
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？具体例を挙げて、検討した方が良さそう）
|
|
45
|
+
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？ 改めて、ビジネスロジックとは何かの定義と具体例を挙げて、検討した方が良さそう）
|
|
46
46
|
|
|
47
47
|
## リソース単位のAPIエンドポイントと画面単位のAPIエンドポイントの両方を用意する？？？
|
|
48
48
|
メリデリ挙げてみて、両方のパターンの組み合わせを用意するのはどうなのだろうと思いつきました。
|
2
補足
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -13,26 +13,36 @@
|
|
|
13
13
|
|
|
14
14
|
EvansのDDD本にはアンチパターンとしてSmart UIなる表現がありますし、最近、ツイッター界隈ではフロントエンドはJSON色付け係に徹するべなる主張も見かけまして、SPA開発におけるAPIやフロントエンド側のStore設計はどうあるべきなのか、混乱してきたのが質問の背景になります！
|
|
15
15
|
|
|
16
|
+
※ EvansのDDD本にあるSmart UIのUIはViewとControllerの両方を含んだプレゼンテーション層を指していると解釈しています。
|
|
17
|
+
|
|
16
18
|
以下、メリデリ考えてみました。
|
|
17
19
|
|
|
18
20
|
## 画面単位のAPIエンドポイントを用意する場合
|
|
21
|
+
### 前提
|
|
22
|
+
画面単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページの表示に必要な情報（質問、回答一覧、関連質問一覧など）を１つのエンドポイントがまとめて返してくれるようなものをイメージして言っています。
|
|
23
|
+
|
|
19
24
|
### メリット
|
|
20
|
-
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる
|
|
25
|
+
- フロント側は単に表示だけしていれば良く、バック側にビジネスロジックをすべて寄せることができる（あるとしても表示に関するフォーマットのロジックを持つくらい）
|
|
21
|
-
- あるとしても表示に関するフォーマットのロジックを持つくらい
|
|
22
26
|
|
|
23
27
|
### デメリット
|
|
24
28
|
- 画面側の表示項目に変更が発生した場合など、API側の改修も必要になる
|
|
25
29
|
- APIが画面に依存するかたちになる
|
|
26
30
|
- 画面毎にAPIを叩く必要があるので、リソース単位のレスポンスと違って、既に取得済みのAPIレスポンスを使い回すことが出来ない
|
|
27
31
|
- ビジネスロジックがバックとフロントの両方に散らばってしまうことになる（フロント側に関しては、フロント側の各画面でビジネスロジックが散らばらないように、store側にビジネスロジックを寄せることで、複数の画面に同じロジックが散らばることは避けられる）
|
|
32
|
+
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、似たような情報を含んだ情報を返すAPIエンドポイントが増えて気持ち悪い気がする
|
|
33
|
+
- 画面毎に対応する画面用のAPIエンドポイントを用意するので、APIエンドポイントが増えがち
|
|
34
|
+
- クライアントがブラウザー、アプリ、CLIと複数ある場合、クライアント毎に表示する情報が異なると思われるので、さらにAPIエンドポイントが増える
|
|
28
35
|
|
|
29
36
|
## リソース単位のAPIエンドポイントを用意する場合
|
|
37
|
+
### 前提
|
|
38
|
+
リソース単位のAPIエンドポイントとは、例えば、このteratailの個別質問詳細ページの場合だと、このページに対応した質問情報を返すエンドポイントがあったり、回答一覧を返すエンドポイントがあったり、関連した質問情報を返すエンドポイントがそれぞれ存在しているようなものをイメージしています。
|
|
39
|
+
|
|
30
40
|
### メリット
|
|
31
41
|
- 画面側の表示項目に変更が発生した場合、フロントが既にバックから受け取っているデータを用いて、計算、加工することでAPIの改修が不要になることもある
|
|
32
42
|
- 既に取得済みのAPIレスポンスをキャッシュして使い回すことができる場合がある（キャッシュして問題ないものに限る）
|
|
33
43
|
|
|
34
44
|
### デメリット
|
|
35
|
-
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？具体例を挙げて、検討した方が良さそう）
|
|
45
|
+
- フロント側で一部、ビジネスロジックを持つことが発生し得る。（独り言：リソース単位でフロントにレスポンス返すと、フロントでビジネスロジックを本当に持ち得えるのか？その処理はフロント側にあっても別に問題ないような処理だったりしないのか？つまり、ビジネスロジックであるのかどうか？具体例を挙げて、検討した方が良さそう）
|
|
36
46
|
|
|
37
47
|
## リソース単位のAPIエンドポイントと画面単位のAPIエンドポイントの両方を用意する？？？
|
|
38
48
|
メリデリ挙げてみて、両方のパターンの組み合わせを用意するのはどうなのだろうと思いつきました。
|
|
@@ -41,4 +51,4 @@
|
|
|
41
51
|
例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。
|
|
42
52
|
|
|
43
53
|
## よくわかっていないけど、BFF ???
|
|
44
|
-
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報を返すAPIエンドポイントをBFFに用意する？
|
|
54
|
+
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報をまとめたレスポンスを返すAPIエンドポイントをBFFに用意する？
|
1
BFF?
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -38,4 +38,7 @@
|
|
|
38
38
|
メリデリ挙げてみて、両方のパターンの組み合わせを用意するのはどうなのだろうと思いつきました。
|
|
39
39
|
こういうのって、実際、やってたりするのでしょうか？
|
|
40
40
|
|
|
41
|
-
例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。
|
|
41
|
+
例えば、リソース単位のAPIを叩くのを基本としつつも、そのAPIでは取得出来ない画面固有の差分を取得するAPIエンドポイントを別途用意するみたいなイメージです。
|
|
42
|
+
|
|
43
|
+
## よくわかっていないけど、BFF ???
|
|
44
|
+
BFFがあまりなんだかよくわかっていないですが、リソース単位のAPIエンドポイントは用意して、フロントエンド側の個々の画面に必要な情報を返すAPIエンドポイントをBFFに用意する？
|