Czy jest sens konteneryzować SPA: react/angular/blazor wasm?

Jakie macie techniki jeśli chodzi o deploy stronek SPA typu react/angular/blazor wasm?
Czy konteneryzujecie front-end np. przez docker czy po prostu leci on do jakiegoś przykładowo azure static web apps?

Mój projekt zakłada:

1. front-end w react/angular/blazor wasm - wysyłający zapytania https do api gateway
2. api gateway + 3 web api - wszystko skonteneryzowane przez docker-compose

No i teraz pytanko, czy logicznie jest pchać w ten docker-compose również aplikację front-end skoro jest to po prostu statyczna spakowana stronka.
Czy może drugie podejście lepsze, że front-end zostawiamy bez żadnej konteneryzacji, natomiast api gateway i web api pakujemy w kontener przez docker-compose

To jest bardziej pytanie filozoficzne a nie techniczne. Wszystko zależy od tego jak utrzymujesz i wdrażasz inne moduły aplikacji. Czy aplikacja wymaga skalowania. Jakim hostingiem dysponujesz? Czy potrzebujesz szybko podnieś apke w innej lokalizacji jak zdechnie.

Ja nie konteneryzuje SPA poza środowiskiem deweloperskim czy testowym.

Zwykłe static websites na Azure Storage czy AWS S3 wsparte CDN-ami jak AWS CloudFront czy Azure FrontDoor żeby zapewnić wysoką dostępnośc i szybką dystrybucję w przypadku apek publicznych jest wystarczające. Do tego GH action robiący build apki i kopiujący output na storage i jest git.

Po co marnować zasoby i pieniądze na uruchamianie kontenera z czymś co może być za grosze hostowane na storage’u. No chyba że chcesz odpalać frontend on-demmand na jakąś chwilę i potem wyłączać to jeszcze przejdzie, ale i tak trzeba by policzyć koszty bo Azure Container Instances, AWS AppRunner czy ECS darmowe nie są i płacisz za zużyte zasoby.

A co byś chciał zyskać tym? Przecież to nie jest tak że SPA potrzebuje jakiegoś runtime'u, to w dużej mierze pliki statyczne. Tzn. runtime owszem jest, ale w przeglądarce użytkownika.

Zależy na jakie podejście chcesz się zdecydować. W projektach, którymi się opiekuje mamy parę podejść:

1. Lokalny build (przez npm) i wrzucenie na serwer klienta
2. Lokalny build dockera i wrzucenie na AWS
3. Build i wrzucenie na kubernetesa(Azure) z poziomu CI/DI

W innym projekcie jeszcze mamy lokalny build (npm) i wrzucenie ręczne na Azure

Wszystko zależy od okoliczności, osobiście wolę wersję 3, gdyż jest najmniej roboty przy deploy, siedzi to w tym samym miejscu co backend i reszta usług.

Według mnie, jeśli

1. już używasz Dockera albo K8s albo innej platformy tego typu
2. jesteś w stanie mieć ten sam proces releasowy dla wszystkich serwisów, czy fronty czy api - czyli dogadałeś się z frontendowcami, używacie tego samego CI/CD, rozumiecie jak działają kontenery
3. nie interesuje cię CDN i zalety z tym związane - czyli np. masz mały ruch, albo większość webapki zaczytuje się raz i potem siedzi w cache przeglądarki

to zdecydowanie tak. Ja tak zawsze robiłem i zawsze była to dobra decyzja. Dyskusje o kosztach można włożyć między bajki, bo pod z nginx-em działa świetnie z limitem 16Mi ramu, o ile nie serwujesz czegoś więcej niż typowe reaktowe śmieci.

Natomiast jeśli:

1. frontendziarze nie ogarniają Dockera, nie ogarniają wersjonowania, nie chcą się nauczyć totalnych podstaw nginx-a, a releasy zawsze robili Filezillą albo scp z mastera
2. mają inne CI/CD, inne procesy ogółem
3. ogólnie nie znajdujecie wspólnego języka

to zdecydowanie nie i tylko się napocisz - wtedy pozwól im mieć swoje metody wdrożeniowe i tylko połączenie między zabawkami zróbcie na poziomie jakiejś wspólnej, minimalnej konfiguracji.