When I'm not coding, wathing youtube videos or playing game, you'll find me cooking, working out in the park or drinking somewhere.

## 登壇しました

結構時間は経ってしまったけど7月にエンジニア向けのイベントでLTの登壇した。
いくつかLT登壇は今まで何回かしていたが、会社名を出して代表として出たので初めてだったので軽く準備過程を書いてみることにした。

## 登壇テーマ

最初は会社で立ち上げようとしていた新規プロダクトの話をするつもりだった。イベントのテーマ自体もフロントエンドだったので新規プロダクトを立ち上げる上での何かをしゃべれば面白いかも、と思って準備していた。
しかし、イベントの日にはまだ新規プロダクトの __プレスリリースが出ていない__ ことからイベントではプロダクト名とあまり詳しい内容を述べてはいけなく、内容として面白くなかったのでテーマを変更。

それで結局決めたのは __フロントエンドとフィードバック・テスト__ についてUzabaseはどうやっているのかを書いてみることにした。当たり前に見えるかも知れないけど最も大事で結構助けられる部分でもあるので自分のためにもまとめてみることにした。

## フィードバックは大事

```
フィードバックサイクルをいかに早く、多く回すか
```

今回のLTで話したかったことはこの一言になる。サービスの開発でフィードバックサイクルを早く、多く回すかはサービスの質に大きく影響するのですごく重要なポイントの一つ。
その中で __多く回す__ と __早く回す__ はそれぞれ技術的なところとそれ以外の所で今回のプロダクトで気をつけたことを述べてみる。

### フィードバックを多く回す

トライアルのユーザーを集めて使ってもらうのもすごく良いプラクティスだが、既にあるサービスの追加機能とかでなく完全新規のプロダクトの場合はそれもできないかも知れない。 __まだログインしかできないけどフィードバックください__ とは中々言いにくいと思う。

そのため外部から集めるのは難しいので内部の資源を上手く活用していくことにした。
まだリリース前のサービスの一番のユーザーはやはり __開発しているエンジニアである__ のでエンジニアからも開発しながら結構なフィードバックを元に改善をしていた。
最初は定まってなかったデザインの基盤もデザイナーさんと多く議論をする中で作り上げていって、最終的には __デザインガイドライン__ を定義できた。コンポーネント設計ではAtomic Designも採用していたのでガイドラインを元にUIフレームワークのように作れたので今後もデザインの統一性は担保できると思っている。

また、Uzabaseではフィードバックは基本的に実際の動いている本番環境を元に行われる。まだ公開してないのでアクセス制限はかけていたが、 __実際のユーザーが使う環境と同じ__ にした上でフィードバックを集めるのでそれらを実現するための工夫はいくつかあるのでまた下で記述する。

### フィードバックを早く回す

フィードバックを早く回すための工夫は大きく２つ。

- CI/CD
- 常にMVPを意識する

__CI/CD__ はフィードバックを早く回すためだけでなく、多く回すためにも必要になる。上で __実際のユーザーが使う環境と同じ__ 環境でフィードバックを集めると書いてあるので開発が終わったユーザーストーリーを本番環境にリリースしないとフィードバックは集まらない。一つのユーザーストーリーであってもフィードバックを早く・多く集めるためにはできるだけ早く本番にリリースする必要がある。

しかし本番環境までリリースする手順が複雑だと __リリース回数は当然落ちる__ のでCI/CDの効率化は大事になる。そこで今回は __ArcoCD・Helmを使ったGitOps__ を採用した。
アプリケーション自体はk8sで動いていたのでHelmでマニフェストを作り、ArgoCDでそれをデプロイする流れになる。

