ここ数年メールを行う実装を行う際にSendGridを使っています。 SendGridはメール配信のSaaSで、細かい事を気にせずHTTPリクエストでメールが送信できるようになり、本当にお世話になっています。
今回はSendGridを利用するアプリケーションでローカルの開発環境やCIなどのテスト環境でどのようにSendGridのキーを使うか考えました。
- 開発環境向けのAPI KEYを発行する。(実際にメールが飛ぶ)
- 開発者ごと/役割ごとに開発環境向けのAPI KEYを発行する。(実際にメールが飛ぶ)
- アプリの実装でメールサービスをモックに切り替える。(メールが飛ばない)
- SendGridのモックサーバーをコンテナで立てる。(メールが飛ばない)
このような方法がパッと浮かび、それぞれについて深く考えていきました。
開発環境向けのAPI KEYを発行する
基本的に楽で良いのですが、鍵の管理方法(gitに含めるかなど)考える必要があります。また誰か退職者がでた際に鍵を更新する必要があります。ただしこの運用がしっかりできる自信がないため極力避けたいと思いました。
開発者ごと/役割ごとに開発環境向けのAPI KEYを発行する
こちらは退職者が出た際はその個人の鍵に対して無効化すれば済みますが、担当者ごとに鍵を発行する必要があります。その管理は行う必要があります。
また実際にメールが飛ぶことは確認としては良いことが多いのですが、運用していく上で誤まってたくさんのメール送ってしまったり、サンプルデータとして作った存在しないメールにたくさん送ってしまったなどミスが時々起こってしまいます。
そのため実際にメールが飛ばない方法の方がミスが少ないと考え、そちらの方法を模索することにしました。
アプリの実装でメールサービスをモックに切り替える。
現状アプリ側ではDIを使って実装しているため切り替えることは容易です。ただし、切り替えられても送信されるはずのメール自体の確認を行うことができません。例えばパスワードリセットしたメールなど実際に送られないため確認ができずパスワードをリセットすることができません。またアプリのログに内容を出すようにしても良いのですが、サーバーサイドのエンジニアはそれでも良いですが、フロントエンジニアにもそれをお願いするのはあんまりな感じがしました。また実装を切り替えやすくしているのもDIの良さだと思うのですが、極力本番に近い依存関係でローカルも動かせるようにしておいた方が確認の上でも間違いないが少なくなると思っていました。
SendGridのモックサーバーをコンテナで立てる。
残ったこちらを実装していくことにしました。
実装方針としてはSendGridのメール送信のAPIを作成する。その送信内容を貯めておく。 その内容をGUIで確認できるメーラー風の画面を作成します。
アプリ本体は環境変数でSendGridのHostを変えているだけで他はそのままで利用することができます。
また思わぬメリットとしてCIで新規登録のE2Eテストを行う際にメールを受け取ったかどうかの確認ができなかったり、その送られたトークンのチェックなどができず、今まで手動で行なっていたのですが、そこに関しての確認が簡単にできるようになりました。
github, docker hubに公開しています。
現状自分たちが使っているAPIの使い方でだけ上手くいくような実装になってしまっているので、こういう使い方した時に動かないなどあればIssueやPRいただければと思います。