Typetalk とその API の基本的な説明をした上で、実際にコーディングを行うイベント Typetalk Hack を以下の日程で予定しています。本エントリを読んで興味をもたれたら是非ご参加ください！
- 4月23日(水) Typetalk Hack Tokyo
こちらの記事(英語)を読まれた方はご存知かもしれませんが、先日正式版のリリースにあわせて Typetalk API が公開されています。
Web サービスの API は、開発者が何らかの問題をプログラムで解決するために利用するものです。ところが Typetalk では、あなたが開発者でなくとも、またプログラムを書かなくても、ブラウザで Typetalk を利用しているときはいつでも、Typetalk の API が裏側では呼ばれています。
というのも、多くのウェブサービスでは、その API とウェブアプリケーションで提供する機能は上のように分けているのが普通です。しかし Typetalk は以下の図のように、ウェブアプリケーションから直接 AJAX にて自身の API を呼び出すというアーキテクチャになっています。そのため、ユーザは意識しなくとも Typetalk の API を利用していることになります。
このエントリでは、なぜ Typetalk でそのようなアーキテクチャを採用したのかを紹介します。
1. 実装コストを低減する
API とウェブアプリケーションの機能を分けて実装した場合、同じような機能に対して似たようなコードを書かなくてはいけないケースが多々あります。また、そういった複数の「似たコード」は不具合の温床にもなりかねません。API を直接ウェブアプリケーションから呼ぶことにより、そういったリスクを低減し、また実装コストも低減する事が出来ます。
実際に私たちはこのアーキテクチャをプレビューベータのローンチ時から採用しており、短期間でウェブアプリケーションと並行して iPhone 及び Android 版の開発を少人数のチームで行うことが出来ました。
2. 継続的なテストと改善
書籍「プログラマが知るべき97のこと」では「API設計の黄金律」として以下のように述べられています。
「APIを提供するときは、API自身のテストだけではなく、必ずそのAPIを利用するコードのユニットテストも書く」
もし、API を実際に使わなければ、その設計が良いのか悪いのかを判断することは出来ないですし、結果として誰も使わないような API になってしまうかもしれません。
Typetalk では「API設計の黄金律」を一歩推し進めて、API をウェブアプリケーションの中心におき、ウェブアプリケーションで提供する機能のほとんどを API として提供することにしました。これにより、私たちが何らかの機能を提供しようと思った時は、まず API の設計と実装から始めることになります。つまり私たちが、その API のファーストユーザになるので、設計の善し悪しにはすぐに気付きますし、また機能をつくりあげていく過程で自然と改善もなされていきます。
3. 全ての開発者に対してオープンに
そして最後の理由は、Typetalk を全ての開発者に対してオープンにし、その機能をフルに活用したアプリケーションを開発できるようにしたいという思いがあります。先にも述べたように、ヌーラボ社内の開発者だけでなく、外部の開発者であっても私たちが提供しているサービスと
同等のものが作れるよう、ほとんど全ての機能を API として提供していく予定です。
公式の iPhone クライアント、Android クライアントも全て公開された API をベースに開発されていますので、それらと同等のものを開発することは可能です。是非あなた好みのスマートフォンアプリをはじめ Typetalkのクライアントの開発にチャレンジしてみてください！
いかがでしたでしょうか？この設計についてご意見ありましたら、是非コメントをお寄せください！
次回はこれをどのように実現しているのかについてのエントリを書きたいと思います！