---
tags: apollo
---

# PNEWS v2 Presskit front-end 技術設計

## 1. 既に決定していること
- フロントエンドフレームワーク: Next.js
- 言語: TypeScript
- CI, deploy: github actions
- css: emotion
- analytics: google analytics
- test: jest
- global state管理: react Context API
- design tool: story book
- visual regression test: jest snap shot
- GraphQL Client: Apollo Client

## 2. Global State

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- Global Stateとして取り扱いそうなもの
- 検索用query => url queryで実現可能
- ルーティング情報 => next.jsの機能としてglobalに管理されている
- セッション情報 => どうにかせねば

### HOW/Which それはどのように解決できるのか、それを解決するにはどんなツールがあるのか[選択肢の列挙]
- react context
- redux

### Because どれにするのかの意思決定 [評価軸の検証, 意思決定]
- 複雑なビジネスロジックを記述するケースは少ない
- Global stateの更新は少ない
- ただただ、セッション情報をGlobalに管理したい
=> react context

## 3. Hosting

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- 初期設定を楽にしたい(一般的に)
- 管理コストを楽にしたい(一般的に)
- サーバー運用に手間をかけたくない(一般的に)
- 簡単にスケーリングできる(ユーザー数、閲覧数が徐々に増える)
- 従量課金制 & 極力安く（初期投資は少なくしたい、課金はユーザー・チームメンバーが増えてから考えたらいい）
- チームメンバーが取り扱えるか

### HOW/Which それはどのように解決できるのか、それを解決するにはどんなツールがあるのか[選択肢の列挙]

#### どのように解決できるか
- serverless
- Next.jsとの相性がいい（コンフィグ記述量が少ない）
- githubと連携し、自動deploy
- slackと連携し、通知を飛ばす

#### ツールの選択肢
- vercel
- netlify

### Because どれにするのかの意思決定 [評価軸の検証, 意思決定]

#### 評価軸の検証

##### vercel
- build
- deploy
- 値段: proは$20/mo per member
- (ほぼ)ゼロコンフィグ
- Next.jsを作成しているvercelが作成しているので相性◎

##### netlify
- build
starter$0: 300 build minutes/month
pro$45: 1000 build minutes/month
- (ほぼ)ゼロコンフィグ
- github連携はGUI操作で簡単に組める

=> 1回のbuild5分だとすると、無料planでversel: 100回、netlify: 60回

### 結論
- どちらでも十分運用していけそうだが、無料プランでのbuild回数が多く、Next.jsとの相性が多くて設定が楽なverselがいい

## 4. cssフレームワーク(bootstrap)

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- デザイナーにjoinしてもらうので、「早く・それなりのUI」を実現するためのツールは必要ない
- pnews webで使用しているフレームワークは導入する必要あるかも

## 5. packagesの共有

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- pnews/clients/packagesを共通で使用できるようにしたい可能性

### HOW/Which それはどのように解決できるのか、それを解決するにはどんなツールがあるのか[選択肢の列挙]
- tolでは、github npm registryを利用して解決している

## 6. componentsの共有

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- `app.pnews.jp`と`v2 Presskit`で共通のコンポーネントを利用したい可能性
- atom, moleculesレベルのコンポーネントからドメインを排除すれば、どちらでも再利用できるかも
- デザイナーとの認識すり合わせも必要だよね
- このタイミングでデザインシステムを作るかどうか

### HOW/Which それはどのように解決できるのか、それを解決するにはどんなツールがあるのか[選択肢の列挙]
- 事前にコンポーネントの整理を行う必要あり。

## 7. Visual Regression Test

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- ここで新たにsnap shot以外の新しい技術を使用して解決したいほどの課題は、v2で見当たらない

## 8. GraphQL Client

### Why どんな技術/技術組織課題が発生し得ると考えるのか[課題の特定/イシューの抽出]
- GraphQL APIとのネットワーク通信を抽象化し、効率的にコーディングしたい
- キャッシュを用いて、高速化したい

### HOW/Which それはどのように解決できるのか、それを解決するにはどんなツールがあるのか[選択肢の列挙]
- GraphQL Client
- Apollo Client
- urql

### Because どれにするのかの意思決定 [評価軸の検証, 意思決定]

#### 評価軸の検証
- urql: 2018~, Apollo Client: 2017~
- コミュニティ: Apollo Clientの方がユーザー数は多い、ドキュメントも豊富
- 思想の差分: urqlは単一のパッケージでファイルサイズは1/4くらい。Apollo Clientは、あらゆる問題を自分たちで解決しようという思想がある。パッケージが5つある
- キャッシング周りの差分
- urqlはmutationが発火したときに、同じ`__typename`のqueryのキャッシュが全てクリアされる。(urqlのキャッシュはgraphQLのレスポンスにある`__typename`をベースにしている)(automatic/custom cache invalidation)(紐づいているキャッシュが多いと全て削除されちゃうよねみたいな問題はある)
- Apollo Clientではmutationが発火した後にrefetchしないと変更が反映されない（refetchしたり、readQuery & WriteQueryで対応したりする必要がある）(これレスポンスがリストとか複雑なときだけっぽい)(https://blog.logrocket.com/exploring-urql-from-an-apollo-perspective/)
- セットアップのしやすさ: Apollo Client v2では、設定の複雑さに批判があったようだが、apollo-boostのような解決策は用意されている。また、tolやpnews.jpで使用しているので、それを真似れば設定コストがurqlと比べて大きいという訳ではない。

#### 意思決定
- キャッシング周りの差分としてmutation発火時の挙動が挙げられるが、v2 presskitからmutationを発火するケースなさそうなので、比較する必要がない。
- 他にurqlを使用するはっきりとしたメリットがないので、ドキュメントが豊富で利用者も多い、Apollo Clientに乗っかる形で問題なさそう。

## FIXしてない
- packagesの共有どうするか => 考えなくていい
- pnews/webとcomponents共有したい可能性について => ちょいとむずい