Kentavr16

Артефакт сборки надо поместить в /app

Тут не помешает двухстейджевая сборка, чтобы оптимизировать размер образа:

FROM node:18 as static-builder

WORKDIR /app

COPY package*.json ./

RUN npm install --legacy-peer-deps

COPY . .

RUN npm run build

# EXPOSE 3000 - эта директива оставлена для обратной совместимости и ни какие порты не открывает, можно её не использовать

FROM nginx

COPY --from=static-builder /app/publc /usr/shared/nginx/html
# или другой каталог, если артефакт сборки помещается не в /app/publc

Как уже сказали, для чатов самое оптимальное websocket, только тут всплывет что у Django с этим проблема, есть channels, но мне они очень не нравятся, выглядит как переделанный сбоку костыль. Кроме этого, год назад видел попытки реализации websocket на основе текущего async в Django, но за этим не следил, так что не знаю какое там сейчас состояние. Так что лучшее решение, перенести чат на async фреймворки

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

Главное преимущество в том что у тебя инфраструктура на проде и инфраструктура при разработке похожие=> в случае проблем, они будут быстро вскрываться.

А билдить после каждого изменения не нужно - во время разработки можно подсовывать новые файлы через волюм (если ты пишешь на интерпретируемом языке), да и с корректным кэширование сборка происходит очень быстро (если пишешь на компилируемом).

Опять же само окружение можно в докер впихнуть - базы данных, бэкенд, всякие nginx-ы.
Если у тебя при разработке много нужно устанавливать - можно даже само окружение для разработчика контейнеризировать через Devcontainers.

Здравствуйте, почитайте про Module Federation

>Или все же это инструмент в первую очередь для доставки контента?
Докер упрощает процесс доставки контента, но это не едиственный его плюс. Он позволяет быстро создать,воссоздать,повторить аналогичное окружение и зависимости которые необходимы твоему приложению в любом (почти) месте где есть поддержка docker.

> но билдить каждый раз после внесения изменений в код - что я от этого выиграю?
Ты не правильно используеш докер, если есть необходимость пересобирать контейнер при каждом изменении. Докер это окружение в котором работает твое приложение.

> Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?
Повсеместно испольуется. Следующий шаг развития докер это k8s, а это mainstream. Если ты умееш работать с докером, то освоить k8s уже намного проще.

Если сильно упростить то контейнер докер это виртуальная машина на linux внутри которой крутиться одно приложение. В идеологии докера каждое приложение должно быть в отдельном контейнере - mysql,redis,php.

Докер позволяет обойти проблему зависимостей.

Помню когда первый раз столкнулся с docker, это была система анализа логов от ruckus. По своей структуре это был centos на котором было запущено 8-9 контейнеров docker. Таким подходом ruckus как минимум решил для себя проблему установки обновлений, тебе не надо ставить обновления на саму ОС, тебе достаточно обновить контейнер. Если контейнер не запустился, то просто откати его. Все библиотеки и зависимости внутри контейнеров. Это настолько упростило процесс разработки и доставки обновлений, что сложно и представить.

Дошел до изучения докера, так как это мастхэв веб-разработчика судя по статьям/требованиям работодателей.

Нет.Это полезно знать, но далеко не всегда стоит применять.

Как с этим дела в реальной жизни, на реальном среднестатистическом проекте?

Среднестатистическому проекту контейнеризация вообще не нужна. И даже там, где нужна, зачастую с ней имеют дело админы, а не разработчики.

В разработке докер нужен только тогда, когда вы ведёте множество проектов, которые требуют разных окружений и не поддерживают собственных средств виртуализации. Например разработка чего-то системного на C.
В развёртывании докер нужен тогда, когда у вас сотни динамически разворачиваемых серверов. Если у вас одна VPS'ка, то докер - это оверкилл.

Смысл в том, что все пакеты, зависимости итд можно упаковать в 1 контейнер, который с помощью 1 yml файла потом можно поднять фактически где угодно ( на любом линукс) с вероятностью в 99%

В случае же стандартной установки пакетов и зависимостей - их потом придется ставить на прод, что может создавать сложности, если там работает множество сервисов...

Ну банально упрощает развертывание. Но обычно этим занимаются девопсы конечно, а не прогеры... Но проблема в том, что только прогеры знают, какие зависимости и каких версий должны стоять, так что эти вопросы придется решать)

Если ты собрал и у тебя работает на локальной машине - не факт что заведётся на тесте/стейдже/проде.
Если ты собрал и у тебя работает в контейнере - оно вероятно будет работать везде и с одной команды.

но билдить каждый раз после внесения изменений в код

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

Лучше вот это изучить.

Есть — примерно все остальные хостинги на свете.

https://developer.mozilla.org/.../box-decoration-break

.tobuy-shance__title_accent {
  box-decoration-break: clone;
  -webkit-box-decoration-break: clone;
}

Поддержка в целом неплохая, но с префиксом. https://caniuse.com/css-boxdecorationbreak

Это разные вещи. Аякас - изначально концепция, но на деле под ним обычно понимают стандартный хтпп запрос на сервер. Веб сокеты - это асинхронный протокол для передачи данных поверх TCP. Голые сокеты не очень удобно применять в вебе, а у хттп свои ограничения - вот и сделали хороший и удобный стандарт. А реактивность - по сути просто обновление интерфейса при поступлении обновленных данных.