Virtual Spring Cleaning (part 5 of X) in which I release Backblaze::B2(::Async)
I'm a sucker for early access to free APIs. So I quickly went forward when Backblaze opened up access to their B2 storage API, and implemented a client for it, Backblaze::B2. I feel a bit guilty for releasing a module without having a use case for it myself, but instead of letting it rot on my filesystem, I'm putting it out for others to use.
Thanks to talks by Paul Evans at YAPC::Europe 2015, I learned about the Futures module which implements Promises for Perl. Thanks to Search::ElasticSearch, I got to spend some time with Promises and really like the API of both. I found that compared to the callback approach of AnyEvent, I was able to consistently shave two or three lines from every asynchronous call. And when you deal with an asynchronous API, having less boilerplate clutter really counts.
I decided to structure the module fairly close to Search::Elasticsearch, to keep it as asynchronous as possible while not getting lost in a maze of callbacks all dissimilar.
As implemented, the module allows storing and retrieval of files on B2. It also implements storing the credentials for applications. The management of the buckets and partial uploads of large files is not yet completely implemented. Likely, this will come once I find an actual use for this module, like storing a minicpan on it.
I'm not too fond of splitting up the code into Moo::Roles as Search::Elasticsearch does, so I just implemented the asynchronous
API first and then created the synchronous API as a thin wrapper over the
asynchronous API which simply calls
await on all results, forcing
the asynchronous execution back into a synchronous/eager mode.
Had I used the Futures module instead of keeping with what Elasticsearch uses, I wouldn't even have had to write my own
await routine but could have used what Futures provides. Maybe I should do a rewrite of the module using Futures just to see the differences. On the other hand, I'm not sure whether mixing Promises and Futures works well.