年に1回ブログ作りたくなったときに考えること

最近HTML上の要素を直接編集できるようにするライブラリをつくってからというもの、どうしてブログの記事を編集するときに記事ページを直接編集できないんだろうとか、どうしてユーザに表示されるのと同じデザインを見ながら編集できないんだろう、プレビュー画面とテキストエリアを左右に並べて見比べているんだろう、とか色々な考えに取り憑かれてしまってやばい。

はてなブログTumblrのテーマにJavaScriptを入れてAPI経由で編集したりできないか試してみたけど、APIを使うための認可用のトークンの発行が安全に行えないとか、異なるドメイン間で通信するのをブラウザが許していないので中継サーバを置くのがだるいとか、そういうことを見積もってみると結局コストが掛かり過ぎそうでぐったりしてた。ブログエンジンから作るみたいなことになると最高に大変そうなのでエディタ部分だけ取り替えたい。

ブログサービスをつくるの、データを預かるという責務が1番大変だと思う。それを避けるために前にGitHubレポジトリをDBとして利用するブログエンジンを作ったことがあったけど、結構無理やりなことをやっていて大変だった (blobオブジェクトをつくって、commitオブジェクトをつくって、masterブランチを作成したcommitオブジェクトに向ける、という個々の処理をAPIでやるみたいな話)。今はファイル投稿APIみたいなものが出来たらしいので少しは楽になっているかもしれない。他にストレージ as a Serviceとして使えそうなのはTumblrDropboxとかで、Dropboxは一度試したこともある。

覚悟決めてMySQLとかその辺に入れとけばええやんという話もあるんだけど、寧ろ開発者的な都合より利用者的な都合の方が大事で、新しく出来たサービスでしかも名もない個人がつくったものは全く信頼性がないので、そういうものにブログ記事とかをおいそれと預けるような人間はあんまり居ない。ので、透過的にデータが信頼できるところに保存されている様子が確認できた方がいい、というのがストレージに外部サービスを使いたい理由の一つ。

ところでブログ風にデータを表現するには、各記事にタイトルと作成日時が必要で、あとユーザ名を元に作成日時降順で記事一覧を取得してくるといったことも出来ないといけない。GitHubAPIではこういうのが効率的に出来なかったので前は結局HTML版をスクレイピングしたりもしてた。ディレクトリのページに行けば日付付きでファイル一覧が取れて便利だった。あとブログだったら画像を投稿したいと思うけど、GitHubAPI経由だと画像のようなバイナリファイルは投稿できないので厳しい。DropboxをDB代わりに利用してたときはその点楽だった。Tumblrは画像投稿もできるかもしれない。

他のサービスをDB代わりにするときにつらいのは、サービス側でもデータの更新が発生するとこ。REST APIだけの情報を使ってアプリを実現しようとするとどうしても通信回数が増えて動作が遅くなってしまう。それで自然とキャッシュしたいという要求が出てくるんだけど、更新するフローが複数あると更新したときにキャッシュを新しくするという戦略が使えない (ので別にバッチを回してキャッシュを生成するみたいなことをしてた)。

こういうことを何周か考えていると、当初のつくりたいという気持ちが徐々に絶望感で上塗りされて日々の生活に戻れる。