
## 概要

画面表示の速度を10倍にした際の振り返り

## 背景

サービスの成長に伴いクライアントが増えてきて、データ量も倍々で増えてきており、ある画面の表示速度がかなり遅くなっていた。

ローディング中のまま一向に必要な要素が表示されないという状況。

それにより作業効率が低下しており、課題として顕在化していた。

表示速度はデータ量によってばらつきがあるが、30秒ほど時間がかかっているケースもあった。

## 原因調査

そもそも該当画面でGraphQLのクエリが叩かれまくっていたのとN+1が起きていたので、他のエンジニアがN+1を修正していたが、それでもまだ遅かった。

コードを確認すると、画面表示するために必要なデータを全部取ってくるまでローディングをしていることが分かった。

画面構成要素の一部であるセレクトボックスの選択肢に表示するデータを全件取得しようとしていた。

下記のように`Promise.all`を使っているので、`Promise`が全解決するまでずっとローディング中のままになっていた。

```js
Promise.all([promise1, promise2, promise3]).then((val) => { ... })
```

しかも、ページネーション等も存在しておらず、全てのデータをセレクトボックスの数だけ持ってきてたので、データ量が増えればその分遅くなるという構造になっていた。

## 方針

上述の課題を解決するために下記の方針を立てた。

- 初回の画面表示は行いつつ、セレクトボックス側が描画されたタイミングでレコードを取得する
- 全件取得を避けるためにページネーションを用意

つまり、セレクトボックスの選択肢に必要なレコードは初回描画時に遅延ローディングする。

セレクトボックスごとにレコードを取得することで、APIリクエストを並列化させて全体のリードタイムを抑えつつ、ページネーションを用意して初回取得上限を設ける。

これによりセレクトボックスの選択肢が揃うまで、他の要素の設定（テキストボックス入力など）をしておける状態に持っていける。

&nbsp;

また、特定件数だけ取得して残りはページネーションを用意することで、大量にレコード取得してGraphQLのクエリが何回も発行されることを避けるようにする。（元々全件取得するために無限ローディングしていた）

まとめると、遅延ローディング + デマンドフェッチ。

上記方針で改善を進めていった。

## やったこと

- 描画時にレコードを取得して選択肢を格納するセレクトボックスコンポーネントの作成
  - 以下、遅延ローディングコンポーネント
- セレクトボックスでページネーションを導入
- `Promise.all`を剥がす
- GraphQLを用いた各種APIリクエストの調整

基本的にはセレクトボックスを新規作成して、`Promise.all`を剥がしていった。

### 遅延ローディングコンポーネントの作成

#### ライブラリのバージョンアップグレード

