オライリーの「初めてのGraphQL」を読んだ

先日の三連休中にオライリーの初めてのGraphQLを読んだ。入門書として内容がよくまとまっている上に、翻訳がとても読みやすく理解が捗った。GraphQL は個人開発で使いたいと思って何度かトライしたが、ネット上の入門記事やチュートリアルをいくつか読んで何度試してみても、腑に落ちたという感覚がどうにも得られなかった。

しかし、この書籍を通して GraphQL のクエリの書き方、Query、Mutation の区別、Subscription の位置付けと実装方法、リゾルバの役割、認可やファイルアップロードといった実践的な機能の実装方法を理解できた。

本書のサンプルコードは JavaScript で記述されている。また、サンプルアプリは Apollo が作っているライブラリ（apollo-client、apollo-server）と React を使って実装していることから、実際に使ってみるイメージが湧きやすかった。

ただし、翻訳の出版が2019年11月であり、サンプルコードでは React Hooks が使われていないのでその辺りは最新の書き方に読み替える必要がある。が、その辺りは本書を読むにあたり足枷には全くならない。

GraphQL に対して漠然とした苦手意識があった

個人的な話を書くと、以前は個人ブログをGastby で作っていたため GraphiQL を使って Query を書くことはできた。フロントで欲しい値はその Query をコピペして custom hooks で使えばよかった。

ただし、まだ GraphQL を理解したと言えない気がしたので Next.js の自分の実験用の Playground のサイトで GraphQL の公開エンドポイントからポケモンを取得する処理を書いてみた。 これで Query はわかった。

しかし、Mutation、Subscription、リゾルバに対する理解が不足していた。そこで、ネット上のチュートリアルの記事を読みながら apollo-server を使ってリゾルバを実装してみた。DB を使わずインメモリで配列を保持し、それに対して簡単な CRUD ができる TODO アプリを手元で作ってみた。

その際、graphql-codegen が便利だという話を聞いていたので、GraphQL Code Generator で TypeScript の型を自動生成する という記事を読みながらスキーマを書いてフロントのコードを自動生成してみた。この頃は、個人開発で自分が実際に使えるかの検証目的だった。

コードを自動生成できて簡単だったものの、認可の処理方法がわからなかったことやリゾルバを書いていても「これで本当に合ってるのか？」と疑念を晴らすことができなかったことから、本書を手に取るに至った。なお、この段階では個人開発での GraphQL の採用は見送って Supabase を使うことにした。

書籍を読むことで頭がクリアになった

本当は GraphQL のドキュメントを読めば済むのだろうが、概要をさっと掴むなら書籍の方がいいと思ってオライリーの初めてのGraphQL を買ったみた。それが数ヶ月前。ただ、個人開発の方を進めていたことと本業では REST API で開発していたことから外部要因で学習を迫られることがなく、ずっと積ん読をしていた。

しかし、やはり周囲から「GraphQL でフロントの記述が楽になる」と聞いて、連休中に重い腰を上げて読んでみた。結論から書くとこれが正解で、自分の知りたかったことが書いているし、俯瞰したようにスキーマ・クエリ、リゾルバその他を見渡せる感覚を得た。この書籍が自分の理解に足りていないピースをはめ込んでくれたのだった。このため、記事に残しておこうと思ったのだ。

以下では、自分の GraphQL に対する理解がクリアになった文をいくつか引用する。書籍の雰囲気は伝わらないかもしれないが、「結局、GraphQL って何？」という疑問にはいくらか答えてくれるはずだ。

GraphQL の紹介

GraphQL の言語仕様 は型システムと型システムに基づいたクエリの実行とバリデーションも規定していま す。しかしそれ以外には何も規定していません。

すべての GraphQL スキーマの核になるのは型です。GraphQL において、型は固有の オブジェクトで、アプリケーションの特性を反映します。

スキーマファーストは設計の方法論です。スキーマファーストではアプリケーション を作成するチームメンバー全員がデータ型について理解しています。（中略） スキーマファーストではすべてのチームメンバーがデータ 型を共通言語にして開発にまつわるコミュニュケーションを取ることができます。

GraphQLプロジェクトの肝はスキーマをうまく設計することです。よくできた GraphQL のスキーマはフロントエンドとバックエンドチームの間のロードマップと契約 として機能し、ビルドされた製品が常にスキーマに対応することを保証します。

仕組み

GraphQL はこの抽象構文木を走査することで、GraphQL の言語仕様とスキーマに対 してバリデーションできます。構文が正しく、クエリに含まれるそれぞれのフィールド や型がスキーマと一致していれば、処理が実行されます。バリデーションで何らかの エラーが発生すると、処理は実行されません。

もし本当に新しい Web の利点を生かしたければ、GraphQL は HTTP リクエ ストだけでなく WebSocket を使用したリアルタイムデータ通信をサポートできなければ いけません。その手段がサブスクリプションです。

定義

スキーマ

スキーマは型定義の集合です。

サブスクリプションのスキーマは PubSub デザインパターンの リアルタイムの通信を実装している必要があります。

クエリ

ミューテーションとクエリのスキーマ定義に仕様的な差はありません。両者は目的が異なります。

フラグメントは複数の場所で使いまわすことができる選択セットです。

ミューテーションはアプリケーションで使われる動詞と対応づくのが望ましいです。 サービスに対してできることがミューテーションとして定義されます。GraphQL のサー ビスを設計するとき、ユーザーが実行できる操作をすべて列挙してください。それがス キーマに定義するべきミューテーションです。

型

GraphQL にはスカラー型とオブジェクト型が存在します。（中略） GraphQL では 5 つのスカラー型が用意されています。整数型(Int)、浮 動 小 数 点 数 型( F l o a t )、 文 字 列 型( S t r i n g )、 論 理 型( B o o l e a n )、 I D 型( I D )で す 。（中略） GraphQL のオブジェクト型は、ひとつ以上のスキーマで定義されているフィールド の集合で、返される JSON オブジェクトの形を規定します。

グラフ理論

カスタムオブジェクト型のフィールドを定義することは、2 つのオブジェクトを接続 することにほかなりません。グラフ理論の言葉では、この接続部分はエッジと呼ばれる のでした。

リゾルバ

リゾルバは特定のフィールドのデータを返す関数です。リゾルバ関数はスキーマで指定されたとおりのデータを返します。リゾルバは非同期で処理することができ、REST API、データベース、その他のサービスからデータを取得したり更新したりできます。

リゾルバは単なる関数であり、GraphQL スキーマのすべてのフィールドをリゾルバにマッピングできます。

コンテキスト

