
## 概要

スケーラビリティの高い API サーバを作成しました。Twitter のような SNS です。記事の日本語版は Zenn、英語版は dev.to に投稿してあります。

<a href="https://zenn.dev/higashimura/articles/74c6e6bf63a133" data-embedded="preview" >1000 万ユーザに耐えるサーバを作ってみた</a>

<a href="https://dev.to/koukikitamura/server-can-handle-10-million-users-10h8" data-embedded="preview" >Server can handle 10 million users</a>

## どうして Zenn に投稿したの?

先日、Zenn の公式 Twitter で職場の同僚の記事がピックアップされているのを見つけました。とても良い記事で、リアクションをたくさんもらってすごいかったです。同僚の影響を受けて、私も Zenn に記事を投稿することにしました。

## あとがき

無事にピックアップしていただき、はてブのテクノロジーの人気エントリーにも載りました。また、著名なエンジニアの方々にも取りあげていただきました。

<img src="/images/blogs/post-zenn/tweet.png" alt="" width="500" height="740"/>


Zennに記事を投稿してみた


現在所属している会社の[テックブログ](https://medium.com/micin-developers)に記事を 2 つ投稿しました。社外のエンジニアの方にも役に立つ内容だと思ったので書きました。

## 1 つ目の記事

1 つ目の記事は、ビデオ通話サーバのリアーキテクチャです。システムの成長と組織体制の変更により、アーキテクチャが適切でなくなったのでアーキテクチャの変更をしました

<a href="https://medium.com/micin-developers/video-call-rearchitecture-62dca4250fd4" data-embedded="preview" >ビデオ通話サーバのリアーキテクチャ</a>

## 2 つ目の記事

2 つ目の記事は新規開発のシステム設計と技術選定です。昨年に、テックリードとしてた携わった新規開発で考えたことを書きました。ライブラリやフレームワーク等の特定の領域に関する技術選定の記事はよく見かけますが、包括的な技術選定の記事は見かけないので書きました。新規開発を初めて行う方にはきっと役立つと思います。

<a href="https://medium.com/micin-developers/system-design-and-tech-selection-a69a7a0fa49b" data-embedded="preview" >新規開発の技術選定</a>

## 最後に

他にもおもしろいトピックはあるので、時間がある時に少しずつアウトプットしていきます。


会社のブログを更新


## 概要

この記事では現実世界のシステムが扱うデータ量がどれくらいなのかを見ていきます。次のトピックを扱います。

- Web サイトのデータサイズ
- ファイルのサイズ
- ハードウェアのキャパシティ
- 世界的なサービスのデータボリューム

## 導入

現在アプリケーションは世界中の人々に使われています。世界中で使われているアプリケーションは次のような特徴があります。

- ユーザ数が数百万
- データ量がペタバイトからエクサバイト(TB-EB)
- パフォーマンスは ms から μs
- 毎秒数百万リクエスト

これらに耐えるシステムを設計するには、データ量への理解は欠かせません。さまざまの物のデータ量に触れることで、感覚を身につけていきましょう。

## データサイズの単位

データサイズは単位は byte です。現在では 1byte は 8bit と定義されています。

データサイズは扱う桁数が大きいので接頭辞をつけて桁数を省略します。国際単位系(SI)では接頭辞は次のようになっています。

| Symbol | Name   | Factor | Power | JP     | EN          |
| :----- | :----- | :----- | :---- | :----- | :---------- |
| k      | キロ   | 10^3   | 10^3  | 千     | thousand    |
| M      | メガ   | 10^3k  | 10^6  | 百万   | million     |
| G      | ギガ   | 10^3M  | 10^9  | 十億   | billion     |
| T      | テラ   | 10^3G  | 10^12 | 一兆   | trillion    |
| P      | ペタ   | 10^3T  | 10^15 | 千兆   | quadrillion |
| E      | エクサ | 10^3P  | 10^18 | 100 京 | quintillion |

一方、 データサイズ の接頭辞は次のようになります。

| Symbol | Name         | Factor |
| :----- | :----------- | :----- |
| B      | バイト       | 8bit   |
| KB     | キロバイト   | 1024B  |
| MB     | メガバイト   | 1024KB |
| GB     | ギガバイト   | 1024MB |
| TB     | テラバイト   | 1024GB |
| PB     | ペタバイト   | 1024TB |
| EB     | エクサバイト | 1024PB |

データは 2 進数として扱われているため 接頭辞は 1000 ごとではなく 2 の 8 乗である 1024 ごとになっています。国際単位系とは区別して KB ではなく KiB とする記法もありますが本記事では KB に統一します。

## Web サイトのデータサイズ

[Page Weight](https://httparchive.org/reports/page-weight)によると、Web サイトの構成要素のデータサイズは次のようになります。集計の対象期間は 2017/1 ~ 2022/1 で、対象はモバイルサイトです。

| Name       | Size    |
| :--------- | :------ |
| Total      | 1.96MB  |
| HTML       | 31.4KB  |
| CSS        | 68.9KB  |
| JavaScript | 452KB   |
| Font       | 119KB   |
| Image      | 956KB   |
| Video      | 2.07 MB |

1 ページあたりの合計サイズであってファイル 1 つあたりのサイズでないことの注意してください。JavaScript のサイズが想像より大きいと感じる人もいるかもしれません。JavaScript のサイズが大きくなる原因としては、フレームワークやライブラリのような外部パッケージのコードも含まれるためです。

## ファイルのサイズ

ファイルの内容によってサイズは異なるので参考程度にしてください。サイズとフォーマットは参照元から適宜変換しています。またファイルフォーマットの良し悪しを比較する物ではありません。ファイルの特徴によって適切なファイルフォーマットが異なるからです。

| Name                                         | Size   | cf.                                                        |
| :------------------------------------------- | :----- | :--------------------------------------------------------- |
| Image - small JPG (size 320 x 320)           | 21.0KB | https://www.instagram.com/p/CZZyelKpmYf/                   |
| Image - small PNG (size 320 x 320)           | 137KB  | https://www.instagram.com/p/CZZyelKpmYf/                   |
| Image - small WebP (size 320 x 320)          | 16KB   | https://www.instagram.com/p/CZZyelKpmYf/                   |
| Image - large JPG (size 1036 x 1036)         | 187KB  | https://www.instagram.com/p/CVoHltuF7_e/                   |
| Image - large PNG (size 1036 x 1036)         | 1.38MB | https://www.instagram.com/p/CVoHltuF7_e/                   |
| Image - large WebP (size 1036 x 1036)        | 148KB  | https://www.instagram.com/p/CVoHltuF7_e/                   |
| Audio - music MP3 (playback time 3:01)       | 5.80MB | https://pixabay.com/music/beats-dont-you-think-lose-16073/ |
| Movie - short MP4 720p (playback time 0:09)  | 851KB  | https://www.youtube.com/shorts/Wm3F8kF9WAE                 |
| Movie - short WebM 720p (playback time 0:09) | 1.10MB | https://www.youtube.com/shorts/Wm3F8kF9WAE                 |
| Movie - short GIF 720p (playback time 0:09)  | 3.50MB | https://www.youtube.com/shorts/Wm3F8kF9WAE                 |
| Document - PDF (4 pages)                     | 150KB  | -                                                          |
| Document - DOC (4 pages)                     | 100KB  | -                                                          |
| Document - XLSX (1000 rows)                  | 140KB  | -                                                          |
| Document - PPT (3 pages)                     | 248KB  | -                                                          |
| Application - Firefox 97.0.1 (Mac)           | 364MB  | https://www.google.com/chrome/                             |
| Application - Discord 0.0.265 (Mac)          | 193MB  | https://discord.com/                                       |
| Application - Zoom 5.1.1 (Mac)               | 52.5MB | https://zoom.us/                                           |
| Application - Xcode 13.2.1 (Mac)             | 32.1GB | https://developer.apple.com/xcode/                         |

## ハードウェアのキャパシティ

ハードウェアのメモリとストレージのデータサイズです。規格がないものに関しては目安を示しています。

| Name                                   | Size           |
| :------------------------------------- | :------------- |
| Memory - AWS EC2 instance t2.micro     | 1GB            |
| Memory - AWS EC2 instance T2           | 0.5GB ~ 32GB   |
| Memory - AWS EC2 instance M5           | 5GB ~ 384GB    |
| Memory - MacBook Pro 13 inch 2020      | 8GB ~ 16GB     |
| Memory - MacBook Pro 14 inch 2021      | 16GB ~ 64GB    |
| Memory - iPhone (1st generation)       | 128MB          |
| Memory - iPhone (13 Pro max)           | 6GB            |
| Storage - AWS EBS Provisioned HDD      | 125GB ~ 16TB   |
| Storage - AWS EBS Provisioned IOPS SSD | 4GB ~ 16TB     |
| Storage - AWS RDS SSD                  | 20GB ~ 64TB    |
| Storage - MacBook Pro 13 inch 2020 SSD | 256GB ~ 2TB    |
| Storage - MacBook Pro 14 inch 2021 SSD | 1TB ~ 8TB      |
| Storage - iPhone (1st generation)      | 4 ~ 16GB       |
| Storage - iPhone (13 Pro max)          | 128GB ~ 1TB    |
| Storage - Floppy Disk                  | 720KB ~ 1.44MB |
| Storage - Compact Disk                 | 650 ~ 700MB    |
| Storage - DVD                          | 4.7GB ~ 8.5GB  |
| Storage - Blu-ray                      | 25GB ~ 128GB   |
| Storage - USB memory                   | 32GB ~ 256GB   |

## 世界的なサービスのデータボリューム

[Data Never Sleeps](https://www.domo.com/learn/infographic/data-never-sleeps-9)によると実際のアプリケーションで作成されているデータは次のようになります。

| Name            | Volume per second | Volume per minute | Volume per day   | Volume per year    |
| :-------------- | :---------------- | :---------------- | :--------------- | ------------------ |
| Twitter tweet   | 9.58K tweet/sec   | 575K tweet/min    | 828M tweet/day   | 302G tweet/year    |
| Instagram photo | 1.08K photo/sec   | 65K photo/min     | 93.6M photo/day  | 34.2G photo/year   |
| Slack message   | 2.47K message/sec | 148K message/min  | 213M message/day | 77.8G message/year |

次はバイト単位でみてみます。Twitter の 1 tweet を 100 文字かつ一文字は 1 バイトをします。そうすると 1tweet は 0.1KB になります。Instagram の 1photo は 0.1MB とします。Slack の 1 message は 50 文字かつ一文字を 1 バイトとします。そうすると 1message は 0.05KB となります。これらのことを踏まえると 1 年間で増えるデータ量は次のようになります。

| Name            | Size per year |
| :-------------- | :------------ |
| Twitter tweet   | 30.2TB/year   |
| Instagram photo | 3.42PB/year   |
| Slack message   | 3.89TB/year   |

1 年間サービスを運用するとテラバイト以上のデータが蓄積されていきます。これほどのデータ量を 1 つのサーバに保存するのは難しいので、データベースのパーティションを行う必要があります。

## 余談

データ量ではなく、どれくらいのユーザがサービスを使っているかを見てみます。[statista](https://www.statista.com/)によると、世界の有名サービスの月間ユーザ数は次のようになっています。

| Name               | The number of users |
| :----------------- | :------------------ |
| Facebook           | 2.91G               |
| Youtube            | 2.56G               |
| Instagram          | 1.48G               |
| TikTok             | 1.00G               |
| Facebook Messenger | 998M                |
| Twitter            | 444M                |

2021 年の世界人口は 78.7 億人なので、Facebook は世界人口の 40%近くが使っていることになります。

また、国内の有名サービスは次のようになっています。

| Name                       | The number of users | cf.                                                                                                            |
| :------------------------- | :------------------ | :------------------------------------------------------------------------------------------------------------- |
| LINE(月間利用者数)         | 86.0M               | https://www.linebiz.com/sites/default/files/media/jp/download/LINE%20Business%20Guide_202101-06_summary_v1.pdf |
| note(月間アクティブユーザ) | 63.0M               | https://note.jp/n/n705929417079                                                                                |
| PayPay(登録ユーザ数)       | 40.0M               | https://about.paypay.ne.jp/pr/20210617/01/                                                                     |
| メルカリ(月間利用者数)     | 20.0M               | https://about.mercari.com/press/news/articles/20211005_20millionmau/                                           |

2021 の日本の人口は 1.26 億人なので、日本人の 60%が LINE を使っていることになります。


データサイズのリアル


## AWS Dev Day とは

AWS Dev Day とは AWS が毎年秋に開催するソフトウェア開発者けの日本最大級のカンファレンスです。 2021 年はサーバレス、コンテナ、フロントエンド開発、機械学習のコンテンツを中心に 3 日間開催されました。2021 の AWS Dev Day 年は 2020 年と同様にオンライン開催でした。

<div>
  <a href="https://aws.amazon.com/jp/about-aws/events/2021/devday" data-embedded="preview" >AWS Dev Day 2020</a>
</div>

## 何を話したのか

登壇は 最終日のクロージングセッションでした。最終日のイベント参加人数は 4000 人でクロージングセッション中の参加人数 1000 人でした。想像以上の方に参加していただて嬉しいです。後日 Youtube にアーカイブがアップロードされます。

<iframe  src="https://www.youtube.com/embed/9pG7AbAlQxk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

自分を含めた登壇者 4 人と AWS の Developer Advocate の方 の計５人でパネルディスカッションをしました。事前の打ち合わせでは

- 最近の仕事内容
- 入社した経緯
- AWS をどのように使っているか
- 今後の展望

などを話す想定でしたが、想定以上に盛り上がったため打ち合わせしていた話題を消化しきれませんでした。ですが医療の事業ドメイン特有のおもしろさと難しさはしっかり伝えることができたと思います。その甲斐もあってアンケートによさられコメントはポジティブなものがほとんどでした！

登壇内容の詳細に関しては会社の note にも投稿してあります。

<div>
  <a href="https://note.micin.jp/n/n1cf816519bf7" data-embedded="preview" >
    AWS Dev Day Online JAPAN 2021に登壇しました｜MICIN公式note「MICINの邁進Days」
  </a>
</div>

## 最後に

他 3 人のパネラーの方は IoT を使用していたので IoT を運用する上でのぶつかった課題を深く聞いてみたかったです。お話を伺っていると農業と畜産も IT 化が進んでおり時代の変化を感じワクワクしました。多種多様な業界で IT 化進んでエンジニアが活躍できるフィールドが増えたら嬉しいですね。


AWS Dev Dayに登壇


## はじめに

業務で Next.js を触る機会があったのでキャッチアップを兼ねて本ブログを作成しました。その過程で学んだ Next.js についての知見を本記事にまとめました。

## なぜ CRA(Create React App)と比較するのか

React の代表的なフレームワークである CRA(Create React App)と比較しながら進めていきます。他にも有名な React のフレークワークとして Gatsby、Razzle、UmiJS 等がありますが、npm のダウンロード数が多い CRA と比較していきます。CRA より Gatsby の方がダウンロード数は多いですが、SSG 専用のフレームワークなので比較対象とはしませんでした。

## 比較する観点

Next.js と CRA を次の観点で比較していきます。

- レンダリング
- ルーティング
- モジュールバンドーラーのカスタマイズ
- 表示速度
- デプロイ

## レンダリングの比較

レンダリングを比較してきます。CRA は CSR(Client Side Rendering)のみをサポートしていますが、Next.js では CSR、SSR(Server Side Rendering)、SSG(Static Side Generation)をサポートしています。

CSR のみでもサービスを作ることはできますが、次の理由によりアプリケーションが肥大化するにつれてページの表示スピードが落ちてユーザ体験と SEO に悪影響が出る可能性があります。

- ページを表示毎に HTML をクライアント側で生成するためにページ表示されるまでの時間がクライアント環境に大きく依存する。
- アプリケーションが大きくなるにつれてバンドルサイズが大きくなります。そのため初回のページ表示時に画面が表示されるまでの時間が遅くなります。モジュールバンドラーでコード分割をして明示的に遅延読み込みを行い対策は可能です。

検索エンジンにインデックスさせないチャットツール、タスク管理ツールのようなページであれば、SEO 観点で表示速度を考慮する必要はありません。そのためユーザが許容できるページ速度であれば問題ありません。ところが検索エンジンにインデックスさせる SNS、EC、メディア等のようなサービスではできるだけページの表示スピードを可能な限り速くして SEO で有利になるようにしておくべきです。

SSR ではサーバ環境で HTML をレンダリング、SSG ではビルド環境で HTML をレンダリグします。そのためクライアント環境によらず安定したページ表示スピードを出すことができます。SSR で安定した表示スピードを実現するためにはアクセスの増減に伴いサーバをスケールする必要があります。

ダッシュボード系のサービスであってもサービスの紹介、FAQ、ドキュメント等はは検索エンジンにインデックスさせる必要があるため、部分的に SSG を使いたくなります。

Next.js を使うと、サービスの紹介ページでは SSG で HTML をビルド時に生成しておき、ログイン後のページのユーザ毎に HTML が異なるページでは CSR で HTML を生成することができます。

## ルーティングの比較

ルーティングを比較していきます。 Next.js はルーティングを標準でサポートしておりディレクトリ構造でルーティングのパスを定義します。CRA は React のアプリケーションにおける開発、テスト、ビルドを解決するためのフレームワークなのでルーティングは提供していません。そのため CRA ではルーティングを定義するためにはサードパーティのライブラリを使用します。

CRA の開発で一般的に使われてる`react-router-dom`を使うと次のようにルーティングを定義るすことができます。

```jsx
import React, { lazy } from 'react'
import { Switch, Route } from 'react-router-dom'
import Home from './routes/Home'
import About from './routes/About'

const App = () => (
  <Router>
    <Switch>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
    </Switch>
  </Router>
)
```

Next.js でがファイルシステムのパスでルーティングのパスを定義します。プロジェクト生成時に作られた pages ディレクトリ以下にファイルを追加すると 1 つのファイルが 1 つのページに対応します。

- ~/project/pages/index.js → https://domain/
- ~/project/pages/blogs/index.js → https://domain/blogs
- ~/project/pages/blogs/[slug].js → https://domain/blogs/:slug (https://domain/blogs/my-trip)

pages ディレクトリにファイルを作成してコンポーネントをデフォルトでイクスポートすることでルーティングを定義することができます。

```jsx
// pages/index.js

const Home = () => {
  return (
    <div>
      <h1>Home page</h1>
      <p>Welcome!</p>
    </div>
  )
}

export default Blogs
```

ページ遷移は Next.js が提供している Link コンポーネントを使うと Link コンポーネントが画面に表示されたらリンク先のページをプリフェッチするため、ページ遷移 A が速くなります。

```jsx
import Link from 'next/link'

const Home = () => {
  return (
    <div>
      <nav>
        <Link href="/">
          <a>Home</a>
        </Link>
        <Link href="/about-us">
          <a>About us</a>
        </Link>
      </nav>
    </div>
  )
}

export default Home
```

CRA と Next.js のルーティングでできることはほぼ変わりません。Next.js 本体がルーティング機能を提供しており、かつファイルシステムベースのルーティングなので Next.js を使用しているプロジェクトであれば強制的にディレクトリ構成が統一されるので、ディレクトリ構成を決める際の議論がなくなります。新たにプロジェクトに参画したメンバーがキャッチアップをしやすいというメリットもあります。

## モジュールバンドーラーのカスタマイズの比較

モジュールバンドーラーのカスタマイズを比較していきます。CRA と Next.js 共にスタイルシート、画像、動画のようなメジャーなコンテンツであればデフォルトの設定でバンドル可能です。しかしブラウザのサポート環境を変更したいなどカスタマイズする必要が出てくる場合があります。

CRA と Next.js 共にモジュールバンドーラーのカスタマイズはできますが、CRA は標準でサポートしていないのでサードパーティのパッケージを使う必要があります。

CRA はモジュールバンドラーを隠蔽しているためモジュールバンドラーをカスタマイズすることができません。webpack の設定は react-scripts 内の[コード](https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/webpack.config.js)上にあります。

CRA の `yarn eject` コマンドを使うと react-scripts 内の設定コードをプロジェクトにコピーすることができます。開発サーバ、ビルド、テスト用のスクリプトがコピーされます。このコピーされたものをカスタマイズすることが可能です。webpack のビルド設定は `scripts/build.js` にコピーされています。package.json はコピーしたスクリプトを実行するように変更されます。

```json
// package.json
{
  // before yarn eject
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  // after yarn eject
  "scripts": {
    "start": "node scripts/start.js",
    "build": "node scripts/build.js",
    "test": "node scripts/test.js"
  }
}
```

`yarn eject` は不可逆な操作なので一度実行すると元には戻せません。そのため CRA が提供するモジュールバンドラーメンテナンスの恩恵を受けられなくなります。

外部パッケージを使うことによって `yarn eject`することなく CRA の設定をオーバライドすることが可能です。[react-app-rewired](https://github.com/timarney/react-app-rewired) は CRA の設定をオーバライドすることが可能なパッケージの一つです。

react-app-rewired では `config-overrides.js` に設定を追加して、`package.json` を書き換えてるだけでカスタマイズ可能です。

```js
// config-overrides.js
module.exports = function override(config, env) {
  //do stuff with the webpack config...
  return config
}
```

```json
// package.json
{
  "scripts": {
    "start": "react-app-rewired start",
    "build": "react-app-rewired build",
    "test": "react-app-rewired test",
    "eject": "react-scripts eject"
  }
}
```

Next.js はモジュールバンドラーのカスタマイズをサポートしています。 next.config.js に設定を追加することでカスタマイズすることができます。

```js
//  next.config.js
module.exports = {
  webpack: (config, options) => {
    config.module.rules.push({
      test: /\.mdx/,
      use: [
        options.defaultLoaders.babel,
        {
          loader: '@mdx-js/loader',
          options: pluginOptions.options,
        },
      ],
    })

    return config
  },
}
```

## ページ表示速度の比較

ページ表示速度の比較していきます。CRA は JavaScript を用いてブラウザ環境で DOM を生成しますが、Next.js の場合は可能な限り必要な DOM はビルド時に生成されるので、レンダリング観点でも Next.js の方がページ速度は速くなります。
レンダリング観点以外でも Next.js はページ表示速度を速くするための機能を提供しています。画像の最適化、JavaScript バンドルファイルのコード分割、リンク先ページをプリフェッチなどを提供しています。

Web サイトが表示されるまでの流れを考えながら説明していきます。Web サイトが表示されるまでの大きな流れは次の通りです。

1. コンテンツ(HTML、CSS、JavaScript) のダウンロード
2. HTML と CSS を DOM と CSSOM へ変換
3. JavaScript を実行して DOM と CSSOM に変更を加える
4. DOM と CSSOM を元に Render Tree を構築
5. Render Tree を元に要素の位置を計算(Layout を決める)
6. Layout を元に描画をする

Next.js は 1 のコンテンツのダウンロード時間を短くすることで機能をページ表示速度を速くしています。

Next.js では ダウンロードする JavaScript のデータサイズを小さくするコード分割機能を提供しています。コート分割により各ページで必要な JavaScript のみをダウンロードすることができます。CRA のような SPA はサイト全体で 1 つ HTML ファイルと JavScript ファイルは 1 つです。一方、Next.js ではページごとに HTML ファイルと JavaScript ファイルを生成します。そのため各ページで必要な JavaScript コードのみバンドルされています。

JavaScript はテキストファイルなのでデータサイズが小さいと考える人も多いと思いますが、実際は違います。[Wdb Almanac](https://almanac.httparchive.org/en/2021/page-weight#page-weight-by-the-numbers)によると JavaScript のデータサイズはデスクトップで 約 472KB、モバイルサイトで 約 430KB になります。HTML と CSS は 80KB 未満に収まるのと比較すると JavaScript のデータサイズが大きいのがわかります。JavaScript ファイルは依存パッケージが多くなる、旧ブラウザに対応のビルドをする等の理由で大きくなります。

アプリケーション開発者側でコード分割の Next.js を設定をする必要はありません。CRA も明示的に設定することで JavaScript のコード分割は可能です。React の lazy 関数を使います。1 つのページに対応するコンポーネントごとにコード分割することができます。

```jsx
import React, { lazy } from 'react'
import { Switch, Route } from 'react-router-dom'

// コード分割
const Home = lazy(() => import('./routes/Home'))
const About = lazy(() => import('./routes/About'))

const App = () => (
  <Router>
    <Switch>
      <Route path="/" element={<Home />} />
      <Route path="/about" element={<About />} />
    </Switch>
  </Router>
)
```

Next.js は画像に関してもデータサイズを小さくする機能を提供しています。Image コンポーネントを使うとブラウザに応じて適切のフォーマットで画像を返します。PNG と JPG の画像を Image コンポーネントに渡すとクライアントがモダンなブラウザであれば WebP を返します。Chrome、Safari、Firefox、Edge のようなモダンなブラウザは WebP 対応しています。
WebP の[公式サイト](https://developers.google.com/speed/webp)によると WebP は可逆圧縮の場合においても PNG よりデータサイズが 26%小さくなります。[Wdb Almanac](https://almanac.httparchive.org/en/2021/page-weight#page-weight-by-the-numbers)によると Web サイトの画像のデータサイズはデスクトップサイトで 982KB、モバイルサイトで 約 877KB です。そのため、約 255KB(982KB x 0.26)のデータサイズを小さくすることができます。

Next.js は Link タグを使うことでユーザがページ遷移する前に予めリンク先のページをダウンロードする機能があります。Link タグが画面内に入ったらリンク先ページをダウンロードします。

```jsx
import Link from 'next/link'

function Home() {
  return (
    <ul>
      <li>
        <Link href="/">
          <a>Home</a>
        </Link>
      </li>
      <li>
        <Link href="/about">
          <a>About Us</a>
        </Link>
      </li>
    </ul>
  )
}

export default Home
```

## デプロイの比較

デプロイの比較をしていきます。CRA はビルドして出力したコートを Web サーバに配置すればデプロイ完了です。Next.js の場合はデプロイの方法が 2 つあります。1 つはに Node.js サーバを動かす方法、もう一つは静的ファイルとして Web サーバに配置する方法です。

Node.js サーバは Next.js に内包されており、コマンドを呼び出すだけでサーバを立ち上げることができます。

```bash
# Node.jsホスティング用にビルド
next build
# Node.jsサーバを立ち上げる
next start
```

Node.js サーバを動かす場合のホスティング方法は 2 つあります。1 つは自前で Node.js をインストールしたサーバ用意してセルフホスティングする方法、もう一つは[Vercel](https://vercel.com/dashboard)や[AWS Amplify](https://aws.amazon.com/jp/amplify/)のようなプラットフォームを利用する方法です。Node.js サーバは負荷の高い SSR と画像の最適化を行うためセルフホスティングする場合はメモリと CPU のリソース管理が重要になります。必要に応じてスケールアウトさせる必要があるためサーバ運用のコストが大きくなります。そのため、プラットフォームを利用するのがおすすめです。

Next.js では `next export` コマンドを実行すると Node.js サーバホスティング用のビルドを静的ホスティングできるように修正できます。next export で出力されらディレクトリを Web サーバに配置すればデプロイ完了です。

```bash
# Node.jsホスティング用にビルド
next build
# ビルド結果をもとに静的ホスティング用ファイルを出力
next export
```

next export で出力されたディレクトリを Web サーバに配置すればデプロイ完了です。

## まとめ

Next.js は CRA(Create React App)で開発をする際にぶつかる課題を解決するように設計されてる印象を受けました。解決されている課題としては次のようなものがあります。

- サービス紹介ページ、ドキュメント、FAQ のようなクライアントサイドレンダリングする必要のないページでもクライアントサイドレンダリングになる。結果的にページが表示されるまでに時間がかかり、SEO 観点で不利になる。
- コード分割を明示的に行わない限り全ての JavaScript コードが 1 つのファイルにバンドルされる。そのためアプリケーションの成長に伴い表示速度が低下する。
- webpack の設定をカスタマイズしたい場合は CRA(react-scripts)に内包されている設定を eject する必要があり、eject は不可逆な操作である。ただしサードパーティの npm パッケージを使ってオーバライドすることは可能です。
- 画像の最適化はフレームワーク外で行う必要がある。画像のダウンロードサイズを小さくするために端末とブラウザに応じてサイズと圧縮形式を最適化するためには画像サーバを別途用意する必要がある。画像サーバのオープンソースでは[thumbor](https://github.com/thumbor/thumbor)があります。

Next.js を使用するとインフラが Vercel や AWS Amplify のようなプラットフォームに強く依存してしまいますが、それでも様々な提供されており非常に便利なので使う価値があります。Next.js は現在も積極的に開発されているので今後どうなって行くのか楽しみです


Next.js vs CRA


業務で Next.js を使う機会があったのでキャッチアップを兼ねて本ブログを作りました。デザインはモバイルファーストでレスポンシブにしました。

<video>
  <source src="/images/blogs/blog-launch/responsive.mp4" type="video/mp4" >
</video>

Web サイトのデザインも自分で行うため、Web Design Standard という本でデザインの基本的なことを学びました。

<a href="https://www.amazon.co.jp/gp/product/4844367773" data-embedded="preview" >Web Design Standard</a>

具体的には次のことを学びました。

- PC とスマートフォンのレイアウト
- サイトの種類ごとのレイアウト
- 色の基本
- 色とレイアウトが与えるイメージ
- レイアウトと配色のトレンド
- UX デザインと UI デザイン

一番興味深かったのはファッションと同様にデザインにもトレンドが素材することです。ここ数年のトレンドだと次のようなものが挙げられます。

- 横スクロール
- ダークモード
- ニューモーフィズム

横スクロールはユーザビリティが低いデザインとして長らく使われてきませんでしたが、Apple の iPad の商品ページで横スクロールが採用されたことにより横スクロールを使うサイトが増えてトレンドになりました。

<video>
  <source src="/images/blogs/blog-launch/side-scrolling.mp4" type="video/mp4">
</video>

ダークモードは 2019 年の OS アップデートにより Apple の 端末でタークモードが使えるようになったことがきっかけでダークモード対応したサービスが増えてトレンドになりました。

<img src="/images/blogs/blog-launch/dark-mode.png" alt="" width="375" height="667" />

ニューモーフィズムはボタンや入力フィールドなどのコンポーネントを凹凸で表現するデザイン手法です。2019 年ごろに [dribbble](https://dribbble.com/shots/7994421-Skeuomorph-Mobile-Banking)というデザイナー向けの SNS での投稿をきっかけにで注目を集め、2020 年ごろからデザイン手法として取り入れるサイトが増加しました。

<img src="/images/blogs/blog-launch/neumorphism.png" alt="" width="440" height="880" />

ブログの favicon には MICIN MONSTER を使いました。MICIN MONSTER とは私が現在所属する株式会社 MICIN で行っている社内の取り組みの一つで社員の個性と特徴を表現したキャラクターアイコンのことです。私のアイコンはシルクハットとトランプを持ったマジシャンのようなアイコンになっています。一時期マジックにハマった時期があり、プロマジシャンが行うマジックもできるようになりました。忘年会でみんなの前で行うこともあります。

<img src="/images/blogs/blog-launch/micin-monster.png" alt="" width="512" height="512" />

<a href="https://www.wantedly.com/companies/micin/post_articles/286697" data-embedded="preview" >MICIN MONSTER</a>

Safari で Web サイトをホーム画面に追加すると このように表示されます。

<img src="/images/blogs/blog-launch/apps.png" alt="" width="375" height="667" />

Next.js を使っみて CRA(Create React App)で開発をする際にぶつかる課題を解決するように設計されてる印象を受けました。解決されている課題としては次のようなものがあります。

- サービス紹介ページ、ドキュメント、FAQ のようなクライアントサイドレンダリングする必要のないページでもクライアントサイドレンダリングになる。結果的にページが表示されるまでに時間がかかり、SEO 観点で不利になる。
- コード分割を明示的に行わない限り全ての JavaScript コードが 1 つのファイルにバンドルされる。そのためアプリケーションの成長に伴い表示速度が低下する。
- webpack の設定をカスタマイズしたい場合は CRA(react-scripts)に内包されている設定を eject する必要があり、eject は不可逆な操作である。ただしサードパーティの npm パッケージを使ってオーバライドすることは可能です。
- 画像の最適化はフレームワーク外で行う必要がある。例えば、画像のダウンロードサイズを小さくするために端末とブラウザに応じてサイズと圧縮形式を最適化するためには画像サーバを別途用意する必要がある。画像サーバのオープンソースでは[thumbor](https://github.com/thumbor/thumbor)があります。

Next.js と CRA(Create React App)の比較は別の記事に投稿します。更新頻度は高くはないですがブログの更新はしていく予定です。


Tech Blog

About Me

Blogs

Zennに記事を投稿してみた

会社のブログを更新

データサイズのリアル

AWS Dev Dayに登壇

Next.js vs CRA

ブログはじめました