GraphQLとそのクライアントライブラリ「Apollo Client」の話です。  
業務でApollo Clientを触る機会があったため、使い方の紹介と感想です。

## GraphQLの特徴

### スキーマ Schemaについて

スキーマはGraphQLにおいて、APIとクライアント間のインターフェースとして利用されるIDLです。

```graphql
type Post {
  id: String!
  created_at: DateTime!
}
```

クライアントからは
- request / responseの型情報
- データ取得関数の自動生成
として利用されます。

この型があることで、補完が効いて開発効率が上がる・型安全になり修正/リファクタ時の負荷軽減が期待できます。

e.g. `$ tsc --noEmit` でAPI変更の影響をざっくり知ることができる

### RESTとの比較

主に下記のような差分があると考えています。
- クライアントがレスポンスを組み立てる
- 基本的に「リソース=リゾルバ」になるためエンドポイント単位でのサブリソースの管理が不要
e.g. 記事ページのAPIにコメントを生やしたが、他ページでもコメントを取りたくなった

GraphQLはクライアントファーストな仕組みと言うことができ、  
SPAが普及してクライアントに複雑性が移動してきた背景を考えるとGraphQLの登場は自然な文脈だと考えられます。

ただし、利用してみて学習・環境構築コストが高く、  
パフォーマンス出しにくいという学びがあったため使い所は見極める必要があると思います。
(シンプルなアプリケーションには向かない)

## Apollo Client

GraphQLクライアントライブラリで、旧facebook社が開発したRelayと2大巨頭。  
クライアント以外にもApollo Serverというライブラリが存在していて、  
Apollo StudioというGraphQLプレイグラウンド・パフォーマンストラッキングなどを行うSaaSと連携できる。  
(課金プランがあるため、使いたい機能がなければ使わないのが無難そう)

https://www.apollographql.com/docs/react/why-apollo/

後発ながら機能が豊富で利用者が多くRelayに比べてfragment collocationは強制されないなど制約が弱めです。  
ツールチェイン周りもRelayはビルトインなのに対して、Apolloはサードパーティのツールを必要とします。  
(GraphQL Code Generator)

https://www.the-guild.dev/graphql/codegen/plugins/typescript/typescript-react-apollo

### apolloで状態管理を行う

コンポーネントを跨いで利用したい状態をグローバルステートと呼び、  
その状態の管理方法が「状態管理」と呼ばれている。  
状態管理で扱うデータの種類は大きく「API経由、それ以外データ」の2つに分類できる。  

この状態管理にはReduxやFluxが利用されるのが通例だが、  
下記のような課題があり recoil などのシンプルな状態管理ライブラリが登場してきている。  
- 概念自体が難しくて初見殺し (バックエンドエンジニアが触りたくなくなる)  
- API経由データの通信状態の遷移を表現するためにmiddlewareが必要
- action, action creator, reducerボイラープレートが多くて大変
- コード量が多くなると職人が必要

また、シンプルな状態管理ライブラリとは別に SWR, useQueryといったキャッシュ機構を持ったfetchライブラリが流行ってきた。  
これらはAPIから取得・変更されたデータをメモリキャッシュとして保持して、
fetch時にキャッシュを自動更新するという機能を提供している。

Apolloもキャッシュ機構を持っていて、上記に加えてオブジェクトごとに正規化してくれる機能がついている。

```js
// __typename x idを識別子としてユニーク性を担保
{
  __typename: 'Post',
  id: 'uuid-1',
  name: 'something'
},
{
  __typename: 'Post',
  id: 'uuid-2',
  name: 'anything'
}
```

この機能によって、下記のような挙動が可能になる。
- ミューテーションで記事を更新する
- 記事一覧のキャッシュが更新される
- 記事一覧の表示が更新される

Reduxで行われていた `dispatch(action, data.payload)` する処理を自動的に行なってくれている。

また、APIを経由しないデータについても「Reactive variables」が利用できる。
layout層にマウントされている共通モーダルの状態などに利用できる。

https://www.apollographql.com/docs/react/local-state/reactive-variables/

```js
// store.js
const flagVar = makeVar(false);

// component.jsx
const Component = () => {
  // flag変更がreactiveに検知される
  const flag = useReactiveVar(flagVar);
  return <div onClick={() => flagVar(true)}>{flag}</div>;
}
```

なお、この機能はリリースされたてのためデバッグ用の拡張機能などが対応していない。
そのため複雑なオブジェクトなどの状態管理には利用しない方が良さそうだと思っている。

## GraphQL Code Generator

下記を自動生成してくれるツール↓
- APIのレスポンス型
- データ取得のhooks

https://www.the-guild.dev/graphql/codegen/plugins/typescript/typescript-react-apollo

APIでスキーマ作成、クライアントにオペレーション(query/mutation)のコードを書いて、
CLIからコマンドを叩くと自動生成される仕組みになっている。