コンテキストはどのリゾルバもアクセスできるグローバルな値を格納できる場所です。コンテキストは、認証情報、データ ベースの詳細、ローカルデータキャッシュ、その他 GraphQL オペレーションのために 必要なものを保管するのに適した場所です。

実践に向けた Tips

可能であれば、GraphQL のサービスは無向グラフにしておくことが望ましいです。 無向グラフにしておくことで、クライアントは非常に自由度の高い問い合わせができる ようになります。任意のノードを起点にしてほかのノードを接続していけるからです。

一般論としては、含まれている複数の型がまったく異なるものであれば ユニオン型を利用するのがよいでしょう。同様に、複数の型に共通のフィールドがある 場合はインターフェースを利用するほうがよいでしょう。

主要な用語は以下のようなもの。順番は思いついた順。

ルートリゾルバ、カスタムリゾルバ、トリビアルリゾルバ、enum、インターフェース、フラグメント、インラインフラグメント、Query、Mutaion、Subscription、スルー型、入力型、カスタムスカラー型、無向グラフ、有向グラフ、ノード、エッジ、グラフ理論

実装の章から定義の章に遡って読んだ

最後に少しだけ、本書を読んだ方法を書き残しておく。

自分は GraphQL に対する部分的な理解があったので、サンプルアプリを実装する第5章から第7章を先に読み、スキーマの設計の4章、GraphQL のクエリを紹介する3章、グラフ理論を解説する2章と遡って読んでいった。

これはどこにも書かれていない Tips なのだが、ある対象を体系立てて説明しているちゃんとした書籍では、前半で定義・解説した概念・用語を後半で活用する。その際、概念・用語が書籍内で初出の前半部分より、実はそれが2回目以降に登場する後半の方がシンプルな説明であることが一般的だ。

これはある概念や用語が書籍内で初出の段階では、なるべく包括的な解説をしようと言葉を費やして著者が丁寧に語ってくれるからである。一方、既に読者がなんとなくその用語や概念を聞きかじっている場合、得てして章の後半で登場する再定義の方が理解・暗記しやすい場合が多い。

このため、最初の解説は自分の知識の抜け漏れ防止のために、後半で出てくる再定義は自分用の簡潔な理解と、人に「AはXである」と伝えるための暗記用に使うと良い。例えば、上の引用のリゾルバの定義は明らかに後者の方が説明がシンプルだ。

今回はまさに「GraphQL を聞きかじった状態」だったため、自分が一番知りたい実装の章から読んでいった。そこで驚いたと同時に面白いと感じたことは、「前半では言葉を尽くして説明してくれたんだろうな」と思える用語のシンプルな再定義が、自分の抜けていた知識・理解の穴を埋めてくれたことだった。これは全く意外だった。

結局、個々の要素はなんとなく知っていても全体像が掴めていなかったのだ。コードを読んで手を動かすことは初めの一歩ではあるが、その実装は全体の中の部分でしかなく、全体の中での位置付けや担っている役割を知っておかないと真に理解したとは言えないのだ。

そして、知らないことを知っているという無知の知は自省だけでは得づらく、読書という著者との対話を通してやっと知らなかったところを知れる。これは一年を通してみても何度もあることではない。今回は良い体験ができた。

まとめ

正直なところ、書籍の紹介は読むのは好きだが自分で書くのは苦手だ。苦手なのだが、初めてのGraphQL のおかげでなんとなく感じていた苦手意識を払拭できたので紹介したいと思って記事を書いてみた。

これからは GraphQL の勉強会にも参加したり、Supabase を使っている個人開発でも自前でリゾルバを書いて段階的に取り入れてみようと思う。Supabase が作っている PostgreSQL の GraphQL extension が Stable になるのが待ち遠しい。

Gatsby から Next.js に載せ替えた動機

本ブログを Next.js でリニューアルしました。 元々このブログは Gatsby で作っており、2019年3月にリリースしましたが（最初の投稿）、ついに Next.js に移行しました。移行のモチベーションはバージョン追従を避けたこと、デザインを一新したいこと、また記事が表示されないというバグが発生する事象があったことです。

まず Gatsby のバージョンアップについて。現在、Gatsby の最新バージョンが4系です。しかし、自分が使っていたテンプレートは3年前に1系から使い始めて、2年前に2系にバージョンアップしました。その後、自分は業務と個人開発で Next.js を使い始めたため、このブログでしか使っていなかった Gatsby の情報を追うのを止めて、記事だけ追加する運用をしていました。 その頃にはバージョンアップをするよりは Next.js で作り直そうと考えていました。

次に、デザインについてです。前のブログのデザインは Gatsby のスターターをそのまま使っていました。記事ページの幅や行間の余白や一部リンクの色や左カラムに表示するコンテンツを変えたものの、レイアウトやページネーションはスターターの実装のままでした。 このため、一から作り直して自分でサイトを作ったという感覚を得たかったという動機も原動力の一つです。 （画像はリニューアル前のトップページ）

そして、記事が一覧に表示されないというバグが発生していたことも理由の一つです。 最新、または最新から1つ前の記事がトップページの一覧に表示されていませんでした。直リンクでアクセスすれば記事は表示されるのですが、せっかく書いた記事が人の目に触れないもどかしさを感じていたことも移行のきっかけになりました。

そして一番のきっかけは、今個人開発で作っているビールのレビューサイト（Beer Break）の休憩です。 2021年の9月末から作業を始めたため、このサイトの構想、Supabase の技術調査、仕様検討、実装を合わせるとすでに4ヶ月ほど経っています。

その間にもブログを作り直したいという気持ちは募っていたこと、サイトを作っている間に記事にしたい知見が溜まってきたこと、そして何よりユーザー登録から投稿の削除まで一通りサイトのリリースに必須の機能を実装できたことを考慮して、気分転換にブログを作り直そうと思い立ったのでした。

Beer Break

Next.js でブログを作る際に工夫したこと

さて、本題の Next.js ブログを作り直す際に工夫した点を紹介していきます。 ブログの開発は余暇の時間を使う個人開発です。このため、ここでいう工夫とは、開発の工数をできるだけ削減することです。そしてこの工夫は再現性があるため、例えば会社や個人で技術ブログを作る機会があればそのまま適用できるテクニックです。

先に結論を書くと、レイアウトを整えてダミーデータを入れ、Vercel にデプロイして一通り動くところまでたった4時間でできました。 なお、最終的にかかった時間は約48時間、工数にして約6人日です。そのうち記事ごとの OG 画像のデザインと自動生成プログラムの作成に1人日かかっているので、 ブログ作成にかけた工数は実質5人日です。（画像はOG画像のイメージ）

工数削減の前提. 慣れた技術を活用する

