Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs

Next.js でリアーキテクトした話
JSConf JP 2021 @Takepepe

View Slide

吉井健文 / Takepepe
株式会社リクルート
横断エンジニアリング部 APソリューショングループ
フロントエンドエンジニア・アーキテクト

View Slide

リクルートでの働き方
横断組織の一員として、
社内事業ソフトウェア開発・技術支援をしています。
主に、得意なフロントエンド開発で携わっています。

View Slide

これまでの働き方
【新規立ち上げプロジェクト】
■ 最適な技術スタックをメンバーと選定し、フルスクラッチ
【リアーキテクトプロジェクト】
■ 既存 MPA（Template-Engine）を FE / BE に分離するプロジェクト

View Slide

これまでの働き方
【新規立ち上げプロジェクト】
■ 最適な技術スタックをメンバーと選定し、フルスクラッチ
【リアーキテクトプロジェクト】
■ 既存 MPA（Template-Engine）を FE / BE に分離するプロジェクト
「開発体制構築・開発フロー構築」をした話

View Slide

フロントエンド技術スタック
■ Next.js
■ CSS Modules
■ SWR
■ OpenAPI Generator
■ MSW
■ Storybook
■ reg-suit
■ jest
■ testing-library
■ Cypress

View Slide

Next.js 選定基準
■ ページ分割による最適化など、パフォーマンス面でメリットを得やすい
■ 数あるアプローチの中から、要件に適合したものを選べる
■ SSR / ISR / SSG など、組み合わせが自在（AMP の実績も）
社内ナレッジも蓄積されてきている

View Slide

アーキテクチャ構成
■ Node.js プロセスは稼働しない
■ Static Generation による full CSR
■ Web Server は Nginx
API Server
Next.js
SSG + CSR
Nginx

View Slide

API 検討
■ BFF として機能する API サーバー
■ BFF 開発はバックエンドチームが担当
■ FE 観点から、適した API を提案
■ Component 境界 = API 境界 = タスク境界
画面単位（Component単位）がタスク境界としても適切な粒度だった

View Slide

プロジェクト課題整理
【1】リリース済み内容をリグレッションさせないこと
【2】React 開発に慣れたメンバーがアサインできるとは限らないこと
【3】フロントエンドエンジニアが先行して OpenAPI を定義する必要がある
【4】10人並列でも開発可能な体制をつくること

View Slide

【課題１】
リリース済み内容を
リグレッションさせないこと

View Slide

リリース済み内容に沿った、マークアップの再現について。
再現するプロジェクトの CSS は BEM で書かれていました。
（全体的に綺麗に設計されている良い設計）
BEM の Block は Component 単位として扱うことができるため、
CSS 定義から遡り、Component へ書き換えを進めました。
React Component への書き換え
【課題１】リリース済み内容をリグレッションさせないこと

View Slide

書き換え前のマークアップ
.breadcrumb {
display: flex;
&__item {
padding-left: 24px;
}
&--mb0 {
margin-bottom: 0;
}
}

View Slide

書き換え後の React Component
// Block はアッパーキャメル変換し、そのまま Component名称とする
function Breadcrumb(props) {
return
}
// Element は Block 接頭辞をもった Component名称とする
function BreadcrumbItem(props) {
return
}
function MyComponent() {
return (

)
}
.breadcrumb {
display: flex;
}
.item {
padding-left: 24px;
&[data-mb0] {
margin-bottom: 0;
}
}

View Slide

書き換えのマッピングコスト
元の CSS 設計が整備されていたこともあり、
スムーズに書き換えを行うことができました。
■ CSS Modules に BEM 定義を移植
■ 命名は変更せず、Case 変換し Component 名称とした
■ Modifier を data 属性に変換した
■ class 名から Component (Atom) の特定が容易

View Slide

