ＭＡＮＡＢＩ

kou

Slackとかのzp-個人板や、times-個人板は学び以外の情報も入ってしまう。
Notionだと、学び用ページを1つ作ってそこに溜めていくような運用になるが、区切りがつけにくいので少し見にくい。

というわけでここで溜めてみる。フロー情報的でありつつストック情報になるようにしたい。

学びや気づきをそのまま書く。垂れ流し用。勿論、解釈が誤っていることもときにはあるはず。
ここで気付いたことを一部まとめて記事にするなどできたらより良いだろうけど、今は考えずにおく。

どうでもいいが最近「ＭＡＮＡＢＩ」のような、全角の英字表記をタイトルにするのに地味にハマっている。Notionとかのタイトルも全角英字にすると少しおされになっていい感じ。

kou

[TITLE] Webアプリケーション開発におけるバックエンドAPIは、ユースケース単位で切ることが殆どなのではないか

あまりリソースを取るというようなAPIが必要になるケースは普通のWebアプリケーション開発においては少ないのかもしれない。

RESTというものに原理的に従った「リソース（DBテーブル=モデルであり、そのモデルのまま返すようなイメージ）を返すAPI（これは個人のイメージであって正確かはわからない）」より、アプリケーション内の比較的個別具体的な「ユースケースのためのデータを返すAPI」が基本的なのかも。

RESTの原則に従って作るといいのは、一般に公開している（外部の誰でも使えるようにしている）Web APIと呼ばれるものなのではないか。（Web API: The Good Partsは、こっち）

kou

[TITLE] HTTPヘッダ: Cache-Controlヘッダで、max-age/s-maxageの秒数とstale-while-revalidateの秒数を設定する際のその秒数の意図

max-age(ブラウザにキャッシュさせる)と、s-maxage(CDNにキャッシュさせる)のキャッシュの設定時間は、どの時間（秒数・分数）までなら古いもの(キャッシュ)を見せることを許容できるか、ということを秒数で指定しているものだと理解できる。

極端な話、常に最新の状態のものを表示しなければならないのであれば、そもそもキャッシュしないか、max-age/s-maxageを0にすると、常にキャッシュではなくオリジンまでアクセスが行き、(API側でレスポンスキャッシュなどをしていない限りは)ほぼほぼ最新のデータを取得することができる。

逆に、例えばmax-age/s-maxage=3600であれば、3600秒=即ち1時間はユーザーが古いデータを見る可能性があることを許容する、と明示していることを意味する。

stale-while-revalidateは、max-age/s-maxageのキャッシュ時間を過ぎていた場合に、1度は古いキャッシュ(stale)を返し（ちなみにこれを返すのはどこの話？CDNか？）、古いキャッシュを返すのと同時にオリジンサーバーまでアクセスしに行って新しいキャッシュを生成する（これも恐らくCDNに置き直すって話なのかな）、ということをする。

stale-while-revalidateがまだ詳しくわかっていないけど、CloudFrontのドキュメントに書いてあったのをここにも貼っておく。

stale-while-revalidateは、あれかな、通常のキャッシュ（max-age/s-maxage）に加えて、プラスどれくらいまでなら古いデータを返していいかを指定しつつ、その範囲(stale-while-revalidateの指定秒数)内でリクエストが来た場合には、非同期で新しくキャッシュを更新しておくみたいな感じなのかな。キャッシュの期限も切れていて、かつstale-while-revalidateの秒数も超えている場合にアクセスがあったときは、通常通りオリジンサーバーまでアクセスが飛んでまた改めてキャッシュされるみたいな感じ？

上のドキュメントに書いてあることまんまだけど、以下のような状況のとき、1時間は普通にキャッシュを返しつつ（=1時間までなら古いものを見せることを許容する）、600秒=10分間は追加で古いデータを返す時間が延長していて、その間内にアクセスがあったら1度古いデータを返しつつ、キャッシュを非同期に更新し、次にすぐアクセスしたユーザーにはもう新しくなったキャッシュが返るみたいな。
1時間超えて、さらに10分も超えた場合には一番最初のリクエスト同様、オリジンサーバーまでリクエストが飛ぶって感じかな。

Cache-Control: max-age=3600, stale-while-revalidate=600

