こんにちは、先日行われたVercel Ship Day3について書きます！今回は、Vercel Spacesを使ってチームで開発を効率化する方法についてご紹介します。 Vercel Spacesは、Vercel上で作成した複数のプロジェクトをグループ化し、関連するプロジェクトを一つの場所にまとめることができる機能です。そして、このVercel Spacesを使えば、プロジェクトごとに異なるチームメンバーを招待することができます。 具体的には、プロジェクトごとに異なるチームメンバーを招待して、そのチームメンバーだけがアクセスできる環境を作ることができます。これにより、プロジェクトの開発状況やタスクの進捗状況を共有し、よりスムーズな開発作業が可能になります。 さらに、Vercel Spacesでは、プロジェクトごとに異なる環境変数やシークレットを設定することができます。これにより、チームメンバーごとに異なる権限を与えることができ、セキュリティ面でも安心して開発作業を進めることができます。 Vercel Spacesは、開発者がチームで開発作業を行う上で非常に役立つ機能です。設定も簡単で、Vercelの全てのプランで利用可能です。ぜひ、Vercel Spacesを使ってチームでの開発を効率化してみてください。 以上、Vercel Spacesを使ってチームで開発を効率化する方法についてご紹介しました。Vercelを利用している方は、ぜひVercel Spacesを活用して、よりスムーズな開発作業を行ってください。

Vercel Spacesを使ってチームで開発を効率化しよう！

Vercel Ship Day3 〜Vercel Spacesを使ってチームで開発を効率化〜

こんにちは、Day2ではセキュリティに関するアップデートを発表しました。 まずはじめに、Vercelはユーザーが自分たちのカスタムドメインを使用する際に、DNSサーバーをより強力に監視し、DNSハイジャック攻撃に対する防御を強化しました。 次に、Dockerfileを使ってアプリケーションをデプロイする際に、より厳格なイメージ検証を実施することで、セキュリティの向上に取り組んでいます。また、依存関係の脆弱性を検出するための自動化されたセキュリティスキャンを改善し、ユーザーに通知するスピードを向上させました。 最後に、自社のセキュリティに関するドキュメントをより詳細に整理し、ユーザーに提供することで、セキュリティに関するトピックについてより分かりやすく説明しています。 以上が、VercelのShip Day 2で発表されたセキュリティアップデートの概要です。これらの改善により、Vercelはより安全で信頼性の高いWebアプリケーションのデプロイとホスティングを提供することができます！ Vercelはどんどん進化していくのでDay3からも楽しみです。 詳細は以下のリンクよりご確認ください。<a href="https://vercel.com/blog/vercel-security" target="_blank" rel="noopener noreferrer">https://vercel.com/blog/vercel-security</a>

VercelのShip Day 2で発表されたセキュリティアップデート！

Vercel Ship Day2 〜セキュリティのアップデート〜

今回発表されたストレージ機能は、Vercel上でのファイルストレージを可能にする新機能でこれにより、静的サイトやAPIのデプロイ先であるVercel上で、画像や動画などのファイルを簡単に管理・配信することができるようになりました。 Vercelのストレージ機能は、既存のVercelプロジェクトにも容易に導入ができて、導入するためには、VercelのCLIツールを使用して、プロジェクトにストレージ機能を追加する必要があります。ストレージ機能を導入すると、Vercel上に保存されたファイルにアクセスするためのURLを生成することができます。これにより、ファイルへのアクセスが容易になり、Vercel上でのファイル管理が大幅に簡素化されます。（これによりS3や別サービスで管理していたファイルを一元化できますね！！ Vercelのストレージ機能は、アプリケーションのパフォーマンスにも大きな影響を与えます。ストレージされたファイルには、高速かつセキュアなCDNによる配信が行われるため、アプリケーションのパフォーマンスが向上します。また、ストレージ機能は、バックアップや復元などの運用面での利便性も向上させます。 Vercelのストレージ機能は、現在はベータ版として提供されていますが、今後も機能拡張が予定されており、Vercel上での開発・運用をより一層強化することが期待されるので今後が楽しみです！ 詳細は以下のリンクよりご確認ください。<a href="https://vercel.com/blog/vercel-storage" target="_blank" rel="noopener noreferrer">https://vercel.com/blog/vercel-storage</a>

Vercelでstorage機能を使えるように！

Vercel Ship Day1 〜ストレージ機能追加〜

既に1レコード単位で登録する画面は存在するが、1個1個手作業で登録するのは手間なのでCSVで一括で登録したい、というよくあるケースを想定しています。 1レコードごとに取り込んでいきます。「1レコードごと」という部分がミソです。 単純にテーブルに取り込むだけならバルクインサートのほうが早いのですが、処理が複雑かつ1レコード単位の登録処理については確立しているという想定のため、CSV取り込みの機能拡張にあたっては既存処理を流用できるよう1レコード単位で取り込みます。 レコード数については多くて千件程度くらいのイメージです。

アプリケーション概要

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/6f91acdcfb4f4a2983b12afe5a5bd684/image.png" alt="">今回は上記のような構成を考えます。<ol><li>画面からS3にCSVをアップロード</li><li>S3からSQS(FIFO)にイベント通知</li><li>LambdaでSQSのイベントを取り出す</li><li>LambdaからS3に配置してあるCSVをダウンロードしてインポート処理を実行する</li></ol>CSVの件数もそこまで多くないため、Lambdaの実行時間等の制約を考えても問題ないだろうという判断です。 S3から直接Lambdaでもいいのですが、実行順を保証したいのと、複数ファイルを同時実行したいためSQS(FIFO)を使用しています。 なお、上記において画面やインポートされるDB等の構成は省略しています。 実際にはVPCにあるDB等にアクセスする必要があるためLambdaをVPCに配置する必要があります。そのため、S3やSQSなどはVPC Endpointを通してアクセスします。

インフラ構成

今回は、GOを使ったCSVインポートの事前準備的なお話でした。まだGOについては全く触れていませんが、次回以降はGOの話になりますので、ご期待ください！

さいごに

GOでCSV import ~ 準備編