元の CSS 設計が整備されていたこともあり、
スムーズに書き換えを行うことができました。
■ CSS Modules に BEM 定義を移植
■ 命名は変更せず、Case 変換し Component 名称とした
■ Modifier を data 属性に変換した
■ class 名から Component (Atom) の特定が容易
探しやすく、マッピングコストが最小限。再現性の高い書き換えに

View Slide

CSS 定義の削除
.alert-text {
color: $col-accent;
}
.annotation {
font-size: 1rem;
}
.nodata {
display: block;
text-align: center;
}
最後まで残った、
使われているか不明な Global 定義。

View Slide

CSS 定義の削除
最後まで残った、
使われているか不明な Global 定義。
この定義削除にあたり、
Visual Regression Testing を活用。
.alert-text {
color: $col-accent;
}
.annotation {
font-size: 1rem;
}
.nodata {
display: block;
text-align: center;
}

View Slide

■ 書き換えのタイミングで、Storybook をコミットしていた
■ リグレッションに備え、reg-suit を導入していた
■ CSS に対し、積極的なリファクタリングが行えた

View Slide

■ 書き換えのタイミングで、Storybook をコミットしていた
■ リグレッションに備え、reg-suit を導入していた
■ CSS に対し、積極的なリファクタリングが行えた
Storybook は開発軸だけでなく、テスト戦略としても必須

View Slide

■ 現在、CSS ソリューションはかつてないほど乱立
■ 異なる CSS ソリューション間で移植しやすい定義かどうか
■ 特定の CSS ソリューションでしか実現できない内容ではないか
次世代のリアーキテクトに向けて

View Slide

■ 現在、CSS ソリューションはかつてないほど乱立
■ 異なる CSS ソリューション間で移植しやすい定義かどうか
■ 特定の CSS ソリューションでしか実現できない内容ではないか
次世代のリアーキテクトに向けて
CSSソリューションは、次世代のマッピングコストも配慮して

View Slide

【課題２】
React 開発に慣れたメンバーが
アサインできるとは限らないこと

View Slide

まだ React は「誰でも書ける」まで至っていません。
初学者であっても、参画しやすいコードベースを目指しました。
■ 見様見真似でも、ある程度実装できる
■ 学習しながらでも、開発に参画できる
■ つまづきやすいポイント・そうではないポイントが分離されている
初学者でも参画しやすいコードベースを目指して
【課題２】 React 開発に慣れたメンバーがアサインできるとは限らないこと

View Slide

初学者でも参画しやすいコードベースを目指して
まだ React は「誰でも書ける」まで至っていません。
初学者であっても、参画しやすいコードベースを目指しました。
■ 見様見真似でも、ある程度実装できる
■ 学習しながらでも、開発に参画できる
■ つまづきやすいポイント・そうではないポイントが分離されている
コードベースの理解しやすさは、学習曲線に影響する

View Slide

■ 【易】Component 構築 → マークアップの延長線
■ 【易】型定義で縛って、Props を渡す
■ 【難】込み入った hooks の記述
■ 【難】React Context Provider の設計
React 初学者でも習得しやすい点

View Slide

React 初学者が習得し辛い点

View Slide

React 初学者が習得し辛い点
Custom Hooks の整備に着手

View Slide

Custom Hooks でコードベースを標準化
export function useMyComponent() {
const { openModal } = useModal();
const handleClick = () => {
openModal({ contentsNode: });
};
}
モーダルを表示する Custom Hooks

View Slide

const { openAlertDialog } = useAlertDialog();
openAlertDialog({
text: "エラーが発生しました ",
buttonLabel: "OK",
});
}
}
ダイアログを表示する Custom Hooks

View Slide

const { showNotification } = useNotification();
showNotification("削除しました");
}
}
ノティフィケーションを表示する Custom Hooks

View Slide

const {
errorMessages,
handleErrorWithErrorMessages,
} = useHandleErrorWithErrorMessage();
const { execFetch } = useFetcher(async () => {
try { ... } catch (err) {
handleErrorWithErrorMessages(err);
}
});
}
エラーハンドリングを集約した Custom Hooks

