Ну т.е. это ок и уже практикуется в тырпрайзах и

в целом? Просто фронт это же считай в упор к пользователю, стоит ли его за еще одной абстракцией в виде куба ставить? Не быстрей все это работать будет "напрямую"?

Уже хз сколько лет практикуется

Это ты нам ответь, с чего ему быть быстрее

С чему ему быть быстрей без кубера?

что ты называешь "фронтом"? набор js-файлов которые отдает s3? Ну так конечно не нужен кубер в этой ситуации.

ага

Да

Да я как-то вообще во фронте не разбираюсь, ну вот этот вот набор файлов там, hello.html, js файлы и прочее, там же вроде какой-то node.js нужен для его работы и прочее, одним s3 не отделаешься, не?

Возможно пора разобраться

вангану, что речь может идти о геораспределенных cdn-ах с доступом к фронту с ближайшего от клиента сервера

не удивлюсь что в cdn-aх тоже кубы под капотом, кек

Да, использование Docker и Kubernetes для фронтэнда практикуется в больших компаниях и "enterprise" решениях. Основные причины этого выбора связаны с унификацией инфраструктуры, управлением версиями, безопасностью и масштабируемостью. Однако, у вас абсолютно верное замечание по поводу дополнительной абстракции. Давайте рассмотрим этот момент подробнее: Производительность: Контейнеры добавляют небольшую задержку по сравнению с "напрямую" развернутыми приложениями. Однако, для большинства веб-приложений эта задержка минимальна и несущественна. Главное влияние на производительность фронтэнда оказывает скорость загрузки ресурсов, оптимизация изображений, JS и CSS, а также время отклика бэкенда. Сложность: Kubernetes добавляет сложности в управление и мониторинг. Если у вас нет опыта с Kubernetes, может потребоваться время для освоения. Масштабирование: Если ваше приложение имеет высокую нагрузку и требуется масштабирование, Kubernetes может предоставить инструменты для быстрого масштабирования и балансировки нагрузки. Близость к пользователю: Если вы используете CDN (сеть доставки контента), то физическое расположение вашего фронтэнда становится менее критичным. CDN кэширует контент ближе к конечному пользователю, ускоряя загрузку страницы. В заключение: использование Docker и Kubernetes для фронтэнда имеет смысл в определенных контекстах, особенно когда требуется масштабирование, унификация инфраструктуры или управление версиями. Однако, для многих проектов, особенно маленьких или средних, это может быть избыточно. Всегда стоит взвесить "за" и "против" на основе конкретных требований вашего проекта.

надо же на чем-то написать программу запаковывающую js в файлы. Вот и node. Но на node технически и бек могут сделать.

они разные бывают часто это дейсвтительно просто набор статики, который можно на cdn положить но по последним веяниям, в моде снова SSR и фронт может быть вполне самостоятельным приложением (привет, next js)

Типа чем больше статики, тем лучше на CDN? А если там мудренное что-то, то уже кубы? Или это не совсем правильный вывод?

все что может быть кешировано - все на cdn, все что нет - нет. и эти варики комбинируют, картинки и шрифты на cdn, мб стили, остальное в ssr

node.js нужен в случае server side rendering. Без него это просто набор файлов, который можно отдавать с CDN

это совсем неправильный вывод

> в моде снова SSR вот только непонятно зачем.

что уменьшить время загружки всех свестоперделок которые собираются из js обычно, в общем сделали виток, раньше с сайта тянулось html, потом js, потом js только которые все в браузере собирал, потом добавили web sockets, теперь рендерят html и скрипты на сервере и отдают пользаку. а остальное опять подтягивают js через web socket

это и в рамках cdn решить можно, если дело только в загрузке. SSR нужен для динамического контента, который в CDN не положишь