複数のコンテナで構成されるアプリケーションについて、Dockerイメージのビルドや各コンテナの起動・停止などをより簡単に行えるようにするツールです。簡単に言うと、Dockerは1度に1つずつしか操作できないことに対し、Docker Composeは1度に複数のコンテナを操作できるということです。 メリットとしては、<ol><li>複数コンテナを簡単・効率的に管理・実行できるようになる</li><li>コンテナを運用する際のミスを軽減できる</li><li>コンテナ間のネットワーク設定が簡単になる</li></ol>といったことがあげられます。

Docker Composeとは

<pre><code>version: '3'
services:
 db:
 image: mysql:5.7
 environment:
 MYSQL_ROOT_PASSWORD: password
 MYSQL_DATABASE: mydb
 web:
 image: httpd:2.4
 ports:
 - "8081:80"
 volumes:
 - ./public-html:/usr/local/apache2/htdocs/</code></pre> DBは、環境変数を使用してルートパスワードとデータベース名が設定しています。これでlocalhost:8081に接続完了しました。 ここから先はまだ学習中なので、どういった場面で使えるとか、もう一つサービスを追加してみるなど少しずつ応用をしていってキャッチアップしていきたいと思います。

MySQLとApacheを含む2つのサービスを定義してみました

実際にDocker Composeを作成してみる

Docker Compose使ってみた

注意点として、table/batch_writer()メソッドは一度に25件までしか削除できないため、forループで処理する。 <pre><code>import boto3


# 削除対象のレコードのパーティションキーをリストで指定
keys_to_delete = ['key1', 'key2', 'key3']


# DynamoDBテーブルに接続
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('table_name')


# BatchWriteItemリクエストを作成するためのリスト
delete_requests = []


