Переодически сталкивался с принцепипльной позицией бэкендеров, что тот или иной функционал необходимо реализовывать на frontend. Типа вам же легче. При том что да, по факту многие такие вещи сводятся к серверной части middleware. Из таких кейсов я помню делал и кэширование сгенерированной SSR статики, логику роутинга на сабдомены в зависимости от выбранного города, различные темки с изменением вызова ручек в зависимости от передаваемого контекста на сервер и т.п. (хотя при этом данные то эти и бэк сразу видит, зачем ручки менять, не понятно). А потом уже когда повысили и в меньшей степени следил за конкретными проектами - находил аналогичные фичи, но уже со стороны backend. Спрашивал в таких случаях у лидов, а отчего дескать так, почему не взяли готовую реализацию? И раз за разом получал ответ - backend сказал, что это легче было реализовать на их стороне, за советом и не стали идти.

Это уже потом стали умнее и начали выстраивать некое подобие BFF в виде отдельных модулей, npm либ и реестра функционала, в которой расписали кто за конкретный функционал отвечает. Ушло правда но это года два, но стоило того.

У меня на данный момент "оркестр" из нескольких контейнеров в Docker: База, Бэкенд (АПИ), Фронтенд (многое рендерится при сборке образа контейнера) и NGINX

На данный момент стоит вопрос целесообразности контейнера с NGINX - хочу убрать его и заменить на демона, который будет жить на хосте

Но контейнерная архитектура явно имеет плюсы, т.к. полгода назад, когда была обнаружена критическая уязвимость React, один хакер получил доступ к контейнеру с фронтом. Благо секретов там не было, ресурсов выделено тоже не особо, поэтому он почти сразу ложил контейнер - я быстро увидел это, т.к. странно, что контейнер фронта, который просто отдаёт странички - стал долбиться в сотку по загрузке

По итогу фронтенд разработчик обновила конфиг Dockerfile на более свежую версию, где критический баг пофиксили разрабы React и сейчас живём спокойно)