**スキーマ**

```graphql
# ルート型
schema {
  query: Query
  mutation: Mutation
}

type Query {
  # フィールド
  post: Post
}
# オブジェクト型
type Post { id: String! title: String }

type Mutation {
  update_post(input: UpdatePostInput!): UpdatePostMutation!
}
type UpdatePostInput { id: String! title: String! } # パラメータ
type UpdatePostMutation { post: Post } # レスポンス
```

**オペレーション**

```graphql
query PostPage {
  post { # フィールド
    id
    title
  }
}

mutation PostPageUpdate($input: UpdatePostInput!) {
  update_post(input: $input) {
    id # ここからレスポンス
    title
  }
}
```

**生成されるコード**

```ts
// レスポンス型
type PostPageQuery = {
  __typename: 'Post';
  id: string;
  title: string | null | undefined;
};
// hooks
const usePostPageQuery = useQuery(...);

// レスポンス型
type PostPageUpdateMutation = {
  __typename: 'PostPageUpdateMutation';
  post: Post;
};
// hooks
const usePostPageUpdateMutatiion = useMutation(...);
```

**hooksの利用方法**

```ts
const Component = () => {
  const { data, loading, error } = usePostPageQuery();
   
  const [mutate] = usePostPageUpdateMutatiion(); // 関数取得
  const handleUpdate = async () => {
    try {
      const { error } = await mutate();
      if (error) return throw error;
    } catch { // エラーハンドリング }
  };

  if (error) return throw error; // エラーハンドリング
  if (loading) return <div>Loading</div>; // ローディング中

  return (
    <>
      <div>{`${data.post.id}: ${data.post?.title}`}</div>
      <button onClick={handleUpdate}>更新</button>
    </>
  );
};
```

## 開発フローについて

GraphQLのライブラリは言語ごとに多種多様だが、  
開発方法は主に2種類(ハイブリットも出てきているらしい)に分類できる。
- Code First  
APIの型・リゾルバーを先に実装して、スキーマを生成するタイプ  
- Schema First  
スキーマを先に作っておき、コード生成するタイプ (gqlgenなど)  

コードファーストのライブラリを利用する場合、  
フロントはスキーマができるまで型や自動生成されたhooksを利用することができない。  
そのため、コードファーストはフルスタックなチームに適している方式なんだろうと想像している。

スキーマファーストの場合、  
フロントがスキーマを書いてバックエンドが具体的なロジックを実装するという方式が取れそう。

いずれにしてもスキーマはRESTに比べて慎重に決める必要があって、
デザイン・ER図ができた段階で相談するタイミングを設ける必要がありそうだと思っている。

なお、第2世代(あるいは第3世代)コードファーストというものも出ていてモデルから型を自動抽出したりしてくれるらしい。
(第一世代はリゾルバーを書くときに手動で定義する)

https://user-first.ikyu.co.jp/entry/2019/12/16/113332#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88-vs-%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%9E%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88
## 最後に

下記に苦戦したのでどこかのタイミングで記事にしたい。  
- fragment collocation  
- persisted query  


Apollo Clientで始めるGraphQLと状態管理

