あらすじ

うーむ。何か変わったことをやりたいな・・・

ということで思いついたのが

という構成のサービス。

基本的なアイデア:
バックエンドサービスは基本的にはGET系のAPIのみを提供し、
POST系の処理はプライベートネットワークからのみアクセス可能とする。
GETだけならトークンもいらんだろうしGitHub Pages(無料版)でもええか？

ということで、さっそく作ってみたのですが・・・

落とし穴1: Mixed Contentの禁止

Google ChormeではMixed Contentが禁止されています。
これは、HTTPSで提供されているサービス中にHTTPで提供されるコンテンツが混じっているような状況のことなのですが、ここでは、次のような状況になっていました。

当然、API呼び出しがブロックされることに。簡単な回避方法も見つからなかったのでひとまずLet's EncryptでTLSを導入することに。

また、この時のドメインについては、いつもの無料DDNSサービス
DDNS Nowさんを使わせていただきました。

443ポートの解放し忘れなど初歩的なミスを犯しながらなんとか当初の目的であった
GitHub Pages上での動作確認に成功したのですが、ここで一つ問題が。

フロントエンドに変更を入れた後、デプロイ前にローカルで動作を確認したかったのですが、確認のためにブラウザを開いているマシンとバックエンドサービスをホストしているマシンのグローバルIPアドレスが同じなために、ルータのポートフォワーディングが正しく機能しないことが判明。

具体的には、ブラウザ側からURLに向けてリクエストが投げられると、

という流れに入ってしまうんですね。
これは同じことはGitHub Pages上の本番フロントエンドを開いた時にも言えるのですが、こちらはひとまず置いておくとして、少なくとも開発時には通常のおうちインターネットで結果の確認ができないと困ってしまうわけです。

とはいえ、同一ネットワークにはいれるのであれば、ポートフォワーディングが機能しなくとも単にプライベートアドレスでAPIにアクセスするように開発時のコードを修正してあげれば・・・

ERR_CERT_COMMON_NAME_INVALID

・・・はい、ダメなんですね。証明書にはしっかりとホスト名が書いてあるので、IPアドレスでアクセスしようとすると、そこが一致しないために不正な証明書であるとしてはじかれてしまいます。

いろいろ対処法はあると思うのですが、ひとまず今回は、バックエンド側にルーティングの処理を追加して、httpでのアクセスもできるようにしました。そのうえでフロントエンド側では、開発時のみhttpで直接プライベートアドレスにAPIリクエストを投げるようにしてあげたわけですね。