2016年秋頃から、2017年3月頃まで、Meteor(v1.3.3)で動いているシステムを実際に開発に携わってみて感じたことを知見として書いておくことにする。基本的には、表題についての根拠がつらつらと書かれている。主に技術選定をするという目線で読んでいただきたい。
DB選択肢がMeteorの長所を活かし切るとMongo DB固定になる
Meteorのリアクティブ動作の恩恵を受ける場合、前提としてDBはMongo DBを選択することになる。Mongo DBで事足りたり、ノウハウがあれば全く問題はない。だが、例えばECサイトなどでトランザクションが使いたかったり、整合性を気にしだすとMeteorが悪いというより、Mongo DB自体が不得手な分野になるので、選定を考える必要がある。プログラムは単にデータベースのラッパーと考える人もいると思うが、プログラムというより、そもそものデータベースの扱いが分からないと致命的だ。正直、Meteor が悪いのではなく、Mongo DBというまだまだメインDBとしてガンガン使われていないDBをいきなり運用することになるので、そこが辛いように思えた。
パッケージの選定から、パッケージ自体のメンテナンス性まで多くの不安が残る
Rails界隈ほどうまくいってないように思える。何かしらやりたいことだったり、Githubでちょっとしたパッケージを探した際に最終更新が「2 years ago」と平気で書かれていたりする。あとは、気になる点として、Meteorはrouterから純正またはサードパーティのパッケージを選択可能で、わりとアプリケーションの根幹の部分から割れている。routerは案外重要で、iron-routerとflow-routerで使用可能なパッケージが異なるケースがよくある。技術選定の際、ベストな選択がすぐに決まらないのはネックだろう。
Meteorは該当バージョンに対応するNode.jsしか使えない上、サポートするNode.jsのバージョンが古い
現状2017年4月現在、最新安定板のMeteorはv1.4だが、対応するNode.jsのバージョンはなんとv4と、現状のNode.js環境(2017年４月22日現在最新はv7、長期サポートバージョンはv6)と比較し、かなり遅れをとっている。ES2015の記法が徐々に現場に浸透してきている中、Node.jsの最新の長期サポートバージョンの6ではなく4でロックされる状態は少し考えてしまう。
Meteor自身が時代に合わせたユーザを魅了するパワフルなアップデートをしていない(これは完全に主観)
Railsでいうならv5でActionCableが実装され、WebSocketを扱うRails開発者に恩恵を与えた。Meteorが特に話題性のあった(?)時期の2012年頃の場合は、Meteorの基本機能のリアクティブ同作、それ自身がメリットであったが、特に他は聞かない気がする。とはいえ、Meteorはすでに基本的にはリアクティブ動作だし、Cordovaを使いネイティヴアプリのコードも出力できるし、コンセプト的にこれ以上必要か？と言われると盛り過ぎな感じもする。
期待するとしとら、個人的にはrouter機能を強化した上で、Meteor自身に内包すること、あとはAPIを作りやすい機能を入れるなどするなどしたら面白いのではないかと思った。なぜこれを思ったかというと、Meteorはあまりに制約がなく、かなり自由度が高い。ある程度制限されても、例えばJSONを出力するAPIをすぐに作れることは結構メリットなのではないかと感じたからだ。
フロントエンドフレームワークのBlazeを選択するとmetaタグで簡単にハマる
詳細については、1つ前の別なエントリーに状況を書いたので、そちらを参照して欲しい。Blazeについては正直、Meteor公式のミスリードと思っている。Meteor v1.3くらいまではBlazeを公式がバックアップして推していた印象があるが、実際Blazeを使ってみてかなりの残念具合だったので、Blazeが公式から分離されたという事実も踏まえると、Meteor自体の動向も少し怪しい印象すら個人的には感じてしまう。強い言葉でいうと、リアクティブ動作に最適化したフロントエンドの構築にMeteor公式が失敗した、という見方をしてしまった。
MeteorのGitHubのスター数に対しての注目度合いについて、若干の疑問が残る
2017年4月22日現在、MeteorはやはりGithubスター数はどのWebアプリケーションフレームワークよりも多いことが確認できた(Github / Web application frameworksを参照し、37,187)。一方で、少しクラスタが狭まるが、2016年で注目度が上がったWebアプリケーションフレームは、Expressであることが、下記の記事により分かる。
JavaScript ベスト・オブ・ザ・イヤー 2016
この状況から、Meteorのスター数は実際は2015年から劇的には変わっておらず、これだけのスター数がありながら、注目度が上がっているかといえば実際はそうでもない。実際にMeteorに手を出してみると、ちょうど今から2年前、2015年で更新が滞っているようなパッケージも多い。インターネット上で記事を探すと、2012年頃が多かったりなど、なんとなく情報も停滞している状況も感じられたりする。
Meteorは、Githubスター数がRaisを超えてかなり多かったため、本ブログでもMeteorを複数回取り上げることに至ったが、実際のところ実情はどうなのかという話になると、GitHubのスター数を指標にするだけではちょっとアヤシイ印象を今では持っている。
現状ではMeteorの使いどころは難しいように思える。Node.jsで組むならExpressで良いし、メンテナンス性、周辺環境が優れたフルスタックフレームワークにいくならRailsで良い気がする
以上のことから、Meteorは注目されているようで、そうでもないし、フルスタックといえども、Rails並みに環境が揃っていて、メンテナンスされているモジュールに恵まれているかといば、そうでもない。印象的には、かなり中途半端なフレームワークと認識している。色々と中途半端な環境が仇となり、扱いが難しいような気がしている。あまりここでは触れないが、mup-xなど、ソースコードをDockerコンテナ化してデプロイするなど、デプロイ方法も変わっているし、おそらくスタンダードが確立されていない。
では、そのような状況の中、Meteorを取り扱おうと思っていた人がMeteor以外のWebフレームワークを選択しようとする場合、何を選定すれば良いのか。答えはわりと簡単で、Meteorに周辺環境の充実を求めていたならRailsに行けば良い。Railsでは、定番のモジュールが長くメンテナンスされているし、Meteorと異なり、ルーティングだったり、ORMがRails公式のロジックが強く、既にRailsに内包されたものを使うことになる。よって、Meteorのrouterのように、アプリケーションのコア部分から覆されたり、妙なロックインにハマることはまずない。また、好みが別れるが、Railsのほうが規約が多い上、知見も多い。そのため、開発・運用上のベストプラクティスを見つけやすいだろう。
Meteorに、Node.jsの高速な処理速度かつ、よくメンテナンスされているフレームワーク環境求めていた場合は、Expressに行けば良い。Expressは、2017年4月22日現在、現状はv4だが、v5のリリースも控えている。Node.jsの黎明期からこれまでスタンダードのポジションは揺るがず、フレームワークが提供するAPIがよくメンテナンスされていることだろう。
Meteorにまつわる本ブログの関連記事へのむすび
本ブログは、2017年4月現在で、圧倒的にMeteor関連記事による自然流入が多いわけだが、Meteorに関する記事が多いからといってMeteorを激推ししているわけではないので、このような否定的な内容の記事を書いた。技術選定にまつわる話ということで今回はシビアな内容だが、作っていて面白いフレームワークではあるので、製品レベルみたいな話でないのなら、他のWebフレームワークにはない特徴を有する、最も面白いフレームワークはMeteorという認識は今でも変わらない。