[microCMS Advent Calendar 2021](https://qiita.com/advent-calendar/2021/microcms) 12日目の記事です。

microCMSに投稿したマークダウン文章をNext.jsのSSGビルド時に、タイトル・リンクなどの要素をコンポーネントに変換する方法について紹介します。  

紹介する方法では投稿時の文章にコンポーネントを含む必要がないため `≒MDX` と表現しています。  

```ts
// MDXの場合
<CustomHeading as="h2">title</CustomHeading>
<CustomLink href="https://google.com">link</CustomLink>

// Markdownの場合
## title
[link](https://google.com)
```

MDX文章として記事を管理する方法と比べて、コンポーネントに変更があった場合に記事の方は `# タイトル` のようなマークダウン構文のままで良いため、修正しなくて良いというメリットがあります。  

```ts
e.g. コンポーネント名やpropsのインターフェースを変更
<Heading level={2}>
↓
<CustomHeading as="h2">
```

## 技術構成について

- Next.js (12.0.4)
- TypeScript
- microCMS
- vercel (Node.js Version 14.x)
- next-mdx-remote (3.0.8)

microCMSへの記事投稿をフックにvercelでNext.js SSGビルドが走る仕組みです。  
https://zenn.dev/tkc310/articles/792582ae9ad131

なお、執筆時点でNode.js LTSは16.12.1ですが、vercelは14系までしか対応していないためご注意ください。  

コンポーネントへの変換には [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote) というライブラリを利用しています。  
(hashicorp謹製)  

## 実装方法について

ほぼ、next-mdx-remoteの使い方の解説になってしまいます。

### 実装の概要

[README example](https://github.com/hashicorp/next-mdx-remote#examples)に記載されている方法を利用します。  

```ts
import { GetStaticProps } from 'next'
import { serialize } from 'next-mdx-remote/serialize'
import { MDXRemote, MDXRemoteSerializeResult } from 'next-mdx-remote'
import ExampleComponent from './example'

const components = { ExampleComponent }

interface Props {
  mdxSource: MDXRemoteSerializeResult
}

export default function ExamplePage({ mdxSource }: Props) {
  return (
    <div>
      <MDXRemote {...mdxSource} components={components} />
    </div>
  )
}

export const getStaticProps: GetStaticProps<MDXRemoteSerializeResult> = async () => {
  const mdxSource = await serialize('some *mdx* content: <ExampleComponent />')
  return { props: { mdxSource } }
}
```

大枠の処理の流れは下記です。  
1. 記事の取得  
`getStaticProps` (SSGビルド時に呼び出される) でmicroCMSからマークダウン文章を取得  
2. mdx文章をhtmlに変換  
`serialize` で `mdxSource` に変換する。  
(mdx -> react elementに変換された文字列 + ライブラリ用のapiが生えたオブジェクト)  
3. 描画用のコンポーネントに渡す    
`<MDXRemote {...mdxSource} components={components}>` のように `mdxSource` を与えるとhydrateしてくれる。  
このとき `components` に、各要素に対応するコンポーネントをマッピングしたオブジェクトを指定する。  
`e.g. { img: (props) => <CustomImage {...props} /> }`

2,3について、詳しく説明していきます。

### mdx文章をhtmlに変換

Next.jsの `getStaticProps` 関数でmicroCMSで投稿したマークダウン文章を取得して、htmlに変換します。  

なお、このライブラリは名前の通りMDXに対応しているためMDX文章でもhtmlに変換してくれます。  

```ts
// getStaticProps
const res = await fetch(url, key);
const article = await res.json();

const mdxSource = await mdx2html(article.body);
```

変換する処理は `mdx2html` のように関数に切り出しています。  

[オプション](https://github.com/hashicorp/next-mdx-remote)としてmdx.jsのAPIが利用できるため、  
下記のプラグインも併用しています。

- `rehypePrism` - コードのシンタックスハイライトを適用  
- `imageSize` - 画像のwidth, height属性を利用できるようにする  

https://mdxjs.com/docs/extending-mdx/

```ts
// mex2html
import { serialize } from 'next-mdx-remote/serialize';
import { MDXRemoteSerializeResult } from 'next-mdx-remote';
import rehypePrism from '@mapbox/rehype-prism';
import imageSize from 'rehype-img-size';

export const mdx2html = async (
  mdxText: string
): Promise<MDXRemoteSerializeResult> => {

  const mdxSource = await serialize(mdxText, {
    mdxOptions: {
      remarkPlugins: [],
      rehypePlugins: [
        [rehypePrism, {}],
        [imageSize, { dir: 'public' }],
      ],
    },
  });
  return mdxSource;
};

export default mdx2html;
```

### 描画用のコンポーネントに渡す

前述の `mdxSource` を `<MDXRemote>` に渡します。  

```ts
interface Props {
  mdxSource: MDXRemoteSerializeResult
}

export default function ExamplePage({ mdxSource }: Props) {
  return (
    <div>
      <MDXRemote {...mdxSource} components={components} />
    </div>
  )
}
```

`components={components}` には、下記のようにhtml変換後の各要素に対応するカスタムコンポーネントをマッピングしたオブジェクトを渡します。  

```ts
const mdxComponents: any = {
  h2: (props) => <CustomHeading as="h2" {...props} />,
  h3: (props) => <CustomHeading as="h3" {...props} />,
  img: ...省略,
  a: ...省略,
};

type Props = {
  as: 'h2' | 'h3' | 'h4' | 'h5' | 'h6';
  children: ReactNode;
};

const CustomHeading: VFC<Props> = ({ as, children }) => {
  const CustomTag = as;
  return <CustomTag>{children}</CustomTag>
}

export default mdxComponents;
```

なお、MDX文章をソースとする場合は下記のようにコンポーネントも定義できます。  

```ts
import { FaBeer } from 'react-icons/fa';

const mdxComponents: any = {
  <FaBeer />,
  h1: ...省略,
};

export default mdxComponents;
```


解説は以上になります。

実装コードは公開していますので、下記からご確認ください。  
https://github.com/tkc310/microCMS_blog

- 記事取得 `getStaticProps`  
https://github.com/tkc310/microCMS_blog/blob/main/src/pages/articles/%5Bid%5D.tsx#L91-L138
- mdx -> html変換 `mdx2html`  
https://github.com/tkc310/microCMS_blog/blob/main/src/utils/mdx2html.ts#L6-L32
- 各要素 x カスタムコンポーネントのマッピング `mdxComponents`  
https://github.com/tkc310/microCMS_blog/blob/main/src/utils/mdxComponents.tsx#L10-L22
- カスタムコンポーネント `CustomHeading`  
https://github.com/tkc310/microCMS_blog/blob/main/src/components/atoms/CustomHeading/index.tsx
- 描画 `MDXRemote`  
https://github.com/tkc310/microCMS_blog/blob/main/src/pages/articles/%5Bid%5D.tsx#L54


## 最後に

今回の記事ではmicroCMSについてあまり触れませんでしたが、和製サービスでUIも分かりやすくオススメです。  
個人ブログに利用していますが、管理画面から登録したAPIスキーマをJSONとして出力・管理できるためチーム開発する際も便利だと思います。  

アップデートも早くキャッチアップしきれていないため、本記事で紹介した内容もスマートに解決できる方法があるかもしれません。

https://microcms.io/


microCMS Markdownをパース時にコンポーネントに変換する方法 (≒MDX)

## Reactフォームライブラリの比較
https://www.npmtrends.com/formik-vs-react-final-form-vs-react-hook-form-vs-react-redux-form

- react-redux-form: 状態管理にreduxを利用していないため除外
- formic: 再レンダリングパフォーマンスが悪いらしいため除外
- react-final-form
- react-hook-form

https://react-hook-form.com/jp/faqs#question10

### react-final-form vs react-hook-form
react-final-form, react-hook-formを比較する。

#### react-final-form
- 3.2kb (+ final-form 5.2kb)
- ts型ビルトイン
- Blitz.jsで採用されている。
- name, value, handlerなどをコンポーネントに渡す形式

ドキュメント  
https://final-form.org/docs/react-final-form/api
https://final-form.org/docs/react-final-form/types/FieldRenderProps

chakrauiとの併用サンプル
https://codesandbox.io/s/github/final-form/react-final-form/tree/master/examples/chakra?file=/index.js:5672-5679

hooksもある
https://github.com/final-form/react-final-form-hooks

#### react-hook-form
- 8.2KB
- ts型ビルトイン
- react-final-formより人気
- ドキュメントが見やすい、日本語記事も見つかりやすい
- 最大/最小値、必須、正規表現などもビルトインでできる
- refをコンポーネントに渡す形式

ドキュメント
https://react-hook-form.com/api
https://react-hook-form.com/api/useform/register

chakrauiとの併用サンプル
https://chakra-ui.com/guides/integrations/with-hook-form

外部ライブラリのコンポーネント、自作コンポーネントはrefを渡せるようにする必要がある。
自作の場合は `React.forwardRef` で対応できる。
https://ja.reactjs.org/docs/forwarding-refs.html

### 結論
どちらも出来ることに差はなさそう

react-hook-formはrefを渡すインターフェースが特徴的で、react-final-formの方がシンプルに見える。
ドキュメントが充実していて、日本語記事も多いためreact-hook-formを選んでおくのが無難そうではある。

## バリデーションライブラリの比較
バリデーションライブラリの比較をする。
シンプルなAPIのものを利用して複雑なバリデーションは自作する方針にしたい。

**参考記事**
https://bagelee.com/programming/react/validation-library/
https://github.com/react-hook-form/resolvers
https://www.npmtrends.com/io-ts-vs-joi-browser-vs-superstruct-vs-vest-vs-yup-vs-zod
とりあえず沢山あることが分かった..

下記がメジャーで日本語記事もよく見つかる。
- yup
- zod

### yup vs zod
yupとzodを比較する。
zodのREADME.mdに比較内容が記載されている。
https://github.com/colinhacks/zod#comparison

#### yup
- 18.2kb
- デフォルト任意入力
- APIの差分
  - nubmer.round
  - object.camelCase
  - string.trim
  - cast, transform

API
https://github.com/jquense/yup

#### zod
- 11.3kb
- デフォルト必須入力
- APIの差分
  - object.partial, object.deepPartial
  - union, intersection
  - primise
  - function
- Blitz.jsで採用されている (final-form x zod)

API
https://github.com/colinhacks/zod#defining-schemas

Blitz.js
https://blitzjs.com/docs/utilities

yupは途中からzodは最初からtypescriptに対応していたという経緯があるからか、下記の記事に書かれているように型生成時の挙動が安定していない部分があるらしい。
https://bagelee.com/programming/react/validation-library/#4

react-hook-formと組み合わせる場合、zodでnumberを扱う時に `{ valueAsNumber: true }` のような記載をする必要がある。
scheme自体はyupよりzodの方がシンプルに見える。

### 結論
ユーザ数はyupが圧倒的に多いため困った時に助かりそうだが、Blitz.jsが採用している & typescriptフレンドリーなzodを利用してみたいと思った。

## 余談
Ant Designはビルトインで `Form` コンポーネントにtypescript対応のstate管理とバリデーションが付いている。
- ステート管理 `useForm`
https://ant.design/components/form/#components-form-demo-control-hooks

- バリデーション
https://ant.design/components/form/#Rule

async-validatorという薄い(4.5kb)ライブラリが利用されていた。
https://github.com/yiminghe/async-validator

Ant Designを利用する場合はreact-hook-form, zodを利用せず、ビルトインのシンプルなAPIで頑張れそうだと思った。


Reactのフォーム、バリデーションライブラリの比較

## SPAとSSRにおける認証コンテンツの表示方法
JAMstack構成のブログを作った際に、部分的に一般公開したくないコンテンツが出てきたため、SSGにおける認証周りについて考えた。

SPAやSSRの要認証コンテンツの表示方法は想像しやすい。下記の2パターンが一般的だと思う。
### SPAの場合
認証が必要なAPIを叩く際に認証トークンを付与する。
認証トークンが存在しなければログインページ or エラーページにリダイレクトするなどの処理が行われる。

### SSRの場合
認証が必要なページをリクエストする際にクッキーに保存された認証情報がサーバから参照される。認証情報が存在しない場合はログインページ or エラーページにリダイレクトするなどの処理が行われる。

ここで考えたいのは、SSGの場合はビルド時にデータを取得してコンテンツを作成するが、ビルド時点では認証できないということ。

SSGの利点はビルド時にデータを取得してコンテンツを作ってしまうため、クライアントからのリクエスト時にデータを参照しなくて良い点だが、下記のような処理を行う場合はクライアントで非同期に処理したくなる。

- リアルタイム更新が必要なコンテンツの表示
- SEO対策が不要なコンテンツの表示 (初期表示はSSR/SSGの方が早い)
- 認証処理

そのため、上記のような要件が出てきた場合は SSG + CSR という組み合わせで対応する必要が出てくる。

サーバレス関数などで都度SSRした結果を取得する方法もあると思うが、認証が必要なページはSEO対策が必要ないため初期表示のパフォーマンスがボトルネックになっているなどの理由がなければ、CSRしてしまった方が良さそう。

なお、firebaseなどのmBaasをクライアントから利用する場合は、apiKeyなどが露出する気持ち悪さはあると思う。

## Next.jsにおけるSSG + CSR
Next.jsではSSGしたい場合に `getStaticProps` という関数をpages配下のコンポーネントと併せて定義することで、ビルド時に実行されて返り値がコンポーネントにpropsとして渡される。

```js
function Posts({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  )
}
export default Posts

export async function getStaticProps() {
  // ビルド時のみ実行されクライアントでは実行されない
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
  }
}
```

SSRの場合も同じだと思うが、サーバで実行される処理とクライアントで実行される処理が混在する形になる。

クライアントでのみ実行したい場合は、イベントハンドラーやコンポーネントのライフサイクルを利用して非同期に実行する必要がある。

```js
import { useEffect, useState } from 'react';
import Loading from 'components/Loading';

function Posts({ posts }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // ブラウザでマウントされた後に認証する
    const currentUser = useAuthentication();
    setUser(currentUser);
  });

  return (
    <>
      {user ? (
        <div>{user.name}</div>        
      ) : <Loading />}

      <ul>
        {posts.map((post) => (
          <li>{post.title}</li>
        ))}
      </ul>
    </>
  );
}
...省略
```

なお、Next.jsではCSRにおいて非同期にデータ取得を行う場合に `useSWR` というhooksを利用することを推奨している。(認証とはあまり関係ない)  

https://nextjs.org/docs/basic-features/data-fetching#swr

キャッシュやポーリングするためのオプションによって、ISR(部分的な更新)を容易に行えるようにしてくれるらしい。

下記のように `getStaticProps` でビルド時に取得しておいたデータで初期化したい場合は下記のように利用できる。

```js
function Posts({ posts }) {
  const { data } = useSWR('/api/posts', fetcher, { initialData: posts })
  // ...
}

export async function getStaticProps() {
  const config = await fetcher('/api/posts')
  return { props: { posts } }
}
```

~~SSGでISRをしたくなるユースケースが思いつかないので、SSR + CSRのケースでは便利だと思う。~~

ただ `useSWR` では再取得(&差分確認)タイミングを「ブラウザのタブが選択された時」などにカスタマイズできるオプションが設けられているため、それらを目的に利用しても良さそう。

https://taroosg.io/useeffect-vs-useswr

2021/07/21 追記---
ISRはむしろSSGとセットで利用される技術だった。
SSGでビルド時にHTMLを生成・エッジロケーションにキャッシュしておき、ユーザがアクセスしたタイミングでISRでHTMLを再生成、キャッシュを置き換える技術らしい。
ISR利用時に `getStaticProps` を持つpages配下のファイルはSSRするサーバレス関数として振る舞い、リクエストタイミングが設定された `revalidate` の期間を超える場合はキャッシュを置き換える。

zennでも一時期利用されていたらしい。

https://zenn.dev/catnose99/articles/8bed46fb271e44#isr%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B

キャッシュの置き換えは `revalidate` に設定された期間によって一定間隔で行われるため、データ変更キャッシュ置き換えにラグが発生するらしいが、FastlyなどのパージAPIなどを利用すれば(vercelには2021/07/21時点で代替手段がない)、データ変更をフックにISRが実行できるためこの問題は解決される。

https://developer.fastly.com/reference/api/purging/

vercel(とNext.js)がSSG + ISRを推しているため、ブログやニュースメディアなどの更新頻度が少ないサービス以外における今後の利用ケースに注目したい。

## firebase authentication を導入する
サンプルとしてNext.jsのSSGで作ったブログに、firebase authenticationで認証機能を追加して非公開のページを設けてみた。

### 認証の流れを確認
まず、firebase authenticationで認証する流れを確認する。

#### 1. sdkを初期化する

firebaseのjavascript sdkをインストールする。

```bash
$ npm i -S firebase
```

事前にfirebaseでプロジェクトを作成しておき、sdkを初期化する際の設定情報を控えておく。
なお、Next.jsでは環境変数の接頭辞に `NEXT_PUBLIC_` をつけなければクライアントから読み込めないため地味に注意が必要。

```javascript
// lib/firebase.ts
import 'firebase/auth';
import 'firebase/firestore';
import firebase from 'firebase/app';

export const config = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  storageBucket: process.env.NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.NEXT_PUBLIC_FIREBASE_SENDER_ID,
  appId: process.env.NEXT_PUBLIC_FIREBASE_APPID,
};

// initializeを複数回走らせない
if (!firebase.apps?.length) {
  firebase.initializeApp(config);
} else {
  firebase.app();
}

const auth = firebase.auth();
export default { auth };
```

とりあえず認証機能のみ使いたい場合は、上記のように `firebase.auth();` の戻り値のみ `export` しておく。

#### 2. 認証処理、認証判定

大まかには2つの機能で認証が実現できる。

```javascript
import { auth } from "lib/firebase";

// 認証処理
const signIn = async (email, password) => {
  try {
    await auth.signInWithEmailAndPassword(email, password);
    location.href = '/private_pages';
  } catch (error) {
    // 失敗しても前回のセッションは破棄されないため明示的にサインアウトが必要
    await auth.signOut();
    alert("認証に失敗しました");
  }
};

// 認証済みか判定
const ovserveAuth = () => {
  auth.onAuthStateChanged((user) => {
      if (!user) {
        // 認証ページにリダイレクト
        location.href = '/auth/signin'';
      }
    });
};
```

認証ページ・認証モーダルなどで `await auth.signInWithEmailAndPassword(email, password)` を実行して、認証が成功したら認証が必要なページにリダイレクトなどを行う。
なお、認証処理は「メールアドレス・パスワード」以外にも各プロバイダーによるOAuthやカスタム認証が可能。  

ユーザが認証が必要なページで `auth.onAuthStateChanged((user) => {})` を実行しておき、未認証状態でアクセスした場合は認証ページにリダイレクトする。 
なお、認証判定はイベントリスナー(オブザーバー？) で認証状態の変更を監視する形がベーシックらしいが、任意のタイミングで認証状態を確認する方法もあると思う。
(認証済みの場合は `firebase.auth.user` のようにユーザ情報を参照できるなど)

### 導入例
ブログにどのように導入したか確認する。

#### 認証判定はhooksを作成
認証判定はhooksにして、非公開コンテンツとして認証が必要な `pages` 配下のコンポーネントから呼び出す形にした。  
hooksの戻り値でユーザ情報を返しているため、コンポーネントでユーザ情報を利用することができるようにしている。  
認証に失敗して認証ページにリダイレクトさせる際には `callback` クエリにリダイレクト前のpathを付与しておき、認証成功時に戻ってこれる仕組みにしている。

https://github.com/tkc310/microCMS_blog/blob/main/src/hooks/useAuth.ts

hooksを利用しているコンポーネントは下記↓

https://github.com/tkc310/microCMS_blog/blob/main/src/pages/notes/index.tsx#L28-L43

なお、ユーザ情報が存在しない場合はローディングアイコンを表示しているが、コンテンツ自体はSSGで作成済みでHTMLをdeveloper toolsで見てみるとデータが確認できてしまう状態になっている。

#### 認証ページ

メールとパスワードを入力してsubmitすると、前述の認証処理が実行される。  
認証が成功したら `callback` クエリのパスにリダイレクトしている。

https://github.com/tkc310/microCMS_blog/blob/main/src/pages/auth/signin.tsx#L47-L69

## まとめ
firebase authenticationで認証機能を追加して、ブログ内の非公開コンテンツは未認証の場合に閲覧できないようにした。

今回の方法では、事前にSSGで作成したコンテンツを認証状態によって表示・非表示を切り替える形にしたが、developer toolsを利用すれば確認はできてしまう。

絶対に見られてはいけないデータなどの場合は、認証判定を通過した後に非同期に取得する形になりそう。

```javascript
function Posts() {
  const currentUser = useAuth();
  if (!currentUser) return <Loading />;

  const { data } = useSWR('/api/posts', fetcher, { initialData: props.posts })
  return data && data.posts?.length ? (
      <ul>
        {data.posts.map((post) => (
          <li>{post.title}</li>
        ))}
      </ul>
  ) : (
    <Error />
  );
}
```

## 余談
microCMSとfirestoreを組み合わせてるケースを見かけて、面白そうだったため後日firestoreも触ってみたい。

https://yasutomo.hatenablog.com/entry/2020/12/22/092831

microCMSはPOSTリクエストに上限があるので、Todoリストなど頻繁に更新リクエストが飛ぶ機能などにfirestoreを利用してみたいと思った。

JAMstackにおける認証コンテンツの表示方法について

一足遅れですがJAMstackというアーキテクチャが流行っていると聞いて調べてみて、学習欲が湧いてきたのでアウトプット場所も兼ねてJAMstackでブログを作ってみたお話しです。

技術スタックは下記です。
- microCMS (ヘッドレスCMS)
- Vercel (ホスティングサービス)
- Next.js
- Typescript

## JAMstackとは
ホスティングサービスのNetlifyの人が提唱した `Javascript, APIs, Markup` の頭文字を取って名付けたアーキテクチャとのことです。

ザックリ説明するとクライアントはSSGで作った静的コンテンツをホスティングして、更にAPIを使って動的なアプリケーションを作るのがJAMstackらしいです。
特にNext.jsやGatsbyなどのSSGが可能なフレームワークとNetlifyCMSなどヘッドレスCMSとしてAPIだけを提供するようなサービスとを組み合わせたアーキテクチャを指しているようです。

## microCMSを選んだ背景

ヘッドレスCMSの種類もいくつかあるようですが、簡単な受託案件などで利用できる非技術者でも触れるようなサービスを探していたところ、「microCMS」という和製で管理画面もみやすいサービスを見つけたので使ってみました。

APIを変更するユーザ用の画面を提供していて、APIのスキーマをユーザが自由に構築できてAPIの変更をフックにgithubからホスティングサービスにデプロイが行われる仕組みになっています。
スキーマさえ構築しておけば非技術者でも簡単に編集できるので、汎用設定的なスキーマを作ってサイト名やよく変わる文章なども編集してもらうことが可能になります。
(感動ポイントでした)

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/05be8b4c2b504c249f1a7b7cb9689811/microcms_capture.png" 
alt="microCMSの管理画面" />

和製サービスなので、日本語で見やすくて日本の企業がカスタマーサポートしてくれるのもよさそうですね。

NetlifyCMSも使ってみましたが、下記のような仕組みになっていて便利ではありましたが、非技術者に扱ってもらえるようにカスタマイズするにはドキュメントが少なくて学習コストも高そうでした。

> NetlifyにホスティングされたSSGの管理画面を動かして記事を入力・保存すると、githubなどのリポジトリにmarkdownとhtmlに変換された静的ファイルとして保存されて、その後Netlifyにデプロイされる

なお、導入の簡単さはフレームワークも選べてワンクリックなのでピカイチでした↓

**参考記事**

[dev.classmethod.jp/articles/try-netlify-cms](https://dev.classmethod.jp/articles/try-netlify-cms/)

## 導入方法について

microCMSの公式ブログでmicroCMS x Next.js x Vercelを利用したブログの作成方法について紹介されています。

[blog.microcms.io/microcms-next-jamstack-blog](https://blog.microcms.io/microcms-next-jamstack-blog/)

下記がハマりポイントでした。
1. microCMSの入稿データ(リッチエディタ形式)がどのような工程を経てブログに表示されるのか
2. Next.jsでSSGする仕組み
3. シンタックスハイライトする仕組み

### 1. microCMSの入稿データ(リッチエディタ形式)がどのような工程を経てブログに表示されるのか

下記の流れです。
- 文章や汎用設定などの動的データを取得できるAPIをmicroCMSで作成
- WebフックでVercel上のSSG(Next.jsなどのFW)がmicroCMSのAPIから取得したデータをHTMLに変換した静的ページを作成
- Vercelにデプロイ

「APIから動的データを取得して、SSGによって静的コンテンツを作る」という仕組みがとても画期的で、あまり馴染みがないアーキテクチャになります。

microCMSの管理画面からAPIのスキーマを編集する際、スキーマのフィールドにはデータ型を選択することができます。
「リッチエディタ」というデータ型を選ぶと、APIのレコードを作成する画面で該当のフィールドにリッチエディタが表示されて、リッチエディタで入力した文章がHTMLに変換されてレコードに保存されます。
(スキーマレスっぽいですがレコード・フィールドと勝手に呼びます)

注意点としては、2021/02/20時点ではリッチエディタに表やコードハイライトなど対応していない機能がある点です。
また、マークダウンにも完全に対応していないため最終的にはテキストエリア型など自由入力できる形式にして、レコードにHTMLではない生の文章データを作る形にしました。

つまり、リッチエディタ型で保存すればHTMLデータをそのまま加工せずに利用できますが、大抵のユースケースでは生の文章データとして保存してSSG側でHTMLに加工したデータでコンテンツを作るという流れになります。

なお、microCMSのリッチエディタにはコンテンツのスタイルを適用することができないため、正確なプレビューは結局別な手段を利用することになります。

SSGフレームワークでプレビュー用のAPI (function) を作り、ホスティング先のプレビュー用APIをmicroCMS上から叩いてドラフト版のデータをAPIがmicroCMSから取得して表示する..という少し複雑な手段で実現ができます。

公式ブログではNuxt.js版のプレビュー実装方法が紹介されています。

[blog.microcms.io/nuxt-jamstack-preview](https://blog.microcms.io/nuxt-jamstack-preview)

### 2. Next.jsでSSGする仕組み

Next.jsやNuxt.jsはルーティングにファイルシステムを利用しています。
対応関係は下記のような感じになります。

|URL|ディレクトリ|
|:--|:--|
| / (root) | `pages/index.tsx` |
| /about | `pages/about/index.tsx` |
| /posts/1 | `pages/posts/[slug].tsx` |

ここで `index.tsx` にあたる単一ページは単純にmicroCMSから取得したデータを流し込んだHTMLファイルを作るんだなと想像に容易いですが `[slug].tsx` にあたる動的ページをHTMLファイルにする仕組みは直感的ではありません。

Next.jsでSSGを行う場合はpages/配下のコンポーネントに `getStaticProps` と `getStaticPaths` という2つの関数を定義してexportします。

```javascript
const MultiPagesComponent = (props) => {
  ...
}
export default MultiPagesComponent;

export const getStaticProps = async (context) => {
  const { slug } = context.params;
  ...
  const data = await fetch(`${apiUrl}/${slug}`).then(res => res.json());
  const { title, body } = data;
  return {
    props: {
      title,
      body
    }
  }
};

export const getStaticPaths = async () => {
  const data = await fetch(apiUrl).then(res => res.json());
  const paths = data.contents.map((post) => `/posts/${post.slug}`);

  return { paths, fallback: false };
};
```

`getStaticProps` はコンポーネントに与えるpropsを作る関数で、microCMSのAPIから取得したデータを加工して、コンポーネントに渡しています。
`context` 引数にはURLのパラメータなどを受け取ることができ、ここでは `posts/slug` としてアクセスがあった場合に `slug` 部分のパラメータをデータ特定のために利用しています。

`getStaticPaths` はこのコンポーネントがアクセスされうるURLを作る関数です。
ここではmicroCMSのAPIから記事一覧を取得して、記事の数だけ `posts/slug` というページを作成しています。

なお、プレビューの際はAPIのリクエストヘッダーに下書きステータスの記事データも取得できるようにする権限のキーを追加することによって、下書きステータスの記事データを取得しています。

### 3. シンタックスハイライトする仕組み

前述した通り、microCMSのリッチエディタではシンタックスハイライト機能などがサポートされていないため、SSG上でデータを加工する必要があります。
ここまでくるとjekyllやhugoなど従来のローカルで完結していたSSGのFWと同じ仕組みになります。

公式ブログでは `cheerio, highlight.js` を利用したシンタックスハイライトの付与方法を紹介しています。

[blog.microcms.io/syntax-highlighting-on-server-side](https://blog.microcms.io/syntax-highlighting-on-server-side/)

記事で紹介されている方法はリッチエディタで入力されたHTMLデータを加工することを前提に紹介されていますが、マークダウンなどの生文章をテキストエリア型で入稿している場合は、「HTMLに変換->シンタックスハイライト付与」という流れになります。

cheerioでHTML文章の中から `<pre><code>ここにコード</code></pre>` にマッチする要素を見つけてきて、highlight.jsで下記のような感じに変換してくれます。

```html
<pre><code class="language-python hljs">
  def hoge()
  <span class="hljs-keyword">return</span>
  <span class="hljs-symbol">"hoge"</span>
</code></pre>
```

自分が好きな配色を選んで、cssを読み込めばhighlight.jsで付与されたクラスなどにスタイルがつくという仕組みです。

## 最後に

このブログはpublicリポジトリにしているので、下記から確認することができます。

[github.com/tkc310/microCMS_blog](https://github.com/tkc310/microCMS_blog)

この記事で紹介した内容以外にも、このブログではMarkdown文書内でJSXが書ける `MDX` などを導入していたりするので、コードを見ていただければと思います。

デザインもパクっていただいていいので、ご自由にお使いください〜

カテゴリー「技術学習ログ」の記事一覧