Почему приложение не может получить доступ к бэкенду?

Кирилл Вегеле,

в репозитории и в ошибке явно указано, что я указываю имя контейнера, а не localhost, однако это не помогает

Ссылки на другие контейнеры создаются по именам сервисов, проверьте это в /etc/hosts контейнера. "Не помогает" - проверяйте, обратитесь к нужному контейнеру по порту и посмотрите, что вам ответят. Неизвестный адрес - проверяйте ссылки в hosts, не может подключиться к порту - проверяйте запущен ли нужный процесс в контейнере по этому адресу.

Действительно ли это реалии рынка?

Дмитрий,

Поэтому я и говорю, что есть 2 непересекающихся тропы: инженеры, которые со светом в глазах что-то делают, разрабатывают, шлют нахер непробиваемые болота тупых ПМов. Либо манки-кодеры-сеньоры-всю-жизнь-работаю-опыт-300-лет, задача которых сидеть на зарплате побольше, в свободное время находить вторую/третью работу, вайбкодить в Курсоре.

Не, есть теоретики о "прекрасном идеальном мире", непонятые обществом, неспособные договориться с "тупыми ПМ". Те, кто уже в 20 лет достиг "совершенства" и с тех пор не развивается.
А есть инженеры, которые не считают всех тупыми, умеют договариваться, делают отличные вещи, приносят прибыль компании, а значит и себе тоже.
Серьезно, прекращайте воевать с менеджерами, добавьте критичности в отношении себя, и увидите, что "тупые ПМ", зачастую поумнее вас будут. И, превратитесь из жалующегося на мир мечтателя в жизнерадостного разработчика работающего ПО.
А если эти слова для вас пустой звук, тогда скажу так, зачем вы воюете с менеджерами, создайте свою компанию и создавайте в ней "идеальное ПО".

Допустим. Работает сеньор в компании...

Отлично. Вы же заметили, что подтвердили мои слова и опровергли свои?

А то, что отсутствие этого рефакторинга и нормальной архитектуры...

А кто писал про отсутствие "рефакторинга и нормальной архитектуры", "процессы разработки, внедрения, ревью"? В принципе, если вам 25 лет, то этот юношеский максимализм простителен. И это ваше деление мира на черное и белое тоже. Но, все равно не стоит свою неудачную работу проецировать на всех.

Раз непонятно, здесь подробнее про мою фразу универсального и специализированного ПО

Нет чисто универсального или чисто специализированного ПО, можно лишь говорить, что то или иное выполняется в большей или меньшей степени. И хотя в учебниках пишут, что ПО должно быть универсальным, там имеется ввиду базовый уровень. Универсализировать все невозможно. Чем выше универсальность, тем сложнее код и его больше. Итак, у нас есть некий открытый реп, некая среднестатистическая либа, такое ПО характеризуется тем, что неизвестно где и как оно будет применяться, любой может ее подключить. И, некий среднестатистический коммерческий проект, он специализирован, применяется на известных мощностях, известным способом. Уже по этому описанию понятно, что требования к ПО разные, в первом случае нужно учитывать вариативность использования и универсализировать для этого код, во-втором случае нужно учитывать конкретное исопльзование и специализировать код на этом.
Это не значит, что во твором случае будет "кривая" архитектура, нет, но, она будет другая. Скажем внешние ключи в СУБД - это универсальное решение для контроля целостности, но в специализированном вполне могут от него отказаться. Или, в универсальной либе мы подготовим интерфейсы взаимодействия, чтобы пользователь мог поменять как можно больше в работе либы, а в специализированной либе будет только то, что нужно сейчас, если понадобится больше у нас нет проблем поменять либу, это быстро, т.к. она под нашим контролем.
Любой сеньор знает это и умеет писать разный код в зависимости от ситуации. Любой мидл знает это и старается следовать. Любой джун считает, что есть идеальный код на все случаи жизни, и стремится к нему. Он вам и Мартина процитирует, забыв что есть и другие, да и своей головой тоже неплохо думать.

Почему приложение не может получить доступ к бэкенду?

Кирилл Вегеле,

Next.js собирает данные с апи и генерирует статические параметры для серверного рендеринга, так что извращением больше звучит отправлять на клиентскую часть гигантский js файл.

Ну причем здесь "гигантский js файл"? Вопрос не в том, что он делает, а как и когда. И да, обращаться к api приложения, во время сборки этого самого приложения, это как минимум очень странно.

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

по localhost:4200/api все корректно отображается