View Slide

const {
validationErrors,
handleValidationErrorsWithAlertDialog,
} = useHandleValidationErrorsWithAlertDialog();
const { execFetch } = useFetcher(async () => {
try { ... } catch (err) {
handleValidationErrorsWithAlertDialog(err);
}
});
}
エラーハンドリング・Component 表示を兼ねた Custom Hooks

View Slide

■ 多くの画面で処理を共通化できた
■ 見様見真似でも Component 作成が可能に
■ 画面毎の考察ポイントは、画面固有のロジック実装のみ
Custom Hooks でコードベースを標準化することができた

View Slide

【課題３】
フロントエンドエンジニアが先行して
OpenAPI を定義する必要がある

View Slide

OpenAPI でバックエンドとフロントエンドの齟齬をなくす
■ Component を起点として API を考える
■ フロントエンドエンジニアが OpenAPI を書く
スキーマ駆動開発
【課題３】フロントエンドエンジニアが先行して OpenAPI を定義する必要がある

View Slide

API 定義が予め決まっている通常の開発フローとは「逆」

View Slide

OpenAPI 定義に慣れている開発メンバーは少数。定義のしやすさが課題に

View Slide

OpenAPI 定義への取り組み
ー User 編集モーダルを作る例ー

View Slide

API スキーマの考察
Component を組み上げ、API に求めるデータを考える
export type ServerProps = {
};
export const ModalEditUser: React.VFC = (props) => {
return (

);
};

View Slide

id: string;
firstName?: string;
lastName?: string;
};
return (

送信

);
};

View Slide

MSW でモックを書き、Component が成立するか検討
export const handlers = [
rest.get("/path/to/api", (_, res, ctx) => {
return res(
ctx.json({}));
}),
];

View Slide

MSW でモックを書き、Component が成立するか検討
return res(
ctx.json({
id: "xxxx",
firstName: "taro",
lastName: "yamada",
}));
}),
];

View Slide

更新系のメソッドも、モックが記述可能
return res(
ctx.json({
id: "xxxx",
firstName: "taro",
lastName: "yamada",
}));
}),
];
rest.put("/path/to/api", (req, res, ctx) => {
return res(ctx.json({ statusCode: 200 }));
}),
];

View Slide

要件定義とすりあわせ、考慮漏れの洗い出し
return res(
ctx.json({
id: "xxxx",
firstName: "taro",
lastName: "yamada",
}));
}),
];
rest.put>("/path/to/api", (req, res, ctx) => {
}),
];

View Slide

要件定義とすりあわせ、考慮漏れの洗い出し
return res(
ctx.json({
id: "xxxx",
firstName: "taro",
lastName: "yamada",
}));
}),
];
if (req.body.id) {
}
return res(
ctx.status(400),
ctx.json({ statusCode: 400, errorMessages: ["不正なリクエストです"] })
);
}),
];

View Slide

API スキーマ考察の軸となった
return res(
ctx.json({
id: "xxxx",
firstName: "taro",
lastName: "yamada",
}));
}),
];
if (req.body.id) {
}
return res(
ctx.status(400),
ctx.json({ statusCode: 400, errorMessages: ["不正なリクエストです"] })
);
}),
];

View Slide

Stoplight Studio を使う
Open API 定義にあたり、
チーム内標準ツールとして
Stoplight Studio を使用。
MSW のレスポンスから、
サンプル JSON を取得。

View Slide

Stoplight Studio には、
JSON から OpenAPI 定義を
Generateできる機能がある。
この機能を使い、
OpenAPI 定義の工数を削減。

View Slide

不足している定義を追加し、
description に詳細を記載。
レビューコミュニケーションに
役立てた。

View Slide

$ npm run openapi:gen
書き上がった OpenAPI から、 fetch client を生成
#########################################
# Thanks for using OpenAPI Generator. #
# Please consider donation to help us maintain this project 🙏 #
# https://opencollective.com/openapi_generator/donate #
#########################################

