最近の仕事で利用したフレームワーク・ライブラリ・サービスとその感想
書こうと思ったモチベーション
下記の記事が話題になっており、自分もここ数年で利用してきた技術の感想を軽くダンプしておきたいと思ったため。
自己紹介
Rails → フロントエンド寄りの広く浅くという経歴ですが、直近2年くらいはほぼ自分一人でいくつかの新規事業のプロダクトの開発を行っていました。
そのため一般的なWebサービスの開発に関しては一人で完結させられますが、インフラ設計に関してはそこまで深い知識を持っていません。
前提
投稿時点から2, 3年程度の範囲でフロントエンドの内容が主ですがそれだけに限りません。
また一部要件上で必須なものもありましたが、記載の技術の選定についてはほとんど要件上の縛りはなく自分が選択したものです。
判断の観点としては、自己紹介の所にも書いたように直近は小さいチームでの新規事業の開発だったので、主にゼロイチの開発スピードと仕様やビジネスの変化への追従性に重きを置いています。
Next.js (App Router)
用途
ユーザーが利用する画面に利用
感想
ファーストチョイス、基本的に出来ないことが無いのが仕事で使う上では最も重要だと考えているので特に理由が無ければNext.js (App Router) を使っています。
特にApp RouterになってからはDBアクセスもほとんどServer Componentから行うようにしており、バックエンドAPIのエンドポイントを作ってフロントエンドに繋ぎ込む、という作業が不要になったのでかなり楽になりました。
例えばBFFがあるような構成でページとAPIが1:1で紐付いているようなケースではPages Routerも悪くはないと思うのですが、私のユースケースではApp Routerは特に有用でした。
そしてやはりフレームワークが提供するパフォーマンスの最適化は他に比べて頭一つ抜けており、最適化のためのアディショナルなコストもほぼ必要ないので気に入っています。
Firebaseとの噛み合わせが良くなかったり、内部的なログのフォーマットを変更するオフィシャルな方法が無いなど気になっている部分がない訳ではないですが、自分の価値基準では一般的なWebサービスを作るときにNext.js以外を選択する理由があまり思い付かないでいます。（強いて言えばパラダイムの変化による学習コストが許容出来ないケースくらいでしょうか）
Tailwind CSS
用途
shadcn/uiと合わせて利用
感想
元はよく言われているように負債化しそうという感覚から利用を避けていたのですが、ここまで流行ると次の世代のCSSフレームワークは思想的にもツール的にもTailwindからの移行を考慮せざるをえなくなったため、そこがあまり問題にならなくなったので利用を始めました。
CSS Module, Chakra UIなども利用してきたのですが、実際に使ってみるとTailwind自体は（少なくとも使っている感覚は）ただのスニペットに近いため、ライブラリレベルの設計や思想が入り込みにくく、UIコンポーネントライブラリとスタイリングライブラリを分離しやすいのが気に入っています。
もっとよく出来た（ように見える）CSSフレームワークはありますが、このへんが自分のような人間が扱える限界なのではないかという感覚を持っています。
shadcn/ui
感想
別のUIライブラリの薄いラップを提供してそれを利用側で管理させるアイデアは思いの外使い勝手が良かったです。
以前はページコンポーネントにおいてUIライブラリからの直接のインポートと自分で定義したAtomicなコンポーネントのインポートが混ざって管理が面倒になりがちだったんですが、それを比較的少ない手間で（完全にではないものの）解消出来たと感じています。
GraphQL
用途
フロントエンドからバックエンドへのリクエストに利用
感想
私のユースケースではToo Muchでした。
クライアントからは使いやすかったのですが、クエリのパターンが無数にあってテストのコストが高かったり、フレームワークへの依存が大きくフレームワーク自体の実装難易度も高いことなど、私にとっては。
APIサーバー・クライアントが1:1ではなく開発チームも分かれているようなケースで、GraphQLを使うことに対してリソースを掛けられるならそこまで悪くない選択肢になるんではないかと思います。
Express
用途
Honoがまだ実用に耐えうるか判断出来なかった時期に開発が始まったプロジェクトのAPIサーバーとして
感想
サードパーティライブラリは豊富ですが、古いものが多くTypeScriptフレンドリーではないことが多いため、Honoの開発が精力的な今あえて使う理由は少ないと思います。
Hono
用途
APIサーバーとして
感想
良い意味で、2024年時点の基準でのごく普通のWebフレームワーク（HTTP Request Handler）という感じで安心して利用できます。
Prisma
用途
ORMとして
感想
ややこしいことをやろうとすると面倒なこともありますが、ORMで表現可能な範囲のクエリを発行する分にはとても楽。
シンプルな構造化データで型安全にクエリを表現出来るのが気に入っています。
ちょうどこれを書いているときに生SQLから型を生成する機能がアナウンスされていました。
Golang
用途
バッチなどスピードが重要で扱うデータ量も比較的多く、ある程度低いレイヤのコントロールが必要な箇所で利用
感想
ゼロ値の仕様とPointer型がnullを許容することを除いてはシンプルで良い言語だと思いますが、手続き的なコードを強制されることが個人の好みの問題で好きになれません。
好みの問題を除外してもなぜ今の時代にPointer型がnullを許容する（参照とNullable, Optionalを区別出来ない）言語が流行っているのかは疑問に感じています。
とはいえ諸々の要件と他の代替手段を考えると悪くない選択だったと思っています。
Cloud Run
用途
Next.jsサーバーを動かすのに利用
感想
必要無い時には寝かしておきたいが必要なときにはある程度のスケーラビリティを担保出来るサーバーをイージーに立てたいときにはとても便利。スケールイン・アウトやコールドスタートも十分に速い。
イージーなソリューションが得意なGoogle Cloudのいいところが出ていると感じています。
Cloud Run Jobs
用途
バッチジョブなどを動かすのに利用
感想
こちらもCloud Runと同様にDockerイメージなどに固めたジョブをイージーに動かしたいときに便利。
まとめ
重要視する観点は組織・プロダクト・機能などの要件によって様々なので技術選定に単一の正解は無いですが、技術によって特定の要件に対しての向き不向きは存在するので、その判断の一助になればと思います。
Discussion