Webアプリのアーキテクチャ
本章では、生産性の高い状態で継続的に開発 していくために、今後のWebフロントエンドのアーキテクチャについてFrontend Chapter と Arch Chapter のメンバーで議論した内容について紹介します。
ここ数年のリニューアルやリノベによりプロダクトのUIがアップデートされ、それに伴いフロントエンドの技術スタックもアップデートされてきました。これまでの技術スタックは大きく4世代存在し、v1〜v4 と呼ばれています。現時点でも v4 以前の古い世代の技術スタックで書かれたコードは存在します。
- v1: Haml / SCSS / AngularJS & jQuery & Backbone.js
- v2: TypeScript + React + Redux + redux-thunk / styled-components / webpack
- v3: TypeScript + React + Redux + redux-thunk / styled-components / webpack / SSR
- v4: TypeScript + React(Next.js) + GraphQL / styled-components
- 新しいページは v4 で作る
- 企業ユーザー向け管理画面は wantedly/wantedly-admin-frontend
- ユーザー向け画面は wantedly/wantedly-frontend
- GraphQLサーバーは wantedly/wantedly-graphql-gateway
新規開発やリニューアルのタイミングでは可能な限り v4 で開発することを推奨します。つまり wantedly-admin-frontend もしくは wantedly-frontend のどちらかの上で開発を行い、GraphQL サーバーを経由して各マイクロサービスと通信を行うようにします。例えば、採用担当者向けのダッシューボード画面は wantedly-admin-frontend、ユーザープロフィール画面は wantedly-frontend で開発するという棲み分けです。
GraphQL サーバーについては wantedly-graphql-gateway を利用していく方針です。2021年7月時点では検証段階のため、visit-api-node で代用します。visit-api-node はすぐになくなることはありませんが、大きな新規開発で Query/Mutation を作る際にはどちらを採用するか議論と検討を行ってください。
2021年10月にフロントエンドの主要レポジトリである wantedly-admin-frontend, wantedly-frontend ともに Create React App ベ ースから Next.js ベースに移行しました。以下がその背景です。
- HTML 配信における課題の解消
- SSR の基盤を世の中的にデファクトといえるフレームワークの上に乗せ、インタフェース・実装ともにより洗練されたものに追従する
- SSR におけるデータ 取得の最適化や、SSG, ISR など他の HTML 配信戦略の検討を可能にする
- 開発体験上の課題の解消
- フレームワーク統一により、一貫した開発体験を提供する
- 特にルーティングフレームワーク, ビルドシステムなど
現状グローバルな（複数コンポーネントをまたぐ）状態管理のために、 wantedly/wantedly の v2, v3 では Redux を主に使用しており、v4 では Apollo Inmemory Cache を使用しています。v4 においては現状複数ページを横断して使用する状態管理が必要ないためグローバルストアは存在しません。しかしながら今後そのような状態管理が必要になったときに Redux, Recoil, Jotai のようなライブラリを使用しないという判断ではありません。v4 においても複雑な状態管理が必要になるシチュエーションにおいてはそのような状態管理ライブラリを導入する余地はあり得ます。そのときには Frontend Chapter において議論が必 要です。小さく試す限りにおいては chapter での議論は最小限（もしくは skip）で問題ありません。 ただし、以下を満たす必要があります。
- 導入の経緯は Architecture Decision Record (ADR) に記録する
- 撤退可能な状態・最 小の規模で導入する
- 振り返りを行う
- 広く導入したいときは、Frontend Chapter で議論する
wantedly/wantedly の v1 スタックのページについてはリノベ・リニューアルのタイミングで積極的に v4 への載せ替えを推奨とします。GraphQL API を用意するのにコストがかかる場合、リノベのようなプロジェクトでバックエンドに大きな手を入れられない等の理由で、 v1 → v4 への直接の移行が難しい場合は v2, v3 を載せることを1次ステップとすることは許容しています。
Wantedly において SSR を導入する1番の目的は SNS でシェアされたときの OG 情報を返すことです。SEO については2021年現在において、Google のクローラーは JS を解釈できることから第一の目的ではないと考えています。したがって、あるページを SSR するかどうかの判断基準の第一は「SNS でシェアされるものかどうか」です。デザインシステムやヘッダなどの共通コンポーネントは SSR されるページで使用される可能性があるので、SSR 前提で開発しておく必要があり、それは最低品質をテスト等でカバーします。
最終更新 9mo ago