View Slide

fetch client を、 Component にバインド
export const ModalEditUserBase: React.VFC = (props) => {
return (

送信

);
};
export const ModalEditUser: React.VFC = () => {
const { data, error } = useSWR(
"/path/to/api",
get("path/to/api")
);
if (error) return ;
if (!data) return <>loading...>;
return ;
};

View Slide

return (

送信

);
};
"/path/to/api",
organismsApi.organismsModalEditUserGet()
);
if (error) return ;
return ;
};
fetch client を、 Component にバインド

View Slide

この段階で期待値と、OpenAPI 定義に齟齬があれば気付く（型推論あわせ）
return (

送信

);
};
"/path/to/api",
organismsApi.organismsModalEditUserGet()
);
if (error) return ;
return ;
};

View Slide

■ 確度の高い状態で、バックエンド担当にレビュー依頼
■ レビューで受けた指摘のもと、OpenAPI 定義を修正
■ 修正内容を伝搬させるため、fetch client を再生成
■ 影響箇所を TypeScript のコンパイルエラーで検知

View Slide

■ 確度の高い状態で、バックエンド担当にレビュー依頼
■ レビューで受けた指摘のもと、OpenAPI 定義を修正
■ 修正内容を伝搬させるため、fetch client を再生成
■ 影響箇所を TypeScript のコンパイルエラーで検知
OpenAPI と Component の疎通齟齬が TypeScript で担保された

View Slide

【課題４】
10人並列でも開発可能な体制を
つくること

View Slide

課題「１２３」の取り組みでコードベースの標準化が整う
✅ 課題１：マークアップから Component への確実なマッピング
✅ 課題２：React Component の一律な実装
✅ 課題３：OpenAPI 定義検討のフロー
増員とチームビルディング
【課題４】10人並列でも開発可能な体制をつくること

View Slide

量産フェーズに入り、大人数での並列開発が開始
■ 2人 → 5人 → 10人と、1ヶ月間隔でメンバーが倍増
■ 新規メンバー受入を兼ねながら進行
■ 並行して開発可能な体制を整える

View Slide

量産フェーズに入り、大人数での並列開発が開始
■ 2人 → 5人 → 10人と、1ヶ月間隔でメンバーが倍増
■ 新規メンバー受入を兼ねながら進行
■ 並行して開発可能な体制を整える
スムーズな増員計画を念頭に

View Slide

定型処理の自動化

View Slide

hygen による定型出力
大人数での並列開発は、lint・formatter だけでは
防げないガイドライン違反が起こりえます。
また、管理上 OpenAPI と Component の
命名規則・書式を一律にする必要性がありました。
そこで活用したのが「hygen」です。

View Slide

$ npm run new:swrfc
> [email protected] new:swrfc
> hygen new swrfc
✔ What is the name of component? ·
npm scripts に hygen のエントリーポイントを登録

View Slide

$ npm run new:swrfc
> hygen new swrfc
✔ What is the name of component? · ModalEditUser
CLI に Component 名称を入力すると…

View Slide

$ npm run new:swrfc
> hygen new swrfc
Loaded templates: .hygen
added: src/components/organisms/ModalEditUser/apis.mock.ts
added: src/components/organisms/ModalEditUser/ModalEditUser.stories.tsx
added: src/components/organisms/ModalEditUser/ModalEditUser.test.tsx
added: src/components/organisms/ModalEditUser/ModalEditUser.tsx
added: src/components/organisms/ModalEditUser/index.tsx
added: /Users/Me/openapi/src/paths/organisms/modal_edit_user.yaml
added: src/components/organisms/ModalEditUser/styles.module.scss
Component 命名に沿ったファイル群が出力される

View Slide

$ npm run new:swrfc
> hygen new swrfc
React Component に必要なファイル群と…

View Slide

$ npm run new:swrfc
> hygen new swrfc
OpenAPI 定義の雛形・MSW ハンドラーも同時に自動生成

