Webフロントエンドアプリのアーキテクチャ
本章では、生産性の高い状態で継続的に開発していくために、今後のWebフロントエンドのアーキテクチャについてFrontend Chapter と Arch Chapter のメンバーで議論した内容について紹介します。

前提知識

ここ数年のリニューアルやリノベによりプロダクトのUIがアップデートされ、それに伴いフロントエンドの技術スタックもアップデートされてきました。これまでの技術スタックは大きく4世代存在し、v1〜v4 と呼ばれています。現時点でも v4 以前の古い世代の技術スタックで書かれたコードは存在します。
    v1: Haml / SCSS / CoffeeScript + AngularJS & jQuery & Backbone.js
    v2: JavaScript + React + Redux + redux-thunk / SCSS + CSS Modules / webpack
    v3: TypeScript + React + Redux + redux-thunk / styled-components / webpack
    v4: TypeScript + React + GraphQL / styled-components / webpack

全体のアーキテクチャに関しての方針

    新しいページは v4 で作る
    企業ユーザー向け管理画面は wantedly/visit-admin-frontend
    ユーザー向け画面は wantedly/wantedly-frontend
    GraphQLサーバーは wantedly/wantedly-graphql-gateway
新規開発やリニューアルのタイミングでは可能な限り v4 で開発することを推奨します。つまり visit-admin-frontend もしくは wantedly-frontend のどちらかの上で開発を行い、GraphQL サーバーを経由して各マイクロサービスと通信を行うようにします。例えば、採用担当者向けのダッシューボード画面は visit-admin-frontend、ユーザープロフィール画面は wantedly-frontend で開発するという棲み分けです。
GraphQL サーバーについては wantedly-graphql-gateway を利用していく方針です。2021年7月時点では検証段階のため、visit-api-node で代用します。visit-api-node はすぐになくなることはありませんが、大きな新規開発で Query/Mutation を作る際にはどちらを採用するか議論と検討を行ってください。

個別アプリに関して

Next.js への移行指針

中長期な目線で、現在のフロントエンドの主要レポジトリである visit-admin-frontend, wantedly-frontend ともに Next.js をベースとしたビルドシステムの上に載せることを考えています。SSR の基盤を自前のものでメンテするのではなく、世の中的にデファクトといえるシステムに乗ることで安定化とメンテナンスに掛けるコストを下げる目的があります。また、現状できていないページごとの SSR, CSR, SSG の切り替えなどの最適化を行えるメリットもあります。ファイル名ベースのルーティングに関してもデファクトに乗りたいという背景があります。 visit-admin-frontend に関しては SSR の恩恵はあまりないですが、2大主要レポジトリでビルドシステムを共通化することで長期的なメンテナンスコストを下げるという目的があります。

個別アプリのアーキテクチャ

状態管理ライブラリに関して

現状グローバルな(複数コンポーネントをまたぐ)状態管理のために、 wantedly/wantedly の v2, v3 では Redux を主に使用しており、v4 では Apollo Inmemory Cache を使用しています。v4 においては現状複数ページを横断して使用する状態管理が必要ないためグローバルストアは存在しません。しかしながら今後そのような状態管理が必要になったときに Redux, Recoil, Jotai のようなライブラリを使用しないという判断ではありません。v4 においても複雑な状態管理が必要になるシチュエーションにおいてはそのような状態管理ライブラリを導入する余地はあり得ます。そのときには Frontend Chapter において議論が必要です。小さく試す限りにおいては chapter での議論は最小限(もしくは skip)で問題ありません。 ただし、以下を満たす必要があります。
    導入の経緯は issue 等に記録する
    撤退可能な状態・最小の規模で導入する
    振り返りを行う
    広く導入したいときは、Frontend Chapter で議論する

v4へのマイグレーション・移行

wantedly/wantedly の v1 スタックのページについてはリノベ・リニューアルのタイミングで積極的に v4 への載せ替えを推奨とします。GraphQL API を用意するのにコストがかかる場合、リノベのようなプロジェクトでバックエンドに大きな手を入れられない等の理由で、 v1 → v4 への直接の移行が難しい場合は v2, v3 を載せることを1次ステップとすることは許容しています。

SSRの位置付け

Wantedly において SSR を導入する1番の目的は SNS でシェアされたときの OG 情報を返すことです。SEO については2021年現在において、Google のクローラーは JS を解釈できることから第一の目的ではないと考えています。したがって、あるページを SSR するかどうかの判断基準の第一は「SNS でシェアされるものかどうか」です。デザインシステムやヘッダなどの共通コンポーネントは SSR されるページで使用される可能性があるので、SSR 前提で開発しておく必要があり、それは最低品質をテスト等でカバーします。

話を聞きに行きたい

もっと知りたい

最終更新 29d ago