API Gateway
が自分がやりたかったことらしいと気づいて、環境を作って実験中。
表側だけの話なので、裏側は既存の仕組みを使えるのがやりやすい。
クロスオリジンとか、カスタムヘッダー周りに設定がいりそうだけど、まだそこまで辿り着けていない。
なんやかんやで1ヶ月くらいはかかってしまうかも。
が自分がやりたかったことらしいと気づいて、環境を作って実験中。
表側だけの話なので、裏側は既存の仕組みを使えるのがやりやすい。
クロスオリジンとか、カスタムヘッダー周りに設定がいりそうだけど、まだそこまで辿り着けていない。
なんやかんやで1ヶ月くらいはかかってしまうかも。
AWSのアカウントを作成してから1年経って、いろんな無料枠が無くなった。
ALBとかRDSとか、勝手に永年750時間無料だと思っていたけど、両方普通に課金され始めて料金が3倍くらいになってしまった。
料金を安くするために、構成を再考している。
lambda→EC2にするか、単にEC2だけで受ける構成にするか、悩み中。
前者は、証明書を今まで通りAWSのスタックに任せられる楽さがあるので、その方向で検討中。
しかし、やっぱり基本的にはお金を絞る以上マネージドではなくなっていくんだな、、、
なんか使っているライブラリによるgit操作が遅いと思って、試しに素のコマンドを呼び出して実装してみたら、条件にもよるけど1.5倍以上速くなった。
枯れた技術の大切さが身に染みた。
遅いというissueだけそのうち立てておこうかな。
「成功したリリース」を定義、特にgitから得られる情報からのみ判断するのはなかなか骨が折れる。
失敗したリリースというのは、後から修正されたリリースだろう、というところまでは素直で良い。
問題は、その失敗したリリースが例えばrcとかbetaとかで正規リリースでなかったとしたら?
そういうプレリリースは普通正規リリースとは違うので無視したいだろう。
ただ、プレリリースに対して修正が入っていた場合、正規リリースの間にも修正が入っているのはまた事実。
これを成功とするか失敗とするかは、ケースバイケースでもありそうだ。
となると、個別に指定できるようにしておくのがよいかなあ。
RSSが動かなくなっていたのを直した。
いつから動いていなかったのかもわからない。
もしかしたら、ルートに平置きしていたファイルをsrc以下にまとめたときからかもしれない。
今までよりリクエスト回数は増えてしまうものの、構成としてはわかりやすく素直になった。