セレクトボックスのコンポーネントは [react-select](https://react-select.com/home) を使っていた。

`react-select`のセレクトボックスを使って遅延ローディングするには、`Async`のpropsを利用する必要があるようだったので、ライブラリのバージョンをアップグレードした。

その上で遅延ローディングのコンポーネントを作成してみたが、関数が発火せずレコードが取得できず調査が難航した。

#### OSSのコードを引っこ抜いて自前で実装

上述した通りうまく作成できなかったので、他のライブラリで実現できないかを調査した。

調査したところ、[react-select-async-pagenate](https://www.npmjs.com/package/react-select-async-paginate)が利用できそうだった。

しかし、リリースノートやタグが切られておらず、破壊的な変更がサイレントで入ってくるリスクがあったので採用できず。

そのため、同ライブラリのコードの中身を引っ張ってきて自前で実装する決断をした。

&nbsp;

https://github.com/vtaits/react-select-async-paginate/blob/52f2e2f0fe99f57bb8536b202ecda409a558b9a5/src/index.jsx

上述のURLは同ライブラリの遅延ローディングの部分であり、クラスコンポーネントで実装されている。

それを関数コンポーネントに直しつつ微調整していった。

最初は難しいかもなと思っていたが、そんなに難しいことはなく初回描画時にAPIリクエストして、stateに詰めているだけなので思ったより簡単。

#### ページネーションを実装

上述したコンポーネントを作成後、そのコンポーネントにページネーションの仕組みを導入した。

リストを最後までスクロールするとGraphQLクエリを発行して次ページを取得するようにした。

加えて、入力値を用いてリスト検索した場合、GraphQLクエリを発行して取得するように実装した。

これにより、無限ローディングを剥がして、デマンドフェッチの仕組みを実装した。

#### 余談

本アプリケーションのフロントエンドはリポジトリパターンで構築されている。

画面描画時の親コンポーネントで必要なデータを取得するために、リポジトリ層を呼び出してレコードを取得している。（ユースケース層を呼び出した方が良いと思うが）

それによって、親コンポーネントのimportがどんどん増えていき、ファイル行数がかなり多くなっており、見通しが悪い状態。700くらいだった。

それが気持ち悪かったので、それを解消するためにレコードを一覧取得する関数だけまとめたファイルを作成して、それをimportする形に変更した。

150くらいファイル行数が減っただけでなく、データ取得の責務をそちらのファイルに分割できた。（神クラスみたいにならないよう運用する際の注意が必要。）

### 小さくデプロイ

コンポーネント自体が完了した後、既存のセレクトボックスを徐々に書き換えるために小さくデプロイをし続けた。

影響範囲を小さく保ち不具合を起こさないようにするため。

全部で20回くらいデプロイしたが、不具合を起こしたのは1回だけだった。（0に抑えたかったが）

### フロントエンドのコンテナがメモリ不足で落ちる問題を解消

開発時にメモリ不足でコンテナが落ちまくっており、~~流石に腹が立って~~ 改善チャンスだったので対応した。

10行くらいファイルを変更して反映を待っていたら、コンテナが`heap out of memory`で毎回落ちていた。

どうやらwebpackがホットリロード時に変更対象ファイルを検知してメモリに載せすぎていたよう。`node_modules`まで検知しようとしていた。

また、webpackのビルド結果をキャッシュするように設定を追加した。

この変更により問題がかなり解消された。

## 結果

レコード数によってまちまちだったが、遅い企業様で画面表示されるまで約25秒かかっていたところを、約1-2秒までに短縮した。

1-2秒は全企業様で固定値だったので、かなり改善できた。

## 開発リードタイムを早めるためにできたこと

- 最初からOSSのコードを参考にする
- コンテナ落ちる問題を早めに対処しておくべきだった
- レビュー会の実施

### 最初からOSSのコードを参考にする

最初は、海外のエンジニアがブログ等に載せているコードを参考に検証を進めていたが、うまく動かなかった。

OSSコードを参考にして検証した方がより確実に動くし早かった。

OSSへの敷居の高さみたいなものを感じていたのと、おそらく自身が読み解くのに面倒さを感じてしまっていた。

カジュアルな内容をもとに簡単に実装できたら良いなという願望のもとに動いていた気がする。

検証段階こそ正確な情報を参照すべきだと痛感した。

### コンテナ落ちる問題を早めに対処しておくべきだった

開発時間の1/4はコンテナ再起動に使っていたかも。

最初は原因がわからずに後回しにしていたが、早い段階から着手しておけばよかった。

本筋以外だとどうしても優先度が下がってしまいがちだが、そこの時間を測ってインパクトを定量化しておくべき。

### レビュー会の実施

20回もデプロイするくらいなのでPR数も多くなっていた。

レビューリードタイムを削減するために、周りを適切に巻き込む必要があった。

ある程度の規模の開発をレビューするとなると、口頭で確認しあうタイミングを設けないとリードタイム削減はしにくいなと感じた。

コンテキストを埋めるのが難しいだけでなく、そこに思考コストがかかるので後回しになりがち。

## まとめ

パフォーマンス改善のタスクってかなり達成感があるのでやっぱり好きだなと感じた。

ただ、この開発を通じて改善点を見つけられたので、今後に活かしていきたい。


画面表示速度を約10倍にした話


## 概要

ReactベースのフルスタックフレームワークのRemixが前から気になっており、公式のチュートリアルを触ってみた感想やその思想を深ぼっていく。

## Remixの思想

[Remix公式](https://remix.run/docs/en/v1/pages/philosophy#philosophy)によるとこのFWは4つの思想をベースとしている。

- サーバー/クライアントモデルを利用（データとコンテンツの分離）
- ブラウザやHTMLなどの基礎技術と協調してく
- JavaScriptを使用してブラウザの動作をエミュレートすることでUX向上
- 基盤技術を過度に抽象化しないこと

[zennで他の方が書かれている](https://zenn.dev/kaa_a_zu/articles/fbd06ca2cc3b86#0.-%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%80%81remix%E3%81%AE%E6%80%9D%E6%83%B3)ように「サーバー/クライアントモデルを利用」に対する説明が他の3つに比べて厚く書かれている印象を受けた。

### 公式doc

[公式doc](https://remix.run/docs/en/v1/pages/philosophy#serverclient-model)の記載によると下記の記載がある。

> With today's web infrastructure you don't need static files to make your server fast. We leveraged distributed systems at the edge instead of static builds. We can fix a typo and the site reflects it within seconds: no rebuilds, no redeploys, not even HTTP caching.

サーバーを早くするために静的ファイルは必要ない。

静的ビルドの代わりにエッジを使って分散システムを構築した。

タイポ修正しても再ビルドや再デプロイ、HTTPキャッシュいらずで数秒のうちにサイトに反映される。とのこと。

つまりSSGの機能は持っておらず、毎度SSRしてコンテンツを返している。

エッジを使った分散システムによりSSRを高速に返すことを実現している。

[Remix公式ブログ](https://remix.run/blog/remix-and-the-edge)に詳細に記載があり、以前のエッジは静的コンテンツの配信だけだったが、最近はDeno deployやCloudflare Workersなど動的コンテンツも返せるようになっている。

Remixはそのエッジコンピューティング技術を利用して任意の場所で高速でコンテンツを返せるようにしているよう。

## QuickStartを触ってみる

Remix公式で紹介されている[QuickStart](https://remix.run/docs/en/v1/tutorials/blog#quickstart)を触ってみる。

[Gitpod](https://www.gitpod.io/)で動作環境を構築したのでローカルで作らなくて済んだ。

便利すぎる。Gitpodは後日記事にしたい。触ってみて分かったことを色々とまとめる。

- routesディレクトリ配下のファイルがroutingになる
- [API routes](https://remix.run/docs/en/v1/guides/api-routes)を作成可能
- Dynamic routes
- ErrorBoundary
- Nested Routes

特に印象深かったのが下記3点

1. API routes
2. Nested Routes
3. ErrorBoundary

### API routes

`.t(j)sx`ファイルでDBからの値取得やfetchなどを行って値を取ってこれる。
特にDBと直接連携して値を簡単に取得できるのは驚いた。
ORMはprismaだった。（prismaをしっかり使ってみたい欲が湧いた。）

### Nested Routes

[Remix公式](https://remix.run/docs/en/v1/guides/routing#what-is-nested-routing)の説明だと、URLのセグメントをUIのコンポーネント階層に一致させる考え方。

下記のgif分かりやすい。

![Nested Routing](/images/nested_routing.gif)

つまりURLのセグメントとコンポーネントが対応しておりそれを1ページで表している形

下記のディレクトリ階層で言うと、`app/root.jsx`をトップとしてその中にroutesディレクトリ配下のコンポーネントがそれぞれ表示されている。

```plaintext
app
├── root.jsx
└── routes
    ├── accounts.jsx
    ├── dashboard.jsx
    ├── expenses.jsx
    ├── index.jsx
    ├── reports.jsx
    ├── sales
    │   ├── customers.jsx
    │   ├── deposits.jsx
    │   ├── index.jsx
    │   ├── invoices
    │   │   ├── $invoiceId.jsx
    │   │   └── index.jsx
    │   ├── invoices.jsx
    │   └── subscriptions.jsx
    └── sales.jsx
```

また`ErrorBoundary`を併用することで1つのコンポーネントがエラーで表示できなくなったとしてもページ全体が表示できないということを防げる。

### ErrorBoundary

コンポーネントのクライアントサイドでのレンダリング時にエラーがあった場合の表示を設定するエラーハンドリング。
＊`CatchBoundary`はレンダリング時にAPIからのfetchやDB更新などでエラーがあった場合にキャッチする。

```javascript
export function ErrorBoundary({ error }: { error: Error }) {
  return (
    <div className="bg-rose-500">
      <div>
        {error.message}
      </div>
    </div>
  );
}
```

QuickStartで使ったソースコードを使って実際にNested Routesと`ErrorBoundary`の動作を確認してみた。

`posts/admin/new`のNested Routesでそれぞれコンポーネントを表示させている。

`Create a New Post`を押すとadminディレクトリ配下の`new.tsx`コンポーネントがレンダリングされる。

その`new.tsx`コンポーネントでエラーが起きた想定で`ErrorBoundary`を利用している。

#### 通常

![Normal](/images/nested_routes_normal.gif)

#### ErrorBoundaryなし

![Without ErrorBoundary](/images/not_boundary.gif)

#### ErrorBoundaryあり

![With ErrorBoundary](/images/boundary.gif)

## まとめ

Nested Routesという概念によりまた一つUX体験を向上させる手段を知れたのでよかった。

Next.jsと違いSSGやISRといった静的ビルドはないけれど、エッジを使ってSSRを高速化しているというところのアーキテクチャの違いが興味深かった。

ちなみこのブログはNext.jsを使って作っておりSSGには日々お世話になっている。

エッジらへんもっと知りたいなと思う。


Remix触ってみた


## 概要

React18リリースがあった関係でWEB DB PRESS vol.129にReactの深層シリーズが掲載されていたので、改めてReactの思想や設計原則などを見直した。

## Reactの特徴

- 宣言的UI
- コンポーネント志向
- 仮想DOM
- 単方向データフロー

の4つが大まかな特徴と捉えている。

### 宣言的UI

UIとして表示する部品をコンポーネントとしてラップして定義した上で、「この場合はこのdivタグを置いて..」みたいな細かい制御ロジックが書かれる命令的UIではなく、あるべき状態を **宣言** したUIを記述する形式。

命令的UIのように画面描写の変化過程を記述するのではなく、結果のみを記述していく。

### 仮想DOM

WEB+DBPRESSに記載のある「宣言的UIでは **状態(state)** と **UI** が明確に分けられており、ユーザーがアプリケーションを使うということはアプリケーションの状態を操作するということであって、**UIというのは現在の状態をユーザーに知らせるための映写装置である** 」部分が印象に残っている。

つまり、命令的UIで扱っていたロジックを状態管理に持ち込むことで、UIは現在の状態を映写するだけという感じ。

状態が変更されて仮想DOMが生成され、実際のDOMとの差分検出を行い、DOMの更新を行う。jQueryなど実際のDOMをいじるのではなく差分検出してDOM構築して一括更新。

mizhiさんの記事がとても勉強になる。[https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766]("https://zenn.dev/mizchi/books/0c55c230f5cc754c38b9/viewer/0c36b7de04ca0e4ed766")

### 単方向データフロー

そして単方向データフロー。
従来のMVCではModelとViewの間に双方向のデータフローが作られる可能性があるので、理解やデバッグが困難。

例えば、Viewが複数Modelのデータ参照/更新を行うことでデータフローが循環する形。これが多くなると複雑度が増す。
そういった背景からFLUXアーキテクチャが登場し、ViewからのイベントがStoreに発行され、Storeが更新されたらViewも更新するという単一のデータフローが構築された。

この記事が参考になる。[https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/]("https://www.infoq.com/jp/news/2014/05/facebook-mvc-flux/")

## Reactのimmutabilityについて

単方向データフローやコンポーネントのカプセル化なども重要だけど、同じくらい、immutabilityの重要性も重要。

[Reactの公式tutorial]("https://ja.reactjs.org/tutorial/tutorial.html#why-immutability-is-important")にもあるけれど、immutabilityが重要な理由として下記3つ挙げられている。

- 複雑な機能が簡単に実装できる
- React自身がオブジェクトの変更を検知しやすくなる
- コンポーネント再描画のタイミングが決定しやすくなる

このブログ記事が参考になる。
[https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/]("https://lyohe.github.io/post/2021-03-17-javascript-nanimo-wakaranai/")

[https://tech.kitchhike.com/entry/react-should-component-update]("https://tech.kitchhike.com/entry/react-should-component-update")

### 内部のロジック

Reactは [shouldComponentUpdate()]("https://ja.reactjs.org/docs/react-component.html#shouldcomponentupdate") という APIを通じてrenderするかを決定している。
その際、コンポーネントに新しいpropsが渡されるもしくは状態(state)が更新されたら呼び出されてbooleanを返す。
trueならばrenderされて、falseならば逆。

内部実装を見てみる。

[https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js]("https://github.com/facebook/react/blob/v18.2.0/packages/react-devtools-shared/src/node_modules/react-window/src/shouldComponentUpdate.js")

```javascript
// @flow

import areEqual from './areEqual';
import shallowDiffers from './shallowDiffers';

// Custom shouldComponentUpdate for class components.
// It knows to compare individual style props and ignore the wrapper object.
// See https://reactjs.org/docs/react-component.html#shouldcomponentupdate
export default function shouldComponentUpdate(
  nextProps: Object,
  nextState: Object,
): boolean {
  return (
    !areEqual(this.props, nextProps) || shallowDiffers(this.state, nextState)
  );
}
```

内部的には areEqualもしくはshallowDiffers 関数を呼んでいることがわかる。

areEqual内部でもshallowDiffers関数を呼んでいるので、実質shallowDiffersの中身がstate or propsの変更を検知するロジックになっていそう。
shallowDiffersの中身を見てみる。

[https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5]("https://github.com/facebook/react/blob/12adaffef7105e2714f82651ea51936c563fe15c/packages/react-devtools-shared/src/node_modules/react-window/src/shallowDiffers.js#L5")

```javascript
// @flow

// Pulled from react-compat
// https://github.com/developit/preact-compat/blob/7c5de00e7c85e2ffd011bf3af02899b63f699d3a/src/index.js#L349
export default function shallowDiffers(prev: Object, next: Object): boolean {
  for (let attribute in prev) {
    if (!(attribute in next)) {
      return true;
    }
  }
  for (let attribute in next) {
    if (prev[attribute] !== next[attribute]) {
      return true;
    }
  }
  return false;
}
```

やっていることはシンプルで

- 1つ目のfor文で変更前と変更後のstate or propsを比較して新しい要素が追加されたのかを確認
- 2つ目のfor文で変更前と変更後のstate or propsで指定されたkeyの値が一致するのかを確認

をやっている。
ここから分かることは、**propsやstateをmutableに変更してしまったら再renderされない可能性がある** ということ。

JSでは、プリミティブではないオブジェクトと配列だけがmutableなので、そういったstateやpropsを更新する時はimmutabilityを担保する必要がある。

[https://developer.mozilla.org/ja/docs/Glossary/Mutable]("https://developer.mozilla.org/ja/docs/Glossary/Mutable")
Object.assign()やスプレッド演算子などを利用してimmutableに更新する。

＊どちらもshallow copyなので1階層しかコピーされないことに注意。ディープコピーを行うには、オブジェクトをJSON.stringify()でJSON文字列化して、それをJSON.parse()でオブジェクトとして復元する方法やloadashなどのライブラリを利用する形になる。

## パフォーマンスチューニングについて

Reactのパフォーマンスはいかに再レンダリングを防ぐかに焦点が置かれている気がする。

あるコンポーネントがレンダリングされると子コンポーネントもレンダリングされるので、コンポーネントの数が多かったりAPIからデータフェッチする関数が多かったりするとかなりコストがかかる処理となる。

この記事がとても参考になる。[https://blog.ojisan.io/react-re-render-history/]("https://blog.ojisan.io/react-re-render-history/")

### shouldComponentUpdate()のオーバーライドとPureComponent

前節で出てきたshouldComponentUpdate()のAPIは再レンダリングを防ぐために利用されていた場合も多かったよう。

クラスコンポーネント時代は、shouldComponentUpdate()を各コンポーネントでオーバーライドしてレンダリングのタイミングを調整することで、不要なレンダリングを防いでいた。

それか、[PureComponent]("https://ja.reactjs.org/docs/react-api.html#reactpurecomponent")を利用して新旧propsとstateを浅く比較して変更がなければレンダリングしないようにするか。

### hooksでのReact.memoとuseMemo useCallback

PureComponentと同じく新旧propsで浅い比較が行われる形。

```tsx
const Component = React.memo((props) => {
  return <div>{props.value}</div>;
});
```

useMemoは変数のメモ化をするhooksAPI。変数を作るコストが高いときに有効。

```tsx
const memo = () =>
  useMemo(() => {
    createVal();
  }, [val]);
```

useCallbackは第二引数の依存配列に渡した要素が更新されたら実行される。

```tsx
const memo = () =>
  useCallback(() => {
    doSomething();
  }, [val]);
```

## まとめ

stateとpropsのimmutableはしっかり意識しようということ。
パフォーマンスチューニングの話はもうちょっと深掘りたい。


Kdevlog

画面表示速度を約10倍にした話

Remix触ってみた

React基本概念の整理