stale-while-revalidateが設定されていない場合だと、1時間ごとに、CDNのキャッシュを更新するために、1時間毎に初回のアクセスユーザーがオリジンサーバーまでデータを取りに行って割を食うことになるけれど、stale-while-revalidateを設定している場合だと、継続的にアクセスが有る限りは、常にキャッシュが返り続ける状態になる（stale-while-revalidateの秒数経過しない限りは）ので、基本的にはstale-while-revalidateの時間は長めに設定しておくのがベターな選択な気がする？

# 86400秒(=1日)の間に1度でもアクセスがあれば、常にキャッシュを更新し続けられる。
Cache-Control: max-age=3600, stale-while-revalidate=86400

でもどうなんだろう？stale-while-revalidateの秒数を長めに設定しておけばいいってもんでもない気がしてきた。うーん…頭こんがらがってきたな。

kou

[TITLE] s-maxageのsはshared cacheのs

なるほどなあ。共有キャッシュか。

kou

[TITLE] ブラウザやCDNにおいてキャッシュすることのメリット

[メリット]

高速でコンテンツがユーザーに返る（ユーザー視点のメリット）
オリジンサーバーへの負荷が軽減される（サービス提供者側のメリット）

[注意点]

特にブラウザキャッシュ（プライベートキャッシュ）の場合、ユーザー個人の認証が必要な情報をブラウザキャッシュさせてしまった場合に、そのキャッシュをクリアする方法がサービス提供者側からではどうしようもできない。一方で、CDNへの共有キャッシュであれば、まだインシデントが発生したとしてサービス提供者側からCDNに向けてキャッシュクリアをかけることができる（ただそれが起きてしまった時点で大問題どころの騒ぎではなさそうだが）。

kou

[TITLE] デザインのコツ

強弱を付けることを意識する。

強める

フォントサイズを大きくする
太字にする
- ※フォントサイズを大きくすることと、太字にするのを併用しないように気を付ける。往々にして強すぎになってしまう

弱める

フォントサイズを小さくする
文字色をグレーめにする
何回も見るような情報は弱めにする
- ex. Twitterのリツイートやいいねアイコンには「リツイート」や「いいね」という文字が表示されていない
境界を区切りたいときはボーダーをつけるが、ボーダーの色はできるだけ目立たないようにする（気づかないぐらいが丁度いい）

kou

[TITLE] DDDをしっかりと学ぶ前にAPI設計とDB設計を固める

重要度的にDDDをしっかりと学ぶより先に、API設計とDB設計をちゃんと固めるのが先。
汎用性を考えてもAPI設計やDB設計のほうがどこでも使えるね。DB設計は特に。

[API設計を固めるために読みたい本]

Web API: The Good Parts
Web APIの設計（link）

[DB設計を固めるために読みたい本]

失敗から学ぶRDB
達人に学ぶDB設計
SQLアンチパターン

kou

[TITLE] Next.jsにおいてuseRouterは何をしているのか

ページ遷移を実現するためのフックだろう、と安易に考えていたが、実は本当に奥深いことをしていたらしい。

そもそも、SPAの時代における「ページ遷移」とは、MPA時代のような、そのままの意味での「ページ遷移」（リロードを伴うようなもの）ではなく、以下の2つの要素の組み合わせで成り立っている。

JSのHistory APIを用いてブラウザの履歴を操作する（アドレスバーに見えている情報を書き換える）
JSでDOMを書き換えて、"遷移先(実際には遷移ではない)"であるページの内容を構築する

つまりuseRouterが行なっていることは、「URLの書き換え」と、「画面の再構築（DOMの書き換え）」をしていることになる。

「画面の再構築（DOMの書き換え）」のためには、その画面を再構築するためのJSのコードが必要になるが、これをNext.jsでは、(恐らく)ビルド時に生成している。（SSRの対象ではない画面のJSコードは/_next/static/...に置かれる？。SSRの対象となる画面は/_next/data/{ランダムな文字列?}/{パス}のようなところに置かれている？）
これをrouter.pushのタイミングなどで_next/...に対してリクエストを飛ばして画面を構築する用のjsを取得している。（以下はSSRではない画面の例。画面をレンダリングする用の画面.jsファイルを取得している。）

↓router.pushのときに発火している、"遷移先"画面を構築する用のJSコードのリクエスト(取得)

後でまた書きたいこと