![argocd gitops](//images.contentful.com/dtew01bna6pd/G12sOcnUzmmPQqujBhZEY/d9af2c3f5432915ec5a0f5a2aab8ff25/____________________________2021-07-31_16.41.01.png)

また、 __常にMVPを意識する__ もすごく重要である。リリースを早くするには各ユーザーストーリーのMVPを常に意識し、早く終わらせて早くリリースする必要がある。 __ストーリーのゴールが不明確であればすぐに相談する__ 、 __追加の開発が必要であれば別のユーザーストールを作成する__ 、 __対応のタイミングや優先順位を議論する__ などアジャイル的なスキルが求められる。こういった議論を繰り返すことで今のユーザーに
多くの価値がある機能を早めに出していくことができる。
もちろんこれはもの凄く難しい部分だが、アジャイルの基礎を心かけてトライアンドエラーを繰り返すと精度も上がってくると思う。

## テストをしっかり書こう

上記の __フィードバックを多く回す__ や __フィードバックを早く回す__　を実現するためにはCI/CDを整えることやアジャイル的に意識するなども大事だが、それらを支えるのはやはり __自動テストを書くこと__ だと考える。

自動テストがないとマニュアルテストで確認するしかないので早く・多くリリースすることに大きく影響する。どんなに早くて使いやすいCIツールがあってもテストにもの凄く時間が掛かっていたら意味はない。
また、フィードバックを集めていたら当然計画は変わる。計画していた機能がなくなったり、新しくできたりすることもあれば既に作った機能の仕様が変わることもあるだろう。自動テストがないとその __変化に対応しにくくなる__ 。アジャイルで開発をしていたら計画は同然変わるものだと認識をした方が良いと思っている。

エンジニアとして __ここの仕様が変わったのでもうその期日には間に合いません__ と返すのはUzabaseのバリューとは合わないので変わるであろう計画に柔軟に対応するためにもテストはすごく大事である。

### ほんで、どんなテストを書くべきか？

テストにはいくつか種類があるが、ここで主に話しているテストのことは __フロントのE2E__ のこと。
もちろんユニットテストは要らないという意味ではなく、E2Eも含めて書いた方が良いという思っている。

チームではE2Eを書く際には __Gauge + Chrome Driverを使った Seleniumのテスト__ で書いている。

```text
# マイページの項目の更新
* トップページにアクセスする
* メールアドレス"test@uzabase.com"パスワード"password"でログインする 
* マイページが表示されている

## メールアドレスを更新することができる - mailaddress * メールアドレスに"test@uzabase.com"が表示されている * メールアドレスに"update@uzabase.com"を入力する
* 更新ボタンを押下する
* メールアドレスに"update@uzabase.com"が表示されている * DBが更新されている
* 外部のAPIにリクエストが行われている
```

簡単に書くとこんな感じ。実際のユーザーが行う操作を書いていって、それを結果を評価する。
Documentにあるelementが描画されているのか、そのelementがどの状態なのが、どういう値を持っているのかなどの確認から、DBやElastic Searchにどういう値が保存されたのかや、外部のAPIにちゃんと通信しているのかなどまで検証できるのですごく便利。

### 自動テストの効果

自動テストは色々効果はあるが、結構書くのに時間がかかる。それに最初自動テストの基盤を作る際には更に時間がかかるでしょ。サービスの開発ではスピードはすごく大事に指標なので逆にテストに時間がかかり過ぎて開発が進まなくなるのは本末転倒である。

それでは自動テストを書くことで消費したコスト（時間）は __いつ回収できるのか？__

![test cost](//images.contentful.com/dtew01bna6pd/6lGAN2YHpjbznWHi0m886o/8a3cf5789f598a2ecfebb3ded6b87b7b/____________________________2021-07-07_14.56.03.png)

[質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition](https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=69)

以前Uzabaseでt_wadaさんの登壇があって、その資料を引用する。
自動テストを書くことで消費したコストはマニュアルテスト3回を回すと逆転する。３回はストーリーの状況では1日もかからない時も多々あるので確実にマニュアルテストより効率的だと言える。

## まとめ

なんか色々書いてはいたが、フロントエンドに限っての話ではないので少し滑った感じはしていた。
UI/UXなどの外部品質に関するものを改善するにはテストやCI/CDなどの内部品質を上げる必要がある、と言いたかったが、少し外れたかもなぁと思ったので次回もあればその時でこそ新規プロダクトの話がしたい。

[登壇資料 | 新規プロダクト立ち上げとフロントエンド設計](https://speakerdeck.com/dordieux/xin-gui-purodakutoli-tishang-getohurontoendoshe-ji)

【PLAID×SmartHR×Uzabase×OPEN8】 SaaSプロダクトのフロントエンド最前線に登壇したお話

そう言えば、登壇してたわ

## はじめに

Next.jsの __9.0__ から登場した __API Routing__ を使って、簡単なAPIを作ってみた。
そのAPIをBFFとして使ってみたので使い方を紹介する。

## API Routingとは

__API Routing__ とはNext.jsで簡単にAPIを作れる機能のこと。
既存のNext.jsのルーティングのように、APIのルーティングもディレクトリの構造で書ける。

```text
pages
 |-- api
 |    |-- posts
 |    |   |-- [slug].tsx
 |    |   |-- index.tsx
 |-- posts.tsx
 |-- index.tsx
 |-- _app.tsx
 |-- _document.tsx
```

上記のように __pagesの下にapiというディレクトリをおくだけて良い__ 。　とても簡単に書ける。
この例だと `/api/posts` と `/api/posts/[slug]` という２つのAPIが作れる。

### 実際の中身

`/api/posts` はContentfulから全てのポストをとってくるAPIだとして書いてみると

```typescript
import type { NextApiRequest, NextApiResponse } from "next";

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const entries = await client.getEntries({
    content_type: "post",
  });

  res.statusCode = 200;
  res.setHeader("Content-type", "application/json");
  res.end(JSON.stringify(entries.items.map((item) => convertPost(item))));
};

const convertPost = (item) => {
  return {
    title: item.fields.title,
    subtitle: item.fields.subtitle,
    body: item.fields.body,
    slug: item.fields.slug,
    publishedAt: item.fields.publishedAt,
  };
};

```

基本的にNodeのAPIサーバーのように書くことができる。
返す値は基本的にJSONにしているが、中身は自分のクライアントに合わせて自由に書けば良い。

### パラメーター付きのAPI

例えば、Contentfulから指定した条件に一致したポストだけを返すAPIを作るとしよう。
`/api/posts/[slug]` というAPIを作るとした場合、このAPIはパスで指定した __[slug]__ でポストを探すAPIになる。

```typescript
import type { NextApiRequest, NextApiResponse } from "next";

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const entries = await client.getEntries({
    content_type: post,
    "fields.slug": req.query.slug,
  });

  res.statusCode = 200;
  res.setHeader("Content-type", "application/json");
  res.end(JSON.stringify(convertPost(entries.items[0])));
};

const convertPost = (item) => {
  return {
    title: item.fields.title,
    subtitle: item.fields.subtitle,
    body: item.fields.body,
    slug: item.fields.slug,
    publishedAt: item.fields.publishedAt,
  };
};
```

__req.query.slug__ でパスで指定した __[slug]__ を取得することができる。
この先の流れは同じく、必要な形に合わせて返してあげるだけで良い。

## 注意点

このブログでもこの __API Routing__ を使ってSSGで作ってるが、いくつか注意する点がある。

- 本当のAPIとしては微妙
- ホスティング先によっては使えない

### 本当のAPIとしては微妙

API Routingとはしてるが、個人的に __WEB APIとして使うのは非推奨__ 。

> Next.jsはあくまでReactを用いること前提のフレームワークであり、APIルーティングはおまけ程度のものです。リクエストメソッドのフィルタリング、リクエストボディのバリデーションなどもすべて自前で記述しなければならないため、本格的なWeb APIサーバを開発するには向きません。

[Qiitaブログ | web-apiフレームワークではないので機能的に貧弱](https://qiita.com/jagaapple/items/faf125e28f8c2860269c#web-api%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%84%E3%81%AE%E3%81%A7%E6%A9%9F%E8%83%BD%E7%9A%84%E3%81%AB%E8%B2%A7%E5%BC%B1)

例えば、DBから値を取得したり、認証の処理を行ったり、といったビジネスロジックが多く含まれるようなAPIが必要な場合は、 __API Routing__ は向いてない。 Reactベースではあるので書こうとすれば書けるかも知れないが、あまりおすすめはできない。

個人的にNEXT.jsのAPIは __BFFとして使う__ ことが最適だと思っている。
[BFFってなに？](https://parkpark.dev/posts/what-is-bff)

クライアントサイドで必要なAPIをラップして、使いやすい形にして返してあげる、それ以上のことはしない、ということが自分の使い方。まさにBFFとして使っている。
上に書いたサンプルコードもContentfulのSDKは使っているが、基本的には __ContentfulのAPIを叩いて、形を変えて返す__ だけの __APIコンポジション__ を実現したBFFになる。

### ホスティング先によっては使えない

__API Routing__ は __SSR__ として実現されるので、ホスティング先がSSRを対応してなければ使えなくなる。
実際にnetlifyの場合はサポートしてなく、 __API Routing__ を使えない。

自分ももともとnetlifyを使っていて、この機能を試すためにvercelに移行した。
基本的なホスティングしかしないのでそこまで使い方は違いないが、やはりNEXT.jsの開発元なのでAPI Routingもサポートしてくれていた。


Next.jsのAPIをBFFとして使ってみた。簡単な使い方と注意点を書いてみる。

Next.jsのAPIを使ってみた

## BFFとは

BFF(Backends For Frontends).
名前の通り、フロントエンドのためのバックエンド。 デスクトップやモバイルなどの __クライアントごとに実装されたAPI Gateway__ のこと。

ほんで、 __API Gateway__ はまたなに？

### API Gateway

__API Gateway__ はクライアント（フロントエンド）とバックエンドのレイヤーに存在して、以下のような機能を持っている。

- リクエストのルーティング
- APIを複数呼び出して、結果をまとめる
- プロトコル変換
- 認証・認可
- リクエストの制限
- キャッシュ
- ログの出力
- etc...

上記の全てを実装してからこそAPI Gatewayになるわけではない。
認証や認可はSSOなどを実現するために共通して切り出すこともあったり、ルーティングはロードバランサを使って実現したりすることもよくある。

__BFF__ はこの `API Gateway` の役割の中で、 __APIを複数呼び出して、結果をまとめる__ 、つまり __APIコンポジション__ をメインとしていると思う。
なぜなら、BFFは __クライアントによってBFFのレスポンスが大きく変わる__ 。

同じマイクロサービスのAPIを使うとしても、クライアントごとに欲しがるレスポンスの形が違うから。

## BFFのメリット

__BFF__ を置くことによって得られるメリットを一つは __パフォーマンスの改善__ にある。
BFFだけでなく、APIコンポジションを行う __API Gateway__ なら共通して得られるメリット。

BFFを置かなく、クライアントでAPIコンポジションを行うことを想定してみよう。
その場合、クライアントは複数のAPIを叩くことになり、大量のリクエストをすることになる。
BFFでAPIコンポジションを行うのであれば、クライアントからのリクエストは __1回__ になるので簡単。
それにクライアントで欲しがる形でデータを返してくれるのでクライアント側でデータの操作がなくなるので、コードがシンプルになる。

また、 __BFF__ を置くと、__クライアントからAPIを隠せる__ ようになる。
複数のAPIが存在する際に、それらのAPIを直接叩いたり、データをまとめるのはBFFで行われるのでクライアントではBFFの位置だけ知っていればデータがもらえる。

クラインととAPIをもっと厳密に切り離すことができるので、メンテナンスはより簡単になる。

## BFFのデメリット

BFFも一つのマイクロサービスなので、 __BFF自体の開発コスト__ もやはりかかってしまう。
基本的にBFFにはビジネスロジックはなく、簡単な操作しかないが、マイクロサービスである以上は当然テストも必要になってくる。

しかし、個人的に会社で開発する際に　__BFF自体の開発コスト__　はそこまで気になりはしなかった。
上にも書いたが、__BFFにはビジネスロジックはない__ ので、テストやE2Eも簡単で、実装自体も結構簡単に済むことが多いイメージ。

## 注意点

BFFはクライアントと近いので下手するとクライアントに大きい影響が出てしまう。
基本的に全てのサービスがそうだが、BFFは特に実装の漏れや不具合が __ユーザに直接的な影響をもたらしてしまう__ ので注意が必要。

また、BFFは複数のAPIを叩くので、一部のデータが欠落しているケースは考慮して設計しないといけない
あるAPIのレスポンスがあまりにも帰ってこない場合は、その他のデータだけを返すとか、そもそも早めにエラーを返すかなどは考えるべき。これもBFFに限っての話してはないが、常に意識はする必要がある。

### 参考
[Microservices Patterns](https://www.manning.com/books/microservices-patterns)

[microservices.io - apigateway](https://microservices.io/patterns/apigateway.html)