工数削減の工夫を説明する前に、工数削減の大前提は自分が慣れている技術を使うことです。 それにより学習コスト、つまりプロジェクトのセットアップ、公式ドキュメントの参照、チュートリアルの写経、デプロイ先の選定、ライブラリや関連ツール等エコシステムのチェックが不要になります。これは特に個人開発では重要な観点です。

今回、ブログを作り替えるにあたり新しく採用したツールは Vitest だけです。それ以外は自分がいつも使っている Next.js、Tailwind CSS、Vercel を選びました。これで技術調査と学習のコストはなくなりました。

関連記事: Next.js が好きな理由と2年間使い続けてきた感想

今回はサイトのリニューアルであるため、仕様策定に関するコストも大きくありません。 ページ数は4ページと多くなく、記事一覧ページ、各記事の個別ページ、以前作ったサイトを集めたポートフォリオと自分のプロフィールページだけです。しかも、今回は元になる Gatsby 製ブログがあるので、表示する内容は基本的に以前のものを踏襲するため新たに考えることはほぼゼロです。

Headless CMS を使うことも検討しました。しかし、以前からマークダウンファイルで記事を作成することに慣れていたこと、将来 MDX の対応をするかもしれないこと、frontmatter でメタ情報を柔軟に設定したいことから、今回は採用を見送りました。

仕様がほぼ固まっており、また慣れた技術を仕様することで上記の工数でを実現できたことは大きな前提です。 そして、以下で紹介する工数削減のキモは巨人の肩に乗ることです。ここでは、世界の人の過去の仕事の成果を借りてくることで、自分の仕事にレバレッジをかけることを指しています。

工数削減の工夫1. next-blog-starter を活用する

最初の工夫は Next.js の examples を活用したことです。

Next.js は GitHub レポジトリ上で様々なツールやライブラリと組み合わせた設定例を公開しています。この中の一つに blog-starter-typescript があります。これはマークダウンファイルを読み込み、SSG で記事ページをビルドするものです。サンプルのまま Vercel にデプロイしてもブログサイトとして動作します。

このスターターの嬉しいところは、md ファイルを読み込む記述とマークダウンをパースして html に変換するライブラリ、それをもとに記事ページを作るプログラムが同梱されていることです。 また、Frontmatter で記事のメタ情報を記述できます。

ブログサイトでは個別の記事ページのビルドに getStaticProps と getStaticPaths を活用します。blog-starter-typescript にはその記述も予め存在するので、フロントエンドでやるべきことは抽出するメタ情報を選択することと、画面を構築することです。つまり、Node.js のコードをほぼ書く必要なく、デザインと React の記述に集中可能になるのです。

工数削減の工夫2. Tailwind UI で UI を構築する

二つ目の工夫は、Tailwind UI を使うことです。 Tailwind UI は Tailwind CSS 公式の UI コンポーネント集です。HTML、React、Vue に対応しており、コピペですぐに使えます。一般的なコンポーネント集と異なり、これは有料で全てのパーツを購入すると$279です。

お金を払う必要はあるものの、コンポーネント自体を再販売しなければ商用でも利用可能であり、また購入した後のアップデートで新しいコンポーネントが追加されても追加料金を払わずに活用できます。

本音を書くと、これはあまり共有したくない情報でした。購入すれば誰でもハイクオリティなサイトを構築できるため、みんながこれを使ってサイトを構築すればデザインが差別化要因にならなくなるからです。

Tailwind UI はこれは人手が足りないスタートアップやデザイナーがいないチームで特に有用なツールです。実際、Supabase や papyrus といった新進気鋭のスタートアップのランディングページや管理画面を見て「このコンポーネント、Tailwind UI にあったな」と気づく回数が増えました。

Supabase に至っては Supabase UI という Tailwind UI を参考に、というかそのまま使っているようなコンポーネント集も作っています。ただし、これはライセンス違反ではありません。

むしろ、Supabase UI はコンポーネントに渡す Props の定義や、Tailwind UI のコンポーネントの様々なバリエーション（例えば、モーダルでボタンが一つあるか二つあるか、アイコンは上に出すか左に出すか）を一つのコンポーネントにまとめる方法がとても参考になり重宝しています。

Tailwind UI でデザインフェーズが変わる

話を元に戻します。Tailwind UI を使うことでデザインフェーズでやるべきことが一変します。 今までは UI コンポーネント集を使ったとしても、ページのレイアウトに悩んだりそのコンポーネントの組み合わせ方に悩んでいました。

そしていざデザインに着手するとなると、デザインが素晴らしいサイトを眺めて参考にできるところを探し、Figma でデザインカンプを作成し、そのデザインカンプをもとに HTML と CSS を実装し、再利用できそうなところをコンポーネントに切り出し、実装起因でデザインとの差分が生じたら Figma を修正する（個人開発の場合は時には諦めることもある）というのがいつものフローでした。

しかし、Tailwind UI を使う場合、ヘッダーとフッターの一覧の中から好みのものを選択し、ブログやプロフィールなどページごとにコンテンツを出すための最適な UI を選ぶだけになります。 選んだ UI のコードをコピーし、ファイルにペーストしてコンポーネントとして扱います。データはダミーなので、Props で受け取れるようにプロパティ名を命名すれば準備完了です（画像は Tailwind UI のヘッダーの例）。

以上、1と2の工夫を実践した結果、たった 4時間でブログのプロトタイプが出来上がりました。 サイトの各ページと Twitter の 画像を見比べてもらうと、ほぼ同じ構成だということがわかると思います。4時間でここまでできたことは想定外でかなり驚きました。

https://twitter.com/Panda_Program/status/1484194104305061896?s=20&t=j40LM858PAAmXh5c8hqiHA

工数削減の工夫3. @tailwindcss/typography でブログ記事のスタイリングをする

ここまででサイトの各ページのレイアウトが完成しました。次に工夫した点は Tailwind CSS の typography を活用したことです。このプラグインのすごいところは、proseというクラス名を一つ付与するだけでブログの文章のスタイリングが完了することです。

関連記事: Tailwind CSS入門 - フロントエンドで素晴らしい開発体験を得るために

これまで、コンテンツの幅、見出しや一文ごとのマージンや行間、ネストしたリストのインデント、引用や太字などのスタイリングは大変でした。細かいところに気を遣う上に、細部にこだわっていても全体としてバランスが整っていないと結局文章が読みにくくなるからです。それがproseというクラス名一つでとても読みやすいレイアウトになるのです。

prose はカスタマイズも簡単です。自分は今お読み頂いているこの文章のスタイルの調整に以下の CSS しか記述していません。ほとんど Heading と リンクの調整だけです。

