GoでServeMuxの機能拡張を提案するProposalがAcceptedになった

GoでServeMuxの機能拡張を提案するProposalがAcceptedになった

Read in: en
GoでServeMuxの機能拡張を提案するProposalがAcceptedになった

以前からウォッチしていたnet/http: enhanced ServeMux routing #61410がAcceptedになったので、それについてポエムをかく。

最終的な仕様がどうなるかはわからないが、静的なルーティングの機能(/foo/barのような固定値のルーティング)しか持っていないServeMuxに動的なルーティング(/foo/:idのようなパスパラメータを使ったルーティング)の機能が少なくとも追加されそうな雰囲気。

自分がこのProposalを気にしている理由は、ルーティングのライブラリを個人的に開発しているである。

cf. bmf-san/goblin cf. bmf-tech.comの関連記事

goblinは有名所のルーティングライブラリと同じく、ServeMuxの機能を拡張するライブラリで、静的・動的なルーティングに対応している。動的なルーティングのパスパラメータは正規表現もサポートしている。

goblinの内部のデータ構造はTrie木をベースにしたロジックで、自分としてできる限りの最適化をしたりしている。(より良いパフォーマンスを求めるならデータ構造を根本から変える必要があるが・・)

今回のproposalに記載されている参照実装とのパフォーマンス比較をやってみたが(リリースされる実際の実装とは異なる可能性があるとは思うが、参考程度にやってみた)、どっこいどっこいという感じ.. cf. Add jba/muxpatterns #23

ServeMuxの機能拡張がリリースされたらgoblinはおそらく使う理由がなくなりそうだなぁと思っている。そもそも使っているのは自分だけで、自分が個人的なアプリケーションで使っているだけだとは思うが・・

goblinは継続的にメンテナンスしていつかは日の目を見る日が・・と思っていたが、今回のproposalで一区切りつきそうw

今後サードパーティのルーティングを採用するかどうかについては、標準のServeMuxが大きな一つの選択肢になってくるのかなと思っている。

サードパーティのルーティングを採用するかどうかの基準としては、標準のServeMuxと比較して、

パッと思いつくところはこのへん。

サードパーティからServeMuxへの乗り換えのしやすさとかは気になるが、net/httpで定義されているinterface(Handlerとか)に準拠しているかどうかあたりネックかなと思うので、準拠していれば大きな問題はなさそう。準拠していないライブラリからの乗り換えは面倒かもしれない。(ほとんどは準拠しているが一部準拠していないオレオレ実装になっていたりする)

Proposalのコメントに依ると、これから具体的な実装を検討していくようなので、引き続きウォッチしていこうと思う。

Tags: Golang router HTTP
Share: 𝕏 Post Facebook Hatena
✏️ View source / Discuss on GitHub
☕ サポート

このブログを応援していただける方は、以下からサポートをお願いします。いただいたサポートはブログ運営・技術研鑽に活用します。


関連記事