а это на хосте? Значит запустите в контейнере так же как на хостовой машине, т.е. в контейнере как и на хосте должно чтото отвечать на 4200 порту. Что это должно быть - не скажу, это лучше уточнять по bun.

Почему приложение не может получить доступ к бэкенду?

Кирилл Вегеле, ну так поменяйте url

и что вы пытаетесь отключить, статическую генерацию параметров?

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

Почему приложение не может получить доступ к бэкенду?

Кирилл Вегеле, ну вот, в ошибке ж написано, что он не смог корректно сделать bun run build, потому как во время сборки идет обращение к backend-test:4200/api, а по этому адресу ничего нет.
В общем, вопрос к bun, поищите как это можно обойти.
Забавно, чуть погуглил, пишут, что опции для отключения нет. Нахрена это в сборке большой вопрос, в npm такого не видел.

Почему приложение не может получить доступ к бэкенду?

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

Действительно ли это реалии рынка?

если человек к 20-22 годам (грубо, к окончанию универа) не стал по скиллам сеньором или хотя бы очень крепким мидлом с горящими глазами, то это просто маркер того, что человеку вообще насрать на то, чем он занимается,

Либо этот человек адекватно оценивает свои возможности. Ктонибудь видел сеньора 20 летнего, я нет, и думаю никогда не увижу.
Сеньор и мидл это опыт. Заявление, что опыт не нужен, или что опыт петпроектов релевантный опыт, это как минимум забавно. Мало того, если тебя называют сеньором в компании разрабатывающей сайты визитки, то вряд ли будешь таковым в компании с крупными проектами. Опять же, потому что нужен другой опыт.

Действительно ли это реалии рынка?

Дмитрий,

Не выходя из дома можно получить опыт в топовых командах известных открытых проектов

Можно. Но это совсем не то, что вы в начале написали

в своих хобби-проектах

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

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

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

Если они "плавают" больше тебя следует обратить внимание на другие компании. Учиться нужно у тех, кто знает больше тебя.

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

Действительно ли это реалии рынка?

Действительно ли теперь рынок в руках умелых врунов, а не умелых инженеров?

Кто ни дня не работал, тот вряд ли "умелый инженер"

Стоит ли вообще дальше развиваться в этом направлении?

Смотря какая цель.

... я что-то делаю не так?
Каковы вообще прогнозы рынка разработки?

В России СМИ пишут, что скоро будут более востребованы токари и слесари.
В мире вряд ли чтото изменится. О том, что не нужно столько разработчиков пишут уже десятки лет в перерывах между этим пишут, что компании не могут найти разработчиков.
Вообще, найти первую работу без опыта всегда сложно в любой профессии. Порой и с опытом не всегда просто бывает. Чему тут удивляться? Тратить деньги и время на обучение стажера мало кто готов.
Сколько по времени ищите?

Как понять почему не работает событие по интервалу (MariaDB)?

Посмотрите в information_schema.events

Нормально ли дублирование строк в IN?

alexalexes,

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

для 11 значений временная таблица не будет более быстрым решением. Сам запрос наверное, но будут же еще и расходы на создание таблицы, наполнение ее данными, удаление таблицы. А т.к. это все разными запросами, то плюс сетевой лаг. Не говоря уже о том, что вместо одного понятного запроса у нас целая вереница, что когда завтра подключим СУБД как slave, свято веря, что мы только читаем, упадем на этом запросе.
В общем, я бы не стал играть с временными таблицами без прям хороших показаний для этого. А выбрать 11 значений очень слабый аргумент для этого.

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

djton1k, ну так nuc это ж и есть минипк, тогда о чем комментарий выше?

А потом придет счет за электричество плюс косарь

Почему не видно свойства?

MikMik,

Дело было действительно в разных процессах. Как только воркеры запускаются они становятся независимыми процессами и не имеют ни какого отношения к классу который их запустил, все переменные которые работают в одном воркере недоступны в другом.

Ну какие разные процессы? Здесь у нас просто 3 объекта со своими параметрами и не более того. Другое дело, как написал в ответе, нужно учитывать порядок выполнения анонимных функций.

Почему PHP считает int числа после математических операций как float?

