tech

LLのフレームワークの賞味期限

最初に結論を言っておきますが、LL言語のフレームワークで作られたWebシステムの賞味期限は、いいとこ二年といったところで、それを過ぎたら、もっとカッチリした言語を使ったシステムに移行していくことを考えた方がいいと思います。

Ruby on Rails

Webサービスのフレームワークとして、爆発的にヒットしたのが、Ruby on Railsです。私見ではありますが、Railsのヒットの理由とその限界の話をしようと思います。

なぜRuby on Railsがヒットしたのか

データベース設計をしなくてもアプリケーションを作れたからです。

実際、ActiveRecordとDBのmigrationにより、要件がはっきりしない段階からでも、ガシガシ実装して動かせるように出来ます。プロトタイピングからアジャイルな開発が可能です。

「顧客が本当に必要だったもの」を顧客と共に考えながら作ったり、新規サービスの立ち上げでグロースハックするといった場合、Railsに勝るものは無かったし、いまでも無いでしょう。

Ruby on Railsでの最初の壁

Railsの利点は、DBを気にしないという所にあります。

逆に言えば、DBの構造や性能を無視できなくなった時点がRailsの最初の壁となります。

ActiveRecordを素直に使えば、n+1問題にぶち当たります。開発初期の性能は二の次な状態であれば、それでもかまわないでしょう。開発スピードとのトレード・オフなので、性能は無視することが出来ます。

性能を二の次に出来なくなったとき、DBの構造を意識して、効率のよいクエリーを考えなければならなくなります。そうなったとき、Railsはその威力を失い、盆百なフレームワークと同じものになってしまいます。

そのとき手札としてあるのは、型が明示されていないmodelクラス群です。DBのスキーマを見れば型は分かりますが、それを正しく使うことをRubyは強制しないので、とりあえず、間違った使い方をしても動作してしまいます。そのためにテストを書くという反論があると思いますが、もともと静的型があればその多くは不要になり、本来のロジックのためのテストだけですみます。テストのS/N比が違ってきます。

Ruby on RailsでのUIの壁

Railsはフルスタックなフレームワークですが、UIに関してCRUD以上のことをしようとすれば、テンプレートを駆使して、UIを構成することになります。しかし、現代的なWebシステムでは、その程度で満足できないことも多く、フロントエンドはJavaScriptでということになります。

しかし、Ruby on Railsである以上、JavaScriptのフロントエンドはアセットに過ぎず、フロントエンド側では別のフレームワークを使うことになって、Railsとは別立てになります。

このとき、前述したような型が明示的で無いことが災いします。わざわざAPIの仕様を明示し、フロントエンドとやりとりをするというRailsである理由自体が失われたアーキテクチャにならざるを得ません。

なぜLL(Lightweight Language)なのか

Railsの成功から、雨後の竹の子のように、よくにたフレームワークが登場しましたが、その多くはLLで作られています。

その理由はアプリの起動が速いからです。

Railsが成功した理由から引き続きですが、爆速で開発できるという利点が、その他の問題を無視することができる状況ではLLは最適なのです。

しかし、開発速度より性能・機能が求められるようになれば、利点が失われ、のこるは脆弱な地雷原です。

型があればいいのでは?

そうですね。

しかし、LLはどうしたわけか、静的型がない(あってもアノテーションレベル)というのが現実です。

まとめ

  • 開発スピードが重視される時点(主に開発初期)では、LLであることが有利
  • 開発スピードよりも性能・機能が重視されるとLLの型が緩いという欠点があらわになる

蛇足

僕が考えた最強のWebシステム

Kotlin/JSをnodeやdeno上で動かしたら、LLのうまみを活かして、将来的にも堅牢なシステムを作れると思うのですが、どうでしょうね。ちょっとやりかけて放置している もの は有ったりするのですが。