初めてのクライアントサーバーシステム。APIを採用する嬉しさとは?

僕は何度かクライアントサーバーシステムを構築してきました。
APIを用いた実装も何度か行っています。
今回はAPIを用いた開発者視点の嬉しさについて語ってみようかと思います。

他層アーキテクチャについて

まず、APIを語る前に多層アーキテクチャについて簡単に述べます。
少し構成を見てみます。

当然APIを実装する3層アーキテクチャはアプリとAPIの二種類を実装しないといけないので手間が増えます。また、トラブルが発生した時、原因を追う箇所が増えるというのもつらいところです。

3層アーキテクチャにおいてアプリの部分をプレゼンテーション層と呼び、
APIの部分をファンクション層と呼びます。ちなみにデータベースの部分はデータ層。
基本的にはAPIに機能を実装しアプリの部分は表示だけの簡単なものにするよう実装します。

が、しばしばアプリも複雑化する。。。
当然2層の方が開発やメンテナンスは楽です。

では、何故3層にするのか?何故APIが必要なのか?

APIの必要性

大きく分けて4つあります。
他にもあると思いますが僕がこれまでに実感したもののみについてご説明します。

  • セキュリティ
  • 負荷分散
  • 双方向通信
  • 基本機能の外部への公開

セキュリティ

おそらく2層で実装した場合、誰しもが感じることです。
アレ?データベースのパスワードを全てのクライアントに持たせないといけない?

3層で実装した場合、API側でパスワードを保持することができます。

2層にするか3層にするかは案外この部分が大きかったりします。

負荷分散

2層アーキテクチャの場合、全てデータベースに負荷が集中します。
また処理はクライアント側の性能に依存します。

3層アーキテクチャの場合、
APIの部分で余分な処理を省くことができたりデータベースに集中する負荷を待たせたりすることができます。また処理速度を通常能力の高いサーバー側に任せることができます。

双方向通信

通常データベースは更新されたことを相手に通知する手段を持ちません。
つまり更新を確認するにはクライアント側が一定周期で問い合わせることになります。
これではリアルタイム性も低くユーザーにとってちょっとしたストレスになります。
かといってポーリング周期を上げてデータベースやネットワークにムダな負荷をかけるのも困ったものです。

また、3層であれば他のアプリが更新したことをAPIが受けて他のクライアントに通知することも可能です。少し実装は大変ですが。。。

基本機能の外部への公開

最近データ活用が取り沙汰されています。
そのため公開可能なものだけデータを公開する方法が必要になります。
また、自動化など第三者の独自サービスによる付加価値向上なども狙えます。
APIのメインの嬉しさはこれです。

まとめ

今回はAPIについて開発者目線の嬉しさベースでお話ししました。
正確には3層アーキテクチャの嬉しさかもしれませんが。

今更な内容かもしれませんが、僕自身も開発時の楽さを優先し2層で後悔したケースがいくつかあります。結局、双方向通信はどうにもなりませんし完全に設計ミスですね。
キモはアーキテクチャでできることが決まってしまうということです。

初めてクライアントサーバーシステムを構築する人のご参考になれば幸いです。

おわり

PR

コメント

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です