Gennady S

Теоретически возможно, но это будет страшное колдунство. Нужно будет развернуть внутри контейнера X-сервер, предоставив ему доступ к оборудованию хоста, а затем подключиться к нему через VNC, например. Что осложняется наличием Windows-хоста, где запуск графических приложений в WLS2 может оказаться нетривиальной задачей. Готового рецепта Вам никто не даст, его не существует, хотя можно найти гайды по запуску графических приложений в Docker вообще, что не факт — подойдет ли решение Вам.

Рационально найти другое решение. Не совсем понятно, причем тут веб-версия, если речь о файловой базе данных? Браузер может с ней работать? А если возможно использовать клиент, который подключается к серверу, зачем клиент помещать внутрь контейнера, если там можно расположить только сервер? Плюс, непонятно, что за изоляцию пытаетесь решить, тем более если речь о файловой базе. Контейнеры — неподходящий вариант для хранения файлов. Наоборот, есть смысл создавать тома, вынесенные за пределы контейнера, даже для серверных баз. А если том вынесен из контейнера, что изолирует контейнер?

Эта задача не имеет адекватного решения. Docker для Windows имеет особую реализацию, собственную сеть, и режим хоста означает, что приложение будет работать не в сети WSL2 / Windows, а в сети самого Docker. Тогда как открытие портов создает туннели для сетей WSL2 и Windows. Единственный способ заставить это работать, это каждый раз при запуске контейнеров вручную делать туннель, что едва ли просто сделать, поскольку, опять-таки, согласно документации "This interface is actually within the virtual machine".

Можно предположить, что пользуетесь маршрутизатором, раз речь о переходе на другую страницу. Состояние компонентов при переходе сбрасывается, т.е. все вложенные в router-outlet компоненты инициализируются заново. Было бы сложнее и хуже, будь иначе. У Вас два пути. Во-первых, сохранить состояние компонента тем или иным образом. Во-вторых, пересмотреть подход к архитектуре приложения.

Вы можете отправить данные вверх, в родительский компонент, использовать глобальное хранилище, сервис или дать возможность пользователю сохранить данные на сервер. Что логично, когда страница отвечает за свой набор данных и при переходе на другую страницу речь идет о другом наборе данных. Если у Вас ряд страниц отвечают за связанные данные, можно исключить переход между страницами, сделать вкладки-табуляцию, например.

По моему опыту, усложнять не стоит. Постарайтесь сделать так, чтобы страница отвечала за набор данных и при переходе состояние сохранялось как состояние страницы, т.е., чтобы при нажатии F5 данные были восстановлены (и утеряны, если пользователь их не сохранил). Воспринимайте состояние страницы как такое состояние, которое должно быть возобновлено после закрытия браузера / приложения. Если несколько разделов отвечают за связанный набор данных, то данные должны храниться в родительском компоненте, а переключение компонент не должно быть переходом между страницами.

Вы собираете решение на основе некого полу-любительского Docker-образа. По ссылке на github видно, что автор(ы) репозитория страдает некой манией велосипедных дел, и создал свои контейнеры на все про всё, и при этом давно их не обновляет. Если хотите решение на базе Docker, то стоит быть готовым к тому, что такое решение нужно сопровождать, т.к. сторонние нестабильны. Поэтому желательно разобраться в базовых образах nginx / php / базы данных, чтобы завести это все вручную и самостоятельно, с уверенным пониманием процесса. В официальных хабах есть все необходимые инструкции: как устанавливать пакеты, как задать стартовые настройки через окружение или шаблонные значения. Это займет время, конечно, день-два, но окупится как в данном проекте, так и в дальнейшем. Эти контейнеры систематически обновляются и имеют лучшую совместимость, в противоположность случаю, когда что-то отваливается у авторов 10+ контейнеров, неспособных их сопровождать (в чем проблема и сейчас: не хватает расширения, автор не предусмотрел / забросил, подложив проблему своим пользователям). В Вашей ситуации нужно также ознакомиться со списком требований Drupal, и развернуть требуемый Dockerfile для PHP (через Alpine и встроенную систему установки расширений или Debian / ppa)

Полагаю, библиотека JSDOM не меняет исходный файл. Вам нужно получить HTML после изменения элемента и передать этот HTML как ответ. Например,

function getCards() {
  // ... некий код
  return dom.window.document.innerHTML;
}
// в обработчике маршрута:
  const html = getCards();
  res.send(html);

<?php
$string = 'Нажми кнопку и получи @приз, чтобы принять участие';
$matches = [];
if (preg_match('/@[а-я]+/ui', $string, $matches)) {
  $word = $matches[0];
  echo $word, PHP_EOL;
}

Это почему сеттеры нарушают инкапсуляцию? Вовсе нет. Контроль сохраняется за внутренней логикой класса. И в отношении конструкторов, получается, странным образом интерпретируете инкапсуляцию. Логика ООП практически потеряет смысл, если нельзя будет настраивать поведение объектов. Каким образом с чем-либо взаимодействовать, если нет значений, которые можно передать объекту?

Самая банальная проблема, которую решает инкапсуляция, это нарушение работы объекта и непредсказуемость последствий при прямом обращении к свойствам объекта. Например, у нас есть класс, реализующий работу с файлом, и одним из его свойств является дескриптор открытого файла. Если открыть файл, а затем обнулить или заменить дескриптор, то объект потеряет контроль над открытым ранее файлом. Понятно, что это свойство должно быть целиком закрыто и лишено внешнего доступа. Но объект может инициализироваться с путем файла, и путь к файлу может быть так же сеттером, и при изменении пути файла пользователем можно корректно среагировать, от исключения до закрытия ранее открытого файла. Это двоякое свойство, которое логично сохранить, скажем, только для конструктора — объекту необходимо установить это свойство, и объект прямо ассоциируется с путем, ему переданным, цикл жизни будет связан с конкретным файлом. Могут быть и иные опции, например, размер буфера, который можно позволить менять в реальном времени, перенастраивая некоторые параметры работы с файлом в логике сеттера и т.д..

То есть, смысл инкапсуляции — это возможность реализации конкретной логики с распределением закрытости свойств. В одних случаях уместно закрыть доступ целиком, чтобы не нарушать базовое поведение объекта, когда разумно оставить установку значений только через конструктор, скажем, если цикл жизни объекта это некий конечный процесс, и может быть уместно запретить изменение этого поведения для дочерних классов, в других — допустимо менять свойства динамически, сеттерами, но оставляя обработку изменения за логикой класса.

Судя по Вашему JSON, полученному от сервиса, Вам не нужны два цикла foreach, второй — лишний, его можно просто удалить.