「現場で役立つシステム設計の原則」読書会レポート vol.8

読書会

株式会社リゾーム システム企画・開発部 第3グループの鳥井です。

読書会の第8回目のレポートです。

前回のレポートは、こちらになります。

tech.rhizome-e.com

8回目レポート

今回は、第8章「アプリケーション間の連携」で参加者は4名でした。

それぞれの感想・意見交換

アプリケーション間の連携方式
  • 代表的なものは以下の4つ
    • ファイル転送
    • データベース共有
    • Web API
    • メッセージング
  • 弊社でよくやる方式なのはファイル転送、WebAPI連携も多少やっている。
Web API設計
  • 更新も削除もPOSTにする
    • アプリケーションの独立性が高くなり、修正の影響を小さくできる
    • 更新や削除もPOSTで行うのはRESTに反するので、どうだろう..。
  • 大は小を兼ねるAPI
    • 必要のないパラメータまで理解しなければならなくなる
    • 受け取ったデータから必要なデータを取り出す処理が必要になる
  • 計算ロジックの置き場所
    • 以下の理由から、単純なものも含めてクライアント側を基本とするのが良い気がする。ただし、DBで集計できるものなどはWeb API側で処理する。
      • どちらに書くべきか判断に迷わなくなる
      • ロジックを書いてある箇所が特定しやすい
  • 登録と参照を分ける
    • 例えば指定席を予約するAPIの場合、POSTのレスポンスは予約番号だけを返し、予約内容はその予約番号を使って別途GETする
      • この例だとPOSTした際に予約内容の詳細を返す場合と比べて1回リクエストが増えるが、シンプルな設計になることのメリットのほうが大きいと思う
  • リソース単位を分ける
    • Web API側はシンプルになるが、これはリクエスト数がかなり増えそう
      • 例えば名前、生年月日、性別の3項目を1つの画面に表示したい場合、3回リクエストする必要がある。リソースの数だけリクエストが増えてしまう。
    • クライアント側はリソースの数だけリクエストする処理や受け取ったデータを管理する処理が必要になるので煩雑になりそう
      • URLを叩く処理などをSDKなどにまとめていけば再利用しやすくなり、クライアント側の負担を減らすことができるかも
非同期メッセージング
  • 非同期メッセージングをアプリケーション間で使ったことはない気がする..。
  • dRubyを使えばできる？
マイクロサービス化
  • 試行錯誤がしづらそうだと思った。サービス単位の分離を上手にやらないといけない。
  • 対象業務への理解が不十分な場合はモノリスで作っておき、後々分けていくのが良いかも
  • サーバーレス＆マイクロサービスが今後の主流になっていくとは思うが、それはある程度サービスが枯れてからが良さそう

まとめ

今までWeb APIを利用することがあまりありませんでしたが、本章を読み進めることでWeb API自体やシンプルでより良い設計の方法について理解を深めることができたと思います。

ただし、Web API側のシンプルさを追求する一方でリクエストの頻度やクライアント側の負担についても考慮する必要があると感じました。

本章を通じて得た知見を活かしてシンプルで保守しやすいWeb API設計を意識しつつ、サービス全体としても最適な設計を模索していきたいと思います。