SSRは初回表示のため（主にSEO、クローラーのため）であり、SSRページAを開いたときに、gSSP内でAページに必要なデータを取得し初回のHTMLにAPIからのデータまで組み込んで返すのは理にかなっているが、SSRページAからSSRページBに遷移する際にも、SSRページBのgSSP内でBページに必要なデータを取得して、BページのHTMLを組み立てて、それをブラウザに返して表示しているわけではない。これだとこれまでのMPAと何も変わらない（毎回の遷移のたびにそのページのHTMLを返す）。そうではなくて、あくまでSSRは初回のHTMLのためであって、その後はSPA的に（=DOMの書き換えで）画面を"遷移"（構築）する必要がある。それをどのように実現しているのか。要は、画面の切り替え用（DOMの書き換え用）JSの取得と、その画面に切り替えたときに必要になるAPIからのデータの取得をどのように実現しているのかというところ。
Next.jsなどにおけるSSRは、「初回だけSSR」なんだよな、ということ。

kou

[TITLE] 2024年6月現在、AuthContextを用いた AuthContextProvider & useContext(AuthContext) をあまり見かけなくなった理由

今は各コンポーネントで、/user APIとかをuseSWRとか用いて気軽に叩きまくることができるけれど、昔はAuthContextとかでルートに近い位置でloginUserを取得して、子どもがuseContext(AuthContext)で受け取るのが多かったが、今はあまり見かけなくなった。それはなぜかというのを話していたのでそのまとめ。

AuthContextとかでloginUserの情報を取得し、下の子どもたちに分配していたのは、今のように各コンポーネントが/user叩くと、その分だけ/user APIへのリクエストが飛んでいたから。
swrライブラリ（useSWR）などが同一エンドポイントに対するリクエストを何度もリクエストしないようにしてくれているおかげで、末端のコンポーネントたちが何度同じ/userを叩いてもAPIリクエストが飛ばなくなった。そのため、一番上流でAuthContextProviderでloginUserを取得して下層へContext経由で流す方法が下火となり、各コンポーネントが自身に必要なデータを必要なAPIを叩いて呼び出すことが可能になった。

受け売りです。

kou

[TITLE] APIから返す値はスネークケースが良いか？キャメルケースが良いか？

結論、最終的にはフロントエンドで使用されるのだから、JavaScriptに合わせてキャメルケースで返すのが良い。

APIから返す値は大体スネークケースになっているイメージが強くて、固定観念的にスネークケースにしてしまうことが多かった。LaravelでAPIを立てている場合でも、PHPはキャメルケースで基本的に書かれるのにAPIレスポンスの値だけスネークケースにしてしまうという意味不明なことをしていた。

現代のフロントエンドはJavaScriptで書かれることが殆どなのだから、APIからはキャメルケース（JavaScriptで一般的なもの）で返すのが一番合理的な気がした。だから、Laravelはそのままキャメルケースで返して良くて、逆にRailsみたいなスネークケースが基本の場合にはキャメルケースに変換して返して上あげるのがいいのかなと思った。

kou

[TITLE] Next.jsのPartial Pre-Renderingについての学び

PPRの概説としてはこの記事が詳しい。

従来のStreaming SSR（Transfer-Encoding: chunkedで返すアレ）は、TTFBとFCP向上に繋がる。クローラー的に対象のWebページのコンテンツも全部ストリーミングされたあとの画面として認識してくれるのかね。

App Router以後の世界では、従来のSSG・ISRなどに対応する「static rendering（静的レンダリング）」と、従来のSSRに対応する「dynamic rendering（動的レンダリング）」がある。

Streaming SSRとPPRの違いは、Streaming SSRがユーザー共通の変わらない部分であっても全て含めてdynamic rendering（要は、ユーザー固有の動的データじゃない部分(=全ユーザー共通部分)でもサーバーサイドで全て一からレンダリングをしている）していたところを、PPRでは、static renderingとdynamic renderingが組み合わされている。
PPRでは、ユーザー共通の変わらない部分はビルド時にSSG的にstatic renderingしておき（ユーザー固有になる部分は「hole（記事内にあるdynamic holeやasync hole）」を意図的に空けておく）、残りの空いた穴（ユーザー固有の部分・holeの部分）をあとからストリーミングでサーバーサイドレンダリングして逐次返して埋めていくという流れを取る。
よって、Streaming SSRと比べてPPRはstatic renderingで事前にレンダリングしているものをリクエストが合った際に高速で返すことができる点において、TTFB(Time to First Bite)が早くなっていると言える。

