いまさらドラクエ10をやり込み始めたのでパーカーを作りました。
https://up-t.jp/market/637681b6dc348

リレミト・スクルト・ルカナン辺りの呪文も魅力的でしたが、誤解を与えにくいピオリムに軍配が上がりました。

怒られそうなため在庫は0にしています。

---
*後日談*

間違ってキッズサイズを注文してしまい、  
34歳にして本格的に迷走しているなと思うこの頃

<img src='https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/c1c5ba51dbef442b83259e6c452267fa/IMG_0471-min.jpg' alt='ピオリム' />

---
全然関係ないけどバックエンドTSを勉強しようと思って調べてたら、一休さんが興味深い挑戦をしていた。
https://speakerdeck.com/naoya/typescript-niyoru-graphql-batukuendokai-fa-75b3dab7-90a8-4169-a4dc-d1e7410b9dbd
スイッチコストを減らすためにクラサバTSにして更に宣言的アーキテクチャで揃えるのは夢があると思って見ている。

まだ時代が追いついていない気がするけど、持ちうる状態のパターンを事前に用意して遷移はフレームワークに任せるというのは見通しも良くなりテスタブルにもなりそうなので、かなり良さそう。
ただ現状は自前でルールを作る必要があるので、実戦投入にはエネルギーを使いそう。

フットワークが軽くなるパーカーを作った

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と状態管理

2021の振り返りと2022の目標を書いていく。

## 2021の振り返り

2021年の前半は休暇中にDeFiにハマってbot職人をしていた。  
社会との関わりが薄くてヤバさを感じたため復職(2回)した。  
Next.js, GraphQL, Pythonを触れてとても幸せ。

### 仕事

今年は2社で働いた。

#### 1社目

まとめると下記3点の学びがあった。

- 要件定義・合意を取るフェーズ、開発フェーズは分けたほうが心理的安全に開発できる  
1社目は技術スタックはとても魅力的だったが、要件定義と並行して開発するスタイルが合わなかった。  
もともと要件定義自体に抵抗はないが、アジャイル・スクラムにしても事前に合意を取るフェーズ・開発フェーズは分かれている方が心理的に安全で成果も出やすいという学びがあった。(確信できた)  

- スタートアップでも初期設計・コーディング規約・サンプルコードは大切  
メンバーの構成(専門スキルや経験値)によってコードの秩序が保ちにくい状況では、初期設計(サンプルコード)・コーディングルール整備は大切だと痛感した案件だった。  

- ローコードツールに限界を感じた  
また、Amplifyでの開発だったが、ある程度複雑なアプリケーションを作る場合はFWを利用して作ったほうが後々困らないという知見も得られた。  
(e.g. DynamoDBにロックインしているため、フルスキャンをさけるためにページングの実装も一工夫が必要だったりトランザクションを書くときにVTLを書く必要があったりなど、通常のWAFに比べて学習コストが高いイメージ)  
Amplifyを含めてローコードツール自体は将来性があると感じているが、現時点では学習コストと見合わない感覚を持った。  

#### 2社目

2社目は在籍中の案件で、1人目の開発メンバーだったためフロント・バックエンドの初期構築から担当させていただいた。

- フロント: Next.js(SSG + CSR), TypeScript, GraphQLというキラキラのナウい構成  
- バックエンド: Python, Django, Graphene-DjangoでGraphQLのAPIサーバーという構成  

