RubyとTypeScript。サーバーサイド技術選定

mofmofアドベントカレンダーの9日目です。

株式会社mofmofのshwldです。

mofmofはRuby on Rails(以下Rails)をメインにゼロイチフェーズのMVP検証を得意とする受託開発会社です。
メイン技術がRailsとは言ってもmofmofでは、Railsを使わなくてはいけないという制約はありません。

基本的には案件の担当チームがその案件に最適なスタックを選定していきます。
そういった環境下でも、Railsは選択肢として最有力になりやすいです。

ここまで書いて、なぜRailsが選ばれるのか社内できいてみたの方がいいかなと思ったのですが、期限の関係で今回はポエムです。

mofmofでRailsが選ばれる理由を考えてみます

理由1. ノウハウが有る

長くRailsを使ってきているので、多くのユースケースは社内の誰かしらが体験をしています。
そして、それは社内だけの話ではなく、Railsは歴史も長く知見や資産となり実績もあるGemがとても多いです。

理由2. リソースが有る

これは全く社内の話ですが、長く続いた場合、触れる人が多いので安心感があります。

理由3. 安定感がある

Rails以外にモダンなよいフレームワークや言語はたくさんあります。
ただ、Railsじゃないほうがいいケースはそこまで多くないです（mofmofに依頼される案件において）
過去にチャレンジングな技術選定も行っていますが、まあRailsでも良かったねという感想に結構な確率でなります。

Railsを選ばないほうがいい場合はどんな場合か

とは言え、選ばないほうが良いケースも増えてきています。
MVPを提供するという目的での開発が多いですが、どっしり構えて、リリース後改善して行くというプロダクトにRailsはマッチします。
MVPまでやって、検証して、改めて本開発は作り直す！だから色々考えること落としていいから早く作って。みたいなプロダクトやアプリの場合、Railsはサーバーを用意する分、初速が遅いです。

そういう案件には、FirebaseやlambdaなどのFaaSでサーバーサイドコードを小さくしてスピードアップをはかる方が良い場合もあるかと思います（作って改善ではなく、作って捨ててを繰り返すイメージ）

Railsを選ぶことの弊害

安定択なんですが、それゆえに飽きます。
技術的成長と言う意味ではあまり良い影響はないです。ある程度サービスが育ったら別ですが、途中で抜けて違う案件にいってまたRailsでイチからというループはまあまあしんどい。

安定択としてのGraphQL

数年前から自分はRailsだけよりちょっと遅くなるけど、安定択としてGraphQLを選定しています。
いくつか理由はあるのですが、一番大きいのはフロントエンドの自由度です。
Railsを選ぶと上で言いましたが、自分は長いことActionViewは使っていません。
フロントと密結合すぎるのが嫌いだったのが理由ですが、かと言ってREST APIもフロントが複雑になるしスピードが出る気もしない。
そこで数年前からGraphQLを採用しているのですが、コードの自動生成によって速度もまあまあ出るし、その上でフロントエンドをアプリにしたりと結合が薄いことによるメリットもちゃんと享受できるのでバランスが良いと思っています。
GraphQL Rubyが良くできているのもでかい。

安定してて速い択を増やしたい

Rails(+GraphQL)みたいに改善を安定して行えて、それでいて速い択欲しいなー。
と常々思っています。

それで自分はTypeScriptをサーバーサイドにしたら、フロントとサーバーサイドのスイッチングコストを減らせるし良いんじゃないかと思って、今年はそこに結構取り組みました。
ただ使ってて、サーバーをどう書くかが大事で、フロントとのスイッチングコストを減らせるほど考え方を同じにするのは大変だなーとも感じています（Reactのフロントエンドを書くのと、サーバーサイドTypeScirptを書くのはやっぱりスイッチングコストがある程度ある）

ならRubyでいんじゃないっていう気持ちに少しなったりして複雑な気持ちです。

↓ そんな感じで、TypeScriptでいろいろ試しているのをアドベントカレンダーにまとめていますので良かったらこちらも。
Next.js + サーバーサイドTypeScript + 関数フレーバーでクリーンなアプリを作ったので実装意図とか書く

最後に

以上になりますが、RedwoodJSは最高にちょうどいい気がしている今日このごろです。