冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

Dropbox4Sをリリースしました

Scala Programming

このご時世にWebサービスやアプリも作らず、大きなネームバリューをもたらすライブラリのコミッタでもなく、まだ誰も手をつけてない革新的なライブラリというわけでもなく、小さ目のWeb APIライブラリばっかり作ってるのもなかなか乙なものです。そこはかとなく目立たないというか、懇親会でもボッチまでは行かなくてもちょいちょいぽつねんとしてしまう自分にはあってると思います。

というわけで、Dropbox4Sというライブラリを作りました。
Dropbox APIの中のCore API*1とDatastore API*2をScalaから扱うためのライブラリです。

リポジトリ

bintrayにもpublishしているのでsbtの依存関係追加すればすぐに使えます。なお、implicit classとか使ってるので、Scala 2.10系が対象です。

dropbox4s

利用方法については、リポジトリのREADMEを読んでください。まだAPIが提供しているすべての機能をライブラリが網羅しているわけではないですが*3、Core APIによるファイル・ディレクトリのライフサイクル、Datasotre APIによる構造化データのライフサイクルについては一通り網羅しています。
使ってみてわからないことは @ にメンション飛ばしたり、このエントリにコメントしてくれれば対応します。

アーキテクチャ

というほど大したものでもないですが、ある程度構造は意識してますよ、ってことで。
Dropbox4Sの対象はCore APIとDatastore APIですが、Core APIはDropboxが公式で出しているJavaのSDKをベースにしています。
実際の構造は下図のような感じになっています。

役割 Core API Datastore API
DSL提供 dropbox4s.core.CoreApi dropbox4s.datastore.DatastoresApi
DSLが利用するモデル dropbox4s.core.model dropbox4s.datastore.model
Web APIを実行するインフラ層 公式のCore API Javaライブラリ dropbox4.datastore.internal

DSL提供層が実際にライブラリユーザに機能を提供する層で、この層が下のレイヤの機能を取りまとめてユーザへ提供している層としても機能しています。
下のレイヤは実際のリクエストを扱っている層で、JSONのパースやHTTPリクエストに関する処理を扱っています。Datastore APIの場合、REST APIとほぼ1対1に対応しているので、DSLが気に食わなければこの層を使ってお好みのDSLを作ることは可能です。Core APIの場合は、ここがSDKになります。
ちなみに、Core APIでDropboxの公式SDKをベースにするかスクラッチ*4でいくか最後まで迷ってたんですが、全体の構造に統一感を与えつつなるべく舵を切りやすい構成というところで考えた結果なので、もっといい方法をひらめいたら変えます。

「うわ・・・私のコード、implicit使いすぎ・・・？」

どうなんでしょうね。そこimplicit classにしちゃう？とか自分で書いてても思いました。多分一番露骨なのはDatastore APIのTableに関連する操作の扱いで、人によってはTableクラスのメソッドにしちゃえばいいじゃん*5、なコードになってるのかと思ってます。
とはいえ、こうしているのにも一応私なりの理屈があってですね。

  • Tableが保持しているSnapshotに対する操作はTableの責務
  • REST APIに対する操作はDSL層の責務

という考えの元で実装する箇所を決定し、implicit classのままにしています。その責務の分割に従ってコードを書いた方が、私にとっては読みやすかったので。。。
そもそも、DSLを使う文脈以外でREST APIを操作できるメソッドの呼び出しはコンパイルエラーにしたいですし、この部分はimplicit conversionがなければDSL層にメソッド作って、レシーバになるインスタンスも引数で受け取って実装していたと思うので、表現力のためにimplicit conversionを使っているだけという点では、使い方として大きく外している感じはしていないのが正直なところです。

今後

箇条書きですが、今後やりたいこと。

  • ID、フィールド名のバリデーション
  • グローバルDatastore対応
  • 未実装のCore APIのDSLを実装

とは別に、Core APIのインフラ層にSDKを使い続けるかどうか考えてみたいとは思っています。Web APIを実行している基盤が別々に実装されている状況が気持ち悪いので。。。Core API側に統合できるのであれば、そっちの方が良いのかもしれませんが。

おまけ

今後もメンテナンスするモチベーションを維持するためにも、使ってみたフィードバックなんかいただけるとありがたいです。というかマサカリ(論理でも物理でも)と「これからもがんばってね的な何か」は常時ウェルカムで。

*1:https://www.dropbox.com/developers/core

*2:https://www.dropbox.com/developers/datastore

*3:自分基準で優先度低かったり、適切なDSLが設計できてなかったり

*4:dispatchとかjson4sとか使ってるのでフルスクラッチというのは少々おこがましい

*5:キャストが発生するのでパフォーマンス的にも