博士

やあ、ロボ子。今日のITニュースはAPI Churnの問題についてじゃ。

ロボ子

API Churnですか。フロントエンド開発でよく聞く問題ですね。

博士

そうじゃ。UIの変更に合わせてAPIを頻繁に変える必要があるからの。UIのニーズがAPIの形を決めてしまうんじゃな。

ロボ子

それで、APIが不安定になるんですね。解決策はあるんでしょうか？

博士

GraphQLのような汎用的なクエリ言語を使うのが一つの手じゃな。少ないエンドポイントで多くの機能を提供できるぞ。

ロボ子

なるほど。フロントエンド開発者がデータの取得や変更を制御できるようになるんですね。

博士

じゃが、良いことばかりではないぞ。表現力の高いエンドポイントは、悪意のあるユーザーにも利用される可能性があるんじゃ。

ロボ子

セキュリティリスクですね。具体的にはどんなリスクがあるんですか？

博士

例えば、GraphQLクエリで従業員の給与情報を不正に取得される可能性があるんじゃ。記事にもそう書いてあるぞ。

ロボ子

それは大変です。コンテキストに応じたフィールドレベルのセキュリティが必要になりますね。

博士

そう、じゃが、それは複雑じゃ。クライアント側のUI開発者に自由度を与えすぎると、セキュリティリスクが高まるというわけじゃな。

ロボ子

開発者に与える自由度とセキュリティのリスクの間には緊張関係があるんですね。

博士

じゃから、サーバーサイドでの解決策も考えるべきじゃ。Intercooler.jsを使って、HTMLレンダリングとドメインロジックの実行をサーバー側で行うとか。

ロボ子

サーバーサイドで開発すれば、セキュリティをより確実に実現できるんですね。

博士

そういうことじゃ。クライアントサイドの開発者に提供する表現力を高める際には、セキュリティリスクを慎重に検討する必要があるぞ。

ロボ子

勉強になります。API Churnとセキュリティのトレードオフ、よく理解できました。

博士

ところでロボ子、APIって、アタシがプリンをあげるポイント、って意味だと思ってなかったか？

ロボ子

まさか！ 博士、それは違いますよ！