[疑問] static renderingというけど、ビルド時に起きている実際のことは何が起きている？HTMLをビルド時に作っているっていうわけではないような気もするがHTMLを作っているのかな？static renderingが従来のSSGに近いのなら、HTMLを作っていても不思議ではない。

PPRは、static renderingとdynamic renderingの両方を恐らく1度のNext.jsサーバーへのリクエスト（例えば、/teacher/11111のような）で返すことになる（これはStreaming SSR同様のTransfer-Encoding: chunkedの影響だと思う。実際に検証してはない）と思うので、ユーザー固有の動的コンテンツ生成(dynamic renderingの部分)までをNext.jsサーバー側で行なうことになるので、CDN上でのキャッシュは使えなくなる。

ブラウザ → CDN → Next.jsサーバー → APIやDB
　　　　　　　　　　↑この部分でdynamic renderingも行なうので、CDNでキャッシュするとここでのdynamic rendering結果もキャッシュしてしまうことになるはず。

以下さらに雑メモ。

App Routerあまり追えていなかったが、サーバーコンポーネントといい、サーバー側にどんどん処理が寄っていってるんだなあ。少なくとも最初の(初回リクエスト時の)レンダリング業務は殆どサーバー側に寄っていってる印象。クライアントサイドからJS使ってブラウザからフェッチかける必要がなくなっていくんだなあ（useSWRとかTanstack Queryがいらなくなっていく理由もわかるな）。

useStateやuseEffectなどのフックは、サーバー側に状態を持っていても仕方ないなどの理由で、これからもクライアントサイド（特にブラウザ上）のJSで実行されるんだろうけど、データフェッチ処理はuseSWRのようにクライアントサイドから直接APIサーバーを叩きに行くことは少なくっていくんだろうなあ。

useSWRとかはfetchの中でもGETに限定したものだけど、fetchのPOSTとかのWRITE系処理は、Next.jsの新たなServer Actionsでこれもクライアントサイド（ブラウザ）から直接APIサーバーに対してリクエストを飛ばすのではなく、Next.js内に定義された（use serverディレクティブだっけ？）Server Actions用関数を実行するようになっていって、どんどん、GETにせよ、POSTにせよ、Next.jsサーバーを1度通す形で処理が行われるようになっていきそうだね。
Next.jsのBFF的傾向が強まっているといえるのかな。

ちょっと良い機会だったので、ざっくりデータ取得/読み込みのGETリクエスト、データ書き込みのPOSTリクエストをどのように行なっていたかの変遷を書いてみる。

## 素のReact時代のGET
①ブラウザ → Reactサーバー（初回ロード：Reactサーバーから空のHTMLとReact実行コードなどが返ってきて、ブラウザ上でReact(JS)を実行、DOMを書き換えてUI表示）
②ブラウザ → バックエンドAPI（UI表示(レンダリング)後、useEffectの中でfetchを実行してAPIからデータを取得、useStateに格納(setState)して、それをトリガーにUIを更新）

要はブラウザからバックエンドAPIを直接叩いてデータを取得していた。

## 素のReact時代のPOST
ブラウザ → バックエンドAPI

フォームなどのPOST処理は普通にブラウザからPOST fetchを実行してリクエストを行なっていた。

---

## Next.js Pages Router時代のGET
①ブラウザ(useEffect内でのfetch、より簡潔にしたuseSWRなど) → バックエンドAPI
②ブラウザ → Next.jsサーバー(各SSRページごと) → バックエンドAPI

素のReact時代と変わらず、①のように、ブラウザ上でuseEffect内でGET fetchリクエストをしてデータを取得し、useStateに入れるというパターン。useSWRのようなライブラリによって、明示的にuseEffect・useStateを書かずとも、そこらへんをうまい具合に抽象化してデータ取得リクエストを扱えるようにしたものが流行り、キーによるGETリクエストのキャッシュ等も相まって、各コンポーネントが自身に必要なデータを取得(勿論クライアントサイド(≒ブラウザ)から実行)するようになっていった。

また、②のように、SSR画面では初回リクエスト時に、Next.jsサーバー上で、データ取得リクエストをバックエンドAPIに向けてリクエストし、その後、HTMLを組み立ててレスポンスするようなこともできるようになった。

## Next.js Pages Router時代のPOST
①ブラウザ → バックエンドAPI（ブラウザからPOST fetchを実行してリクエスト）
②ブラウザ → Next.jsサーバー(API route) → バックエンドAPI