Виктор Кожухарь, Понятно, что все в голове не удержишь, но типы это базис языка, в том числе их неявные преобразования. И, явное указание типов здесь никак не поможет. К примеру, в коде всем числам указали тип int (как у автора вопроса, потому что ему нужно целое число, а про другое он не читал), и вроде все работает, до дня Х, когда случится переполнение и следовательно конвертация в float и все ляжет. А точно нужно было так? Возможно float тоже вполне себе подошел бы? Но даже если нет, тогда нам бы следовало сделать проверку и выбросить нормальный эксепшн о превышении лимита для какой-то сущности, а не фатал: "не пихается float в int". Т.е. помощи здесь от явного указания типов 0. А вред от неизучения типов и их преобразований огромный.
Конечно польза от явных типов примитивов есть, но в отличии от языков со статической типизацией, это не более чем тупая проверка диапазона в надежде, что ошибка из него выбивается. Т.е. по-сути бизнесовая проверка, а не работа с памятью. Например, есть у нас id, целочисленный, мы обложились типом int и как бы норм, только вот id - это у нас все положительные целые числа, а int - это знаковые целые числа, обычно в диапазоне 64-бит. Диапазоны не совпадают, нужны еще проверки, но даже после них ничего не помешает пройти какому-нибудь абсолютно левому числу. И тут, гораздо эффективнее подключать типы ООП.

зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности.

Ну вот причем здесь Rust? Или выделение/освобождение памяти? Когда вы последний раз сталкивались с этой "главной проблемой современности" в php? Или вообще выделяли или освобождали память в php? Правильно, никогда, потому как у программиста там нет таких инструментов, совсем, все делается за него. И, каким боком такой сложный вопрос как выделение/освобождение памяти связан с проверками типа в php, т.е. с тупо сравнением? Это там, где типы проверяются на этапе компиляции, хотя бы тупо чтобы не прочитать как число данные, записанные как строка, там сложная работа с типами, в php где все данные маркированы типом это не нужно.

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

Как написал выше не такая логика, и вообще ничего общего. Поэтому вопрос, что за "такие баги"?

Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.

Я хрен знает что такое "мир JavaScript", я так понимаю это мир из 2х языков: js и ts? Ну тогда чему удивляться, любой адекватный язык всяк лучше js. И да, обязательное явное указание типов примитивов в ts наверное правильное решение, т.к. основная аудитория это те, кто писал на js. Даже на этом форуме кто приходит с php-шным global закидывают какашками, а времена register_global вспоминают с ужасом. Но в сторону js, с его областью видимости луковицы и прототипами никто плохого не скажет, просто у ребят альтернативный взгляд. Настолько альтернативный, что не смотря на монополию в браузерах пришлось костылями ваять ts, чтобы как то совсем не потонуть.

Почему PHP считает int числа после математических операций как float?

Помоему контроль типов в PHP вполне себе годный. Все нужное есть, а то что "явно типизировать обычную переменную не получится" - да, но оно и не нужно. Вообще, для контроля бизнесовых данных контроль примитивных типов помогает слабо, а хорошо решают проблему типы в ООП и там все что нужно есть. Поэтому для безопасности лучше использовать именно ООП. Но даже на уровне примитивов контроль есть - на уровне входа/выхода из функций, а указание типа отдельной переменной это ненужное.

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

Неявные преобразования в языке, хоть с динамической, хоть со статической типизацией, это часть движка. А вот "строгая типизация", вернее явное указание типов переменных это опциональный инструмент в php. Поэтому первое нужно знать обязательно, к том же это прекрасный инструмент. А расчет что "строгая типизация" спасет - очень опасный путь.
Изучая типы используемые в языке, всегда изучаешь неявные преобразования, иначе невозможно. Например, мы знаем что int в php - это обычно int64, очевидно что возможно переполнение и нужно проверить как компилятор будет на него реагировать. В php реагировать он будет всегда одинаково - преобразует в float. И только потом, при записи в переменную может проверить ее тип.
Причем не обязательно знать все и вся, абсолютно неважно в какое конкретное значение string преобразовывается array (если такую хрень не использовать), но важно помнить, что получится строка, и без всяких ошибок.
Не говоря уже о том, что ошибки компиляции и runtime это совсем разные вещи в плане отладки.

Почему PHP считает int числа после математических операций как float?

Дмитрий, извиняюсь, неправильно прочитал, почемуто подумал, что там деление 2х int-ов. А для float - да, проще каст.

Почему PHP считает int числа после математических операций как float?

Дмитрий, очевидно имелось ввиду intdiv

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

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

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Ziptar, ну там много что не съемное, не заменяемое. И это логично. Но, с бп какаято проблема? Именно они выходят из строя чаще всего? Внутренние 12 вольтовые?

Какой мини ПК посоветуете для домашнего веб сервера для некоммерческих целей?

Ziptar, так там же внешний бп.