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

## はじめに

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)