- GraphQLによるAPIの型安全  
[graphql-codegen](https://www.graphql-code-generator.com/) というツールを利用して、スキーマ・レスポンスの型などを生成できるため、フロントが型安全に開発できる。  
例えば、データ構造に大きな変更があった際にAPIが修正されていれば、フロントは型エラーが出ている箇所を重点的に修正すればよいため、開発体験がとても上がった。  

- pythonのtype hint  
python側でも型チェックは行っているが、mypyはvscodeでの設定が複雑になちがちなため、  
pyrightというmicrosoft謹製のツールに変えたいという話が出ている。  
(djangoやミドルウェアのstaubが上手く動かなく、ほぼ `# type: ignore` しているが、これも解消できるとの噂)  

- pythonのパッケージ管理  
パッケージ管理はpipenvを利用しているが、新興のpoetryに変更したいという話が出ている。  
(installが遅い、デフォルトで依存パッケージの更新がされないなど)  
poetryに変えたところで問題はありそうだが、poetry推しの記事が増えてきている様子。  

- 型とテストについて  
フロント・バックを通じて型制約を強めにしたのと、フロントの統合中心のテストを導入したのが、  
3ヶ月位たって、効果が出始めた気がしている。   

いままでのキャリアではしっかり型やテストを書いてこなかったので不安もあったが、  
型は強めにして最低限のテストケースを用意しているだけでも、  
リードタイムが削減でき・精神衛生的にも良い開発体験になってきたのでよかった。  
(静的補完も素晴らしい)  

初期フェーズのプロダクトにおいても、アジャイル的にコード変更が頻発するようなケースでは導入したほうがよいと思った。  

- 開発フロー  
スクラムで運用しているため、各イベントで合意・開発フェーズが分かれていてやりやすい。  
個人的にはプランニングに掛ける時間を意図的に短くしていることもあり、見積もりの正確性・ベロシティに信頼性が出ていない部分は改善ポイントだと思う。  
また、コードレビューではコメントすべきこと・すべきでないことの境界が曖昧なため、  
ワンチャン、ガイドラインを作成して心理的安全性が高くPRをだせる文化を提案したいと思っている。  


### スキルの振り返り

**今年の収穫スキル**  

目標としていたものは、ほぼ学習できた

- Amplify  
DevOpsまで構築してくれる体験はRails以上の衝撃だった  
複雑なアプリケーションでは学習コストのメリットが上回りそう  
- ReactNative  
機能やパフォーマンス要件の実現が難しくなる場合があるため、flutterが良さそうだった  
Reactコードを流用できるかと思っていたが、想像以上に流用性が低かった  
Reactスキルでアプリを作れるのがメリットだと思う  
- Redux-toolkit  
定型文が少なくなり、非同期も簡単に使える  
Redux使うとき機会があれば利用すると思う  
- TypeScript  
strict=trueで頑張っている  
typescript challengeで型パズルを学習する  
- python  
肩周りのエコシステムが弱いが、頑張って覚える  
- mypy  
strict=trueで頑張っている  
typescriptに比べて実現できる機能が少ない  
pyrightに乗り換えてみる  
- go言語  
基本文法とECHO/GINによるCRUD、100本のノック(20本くらい)しかできなかった  
- Next.js  
zero configのすごいやつ  
vercelにロックインしないと使えない機能が多いのが難点  
フロントの概念を刷新するレベルのFWなので今後もキャッチアップ頑張る  
- GraphQL (apollo-client)  
学習コストは掛かったが、型・リクエストをまとめる・ディレクティブ・キャッシュ周りの機能が強力  
GraphQL自体の仕組みも開発者体験を高めてくれ、上記機能によってユーザ体験も高くなると思った。  
複雑度・深さ制限などセキュリティ周りの学習を頑張る  


### ライフスタイルの振り返り

- 筋トレ  
ジムに通わなくなり、自宅で筋トレしているが気合が入らない。  
朝起きてからtabata式トレーニングをしていたが、朝起きるのが辛くて週1-2になってしまった。  

- 食事  
プロテインもストロベリー->ブルーベリー味に変えてから飲む頻度が下がった。  
休日は昼や夜に起きるので、3食たべなくなり痩けた  

- ペット  
猫かマイクロブタを買いたいと思っていたが、マンションがペット禁止だった  

- カメラ、キャンプ  
友達を誘うタイミングを見失っていってない  

- DeFi bot, OSS開発   
復職時にやめてしまった。    
改良ポイントが山積み   


## 2022の目標

QOL高めたい年にしたい。  
スキルはserver side typescript, go言語の勉強に集中する  

### 仕事の目標

#### 本職
- まずは、リリースできることを目標に頑張る。  
- フロントのパフォーマンスチューニングと共通化、単体テスト追加  
- strybookのカタログ、インタラクションテスト、vrt、 autify導入を頑張る  
- 心理的安全性を高める施策を提案してきたい (コードレビューガイドラインなど)  

#### 副業
- 友人の不動産サービスのプランニング  
- DeFi botの改良、Udemyでラーニング動画販売  

### スキルの目標

型月言語を学習しつつ、TypeScriptをサバクラで触れるようにする。

- typescript challengeで型パズルを学習する  
- server side typescript (Blits.js Nest.js, prisma)  
- go言語 (go道場)  
- rust (基本文法 + CRUD)  
- python力、scraping力を高める  
- flutter (余裕があれば触る)  

### ライフスタイルの目標

- 友達をキャンプとカメラに誘う  
- 引っ越してペット買う  
- 都内近郊でワーケーションしながら物件を探してみる  
- ヘルス・メンタルケアは習慣化して健康に暮らす  
  - 週2回の筋トレ  
  - 日課のtabata式  
  - プロテイン + 3食しっかり摂る  
  - 朝・昼・晩のマインドフル瞑想  
  - コンパッション系の本を読む  



2021の振り返り・2022の目標

[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)

404エラーTシャツに続いて無病息災コマンドTシャツを作りました。  
Tシャツ作るの楽しい笑

今回はコロナ撲滅を願って、無病息災Tシャツを作成しました。

便利コマンドシリーズです。
何枚か売れたらまた作ります。
https://up-t.jp/market/617479ba4a031

