released reprow "reverse proxy for worker"

Release reprow which serves as reverse proxy for worker.

For english document, please see below. github.com

microservice/soa化が　ますます普及する中で Job Queue による非同期実装はとても一般的になりつつも、Job Queue Worker自体には

• プログラミング言語 x Backend queue ごとに実装/プロトコルフレームワークが分かれている
• 通常のAPI Callなどは Push駆動、WorkerはPull駆動と、異なる方式でプロセス管理しないといけない

というところは個人的にあまりうれしくないなと感じていた部分です。それを解決するためのproductです(golangをまじめに使ってみたかったということもありますが)

• Applicationはタスクの実行という本質的な処理に注力すればよく
• BackendのQueueとのやりとりなどはmiddle wareに任せるべきで
• そして、そのmiddlewareとの通信プロトコルは一般的なプロトコルを用いるべきである

と思っております。

Web ServerなどでReverse proxy と Applicationの間の通信プロトコルが Reverse proxyから Push駆動で Application Serverに HTTP でrequestするというのが必ずしも理想的な方法かという点に関しては議論があるところだと思いますが(Pull型のシステムと異なり比較的死亡しやすいWorkerの監視をかなり厳しく行わないといけないなど問題はあります)、一般のWeb Serverなどは現在の実情としてそのような作り方をしてますし、HTTP 自体は非常に一般的なプロトコルなので それほど筋は悪くないと思います。

今回つくったライブラリは WorkerもWeb Serverと同様の作り方で作れるようにしたものです。 nginxの代わりに、reprowで proxy serverをたてれば、BackendのJob Queueとのやりとりはreprowが責任をもち、Application Serverはreprowからよばれる HTTPのCallにたいして正しくresponseを返せばよくなります

 JobBackend                          reprow                         Application
                   <- pulls a job
                                                  -> HTTP Proxy
                                                  <- Returns response
                   <- abort or ends Job

sqsだろうが、q4mだろうが、別のbackendだろうが　、goで作ろうが、rubyで作ろうが reprowを立ち上げて、jobを実行するHTTP Serverをbackendに立てればWorkerがつくれるということです。

一応 Retry-After Headerとかにもsqsの場合は対応していたりします。

実際使ってみて不便な点も感じるかもしれませんが個人的には現在のように言語xBackendでworkerのframeworkかいてるよりは作りやすいのではないかと考えておる次第です。