.markdown {
  @apply prose prose-invert tracking-wide;

  // Headings
  @apply prose-headings:mb-4 prose-headings:border-b prose-headings:border-gray-700 prose-headings:pb-1 prose-headings:font-normal prose-headings:leading-snug prose-headings:text-gray-100;
  @apply prose-h2:mt-12 prose-h2:text-2xl;
  @apply prose-h3:mt-8 prose-h3:text-xl;
  @apply prose-h4:mt-8;

  // a
  @apply prose-a:text-blue-400 prose-a:no-underline prose-a:visited:text-indigo-400;

  // コード
  @apply prose-code:before:content-none prose-code:after:content-none;
  @apply prose-pre:rounded-tl-none prose-pre:bg-[#0d1117] prose-pre:p-2 prose-pre:shadow-lg;

  // strong
  @apply prose-strong:font-bold prose-strong:text-gray-50;

  // ul, li
  @apply marker:text-gray-400;
}

これを PostBody コンポーネントで呼び出しています。style['markdown'] が上記の CSS で、 contentはマークダウンから変換した HTML です。本文のコンポーネントはたったこれだけです。

import { convertToReact } from '@/lib'
import style from '@/styles/markdown-styles.module.scss'

type Props = {
  initialContent: string
}

const PostBody: React.VFC<Props> = ({ content }) => {
  return (
    <div className="space-y-4">
      <div className={style['markdown']}>{convertToReact(content)}</div>

      <p className="text-gray-300">Happy Coding 🎉</p>
    </div>
  )
}

export default PostBody

ブログページに関する残りの作業は、シンタックスハイライトを hilight.js で適用したこと、a タグを next/link の Link コンポーネントに、img タグを next/image の Image コンポーネントに変換した程度です。

https://twitter.com/Panda_Program/status/1484855016359821312?s=20&t=Dpb3zG-ss1xQO8LIx8awjg

上記の Twitter のつぶやきではここまで8時間かかったと書いています。しかし、実はシンタックスハイライトまでであれば6時間で完成しています。今回のブログリニューアルを通じて、Next.js と Tailwind UI、Tailwind CSS のおかげでハイクオリティなプロトタイプを短時間で作成できることがわかりました。

終わりに

もちろんブログに必要なコンテンツは一覧とブログページだけではありません。同じタグやカテゴリの記事を表示したり、ページネーションを実装したりとやるべきことはたくさんあります。それでも「いい感じのサイトを思ったより楽に実装できる」とわかるだけでも大きな収穫です。

実際、たった数時間でプロトタイプが出来上がったため、これならリニューアルに時間はそれほどかからないだろうと自信を得ることができました。繰り返しになりますが作業開始からブログのデプロイまでにかかった時間は48時間、業務後に開発を進めたためかかった日数は10日でした。

このブログは Next.js で作成しているものの、工夫2と工夫3はバックエンドのフレームワークに関わらず活用できるテクニックです。皆さんの技術ブログ作成の参考になれば幸いです。

なお、リニューアル前のブログはこちらからご覧いただけます。

2021年の活動を振り返る

2021年も年の瀬です。今年も家で過ごす時間は少なくありませんでした。

結果、通勤時間がなくなったことにより個人開発と技術記事の執筆に充てる時間を今までより確保できました。そんな今年のことを振り返ってみます。

個人開発の記録

2021年は3つの開発に取り組みました。 2つのツールを開発し、1つのサイトは現在開発中です。最後のものは来年1月末にはリリースできそうです。

技術スタックはどれも自分が一番慣れている Next.js + TypeScript + Tailwind CSS + Vercel を採用しています。

以下で簡単に紹介していきます。

Panda Editor（2021年1月中旬~2月初旬）

1つ目は、個人用のツール「Panda Editor」です。 このツールは技術記事執筆に役立つ自分用のエディタです。概要は以下の記事にまとめたり、当時所属していた会社の勉強会で発表しました。

Electron + Next.js + Tailwind CSS で Markdown エディタを作った

技術としては、Electron、Next.js、Tailwind CSS に加えて Textlint を採用しており、自分が書いた文章に対してリアルタイムで日本語の表記チェックが入ります。

Electron を使ってデスクトップアプリを作ってみたかったことが技術的なモチベーションでした。

また、開発の動機は PhpStorm や VSCode といったエディタが技術記事を書くに当たり少し物足りないと感じたことでした。

解決したかった課題は、文章執筆の過程でほとんど必須になるリサーチを簡単にすることです。 つまり、文章を書きながら、自分の知識を確認したり外部の著作物を引用するために Google 検索することを楽にして、書くことと調べることをシームレスにしようと試みていました。

工夫した点

この考え方をツールに反映するために、文章を記述するための入力欄は常に画面の左半分に表示しています。 また、右半分を「マークダウンのプレビュー」、「Google のトップページ」、「PDF などローカルのファイルを表示する画面」、「Textlint のエラーを表示する画面」に割り当てました。

それぞれの機能に対してプレビューモード、検索モード、閲覧モード、校正モードと名前でユースケースに応じて呼び分けました。 これがこのエディタの特色です。

このツールを作っていた2021年の1〜2月は、「人がこぞって使いたくなるツールのアイデアを自分は何も思い浮かばない。しかし、個人開発はしたい」という時期だったため、プライベートレポジトリで開発していました。今も公開はしていません。

結局自分でも今はこのツールを使っておらず、この記事は PhpStorm で書いています。この時期、仕事は忙しかったですが、個人開発の時間を捻出できたことや Electron の勉強ができたことに意義がありました。

また、前年の2020年は個人開発に対して大きく自信を失っていたため、2週間でそれなりのものが作れるんだという自信を取り戻したので振り返ると自分にとっていい経験になりました。

なお、Electron + React の実装に関しては azu さんの faao という GitHub Client の内容を参考にしていました。

レポジトリを見ると約 100 commit で作っています。

note PDFy(2021年6月末 ~ 8月上旬)

次に、note PDFy というツールを作ってみました。これは note の記事を PDF 化してダウンロードできるようにするツールです。 エンジニアの方は「Chrome の印刷機能で PDF 化できる」と思われるかもしれませんが、保存して手元に置いておきたい記事がいくつもある時にその作業は少し面倒なんです。

そこで、記事の URL を入力するだけで、自動で PDF が生成できるようにしました。 なお、後述するように初期の仕様は「note のユーザー名を入力すると、その著者の記事を zip でダウンロードできる」というものでした。

使用技術は、フロントエンドは Next.js + TypeScript + Tailwind CSS + Vercel。バックエンドは Node.js + TypeScript + Puppeteer + Cloud Functions for Firebase です。

課題発見の方法としては、自分が note で特定の著者の記事を一気に読みたいと思ったことです。 特に PDF で保存して iPad で読みたいと思ったので、以下の記事で紹介したツールを使って note の特定の著者の無料記事を全部にダウンロードして、ローカルでPDF 化するシェルスクリプトを4月に書いてみました。

その内容は以下のブログ記事に記述しています。

Rust製CLIツールmonolithでnoteの記事を簡単に保存する

これが note PDFy のアイデアの原型になり、そのまま同じことを Web アプリケーションでできるようにしようと考えました。 ちなみに、一気読みした note の著者は LayerX の福島さんです。

自分にとって新しい試み

さて、このツールを作る際に初めて取り入れた手法があります。それは需要を探るためのインタビューと、自分用の UI コンポーネント集の作成です。

前者に関しては、アルファ版、ベータ版の時点で感想を聞きました。具体的には、note のユーザー名を入力してもらい、ダウンロードボタンを押すとダミーの zip をダウンロードできるサイトを友人に見せて反応を伺いました。 質問事項としては、「note を普段読むか」「サイトに対してどんな印象を受けたか」がメインです。

計6名にフィードバックを貰ったものの、誰も習慣的に note を読む人はいませんでした。 友人のうち1人が非エンジニアで残りが全員エンジニアとサンプルが偏っていたこともあるかもしれません。ただ、よくないとわかっていも失敗するのが恥ずかしいので個人開発に理解のあるエンジニアを優先していました。そもそも感想を貰えるだけありがたいです。

この画像に書かれている感想を見てもわかるように、はっきりいって note を PDF で保存するという需要はなかったです。 しかし、その段階で目標を「とりあえず作り切ること」と「自分用の UI コンポーネント集を作ること」に切り替え、「note のユーザー名をどこから取得すればいいかわからない」と評判が悪かった note の著者名を入力する仕様を変え、note の 記事 URL を入力する仕様に変更しました。

特にこのツールのユースケースをサイトに記載したところ、使う場面や目的がわかりやすいと評判が良かったです。

このツールは公開まで持っていきましたが、やはり使ってもらえる数は多くありません。 2021年12月のアクセス数は10だけです。実際、「note PDF 化」という検索ワードでも Google 検索の上位にきていないため検索流入も期待できません。

しかし、UI コンポーネント集は手元に残りました。次にサイトを作る際にもゼロからのスタートではありません。 今までは新しくサイトを作るときにゼロベースで作っていたため、次につながる資産を残そうと最初から考えていました。そして、これが次の Beer Break 開発で役立っています。

なお、note PDFy の開発後、多くの人に使ってもらえるサービス開発に必要なのはマーケティングの知識と実践ではないかと考え始めました。 そこで note の記事「【1時間で分かる】P&G流マーケティングの教科書」を読んだり（何度も読みたいのでもちろん note PDFy で PDF として保存しました）、 USJを立て直したマーケターの森岡さんの本や ジョブ理論、 ブランディングの教科書を読みました。

ここでは深く踏み込みませんがマーケティングの考え方を知った結果、市場や消費者に対する考え方が変わりました。 また、エンジニアというクリエイター職をマーケターがどうのように見ているかも理解できました。

レポジトリを見ると360コミット（フロントエンド 300 commit、バックエンド 60 commit）でした。

Beer Break(2021年9月上旬~現在)

現在は Beer Break というビールのレビュー投稿サイトを開発しています。

今開発してるビール画像投稿サイトの名前は Beer Break に決めました🍻
ファーストビューはこんな感じにしようと思います！ pic.twitter.com/agj12HIur5

— プログラミングをするパンダ@Beer Break 開発中🍺 (@Panda_Program) November 28, 2021

使用技術は Next.js + Tailwind CSS ですが、バックエンドに Firebase に代替である BaaS である Supabase を利用しています。 また、基本的な UI は note PDFy で作成した UI コンポーネントをそのまま流用しています。

note PDFy に比べて画面数もコンポーネント数も増えたので、さらに多くのコンポーネントを UI コンポーネント集に追加しています。 UI コンポーネント集は段々と育ってきており、Storybook のコンポーネントも多様になりました。

Beer Break 開発のモチベーションは、ちゃんとした UGC のサイト（User generated content。ユーザーの投稿がコンテンツになるサイトのこと）を作ることでした。 そこで、Supabase でフィジビリティ調査を1ヶ月ほど実施し、機能的に問題ないことを確認しました。

その過程で Postgres の DB のテーブル設計をしたり、Supabase の使い方を調査した結果を Zenn のスクラップ にまとめています。

現在サイトは完成しておらず、また機能としては一般的な UGC であるため、プロダクト自体に特筆するところは今のところありません。 そこで、開発の過程で工夫した点を紹介します。

工夫のポイント4点

1. Changelog 駆動開発

今は Changelog 駆動開発（Changelog に TODO リストを記述し、1つずつタスクを処理すること）で開発しています。

この効用は、パソコンを開いた時に次にやることが明確であることです。 もし TODO リストがないと「今日は何をやろうかな」と考えながらエディタではなくブラウザを開いてネットサーフィンが始まるでしょう。それは時間の浪費です。

自分の時間というリソースを上手に活用するため、タスクに優先順位をつけて着実に開発を進めることを意識した結果、この形になりました。 初めは Trello や GitHub Issue を使ってタスク管理していたのですが、個人開発である限り他人に詳細を共有する必要がないのでシンプルな TODO リストに落ち着きました。

2. 個人開発に取り組んだ時間を記録する

また、個人開発に充てている時間を記録するようにしました。 これは心理学でいうところの「認知の歪み」を矯正するために有効な手段です。

具体的には、このシートで作業を振り返ることで「たくさん時間をかけたのに少ししか進んでいない」、「やらないといけないのにもう何日間もサボってしまっている」という思い込みを修正することが可能です。

前者に対しては、工数という客観的な数字を見返すことにより「大変な実装だったから時間をロスしてしまった。自分に実力が足りないからだ。だけどシートを見ると6~8時間しか使っていない。これは1人日だからそこまで大変じゃなかったな」と自分を納得させられます。

後者は、「何日もサボってるように思ったけど、シートを見ると1日や2日しか休んでいない。しかもこの2日間は飲み会や家族と過ごす時間に充てたからリアルな人間関係を重視することはいいことだ」と、記録のおかげで明日からまた取り組もうという気力が湧いてきます。

ただし、絶対にしてはいけないのは取り組んだ時間を時給で計算することですね（笑）。 フロントエンドエンジニアなら3000円から3,500円が相場かなと思いますが、単純に時間と単価を掛け算をしたらかなりの金額を稼げています。ただ、副業と個人開発ではプレッシャーと責任が全然違うので、実のところ単純な比較はできないですが。

3. 開発者ギルドの Slack に参加する

個人開発者の集まりである運営者ギルドの Slack に参加しました。 目的は個人開発を継続する仲間の姿を見たかったからです。

個人開発の鬼門は、技術的な課題の解決やマーケティング課題の解決ではなくモチベーションの維持です。

おそるおそる Slack に入ってみると、自分がエンジニアになる前にブログを読んでいたジャバ・ザ・ハットリさんや Zenn を開発した CatNoseさん、個人開発したサイトを売却した nabettuさん、英単語辞書&暗記アプリ BooQs のかわんじさん、投げ銭アプリ Baskadia の小林さん（いつも Slack の投稿に対してスタンプありがとうございます☺️）などなど、ここに挙げきれないほどの個人開発のスタープレイヤーと話す機会がありました。

毎月のユーザーの増加具合やサブスクの売上データ、投資家にアプリを見せて出資を募ったことやサイトをリリースした週に100万 PV があったことなどの投稿が日々されているため、自分も頑張ろうというモチベーションが湧いてきます。

4. マーケティングの手法を取り入れる

note PDFy の反省を踏まえてマーケティングの書籍をいくつか読んだため、早速その手法を実践することにしました。 例えば、以下のツイートはテストマーケティングの手法です。

飲んだビールの画像を投稿できるサイトのプロトタイプを作ってみました。30RT、100いいねを超えたら開発を進めてみようかな pic.twitter.com/Hhaev0fWhp

— プログラミングをするパンダ@Beer Break 開発中🍺 (@Panda_Program) August 29, 2021

自分の Twitter のフォロワーはほとんどがエンジニアの方なのですが、それでも目標としたいいね数、RT数を超えたので開発しようと決めました。

本当は、初速の PV 数がすごいねと言われるサイトの告知ツイートは3000いいねくらい貰っているのは知っています。このため、自分のツイートは全然人の興味を惹けていないと思うのですが、今は Twitter での宣伝のみならず違う媒体で宣伝して認知をもっと広げれば使ってくれる人も増えるのではないかという仮説を立てているのであまり気にしていません。

認知率という言葉はキーワードです。 note PDFy も認知を広めていなかったためユーザー数が増えていないと推測しています。実際、note を使っているユーザーのためのツールなのに、Twitter で告知しかしていなかったです。 このため、今はツールを必要としている人に認知されていないからユーザー数が増加しないと考えています。

マーケティングの考え方を知る前は、自分のツールがイケてないからだ、Chrome の機能で十分だとみんな思っているからだ、機能が足りないから使ってもらえないのだと思っていました。 しかし、実際は認知率を上げるところから市場との勝負が始まるのです。

下に掲げる消費者のマインドフローを考慮すると、サイトやツールを使ってもらうためにはまず認知をとる、つまり多くの人に知ってもらう必要があります。 認知がなければいくらいいプロダクトを作っても成長は始まりません。

マインドフローは実戦マーケティング思考という本に記載されていたフレームワークです。

このフレームワークに従って、Beer Break はリリース後、しっかり宣伝をしようと思っています。

今考えている具体的な案は Facebook、note で記事を執筆、Pinterest でサイトの画像を投稿、自分の Instagram のアカウントで投稿、企業の Slack の「ビール部」に投稿をお願いするくらいですが、何かいい案があれば自分の Twitter までご提案いただければ幸いです。

色々考えることはあるのですが、まずは Beer Break のリリースに向けて一歩ずつ実装を進めていきます。 ビールを飲んだら写真を撮る、という方はぜひリリースしたら Beer Break に投稿していただければとても嬉しいです！

なお、Beer Break のコミット数は現時点で既に 1,200 です。

2021年の個人開発まとめ

2021年は今まで以上に時間的、精神的に時間を個人開発に割くことができた年でした。

今年の個人的なトピックとしては、2年半勤めた会社からの転職したり、イーサリアムを買ってNFTを1つ買ってみたり、住宅ローンを組んで家を購入しました。そのようなパーソナルな話もそのうちエッセイの形で記事にしたいと思っています。

2022年はエッセイを書くパンダというアカウントで、技術記事以外にも IT業界での働き方や個人開発・プログラミング、旅行、お金の話、家族の話など日々のことをエッセイを書いていきます。

ぜひ note のアカウントのフォローや記事に対するいいねもお願いします！

以上、プログラミングをするパンダでした。

2021年12月も下旬に差し掛かった。毎年恒例の年末進行だ。去年はできなかった対面での忘年会がいくつかあった。珍しいことに、大学の部活や寮の同期・後輩はソフトウェアエンジニアが多い。

情報系の大学院に進学して就職した者、文系から新卒でエンジニアになった者、全く別の職種で就職して、社会人からプログラミングの勉強を始めてエンジニアに転職した者。自分も最後のタイプの一人だ。同窓会を開くたびにエンジニアが増えていく。

彼らとエンジニアのキャリアについて話した。 その中で挙げられた選択肢は、同じ会社で働き続ける場合はエンジニアのままテックリードなど知識・スキルを深化させ会社のために活かす役職につくか、マネージャーになってメンバーの成果を最大化することに注力するか、間をとってプレイングマネージャーになるかだった。

もし会社を飛び出すなら、仲間を見つけて起業してCEOもしくはCTOになるか、フリーランスのエンジニアになるかだ。情報系学部以外卒のエンジニアのコンプレックスを解消するために大学院に行っても良い。この場合、働きながらでも良いし、フリーランスになって週2日働きながら大学院に通っても良い。実際、最後に挙げた例を選択をした知人もいる。

翻って自分と向き合ってみる。すると今やりたいことは現在の仕事と、Webサイトを個人で開発して多くの人に使って貰えるサービスを作るという挑戦をすること。そして、こうして文章を書くことだ。

私にとって綺麗なコードを書くことと綺麗な文章を書くことは感覚的にとても近い。 例えば、文章の構成を練ることとコードの設計をすることは似ている。他人の文章の引用や自分の知識、言い回しが正しいことを確認することと、言語、フレームワーク、ライブラリの使い方を調べることも似ている。人が読みやすく理解しやすい文章になるようブラッシュアップすることとコードのリファクタリングはさらに似ている。リファクタリングが私の一番好きな作業だ。

世界中で使われているブログツールであるWordPressの作者は「Code is Poetry」という言葉を好んで使っている。コードは詩であるというのだ。 実際、wordpress.orgの最下部にはこの言葉が刻まれている。コードはコンピュータへの命令である一方、読み手である人間に様々な感情を呼び起こす。良いコードと良い文章が読み手に与える印象はとても似ている。

振り返ると小学生の頃の夢はジャンルは問わず、何らかの本を出版することだった。しかし、大人になってコードを書くようになりWebサイトをPublishすることはあっても、本を出版することはできなかった。コードを書けばコンピュータは動く。だが、文章を書いても人の心が動くかはわからない。 結果のわからないことに対して人は腰が重くなるものだ。

私はかつてネット上に文章を書くこともしていた。中国万事通 というサイトを作って自分の中国旅行を記録していたのだ。当初WordPressで作成したこのブログサイト（現在はGatsbyで作り直している）が、自分に文筆家としての富や名声をもたらすことはついになかった。しかし、このサイトを立ち上げて自力でカスタマイズしたことが、自分にWebエンジニアとしての道を開いてくれたのだった。

エンジニアとして働き始めて来月で5年目だ。起業も大学院への進学も自分の今やりたいことではない。周りのエンジニアと考えることは違うかもしれない。だが、30歳を迎えたこの1年間は余暇を使ってもう一度子供の頃の夢を追ってみようと思う。 1~2週間に一度、noteにエッセイを投稿することにした。旅行のこと、キャリアのこと、家族のこと、お金のこと、色々書いていきたい。ただ、SNSで現実のコミュニティを引き継いでいる現代のインターネットは完全に匿名ではないので、仕事の話題はあまり多くないかもしれない。

私の好きなCreepy Nutsと菅田将暉の「サントラ」という曲の中で、歌手も役者も人の感情以外は何も生み出さない仕事と語られているが、エッセイというジャンルもその一つだ。 それでも、文章を書き残すことで自分の足跡を残し、それが読んで貰える人にとって少しでも役に立つなら恐縮であり光栄でもある。次の投稿の内容を考えつつ、今回は筆を置くことにする。

この記事は Next.js アドベントカレンダーの11日目の記事です。

Next.js が好きな理由と2年間使い続けてきた感想

私が Next.js を使い始めて2年が過ぎました。**Next.js を取り巻く現在の状況は2年前と比べると激変しており、Next.js を利用している企業、ユーザーが大きく増えています。**今では chibicode さんが作成された Next.js の実践的な公式チュートリアルもあるし、有志によって翻訳されたドキュメントの日本語訳もあります（私も本当に微力ながらお手伝いしました）。

しかし、2年前の日本では Vue.js, Nuxt.js の勢いがすごく、Google 検索で「Next.js 〇〇」と入力しても結果に「もしかして: Nuxt.js 〇〇」と毎回表示されるほどでした。フロントエンドで開発するなら React ではなく Vue.js を選ぶのが良いと様々な記事で書かれていた記憶があります。

一方 React はというと、 Hooks の登場により、日本での人気を取り返し始めつつあるという環境でした。それ以前では Redux のボイラープレートを嫌って日本の開発者が React から Vue.js に流れてしまったと先輩から聞いたことがあります。そんな2年前はまだ「React で開発をするなら Create React App を選ぶ」ことが定石だったように記憶しています。

2年経った今では Next.js のカンファレンスも開催されるようになり、**一定以上の規模のサイト React で開発するなら Next.js を採用するのが一般的になったように見受けられます。**自分にとって節目の時期なので、少し過去を振り返ってみようと思います。

そこで、この記事では Next.js を使ってきて好きだと感じる点を紹介していきます。

Next.js のここが好き

自分が好きな点は、大まかに以下のようなところです。

• 覚えることが少ない
• JS の様々なライブラリを組み合わせて開発ができる
• React で Web アプリを作る際に必須のライブラリ選定が不要
• その他
  • 様々なライブラリを利用したサンプルが豊富
  • DX 向上に力を入れている
  • Vercel 社が開発している OSS であり、プロジェクト継続の安心感がある
  • 社外のチームを巻き込むのが上手い

以下では1つずつ説明を加えています。ただ、他にも API Route で簡単に API が作れる、メジャーバージョンが上がっても Breaking Change が少ないなど、細かいところを上げると枚挙にいとまが無いので、説明するのはある程度大きな話題に絞っています。

覚えることが少ない

React 開発者にとって、Next.js はそれほど学習コストを払う必要なく使えるフレームワークです。 一般的なフルスタックフレームワークと異なり、フレームワーク特有の書き方（いわゆるお作法）が少ないからです。

**サーバーサイドの一般的なフレームワークを使う時は、使われているプログラミング言語以外の学習が必要です。**学習対象は、ルーティングの書き方、DI の設定方法、モデルのメソッドには何があるのかなど、Web アプリを作るに当たり必要で便利な機能です。 また、その書き方はフレームワークが依存しているライブラリに左右されることもあります。

**Next.js にはそのような学習コストを払う必要はほとんどありません。**直感的に使えて覚えることが少なく、React の学習が終わってから何か Web サイトを作りたいと考える方にもオススメできます。

実際、以前業務で React 初心者のサーバーサイドエンジニアの方（すごく吸収が早くて優秀な方）と3ヶ月間ほど Next.js で Web アプリを作る経験をしたのですが、コードレビューでコメントした点は React の挙動の解説と TypeScript の書き方くらいだったように記憶しています。

**ただし、例外は SSR と SSG に関連する getServerSideProps / getStaticProps / getStaticPaths です。**これらは手元でコードを実行して挙動を確認するなど、学習が必要な機能です。以前はデータフェッチなら getInitialProps に書けばいいという設計だったので、データフェッチに関して考えることは少なかったのですが、ここは少し腰を据えた学習が必要です。

さて、Next.js はフルスタックフレームワークではなく覚えることが少ないという特徴は、次の「JS の多様な資産を活用できる」という利点に繋がります。

JS の様々なライブラリを組み合わせて開発ができる

Next.js はフルスタックフレームワークではないため、入力のバリデーションを行いたいときやテーブルからデータを取得したいときは、自分でライブラリを選定する必要があります。

この点はフルスタックフレームワークの特徴と表裏一体です。フルスタックフレームワークの方は基本的なライブラリ選定の必要はなく、一般的な Web サイトの開発に必要な機能を備えているのに対し、Next.js にはそれがありません。

しかし、特定の書き方やライブラリに依存していないからこそ Next.js は多様な JS の資産をフル活用できます。つまり、自分の好きなライブラリを自由に組み合わせてアプリを開発することが可能になるのです。

また、それらのライブラリは直接使用でき、プラグインをはさむ必要はありません。このため、以下のような開発者のペインを避けられます（以下は実際に自分が見聞してきたことです）。

• あるライブラリを使用したいがそれ用のプラグインがないためライブラリが使えない
• プラグインを使うべきか、そのまま元のライブラリを使うべきか議論に時間を取られる
• ライブラリのバージョンが上がったのにプラグインが依存しているバージョンが古いため、ライブラリの新機能が使えない

ライブラリを自由に選定できるということは、ライブラリの盛衰に影響されないということです。一方で、技術選定の視点が必要になり、組織やチームにあった決断をする必要があるため、学習コストというよりは意思決定の部分で労力や調整が必要になるでしょう。これらの点はトレードオフです。

なお、Next.js を元に作られた Blitz は、バリデーションのライブラリに zod を、DB 接続に Prisma を選んでいるなど、Next.js をフルスタックにしたフレームワークです。

Next.js 自体はフルスタックのフレームワークではありませんが、次に紹介するような痒いところに手が届く機能を備えています。

React で Web アプリを作る際に必須のライブラリ選定が不要

Create React App を使って Web アプリを作るに当たって、毎回最初にしていたことは Router ライブラリ（react-router）のインストールでした。また、SSR 対応の有無もサイトの設計段階から検討が必要な項目だったように思います。

一方、Next.js には同梱の Router ライブラリがあります（next/router）。このモジュールを import するだけで簡単にページ遷移の実装ができます。また、ファイルルーティングを採用しているため URL とページコンポーネントの対応が直感的にわかります。

これにより、「このパスでアクセスしてきた時はこのコンポーネント / Viewを表示する」という、サーバーサイドのフレームワークで一般的なルーティングの記述が不要になります。

**また、Next.js は SSR の機能を備えているので、SSR が必要ならいつでも後から設定できます。**関数を1つ追加するだけでページ単位で SSR できるのはとても魅力的です。さらに、優秀なエンジニアの方が Next.js 本体で最適化をしてくれているので、Next.js のユーザーは難しいことを考える必要がありません。

Next.js が一般的になる以前、自前で SSR を実装する方法は何種類かあった上に、パフォーマンスのチューニングに苦労したと読んで記憶があります（ただ、自分で SSR 対応はしたことがなく、当時読んでいた記事の記憶で書いているため誤っている可能性があります）。

Next.js はフルスタックフレームワークではないものの、フレームワークだったら備えていてほしい機能がちゃんと用意されているところが自分の好きな点の1つです。

その他の特徴

様々なライブラリを利用したサンプルが豊富

**Next.js は様々なライブラリと組み合わせて使えるため、そのライブラリの設定や Next.js での簡単な使い方が examples のページに紹介されています。**このサンプルがとても豊富で重宝します。

**Next.js で自分が使いたいライブラリがあれば、この examples の中を検索すると大抵見つかります。**ただし、本当に hello world 程度なので、もしそのライブラリを使い込むのであればそのライブラリの公式ドキュメントを読み込むことが必要になります。

DX 向上に力を入れている

**Next.js はインストールしてすぐに使えます。**Webpack などの設定が不要だからです。そして、Webpack の設定をカスタマイズしたい時にはそのための記述も可能です。

また、以前は .env ファイルから環境変数を読み取ったり、scss を使って開発する際にはそれを実現するモジュールを使ったり、設定を記述する必要がありました。例えば、scss を使って CSS Modules を使う場合、next.config.jsに以下のように記述していました。

// next.config.js
const withSass = require('@zeit/next-sass')

module.exports = withSass({
	cssModules: true,
})

しかし、後のアップデートで CSS Module はデフォルトで使えるように、scss は npm install sass をするだけで使えるようになりました。このようなアップデートも DX 向上のためには嬉しい点です。

Vercel 社が開発している OSS であり、プロジェクト継続の安心感がある

Next.js の調査をしているときに、業務で導入するための説得がしやすかったのがこのポイントです。Next.js は OSS ですが、個人が開発しているプロジェクトではなく、Vercel 社が開発しているため、コアコントリビューターがいなくなって急に開発がストップする可能性はとても低いと考えられます。

社外のチームを巻き込むのが上手い

Next.js の開発主体は Vercel 社内に止まりません。これは OSS なので当然といえば当然です。ただし、Next.js は個人のコントリビューターのみならず、Facebook や Google といったテックジャイアントを積極的に巻き込んで特定の機能を開発しているのは特徴と呼べると考えています。

これは Next.js v11 リリースのブログからコミュニティに対する謝辞の中に両社の名前が追加されたことからもわかります（他社との共同作業自体は v9 あたりから 始まっています）。

例えば、Next.js は React の新機能である React Suspense や Streaming API などに対応しようとしています。この作業は React のコアチームと共同で行われています。また、画像の表示を最適化する Image コンポーネントやコードの分割の最適化は、Google と共同で開発されたとのことです。

次に述べるように Next.js を開発している Vercel 社の目的の1つは Web を速くすることであり、その目的のためにやれることをなんでもやるという姿勢が伝わってきます。

Next.js と Vercel 社に賭けよう

Vercel 社の目標の1つは Web を速くすることです。Web を速くするとは、「Web 開発の速度を速くする（＝リリースサイクルを早める）」ことと「ユーザー（クライアント）に高速に配信すること」の二つの意味があります。

最近 Vercel 社からその2つの側面がよく表れた発表がありました。前者に対しては、Rust 製コンパイラ swc の製作者と Pecel の作者を Vercel 社に採用したこと、後者に対しては Svelte の開発者を採用して、Svelte 開発に専念できるようにしたことです。

そしてビルドの速度を速くする swc を Next.js に組み込んだり、React より配信する JS のサイズが小さくて済む Svelte¹ のカンファレンスに Rauch 氏が登壇したりしています。

Vercel 社がさらに気になった方は CEO の Rauch 氏のブログ記事もぜひご一読ください。「Vercel は Next.js の会社だ」という印象がきっと変わるでしょう。

• 7 Principles of Rich Web Applications
• Vercel (日本語訳)
• Making the Web. Faster.

そんな Vercel 社が開発する Next.js に対する好きな点の紹介でした。これからも Next.js の進化が楽しみです！

（なお、本記事は自分の主観と昔の記憶が入った記事なので、事実の誤認があれば Twitter で遠慮なくご指摘ください）

Footnotes

1. https://macos.vercel.app/ の作者によると、元々 React で作っていた時は 146KB minify + brotli（圧縮）で JS は146kb だったそうですが、Svelte で作り直してさらに機能を追加した現在は 28.5KB のJS と 3.6KB の CSS で済んでいるそうです。詳しくは作者のブログをご覧ください。 ↩