nowm

У дискорда есть такая фишка, что на interaction нужно ответить в течение 3-х секунд. Если не успели, он начинает выдавать такую ошибку. Есть несколько вариантов:

1. Сразу после того, как был получен interaction, нужно вызвать interaction.deferReply. Вызов deferReply даёт возможность продлить срок ответа до 15 минут. Дальше как обычно — делаете pool.query и потом interaction.reply
   

   await interaction.deferReply();
   // После вызова кода выше, дискорд даёт ещё 15 минут 
   // на то, чтобы отправить ответ.
   
   // [Тут какой-то ваш код, который долго работает]
   
   await interaction.reply('Информация о сервере: бла-блабла');

   
   
   
2. Можно использовать механизм Follow-ups. В таком случае вы сразу что-нибудь отвечаете с помощью interaction.reply, потом делаете pool.query и потом добавляете ещё текст с помощью interaction.followUp:
   

   await interaction.reply('Ща, погодь, нужно в БД посмотреть...');
   // После вызова кода выше, дискорд даёт ещё 15 минут 
   // на то, чтобы отправить follow up.
   
   // [Тут какой-то ваш код, который долго работает]
   
   await interaction.followUp('Вот, нашёл: Информация о сервере: бла-блабла');
   // Код выше добавляет к ответу текст "Вот, нашёл: Информация о сервере: бла-блабла" 
   // (фраза «Ща, погодь» никуда не пропадает)

   
   
   
3. Можно точно так же сразу ответить, но вместо interaction.followUp вызывать interaction.editReply. В этом случае даётся тоже 15 минут на то, чтобы вызвать editReply.
   

   await interaction.reply('Подождите...');
   // После вызова кода выше, дискорд даёт ещё 15 минут 
   // на то, чтобы отредактировать это сообщение
   
   // [Тут какой-то ваш код, который долго работает]
   
   await interaction.editReply('Информация о сервере: бла-блабла');
   // Код выше заменяет "Подождите.." на "Информация о сервере: бла-блабла"

   
   
   

Команда node — это интерпретатор. Сам NodeJS — это не сервер, а среда исполнения, которая, в числе прочего, даёт возможность писать на JS web-серверы, используя встроенные модули NodeJS. Для того, чтобы сделать web-сервер, нужно написать такой файл test.js, в котором будет запускаться сервер с определёнными параметрами и определённым портом. Затем этот сервер запускается командой node test.js. Если вы будете напрямую открывать файл test.js из браузера, это не сработает так, как вы хотите, так что да — он вообще не должен быть в public_html.

Пример test.js.

// Импортируется встроенный в NodeJS модуль http,
// который даёт возможность создать web-сервер
const http = require('http');

/**
 * Когда делается запрос к этому серверу, вызывается эта функция
 *
 * @param {module:http.IncomingMessage} request
 * @param {module:http.ServerResponse} response
 */
function requestProcessor(request, response) {
    switch (request.url) {
        case '/':
            response.end('Запрошена главная страница');
            return;
        case '/500':
            response.statusCode = 500;
            response.end('По просьбам посетителей — ошибка 500');
            return;
    }

    response.end(`Не знаю, как обработать адрес ${request.url}`);
}

// Создаётся сам сервер, в качестве параметра передаётся функция, которая обслуживает запросы
const server = http.createServer(requestProcessor);

// Созданный сервер запускается
server.listen(8888, function() {
    console.log('Сервер запущен на 8888-м порту. Откройте http://localhost:8888/ для проверки');
});

В одном JS-файле можно запустить даже больше одного сервера — это всё управляется кодом на JS, а сам NodeJS только помогает этот код запустить.

Замените - "80:5001" на - "5001:5001" в блоке services.backend, и должно заработать. Так же, нужно удостовериться в коде самого проекта NodeJS, что вы слушаете только порт 5001 и не трогаете порты 80 и 443.

Я обычно пользуюсь DOM в PHP. Конечно, можно отдельные поля регулярными выражениями отловить, если знаешь их название, но есть большая вероятность, что у одного инпута сначала будет идти `type`, потом `name`, а у другого наоборт, и придётся для каждого инпута писать отдельный код, который будет из него вытаскивать значение. Проще воспринимать их как сущности с одинаковыми признаками и переложить парсинг на специализированные билиотеки.

Насколько я понял, судя по особенностям наименования инпутов, это был форум на базе hoop.la (не путать с hoopla). Я бы примерно так организовал парсинг:

$dom = new \DOMDocument();

libxml_use_internal_errors(true);
if (!@$dom->loadHTML('содержимое страницы в виде HTML')) {
    /** @var \LibXMLError $error */
    $error = libxml_get_last_error();
    if ($error->level > LIBXML_ERR_ERROR) {
        throw new \Exception($error->message);
    }
}

$xpath = new \DOMXPath($dom);

/** @var \DOMNodeList $form */
$form = $xpath->query('//form[@name="mainLoginForm"]');
if (!$form->length) {
    throw new \Exception('Форма не найдена');
}

$post_data = [];

/** @var \DOMElement $input */
foreach ($xpath->query('.//input', $form->item(0)) as $input) {
    $post_data[$input->getAttribute('name')] = $input->getAttribute('value');
}

$post_data['email'] = 'логин';
$post_data['password'] = 'пароль';

// В $post_data находятся все данные которые нужно отправлять

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

В каких-то других ситуациях, кроме инпутов нужно будет искать ещё и селекты, или предусматривать ситуации, когда нужно делать выбор из нескольких radio-элементов, либо предусматривать ещё более комплексные ситуации, но конкретно в случае с hoopla этого не потребуется — там одни инпуты, и они динамически с помощью JS вроде бы не модифицируются (сильно не тестировал).

Код может быть нерабочим. Я его наполовину копипастил из собственных разработок, наполовину писал прямо на Тостере. Главное, из него понятен смысл.