Wantedly Engineering Handbook
  • Wantedly Engineering Handbook
  • まえがき
  • 第一部:開発チームへの案内
    • 技術とアーキテクチャ
    • プロダクト概要(未執筆)
    • 開発チームの構造
    • コミュニケーションの全体
    • ドキュメンテーション(未執筆)
    • カレンダー
    • 障害対応の心構え
    • 効率的な社内知識の調べ方
    • 外部発信(執筆中)
  • 第二部:技術領域への案内
    • Apps
      • アプリを提供するプラットフォーム
      • デザインシステム入門
      • Web アプリのアーキテクチャ
      • プロダクトデザイナーと上手に協働するための心得
      • Web アプリのデザインシステムライブラリ
      • Web アプリ共通ライブラリ "React Shared Component" の紹介
      • モバイルアプリのアーキテクチャ
      • モバイルアプリのデザインシステムライブラリ(未執筆)
    • The System
      • protobuf スキーマと gRPC 通信
      • 実践: gRPC in Ruby
      • 実践: gRPC in Go
      • GraphQL Gateway - アプリ向けに API を公開する
      • Wantedly Visit で BFF GraphQL サーバーを辞めた理由
      • 実践: GraphQL スキーマ設計(未執筆)
      • API での認可処理 (Authorization)
      • マイクロサービス共通ライブラリ "servicex" の紹介
      • 非同期メッセージング処理入門(未執筆)
      • バッチ処理入門(未執筆)
    • Infrastructure
      • Infrastructure Squad
      • プロダクト開発のための Kubernetes 入門
      • インフラ構成概要
      • リリース・デプロイ戦略を支える技術
      • SaaS を活用する:New Relic, Honeybadger, Datadog
    • Data
      • データ基盤入門
      • レコメンデーション
      • Looker 入門
      • 推薦システムの開発に使っているツール
    • 開発プロセス
      • Git の慣習
      • ポストモーテムの取り組み
      • 負債返済日の取り組み
      • プロダクトの課題発見及び解決
      • ソフトウェアデザインの基礎
      • コードレビュー
      • コーディング規約
      • リリース・デプロイ戦略
      • 上長承認が必要な作業
      • アーキテクチャディシジョンレコード(ADR)
      • 作業ログを残す意味
      • 多言語化対応(i18n)
      • メール開発
    • 開発ツール
      • 社内利用している開発ツールの最新状況
      • kube
      • Code Coverage
      • Kubefork
  • おわりに
    • ロードマップ(未執筆)
    • Handbook の書き方
    • コントリビューター
  • 付録
    • 社内用語集
    • 主要な GitHub レポジトリのリスト(未執筆)
    • 今後の挑戦・未解決イシュー(未執筆)
    • プロダクト開発組織のバリュー(未執筆)
    • 採用についての考え方(未執筆)
GitBook提供
このページ内
  • 前提知識
  • 全体のアーキテクチャに関しての方針
  • 個別アプリに関して
  • Next.js への移行の背景
  • 個別アプリのアーキテクチャ
  • v4へのマイグレーション・移行
  • SSRの位置付け

役に立ちましたか?

  1. 第二部:技術領域への案内
  2. Apps

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 を作る際にはどちらを採用するか議論と検討を行ってください。

個別アプリに関して

Next.js への移行の背景

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 で議論する

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 前提で開発しておく必要があり、それは最低品質をテスト等でカバーします。

話を聞きに行きたい

もっと知りたい

前へデザインシステム入門次へプロダクトデザイナーと上手に協働するための心得

最終更新 2 年前

役に立ちましたか?

Slack:

#frontend_chapter
Wantedly Visit のウェブフロントエンドの構成の歴史 (internal)
Wantedly のこれからの Frontend Architecture を考える (internal)
Frontend Architecture を考える 2021春 (internal)
Web Frontend Directory structure 2021 秋 (internal)