View Slide

ModalEditUser.tsx
const { data, error } = useSWR(apiPath(), () => get(apiPath()));
if (error) return ;
return ;
};
ファイル命名ミスがなく、コンポーネント書式も一律に

View Slide

ModalEditUser.stories.tsx
const defaultArgs: Props = { ...data };
const Template: Story = (args) => (

);
export const Index: Story = Template.bind({});
Index.args = {};
export default {
title: "organisms/ModalEditUser",
} as Meta;
Storybook の雛形ファイルも同時に生成

View Slide

describe("organisms/ModalEditUser", () => {
describe("異常系レスポンスの表示", () => {
describe("エラーレスポンスが返ってきた時", () => {
test.skip("エラーが表示される", async () => {});
});
});
describe("正常系レスポンスの表示", () => {
describe("正常レスポンスが返ってきた時", () => {
test.skip("コンテンツが表示される", async () => {});
});
});
});
ModalEditUser.test.tsx
テストの雛形ファイルも同時に生成

View Slide

modal_edit_user.yaml
post:
summary: XXX::画面名称::POST
description: 画面概要
operationId: OrganismsModalEditUserPost
tags:
- Organisms
responses:
'201':
description: Created
content:
application/json:
schema:
$ref: ../../components/common_201.yaml
'400':
description: Bad Request
content:
application/json:
schema:
'403':
description: Forbidden
content:
application/json:
schema:
Component に紐づいた Open API の雛形ファイルも同時に生成
openapi: 3.0.0
info:
title: XXX::画面名称
version: '1.0'
servers:
- url: http://localhost:8080
description: development
paths:
/organisms/modal_edit_user:
get:
summary: XXX::画面名称::GET
description: 画面概要
operationId: OrganismsModalEditUserGet
tags:
- Organisms
responses:
'200':
description: OK
content:
application/json:
schema:

View Slide

コード標準化・定型作業の自動化にあわせ「タスク標準化」にも着手
■ 「定型的な工程・非定型的な工程」を分離
■ 「レビュー依頼先・レビュー観点」を分離

View Slide

大人数での開発が本格化する前に、ばらつきが出ない「標準化」を徹底した
コード標準化・定型作業の自動化にあわせ「タスク標準化」にも着手
■ 「定型的な工程・非定型的な工程」を分離
■ 「レビュー依頼先・レビュー観点」を分離

View Slide

分離された５段階タスク
１画面あたり、５段階に分離されたタスク
Scaffold
生成
Component
構築
API 考察
接続
OpenAPI
定義
テスト拡充
1画面

View Slide

分離された５段階タスク
PR 単位も一律になるため、差分・レビュー観点が一律に
Scaffold
生成
Component
構築
API 考察
接続
OpenAPI
定義
テスト拡充
1画面

View Slide

新規メンバー受け入れと、複数人並列開発を実現した要因
■ 参画ハードルが低く、標準化されたコードベース
■ タスク境界が分離されているため、閉じた影響範囲で作業が完遂できる
■ 完了した類似タスク範例があるため、作業内容の認知負荷が低い
API とComponentが結合している設計
メンバーからも「開発しやすい」と評価

View Slide

新規メンバー受け入れと、複数人並列開発を実現した要因
■ 参画ハードルが低く、標準化されたコードベース
■ タスク境界が分離されているため、閉じた影響範囲で作業が完遂できる
■ 完了した類似タスク範例があるため、作業内容の認知負荷が低い
API とComponentが結合している設計
【成果】マイルストンから６週間前倒して開発完了

View Slide

設計と開発フローは不可分であり、
「継続的チームビルディングの基礎となる」
という事を実感できた案件でした

View Slide

ー　ご清聴ありがとうございました　ー

View Slide

Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs

Next.js でリアーキテクトした話 / story-of-re-architect-with-nextjs

Takepepe

More Decks by Takepepe

Other Decks in Technology

Featured

Transcript