LDRがなくなるとのことがなくなったけど俺用フィードリーダー作った

mizchiさん(LDRがなくなるとのことで俺用フィードリーダー作った - mizchi's blog)のパクリです。はい。

f:id:ishiduca:20141115134146p:plain

実際LDRがなくなると、いずれは他のフィードリーダーも終わっていくんじゃないの? という不安がある。
なので、ローカルで動くものを持っておくのも仕方がないことなのかもしれないとモヤモヤしていたところで、mizchiさんのオレオレフィードリーダーが出てきた。
ごちゃごちゃ悩んでないでとりあえず作るべき。

ishiduca/feedr · GitHub

パクる

LDRに準拠したキーバインドとかマウス操作に対応させないとか、僕にとって重要でパクれるところはパクった。

既読管理の方法は違っていて、インメモリではなくleveldbにアウトソースしてる(下記参照)
ブラウザ上では未読/既読の管理はしてない

localStorageではLDRでいうところのピンのような機能を持たせることに。npmライブラリの localstorage-down 使ってみた。
localstorage-down は ユーザが触れるapiのところがleveldbのapiと同じlevelupを使うのでバックエンドとフロントエンドで同じapiでいい感じ。

leveldbはポータブルに使えるので今回の要件にはマッチしてたので使ってみた。

実装の方針

opmlファイルの読み込みからフィードエントリーをクライアントへ届けるまでStreamのパイプで直列化できるんじゃないの? という発想から後先考えずに mkdir -p feedr/{lib,node_modules,t} したので、ストリームインターフェイスのモジュールを書く。機能毎に小分けにしたストリームを書く。

Streamについて

わりと手間がかかる
でもStream1より実装者がコードを書く量が少ないのはいい
.onpipe時にwritableに例外が投げられると.unpipeされるので例外処理重要!

同時接続数の制御

セマフォ的な役割をこなすストリームで全体の同時接続数と同一ドメインでの同時接続数を制御してる。
任意の接続数に達した時点で上流のストリームの流れを止める方法が思いつかなかったので実装にしてみたけど、今からしてみれば上限数に達した時点でパイプ接続を一旦切ればよかったな、と

まとめは特にない。