①か②のいずれかの方法が使えた。②は自前でAPI routeを定義しないといけないので少し面倒だし、バックエンドをAPIの管理と二度手間になる懸念がある(?)

---
## Next.js App Router時代のGET（サーバーコンポーネント時代のGET）
ブラウザ → Next.jsサーバー(各Server Componentsごと) → バックエンドAPI

Next.jsサーバー上で動く、サーバーコンポーネント上で、バックエンドをAPIを叩いてデータを取得するようになった。つまり、ブラウザから直接バックエンドAPIを叩いてデータ取得をするようなこと（これまでのuseEffect内でのfetch実行や、useSWRなど(これも結局はuseEffect内でのfetch実行だが)）がなくなった。（※ただこれ完全にブラウザからデータ取得のfetch実行をすることがなくなったのかどうなのかはわからないので、調べてみてもいい。例えば、キャッシュさせたくない画面の動的データとかは未だにブラウザからfetchリクエストをすることもあるんじゃないかと思う。CDNキャッシュさせたいときに、サーバーコンポーネントで動的データを取ってしまうと、そのデータでキャッシュしてしまうので問題そう、など）

## Next.js App Router時代のPOST（≒Server Actions時代のPOST）
ブラウザ → Next.jsサーバー(Server Actions) → バックエンドAPI

Next.jsサーバー上でビルド時に(?)定義されるServer Actionsを用いて、バックエンドAPIへのPOSTリクエストなどを飛ばすようになる。これまでは、Next.jsのapi route機能で自前定義すれば同様のことは可能だったが、それを自前でより意識せずにサーバー側で実行するPOSTリクエスト等を定義しやすくなったということだと思う。

※サーバーコンポーネントも、Server Actionsも、大本はReact自体の機能だったはず。

ハイドレーションについての疑問。
従来SSRの初回HTMLが返ってくるのと同タイミングでハイドレーション用のJSコード（イベントハンドラのアタッチとかuseStateの実行とか？）を返しているのか？

kou

[TITLE] RSC（React Server Components）について学び中

Zennのトレンドにあった以下の記事を読んで、SCというものに少し興味が湧いたので色々な記事を読んでいる。

前から存在は知っていたが、今更ながらuhyoさんのこの記事も読んだ。

RSCが多段階計算であると主張する前提として、PHPでのテンプレートエンジンが多段階計算の例として出てきていたが、とても分かりやすかった。
PHP（恐らくRubyなどでも）では、多段階計算の過程で、PHP→HTMLやJSのようにプログラミング言語を跨ぐ必要があったのを、現在のReactでは、JS(バックエンド上で処理されるJavaScript) → JS(クライアントサイドで処理されるJavaScript)という、言語を跨がずに多段階計算が行なうことができるというのが、これまでと異なる部分になっているとのこと。しかも、実装者はそのことをバックエンドで処理される・クライアントサイドで処理されるということをそこまで意識せずに同じような記法で実装を進めることができるというのも、メンタルモデルが統一されていて良い。

バックエンド側のJS → クライアント側のJSという多段階計算過程において、バックエンド側のJSはPHPのテンプレートエンジンがHTMLを生成して返すことができていたように、バックエンド側のJSでHTMLを生成して返すことができる（サーバーサイドレンダリング(=Next.jsのgetServerSidePropsなどの画面単位のSSRといった話ではなく、サーバーコンポーネントなども含めた広義でのサーバーサイドレンダリング)）。
クライアントサイド側のJSでは、今までのReact同様、JSのDOM APIを用いたHTMLの更新（厳密な意味ではHTMLの更新というより、それをもとにしてできたDOM要素の更新が正しいか）を行なう。

さらに今更、danさんの有名記事に目を通してみた。

The story doesn’t end here. When the data for the comments is ready on the server, React will send additional HTML into the same stream, as well as a minimal inline <script> tag to put that HTML in the “right place”

物語はここで終わらない。コメントのデータがサーバーで準備できたら、Reactは追加のHTMLを同じストリームに送信し、そのHTMLを「適切な場所」に置くための最小限のインライン<script>タグも送信する

同じストリーム内に追加でJSを配信して、あとからDOMを動的に書き換えるの面白いな。このHTTPのストリーム自体の仕組みってどうなってるんだろうね。

