cloudfrontを設定について悩まされた話

エピソード

直接関わってないけど、cloudfront周りで躓いたので、備忘録として残しておきます！
現在はバックエンドのタスクをこなしており、インフラ面は合同開発会社が担当している案件に従事しています。
今回の技術要件として、フロントがnuxt.js バックエンドlaravel、インフラawsの構成でした。
トラフィックはcloudfrontを経由してそれぞれのオリジンにアクセスする構成。nuxt.jsはs３に静的ホストしていました。
１つの大替ドメインでそれぞれのファイルアクセスを行う為に、Behaviorの設定を　/js　など色々設定していました。起きたことはnuxt側のパスと laravel側のパスとで競合がおき、適切にファイルを読みでくれないといく問題に直面しました。

そもそも何が悪かったのか？

1,　1つの大替ドメインの運用
2,   そもそもlaravelのasset ファイル群をs3にuploadして管理してない。
3,    そもそも、crosの設定をすることを許容できなかった

 1つの大替ドメインの運用

そもそもサブドメインを切って大替ドメインを分けてオリジン管理をすることでこのような問題はなくなる。
問題としてはcross originの設定が必要。こちらに関しては「バックエンドで必要なヘッダーを返す、フロントで必要なヘッダーを付与してrequestを投げる。」これで問題解決。それぞれの責務が分離できて管理が容易になる

そもそもlaravelのasset ファイル群をs3にuploadして管理してない

そもそもpublic配下のassetファイル群をバックエンド側で管理したままだった。asset用のs3を用意して、circleciのbuild時にそっちにsyncさせる。アセットパスの設定を変更して、s3のオリジンに向き先を向けるように設定する。

そもそも、crosの設定をすることを許容できなかった

恥ずかしい話し、crosの設定がうまくできおらず、プリフライトリクエストでずっと怒られていたのと、時間的な猶予がないとのことで、現在の設定になってしまった。。らしい。。
そもそもローカルではcrosの設定はうまくいっていたので、dev環境でできないはずがない。
おそらく、envの許可するドメインの値がうまく読み込まれていないのが原因かなと思われる。アクセス先のオリジンに対して、Access-Control-Allow-Originが返却されていない。

対応したこと

2つめの問題に対して対応しました！少しでも責務を分離できたのではないかなっと思います。この辺は構築経験が生きたと思います。
また、サブドメイン等の管理は提案はしましたが、時間的に猶予がないとのことでお見送りになりました。
SIだけじゃないかもしれませんが、もっと腰を据えて開発したいです。