# 削除対象のパーティションキーを含むDeleteRequestを作成し、リストに追加
for key in keys_to_delete:
&nbsp; &nbsp; delete_requests.append({
&nbsp; &nbsp; &nbsp; &nbsp; 'DeleteRequest': {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'Key': {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'partition_key_name': key
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; })


# BatchWriteItemリクエストを実行する
with table.batch_writer() as batch:
&nbsp; &nbsp; for request in delete_requests:
&nbsp; &nbsp; &nbsp; &nbsp; batch.delete_item(request['DeleteRequest']['Key'])


</code></pre>

コード全体

Boto3でDynamoDBのテーブルから複数レコードを一括で削除する

Go言語は、並行処理を実現するために並行処理のための独自の仕組みを持っています。並行処理は、複数の処理を同時に実行することで、アプリケーションのパフォーマンスを向上させることができます。 Go言語における並行処理は、goroutineという軽量スレッドを使用して実現されます。goroutineは、スタックサイズが非常に小さく、起動や停止のオーバーヘッドが低いため、多数のgoroutineを起動することができます。 また、並行処理を実現するために、Go言語はチャネル（channel）という仕組みを提供しています。チャネルは、goroutine間でデータのやりとりを行うための機能であり、同期的にデータの送受信を行うことができます。

Go言語の並行処理とは

goroutineは、ランタイムによってスケジューリングされます。スケジューラは、goroutineが実行可能であるかどうかを判断し、実行可能なgoroutineがある場合はスケジュールします。 しかし、goroutineのスケジューリングは、厳密には制御できません。そのため、goroutineを適切に制御することが重要です。 例えば、無限ループを含むgoroutineを起動すると、そのgoroutineが無限ループを繰り返し、CPUリソースを占有してしまいます。そのため、goroutineを制御するために、タイムアウトやキャンセル処理を実装することが重要です。 以下は、goroutineにタイムアウト処理を実装する例です。<pre><code>func timeoutFunc() {
 select {
 case &lt;-time.After(time.Second * 5):
 fmt.Println("timeout")
 case &lt;-quit:
 fmt.Println("quit")
 }
}

func main() {
 go timeoutFunc()
 time.Sleep(time.Second * 6)
 quit &lt;- true
 fmt.Println("done")
}</code></pre> 上記の例では、timeoutFunc()関数が5秒間実行されます。しかし、main()関数から6秒間スリープした後、quitチャネルにtrueを送信することで、timeoutFunc()関数をキャンセルします。timeoutFunc()関数内のselect文は、time.After()で5秒待機するか、quitチャネルからの受信を待機します。どちらかが先に発生した場合に、その処理を実行します。つまり、5秒以内にquitチャネルにtrueが送信された場合には、quitという文字列を出力し、6秒後にmain()関数が終了するため、doneという文字列を出力します。 また、quitチャネルは、bool型のチャネルであり、timeoutFunc()関数が実行されている間、main()関数からtrueが送信されるまで待機します。main()関数がtrueを送信することで、timeoutFunc()関数がキャンセルされます。 このように、goroutineを適切に制御することで、効率的で安全な並行処理を実現することができます。

goroutineのスケジューリングについて

チャネルは、同期的にデータの送受信を行うことができます。しかし、チャネルを使った通信は、送信側が受信側にデータを送信するまでブロックされます。そのため、バッファリングされたチャネルを使用することで、ブロックされることなく非同期的にデータの送受信を行うことができます。 以下は、バッファリングされたチャネルを使用する例です。<pre><code>func main() {
 ch := make(chan int, 1)
 ch &lt;- 1
 fmt.Println(&lt;-ch)
}</code></pre> 上記の例では、チャネルをバッファリングして、1つの値を送信します。その後、受信側で値を取得します。この例では、送信側が受信側よりも先に実行されるため、データを受信する前にブロックされることはありません。

チャネルのバッファリングについて

Go言語には、syncパッケージがあります。syncパッケージは、並行処理における排他制御を行うための機能を提供しています。例えば、複数のgoroutineが同時に共有リソースにアクセスする場合、排他制御を行わないとデータ競合が発生する可能性があります。そのため、syncパッケージのMutexを使用して、共有リソースに対する排他制御を行うことが重要です。 以下は、sync.Mutexを使用した排他制御の例です。<pre><code>import (
 "fmt"
 "sync"
)

var count int
var lock sync.Mutex

func increment() {
 lock.Lock()
 defer lock.Unlock()
 count++
}

func main() {
 var wg sync.WaitGroup
 for i := 0; i &lt; 1000; i++ {
 wg.Add(1)
 go func() {
 defer wg.Done()
 increment()
 }()
 }
 wg.Wait()
 fmt.Println("count:", count)
}</code></pre> 上記の例では、increment()関数でcount変数に対する排他制御を行っています。increment()関数内で、MutexをLock()してカウントアップ処理を実行し、処理が終わったらMutexをUnlock()します。これにより、複数のgoroutineが同時にincrement()関数を実行しても、データ競合が発生しません。 また、main()関数でWaitGroupを使用して、すべてのgoroutineの処理が完了するまで待機しています。

syncパッケージを使用する

Go言語には、contextパッケージがあります。contextパッケージは、goroutineのキャンセルやタイムアウト処理を簡単に実装するための機能を提供しています。 例えば、Webサーバーを実装する場合、HTTPリクエストの処理に対してcontextを使用することができます。これにより、リクエストがタイムアウトした場合には、リクエスト処理をキャンセルすることができます。 以下は、contextパッケージを使用したキャンセル処理の例です。<pre><code>import (
 "context"
 "fmt"
 "time"
)

func longProcess(ctx context.Context) {
 fmt.Println("start")
 defer fmt.Println("end")

 for {
 select {
 case &lt;-ctx.Done():
 fmt.Println("canceled")
 return
 default:
 fmt.Println("processing")
 time.Sleep(1 * time.Second)
 }
 }
}

func main() {
 ctx := context.Background()
 ctx, cancel := context.WithCancel(ctx)
 go func() {
 time.Sleep(3 * time.Second)
 cancel()
 }()
 longProcess(ctx)
}</code></pre> 上記の例では、longProcess()関数で、contextを使用してキャンセル処理を実装しています。longProcess()関数では、無限ループを行い、データの処理を続けます。しかし、ctx.Done()が発生した場合には、処理をキャンセルして終了します。main()関数では、contextをBackground()で生成し、cancel()関数を生成します。cancel()関数は、3秒後に実行され、longProcess()関数をキャンセルします。

contextパッケージを使用する

並行処理のベストプラクティス

以上が、Go言語における並行処理のベストプラクティスです。goroutineの制御やチャネルのバッファリング、syncパッケージやcontextパッケージを使用します。 今回3パターンを紹介しましたが、それぞれに適切な使用場面があり、これらのベストプラクティスを実践することで、安全で効率的な並行処理を実現することができます。(適切な使用場面の説明は時間がある時に追記するかもしれないです。。)

まとめ

Go言語における並行処理のベストプラクティス

CLIにしたのは単純にvscodeのターミナルからChatGPTが使えたら便利かも、と思ったから。ただ問題点として、OpenAI API単体でCLIツールにしても、日本語入力でリクエストを送ると回答の精度が著しく低下するということがあり頭を悩ませていました。そこで入力した日本語を一度英語に翻訳してOpenAI APIにリクエストを投げることで回答の精度をあげることができるのではと思い、今回Deeplを使用することにしました。

作った背景

chatgpt-cliという名前のファイルをダウンロードしてください。もしくは自分のローカルに git pull してコンパイルしてもらっても構いません。<a href="https://github.com/yootaki/chat-cli" target="_blank" rel="noopener noreferrer">https://github.com/yootaki/chat-cli</a>

バイナリファイルをダウンロードする

<code>$ vim ~/.zshrc</code> で設定ファイルを開き、下記を追記します。<pre><code>export PATH=$PATH:$HOME/追加するディレクトリ

#自分の場合はこんな感じにしました
export PATH=$PATH:$HOME/my_commands</code></pre><code>$ source ~/.zshrc</code> で設定を再読み込みします。

自作コマンド用のディレクトリを作成してPATHを通す

ダウンロードもしくはコンパイルしたバイナリファイルを、先ほど作成したディレクトリ配下に移動させます。

ダウンロードしたバイナリファイルを先ほど作成したディレクトリに入れる

<code>chmod u+x /&lt;ディレクトリパス&gt;/&lt;ファイル名&gt;</code>でファイルに実行権限を付与してあげます。

実行権限を付与する

OpenAI APIはここから<a href="https://openai.com/blog/openai-api" target="_blank" rel="noopener noreferrer">https://openai.com/blog/openai-api</a>Deepl APIはここから<a href="https://www.deepl.com/ja/pro/change-plan?cta=header-prices#developer" target="_blank" rel="noopener noreferrer">https://www.deepl.com/ja/pro/change-plan?cta=header-prices#developer</a> 登録してAPIキーを発行します。取得できたら.zshrcに下記を追記<pre><code>export DEEPL_API_KEY=&lt;DeeplAPIのAPIキー&gt;
export OPENAI_API_KEY=&lt;OpenAIAPIのAPIキー&gt;</code></pre><code>$ source ~/.zshrc</code>で再読み込み

環境変数にOpenAI APIとDeepl APIのAPIキーを設定する

ここまで設定したらいつでもどこでもコマンドが叩けるはず。コマンドはバイナリファイル名なので <code>chatgpt-cli</code>とターミナルで入力してEnterを押せば入力プロンプトが表示されます。

実行

使い方

メインとなる処理。処理の流れとしては入力→Deeplで日本語から英語に翻訳→OpenAI APIに投げる→回答を英語から日本語に変換→出力をひたすらループしています。<pre><code>package main

import (
	"fmt"
	"os"
	"strings"

	openai "./openai"
	deepl "./deepl"
)

func main() {
	deeplClient, openaiClient := initClient()

	for {
		input, err := getInputFromUser()
		if err != nil {
			fmt.Println("入力の読み取りに失敗しました:", err)
			continue
		}

		translated, err := deeplClient.Translate([]string{input}, "EN")
		if err != nil {
			fmt.Println("翻訳に失敗しました:", err)
			continue
		}

		response, err := openaiClient.GetChatResponse(translated)
		if err != nil {
			fmt.Println("OpenAI APIに接続できませんでした:", err)
			continue
		}

		if len(response) != 0 {
			result, err := deeplClient.Translate(response, "JA")
			if err != nil {
				fmt.Println("翻訳に失敗しました:", err)
				continue
			}
			fmt.Printf("&gt;&gt; answer&nbsp; &nbsp;: %s\n", result)
		}
	}
}

func initClient() (*deepl.Client, *openai.Client) {
	deeplAPIKey := os.Getenv("DEEPL_API_KEY")
	if deeplAPIKey == "" {
		fmt.Println("DEEPL_API_KEYが設定されていません。")
		return nil, nil
	}
	deeplClient := deepl.NewClient(deeplAPIKey)

	openaiAPIKey := os.Getenv("OPENAI_API_KEY")
	if openaiAPIKey == "" {
		fmt.Println("OPENAI_API_KEYが設定されていません。")
		return nil, nil
	}
	openaiClient := openai.NewClient(openaiAPIKey)

	return deeplClient, openaiClient
}

func getInputFromUser() (string, error) {
	fmt.Print("&gt;&gt; question : ")
	var input string
	_, err := fmt.Scanln(&amp;input)
	if err != nil {
		return "", err
	}
	return strings.TrimSpace(input), nil
}</code></pre>

main.go

リクエストを作成してOpenAI APIに向かって投げているだけです。<pre><code>package openai

import (
	"bytes"
	"encoding/json"
	"errors"
	"fmt"
	"net/http"
)

const (
	baseURL&nbsp; &nbsp; &nbsp;= "https://api.openai.com/v1"
	endpoint&nbsp; &nbsp; = "/chat/completions"
	model&nbsp; &nbsp; &nbsp; &nbsp;= "gpt-3.5-turbo"
	role&nbsp; &nbsp; &nbsp; &nbsp; = "user"
	temperature = 0.9
	max_tokens&nbsp; = 1000
)

type Client struct {
	apiKey string
	client *http.Client
}

func NewClient(apiKey string) *Client {
	return &amp;Client{
		apiKey: apiKey,
		client: &amp;http.Client{},
	}
}

// レスポンス
type Response struct {
	ID&nbsp; &nbsp; &nbsp; string `json:"id"`
	Object&nbsp; string `json:"object"`
	Created int&nbsp; &nbsp; `json:"created"`
	Model&nbsp; &nbsp;string `json:"model"`
	Usage&nbsp; &nbsp;struct {
		PromptTokens&nbsp; &nbsp; &nbsp;int `json:"prompt_tokens"`
		CompletionTokens int `json:"completion_tokens"`
		TotalTokens&nbsp; &nbsp; &nbsp; int `json:"total_tokens"`
	} `json:"usage"`
	Choices []Choices `json:"choices"`
}

type Choices struct {
	Message&nbsp; &nbsp; &nbsp; Message `json:"message"`
	FinishReason string&nbsp; `json:"finish_reason"`
	Index&nbsp; &nbsp; &nbsp; &nbsp; int&nbsp; &nbsp; &nbsp;`json:"index"`
}

// リクエスト
type Request struct {
	Model&nbsp; &nbsp; &nbsp; &nbsp;string&nbsp; &nbsp; `json:"model"`
	Messages&nbsp; &nbsp; []Message `json:"messages"`
	MaxTokens&nbsp; &nbsp;int&nbsp; &nbsp; &nbsp; &nbsp;`json:"max_tokens"`
	Temperature float64&nbsp; &nbsp;`json:"temperature"`
}

type Message struct {
	Role&nbsp; &nbsp; string `json:"role"`
	Content string `json:"content"`
}

func (c *Client) GetChatResponse(prompt string) ([]string, error) {
	requestBody := Request{
		Model:&nbsp; &nbsp; &nbsp;model,
		MaxTokens: max_tokens,
		Messages: []Message{{
			Role:&nbsp; &nbsp; role,
			Content: prompt,
		}},
	}

	requestBodyBytes, err := json.Marshal(requestBody)
	if err != nil {
		return nil, fmt.Errorf("failed to marshal request body: %w", err)
	}

	request, err := http.NewRequest("POST", baseURL+endpoint, bytes.NewBuffer(requestBodyBytes))
	if err != nil {
		return nil, fmt.Errorf("failed to create API request: %w", err)
	}

	request.Header.Set("Content-Type", "application/json")
	request.Header.Set("Authorization", "Bearer "+c.apiKey)

	client := &amp;http.Client{}
	response, err := client.Do(request)
	if err != nil {
		return nil, fmt.Errorf("failed to make HTTP request: %w", err)
	}

	defer response.Body.Close()

	var responseBody Response
	err = json.NewDecoder(response.Body).Decode(&amp;responseBody)
	if err != nil {
		return nil, fmt.Errorf("failed to decode response body: %w", err)
	}

	if len(responseBody.Choices) == 0 {
		return nil, errors.New("ChatGPT API returned empty response")
	}

	var res []string
	for _, r := range responseBody.Choices {
		res = append(res, r.Message.Content)
	}
	return res, nil
}</code></pre>

openai.go

こちらも基本的にリクエストを作成してDeepl APIにリクエストを投げているだけです。<pre><code>package deepl

import (
	"bytes"
	"encoding/json"
	"errors"
	"fmt"
	"io/ioutil"
	"net/http"
)

const (
	baseURL = "https://api-free.deepl.com/v2"
)

type Client struct {
	apiKey string
	client *http.Client
}

func NewClient(apiKey string) *Client {
	return &amp;Client{
		apiKey: apiKey,
		client: &amp;http.Client{},
	}
}

type Translation struct {
	DetectedSourceLanguage string `json:"detected_source_language"`
	Text&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;string `json:"text"`
}

type TranslationResponse struct {
	Translations []Translation `json:"translations"`
}

func (c *Client) Translate(text []string, targetLang string) (string, error) {
	requestBody, err := json.Marshal(map[string]interface{}{
		"text":&nbsp; &nbsp; &nbsp; &nbsp; text,
		"target_lang": targetLang,
	})
	if err != nil {
		return "", fmt.Errorf("failed to marshal request body: %w", err)
	}

	request, err := http.NewRequest("POST", baseURL+"/translate", bytes.NewReader(requestBody))
	if err != nil {
		return "", fmt.Errorf("failed to create HTTP request: %w", err)
	}

	q := request.URL.Query()
	q.Add("auth_key", c.apiKey)
	request.URL.RawQuery = q.Encode()

	request.Header.Set("Content-Type", "application/json")

	response, err := c.client.Do(request)
	if err != nil {
		return "", fmt.Errorf("failed to send HTTP request: %w", err)
	}
	defer response.Body.Close()

	body, err := ioutil.ReadAll(response.Body)
	if err != nil {
		return "", fmt.Errorf("failed to read HTTP response: %w", err)
	}

	var responseBody TranslationResponse
	err = json.Unmarshal(body, &amp;responseBody)
	if err != nil {
		return "", fmt.Errorf("failed to decode response body: %w", err)
	}

	if len(responseBody.Translations) == 0 {
		return "", errors.New("DeepL APIから回答がありませんでした")
	}

	return responseBody.Translations[0].Text, nil
}</code></pre>

deepl.go

実装について

最初OpenAI APIだけで作った時には全く使い物にならなかったですが、Deeplと組み合わせただけでかなり精度が上がりました。生成系AIはこれからもどんどん盛り上がっていきそうなので、こうして遊びながら触っていこうと思います。またCLIツールとしても、改行に対応して複数行の質問を投げることができるようにしたり、生成されたプログラム部分にはDeeplの翻訳をかけないようにするなど、まだまだ改善できそうな点があるのでChatGPTくんと協力しながらちょくちょくアップデートしていけたらなと思っています。

終わりに

OpenAIとDeeplのAPIを使ってChatGPTのCLIツール作ってみた

Dockerfileを基にDocker imageを作成していきます。今回は簡単に以下のような形でDockerfileを作成しました。<pre><code>#ベースになるコンテナ
FROM ubuntu:16.04

#システムのパッケージをアップグレード、apache2、nginxパッケージをインストール
RUN apt-get update &amp;&amp; apt-get upgrade -y &amp;&amp; \
apt-get install apache2 -y
RUN apt-get update &amp;&amp; apt-get install -y -q nginx

#コマンドの指定
CMD ["/usr/sbin/apachectl","-DFOREGROUND"]</code></pre> それでは、作成したDockerfileを使ってDockerイメージを作成します。Dockerfileのあるディレクトリに移動して、Dockerビルド（Dockerイメージを作成するコマンド）を実行します。<pre><code>$ docker build -t &lt;Dockerイメージ名&gt; &lt;Dockerfileが存在するディレクトリ&gt;)</code></pre>これでDockerイメージが作成できました。このDockerイメージを使用して、コンテナを起動します。<pre><code>#今回は443番ポートでポートマッピングする必要があったので443番ポートにしてます。
$ docker run -it --name &lt;Dockerイメージ名&gt; -p 443:443</code></pre> 以上でDocker image,container作成完了。

Docker image,container作成

セクション1で作ったコンテナの中に入りApacheでオレオレ証明書を発行したいと思います。まず、秘密鍵の作成。<pre><code># cd /etc/ssl/private
openssl genrsa -aes256 -out server.key 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
...................................................++++
....++++
e is 65537 (0x010001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:</code></pre>

秘密鍵の作成

<pre><code># openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:</code></pre>

CSRの作成

今回は10年持つ証明書<pre><code># openssl x509 -in server.csr -out ../certs/server.crt -req -signkey server.key -days 3650
Signature ok
subject=C = JP, ST = Tokyo, L = AdachiKu, O = Internet Widgits Pty Ltd, CN = localhost
Getting Private key
Enter pass phrase for server.key:</code></pre>

証明書の作成

<pre><code># vim /etc/apache2/sites-available/default-ssl.conf 

#32, 33行目
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key</code></pre>

Apacheの設定

<pre><code># a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
 systemctl reload apache2

# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
 systemctl restart apache2</code></pre>

SSL設定

このままcurlコマンド実行すると、ServerName を指定しろとエラーが出ちゃいます。なので、<code>/etc/hosts</code>と<code>/etc/apache2/apache2.conf</code>に指定していきます。<pre><code># vi /etc/hosts
127.0.0.1	localhost

::1	localhost ip6-localhost ip6-loopback

fe00::0	ip6-localnet

ff00::0	ip6-mcastprefix

ff02::1	ip6-allnodes

ff02::2	ip6-allrouters

172.17.0.2	www.myserver.hoge</code></pre> <pre><code># vi /etc/apache2/apache2.conf

# 一番最後に
ServerName&nbsp; &nbsp; &nbsp; www.myserver.hoge</code></pre>ServerNameを指定してあげることで、正確な通信経路を確立することができます。

FQDN を指定

Apacheでオレオレ証明書を発行

以上を設定することで、<pre><code>$ curl https://www.myserver.hoge</code></pre> 確認完了です。

curlコマンド確認

自分はエンジニアになって3ヶ月ほどの新米です。まだ、なにをするにも未熟で足りない部分が多くしんどくなることもありますが、挑戦したことに間違いはなかったと思っています。早く一人前になれるように、もっと質の高いブログかけるように日々精進します。ありがとうございました！

最後に

Apacheでオレオレ証明書を発行して自分を証明したい

時間がない人のために先に結論だけ申し上げると、結局ドキュメントに記載のとおりだった。ただ、もう少し付け加えると、無限に多くのリクエストを受けられるわけではなく、RDS Proxyが利用できる最大接続数が多いほど、多くのリクエストを捌くことができた。リクエスト数が一定以上多くなるとレイテンシーが増加し、それ以上は増えないという結果になった。また後述するが使用する言語・ライブラリ・実装によっても挙動が異なる場合があるため注意が必要で、上記の結論はPython / sqlalchemy(NullPool)+pymysqlを使用した場合。

スケールするので基本的に上限はない

まずは結論から

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/72d7171be8f24408b1f68efad6c60aca/image.png" alt=""><ul><li>上記のインフラ構成で、APIをマルチスレッドで5分間リクエストを投げ続けることで検証を行った</li><li>リクエストを投げ続ける処理については<a href="https://github.com/wg/wrk" target="_blank" rel="noopener noreferrer">wrk</a>というツールを使った<ul><li>Docker化したのでローカルを汚さずにサクッと環境構築したい人は<a href="https://github.com/jtamu/http_benchmark" target="_blank" rel="noopener noreferrer">こちら</a>どうぞ</li></ul></li><li>Lambda関数の内容としては、DB接続を取得し、簡単なクエリを発行してから接続を閉じる、というもの<ul><li>言語はPython、DB接続部分のライブラリはsqlalchemyを用いた<ul><li>Lambda環境は基本的に実行が終わったら破棄されるためLambda環境内にコネクションをプーリングするメリットはあまりないため、poolclassにはNullPoolを使用した</li></ul></li></ul></li><li>Lambda関数のソースコード：</li></ul><pre><code>import os
import pymysql
import mysql.connector
import time
from sqlalchemy import create_engine, text
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy.pool import NullPool

host = os.environ['RDS_HOST_NAME']
user = os.environ['USER']
password = os.environ['PASS']
db = os.environ['DB']
connect_count = os.environ['CONNECT_COUNT']
connect_timeout = os.environ['CONNECT_TIMEOUT']


def lambda_handler(event, context):
&nbsp; &nbsp; _connect()
&nbsp; &nbsp; return {
&nbsp; &nbsp; &nbsp; &nbsp; 'isBase64Encoded': False,
&nbsp; &nbsp; &nbsp; &nbsp; 'statusCode': 200,
&nbsp; &nbsp; &nbsp; &nbsp; 'headers': {},
&nbsp; &nbsp; &nbsp; &nbsp; 'body': '{"message": "Hello from AWS Lambda"}'
&nbsp; &nbsp; }


def _connect():
&nbsp; &nbsp; engine = create_engine(
&nbsp; &nbsp; &nbsp; &nbsp; 'mysql+pymysql://{user}:{password}@{host}/{dbname}'.format(user=user, password=password, host=host, dbname=db),
&nbsp; &nbsp; &nbsp; &nbsp; echo=True,
&nbsp; &nbsp; &nbsp; &nbsp; poolclass=NullPool,
&nbsp; &nbsp; )

&nbsp; &nbsp; session = scoped_session(
&nbsp; &nbsp; &nbsp; &nbsp; sessionmaker(
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; autocommit=False,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; autoflush=True,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; expire_on_commit=False,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bind=engine
&nbsp; &nbsp; &nbsp; &nbsp; )
&nbsp; &nbsp; )

&nbsp; &nbsp; res = session.execute(text('select now()'))
&nbsp; &nbsp; for v in res:
&nbsp; &nbsp; &nbsp; &nbsp; print(v)

&nbsp; &nbsp; session.close()</code></pre><ul><li>処理件数の上限は何に依存して決まるのかを確認するため、RDSのスペックを下げた場合と、最大接続数を下げた場合についても比較検証を行った</li></ul>

検証方法

<ul><li>RDSのインスタンスタイプ: db.t3.medium（プロキシで利用できる最大接続数: 100%, 305）<ul><li>1分間に最大8万リクエスト程度が限界だった<ul><li>なお、上記はRDS(Proxy)と同じVPC上のEC2環境で実行した場合</li><li>ローカル環境で実行した場合はその半数の4万リクエスト程度が限界だった</li></ul></li></ul></li><li>RDSのインスタンスタイプ: db.t3.micro（プロキシで利用できる最大接続数: 100%, 61）<ul><li>1分間に最大6万5千リクエスト程度</li></ul></li><li>RDSのインスタンスタイプ: db.t3.medium（プロキシで利用できる最大接続数: 20%, 61）<ul><li>1分間に最大6万7千リクエスト程度</li></ul></li></ul> EC2から実行した場合のほうがリクエスト数が多くなったのは、レイテンシーが小さかったためで、おそらく、同じVPCにあるので通信のパケットが長い距離を移動しなくて済むためと考えられる。なお、2つのマシンから同時に実行した場合もリクエスト数はほぼ変わらなかったため、クライアントマシンのスペックはあまり関係なく、送れるリクエスト数の上限はネットワーク帯域的な限界で決まるのではと思った。また、RDSのスペックもあると思うが、RDS Proxyの最大接続数によって最大リクエスト数がほぼ決まることがわかった。

検証結果

<ul><li>sqlalchemyのpoolclassにNullPoolを使用せず通常のQueuePoolを使用した場合、パフォーマンスが大幅に悪化した。<ul><li>Lambda環境は破棄されるがコネクションは紐付いた状態のままになるため、RDS Proxy側で再利用できないのが原因と考えられる</li></ul></li></ul>

その他わかったこと

具体的な検証内容

sqlalchemy(NullPool)+pymysqlを使用した場合は<code>session.close()</code>してもコネクション自体は切れずにプロキシでプールされ別の接続リクエストに再利用されるが、 pymysqlを単体で使用した場合はコネクションがプールされずに毎回切れる、という全く異なる挙動を示した。これによりpymysqlを単体で使用した場合はパフォーマンスが悪化し、リクエスト数が多くなるとレイテンシーの増加だけでなく接続失敗も発生するようになった。問題はコネクションの部分なのでクエリのログには原因を示すようなログは特に見当たらず、解決のためにはTCP接続の部分やソースコードなどを掘り下げていく必要があり時間がかかりそうだったため、今回はそこまで深追いすることはやめた。

使用するライブラリによって挙動が全く異なる

残る謎

Lambdaの課金は実行回数によって決まるため、最初なるべく実行回数を少なくしようとして1関数の中でループして500個のDB接続を取得するようにしていた。この関数を単体で実行したときは正常に動作したが、DBリクエスト数が2万件くらいになったあたりからレスポンスが正常に返ってこなくなった。Lambdaのエラーログには<code>Lost Connection</code>となっていたのでRDSの設定などを見直していたが、 最終的にAPI Gatewayの時間制限(30秒)に引っかかっていることがわかった。知っていれば回避できたと思うが、この問題の解決にかなりの時間を費やしてしまった。RDSのサービスを使う際には予め制約を把握しておくことが重要ということが身にしみてわかった。

API Gatewayの時間制約に翻弄される

苦労した点

RDS Proxyの負荷検証を行った件について

<ul><li>個人情報をサーバーに保存したくない人</li><li>少しでも画像データの削減をしたい人</li></ul>

この記事はこんな人向け

FinderでExif情報がある画像を見ると、こんな感じ。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/eeeef582d0274ea5b4f00f440d8e9a63/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-03-21%2022.34.30.png" alt=""> <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/03171583a01c467a88f41cdc41e274bd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-03-21%2022.34.37.png" alt="">GPSはFinderから消せるけど、他の情報は消せない。。。 画像のように、Exif情報は、画像の向きや撮影したカメラ情報、撮影場所のデータが格納されている。どの画像ファイルにもあるものではなく、JPEG（JFIF/.jpgファイル）あるいはTIFF（.tifファイル）などのファイル形式と共に用いられることが多い。 jsでExif情報の操作をする記事は少ないので苦労しました。みんなどうしているんだろう。。。pythonなどでは、PILを使って画像自体を新規作成したら消せるみたいなこともある様子。 Exif情報には、画像の向きなどの情報も含んでいるので、むやみに消すのは良くない。

Exif情報について詳しく

今回は、<a href="https://github.com/TakeshiOkamoto/EXIF.js" target="_blank" rel="noopener noreferrer">こちら</a>のライブラリを使わせていただきました。中身を見るとわかるのですが、バイナリデータをそのままいじっています。JPEGファイルの構造などは、<a href="https://hp.vector.co.jp/authors/VA032610/JPEGFormat/StructureOfJPEG.htm" target="_blank" rel="noopener noreferrer">こちら</a>を参照ください。 まずは、<a href="https://github.com/TakeshiOkamoto/EXIF.js/blob/master/EXIF.js" target="_blank" rel="noopener noreferrer">EXIF.js</a>を丸々コピーして、assetsフォルダなどの適当なところをに保存します。次に、先程保存したjsファイルをhtml側から呼び出せるように読み込ませます。<pre><code>&lt;script src="assets/EXIF.js"&gt;&lt;/script&gt;</code></pre> あとは、下記のコードをhtml内で動かせばjpegファイルがダウンロードされます。<pre><code>// inputフォームなどから画像データを取得。このあたりはよしなにしてください。
var buffer = event.target.result;

// uint8arrayに変換する。
var uint8Array = new Uint8Array(buffer);

// EXIF object定義。
ExifMaster = new TExifMaster(uint8Array);

// EXIF削除し、画像をダウンロード。
ExifMaster.SaveToFile("test.jpeg", false)</code></pre>

ライブラリを使う

僕は、Exif情報を消したあと、s3にアップロードしたかったので、先程のEXIF.jsに関数を付け足しました。 <pre><code>// -----------------------------------------------------------
// all : true 全てのExifを削除 false 画像方向のみを残す
// -----------------------------------------------------------
SaveToUint8Array: function (all) {
	// uint8arrayオブジェクトが返却される。
	return this.SaveToStream(all, true);
}</code></pre> 呼び出し側は、下記のようにしてみました。<pre><code>var buffer = event.target.result;

var uint8Array = new Uint8Array(buffer);

// EXIF object定義
ExifMaster = new TExifMaster(uint8Array);

// EXIF削除。uint8arrayオブジェクトで取得
const convertedUint8Array = ExifMaster.SaveToUint8Array(false)

// Fileオブジェクトに戻すなどしても良い。
upload_file = new File([convertedUint8Array.buffer], upload_file.name, {type: "image/jpeg"})</code></pre> Exif情報の確認は、TExifMasterを初期化後、Analystプロパティに保存されます。console.logなどで、ご自身が欲しい情報を見つけてみてください。 <pre><code>ExifMaster = new TExifMaster(new Uint8Array(reader.result));

// プロパティ確認用
onsole.log(ExifMaster.Analyst);</code></pre>

ライブラリをカスタマイズしてみる

Exif情報を削除してみる

【javascript】画像に含まれるexif情報を削除する

OpenAPIを<a href="https://swagger.io/" target="_blank" rel="noopener noreferrer">Swagger</a>とか<a href="https://redocly.com/" target="_blank" rel="noopener noreferrer">Redoc</a>でブラウザに表示させながら、書き換えもしたいし、リアルタイムに変更を見たいし、さらにはHTMLを書き出したい時だってあるよね。 そんな時はこの構成でホットリロードとバンドルをしちゃえば運用コスト低めで叶えることができるよね。

tl;dr

はい、いきなり愚痴が出てしまいました。 そうなんです、OpenAPIをゼロから書く時って割とファイル量が多く、着手から10分後くらいには途方もなさを感じてメンブレ必至です。 既存APIの実装からOpenAPI形式で仕様を書き出すツール等ありますが、初期整備として仕様書を書く際はゼロから書かなければいけないケースが大半かと思います。 前述していますが、OpenAPIは細かい仕様を書くことができる。だからこそ、完成度の高い仕様書を作成するとなると必然的にファイル量は増えてしまいます。

ゼロから書いていくのは割と辛い。

何かしらの仕様に変更や誤りがあったり、単純に誤字していることに気が付いたり。 いざ実装を進めていると、細かいことにも気が付くようになり、多少なり仕様書を書き換えることがあります。 「仕様書を見ていつつも、書き換えもしたい」そんなニーズです。

ちょっと修正したい時だってある。

これはOpenAPIの強みの一つなので、僕にとってファイル分割は必ず採用したいものです。（というより、OpenAPIを一つのファイルで書ききるのは鬼の所業…。） そして、分割されたファイルを一つにバンドルしておきたい。一つのファイルにまとまっていると、何かと便利です。 例えば、<ul><li>ファイルのPath指定による<code>$ref</code>はSwaggerだと上手くいくが、Redocだと上手く参照できずエラーになる。</li><li>OpenAPIをHTMLにしてチーム内で見れるようにホスティングしたいが、分割されていると上手くHTML出力ができない。</li></ul>みたいなケース。（使っているツールに依る部分もあるかと思います。） こんなケースをカバーするためにも、一つのファイルになっていると恩恵を受けることがあります。

ファイル分割は絶対にしたい。でもバンドルもしたい。

OpenAPIに対する悩み

前置きが長くなってしまいました。さて、前述のお悩み解決に対処する方法です。 ポイントはズバリ二つ。<ol><li>ホットリロード</li><li>分割されたファイルのバンドル</li></ol>

以下の内容で構成していきます。今回はDockerでRedocとして表示させるので、Redocの公式イメージを使います。 <ul><li>Docker<ul><li><a href="https://hub.docker.com/r/redocly/redoc/" target="_blank" rel="noopener noreferrer">Redoc公式イメージ</a></li><li>OpenAPIを編集するための作業スペース</li><li>開発中に表示させて確認する</li></ul></li><li>JavaScriptスクリプト<ul><li>OpenAPIのウォッチャー<ul><li><a href="https://github.com/paulmillr/chokidar" target="_blank" rel="noopener noreferrer">paulmillr / chokidar</a></li></ul></li><li>バンドラー<ul><li><a href="https://github.com/WindomZ/swagger-merger" target="_blank" rel="noopener noreferrer">WindomZ / swagger-merger</a></li></ul></li></ul></li><li>OpenAPI</li></ul>

Dockerでレンダリング & ホットリロード & バンドル

<pre><code>/
├── compose.yaml # Docker Compose
├── docker
│&nbsp; &nbsp;└── redoc
│&nbsp; &nbsp; &nbsp; &nbsp;├── Dockerfile
│&nbsp; &nbsp; &nbsp; &nbsp;├── bundle.ts # バンドラー
│&nbsp; &nbsp; &nbsp; &nbsp;└── start.sh # Docker EntryPoint
└── api_docs/ # 分割されまくったOpenAPIたち
 &nbsp; &nbsp;├── components/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;├── parameters/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── path/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── query/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── requestBodies/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── responses/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── schemas/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── securitySchemes/
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;├── paths/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│── tags
 &nbsp; &nbsp; │&nbsp; └── xxx.yaml
 &nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;└── openapi.yaml # バンドルされたOpenAPI</code></pre>

ディレクトリ構成

<pre><code>version: "3.8"

	services:
	 redoc:
	 build:
	 context: .
	 dockerfile: ./docker/redoc/Dockerfile
	 volumes:
	 - ./docker/redoc/bundle.ts:/app/bundle.ts
	 - ./docker/redoc/start.sh:/app/start.sh
	 - ./api_docs:/usr/share/nginx/html/docs # Redoc公式イメージでは '/usr/share/nginx/html/' 配下にOpenAPIを置く必要がある
	 ports:
	 - 9000:80</code></pre>

compose.yaml

<pre><code># Redoc公式イメージをベースに
FROM redocly/redoc:v2.0.0
	
WORKDIR /app
	
# ホットリロードにnpmパッケージを使用するためnpmインストール
RUN apk add --no-cache npm
	
# npmパッケージをコンテナ内でしようするための設定
ARG NODE_MODULE_PATH=/node
RUN npm config set prefix=${NODE_MODULE_PATH}
ENV PATH $PATH:${NODE_MODULE_PATH}/bin
ENV NODE_PATH ${NODE_MODULE_PATH}/lib/node_modules
	
# レンダリングするOpenAPIのPath　（Redoc公式イメージの環境変数）
# ファイル分割された '$ref' が含まれていると上手く参照できずエラーになる
# そのため、バンドル前の 'index.yaml' は使わず、バンドルされたファイルを指定する
ENV SPEC_URL docs/openapi.yaml
	
# ホットリロードに使用するnpmパッケージ群をインストール
RUN npm i -g \
 forever \
	ts-node \
	chokidar \
	swagger-merger
	
# EntoryPointにShellスクリプト指定
ENTRYPOINT [ "sh", "start.sh" ]</code></pre>

docker/redoc/Dockerfile

<pre><code># RedocのNginxを立ち上げる
# 'docker/redoc/Dockerfile'の 'ENTRYPOINT' で公式イメージの ' ENTRYPOINT ' は上書きされてしまったので再定義
# '&amp;' を付けてバックグラウンドプロセスにして、後述のバンドラーのプロセスと並走できるようにする
source /usr/local/bin/docker-run.sh &amp;
	
# バンドラー実行
ts-node bundle.ts</code></pre>

docker/redoc/start.sh

<pre><code>// 'ts-ignore' 連発。非常に良くないので反面教師で。。。
// @ts-ignore
const chokidar = require("chokidar") // ウォッチャー
// @ts-ignore
const swaggerMerger = require("swagger-merger") // バンドラー

const rootPath = "/usr/share/nginx/html/docs/" // OpenAPIが置かれているPath
const rootFile = `${rootPath}index.yml` // OpenAPIのルートファイルPath
const mergedFile = `${rootPath}openapi.yml`　　// バンドルしたOpenAPIを吐き出すPath
	
chokidar
 .watch(rootPath, { ignored: mergedFile })
 .on("all", (event: string, path: string) =&gt; {

 // ウォッチャーの検知したイベントをログに出力
 console.log(event, path)

 // OpenAPIをバンドル
 swaggerMerger({ input: rootFile, output: mergedFile })
 .then(() =&gt; {
 	 console.log("ReBundled OpenAPI")
 })
 	.catch((err: object) =&gt; {
	 console.error(err)
	 })
	})</code></pre>

docker/redoc/bundle.ts

この悩みに対処しよう

<ul><li>レンダリング<ul><li>Dockerを立ち上げればRedocをブラウザで確認することができます。</li><li>API実装中には必須だと思います。</li></ul></li><li>ホットリロード<ul><li>OpenAPIを書き換えたらRedocもそのタイミングで更新されます。<ul><li>表示を確認しながらサクサク書くことができます。</li></ul></li><li>「変な表示になってないかな？」「API実装中だけどちょっと修正しとこ。」ができます。</li></ul></li><li>バンドル<ul><li>OpenAPIを書き換えたら一つのOpenAPIとしても書き出されます。</li><li>これさえあれば色んな用途で柔軟に使い回せます。</li></ul></li></ul>

これで何が起こるか (まとめ)

今回はOpenAPIにまつわる開発体験の向上を軸にご紹介しました。割と良くある構成なのかな？とも思いますし、ツールの選定によってはもっとシンプルにすることができるかと思います。 もっと良い構成をご紹介できるように、チャンスがあれば色々試していきたいと思います。 最後まで読んでくださりありがとうございました！では！ﾉｼ

BuildersIO produced by YOKU

Vercel Ship Day3 〜Vercel Spacesを使ってチームで開発を効率化〜

Vercel Ship Day2 〜セキュリティのアップデート〜

Vercel Ship Day1 〜ストレージ機能追加〜

GOでCSV import ~ 準備編

Docker Compose使ってみた

Boto3でDynamoDBのテーブルから複数レコードを一括で削除する

Go言語における並行処理のベストプラクティス

OpenAIとDeeplのAPIを使ってChatGPTのCLIツール作ってみた

Apacheでオレオレ証明書を発行して自分を証明したい

RDS Proxyの負荷検証を行った件について

【javascript】画像に含まれるexif情報を削除する

OpenAPIの運用コスト下げたい。

単体テストのベストプラクティス

Auth0環境を構築して自作のAPIと連携してみた

OpenAIとDeeplのAPIを使ってChatGPTのCLIツール作ってみた