最近getServerSidePropsが何者であるか、どういうときに呼び出されるものなのか（初回のPages Router時代のSSRでの初回のHTMLロード時や、router.push時など）を理解したけれど、RSC時代に置いて、画面単位での分かりやすいgetServerSidePropsのようなものがなくなった世界において、どうやってrouter.push時などにgSSP相当のものを動かしているのだろう？

router.push時には/hogeのような"画面"に対しての遷移を行なうと思うけど、サーバーコンポーネントの時代においては、そのときのデータ取得は"画面単位で取得する"のではなくて、"サーバーコンポーネント単位でNext.jsサーバー上からAPIサーバーに向けてデータを取得する"ってことなのかもしれない。

kou

[TITLE] 相談・質問の仕方

相談した際にどういった回答が返ってくるかを想定する。回答する側に選択の余地・検討の余地がない相談になっていないか事前に確認。相談の質を上げる。相談の質が低いと、相談を受ける側が頭を働かせて、背景を汲み取ったり、没にした選択肢を拾い上げたりと、その相談全体の質が相談を受ける側に依存してしまう。なので相談を持っていく時点で質を高める工夫をしよう

kou

[TITLE] デザインをする前の実装/実現しようとしている機能の目的の明確化

この共通認識がない時点でデザインの議論をしても個人の主観の戦いになってしまう。デザインを組む際は、デザインを組む前にまずはこの機能を通してどういった目的を果たしたい・実現したいのかを明確にすること(事前に仮説を立ててからPdM等に持っていって確認するとより良い)。実際のデータなどがあれば、実際のデータをもとに自分なりに目的を考えてみる

kou

[TITLE] 改めて、SPAを理解し直す

MPA
MPAは、Webサーバー(?)の/page-Aにリクエストをしたら/page-Aに対応したHTMLが返される。/page-Bにリクエストをしたら/page-Bに対応したHTMLが返される。

◎ 一番原始的
WebサーバーにHTMLが置いてあり、ブラウザからリクエストされたパスに応じてそのHTMLを返す。

# ( ... ) はクライアントサイド（HTTPリクエストを通してサーバーサイドにリクエストする(ネットワークをまたぐ)）
# [ ... ] はサーバーサイド（全て同一サーバーで動いているものを想定）
(ブラウザ) ⇔ [ Webサーバー ]

◎ 動的処理を行なった上でHTMLを返す（テンプレートエンジン的なやつ）
WebサーバーからHTMLが返されるが、HTMLを組み立てる部分でPHPなどが動き、動的にデータを埋め込んだ上でHTMLを作り、それを返す。

# ( ... ) はクライアントサイド / [ ... ] はサーバーサイド
(ブラウザ) ⇔ [ Webサーバー ⇔ アプリケーションサーバー(PHPなど) ⇔ DBサーバー ]

SPA
SPAは、初回リクエスト時のみHTMLを返す。それ以降はそのHTML上(※正確にはDOM上)で、DOMを書き換えることで画面の構築を行なう。

TODO:
SPAの図書く。
HTMLは初回のリクエストで返ってきたあと、すぐにDOMになって、以降はHTMLは使わないという認識で合っているかChatGPTに聞く。HTMLは一番最初の土台であって、以降はDOM（JavaScript）での操作になる？

kou

[TITLE] Laravel × 非同期処理

何かしらの処理後、一定時間経った後に任意の処理を実行したいみたいなケース。

LaravelのQueueを使い、Jobクラスを作成して、Job::dispatch()でQueueに積み任意の処理を非同期で処理させる。
- Job::dispatch()->delay()で遅延実行させることが可能。
(もはやLaravel自体ではないが)AWS StepFunctionsで(?)、一時的にLaravelコンテナを立てて、そのLaravelコンテナに対してphp artisan command:xxxでコマンドクラスを実行して任意の処理を非同期で処理させる。

基本的にLaravelのQueue機能でほとんどのことが行えるような気がしているが、AWS StepFunctionsの方を使用したほうがベターなケースとしてはどういう状況があるのか検討してみたいところ。

LaravelのQueueは、普通にやったら1つのQueueで処理されるので、大量のJobを捌く際に、1つずつ順に処理される点がつらいかも（ただこれもQueue自体を並列実行するみたいなことが可能なようなので、やりようはある）。
対して、AWS StepFunctionsパターンでは、各処理(実行したい処理)ごとにコンテナ自体が独立しているので、大量の実行でも他のタスクに影響を受けない点は強いか。ただ料金面は気になる。