Согласен с автором. GraphQL актуален для задач, когда есть очень «толстое» api с сотнями полей в запросе, и клиенту нужна небольшая их часть. Но это редкий кейс, как правило больших компаний, аля Facebook.
В остальных случаях не очень понятно, какие есть от него плюсы, когда есть кодогенерация REST клиента с типами на основе OpenAPI схемы, которая тоже генерится на основе сервера, а так же есть OpenAPI Editor для ручных запросов.
100 из 100. Во многом из-за переусложнения как с технической части, так и с бизнесовой, проекты превращаются в макаранного монстра, где "идеальная архитектура" и за неделю не дает простую фичу добавить, а кол-во непонятно кем используемого функционала продукта тормозит дальнейшее развитие...
Да, пробовал ts-sql-query. Его несомненный плюс это поддержка больше кол-во типов БД, но как вы отметили kysely с типизацией через строки лаконичнее и прям очень похож на sql. А ts-sql-query при использовании выглядел очень многословно, как в плане запросов, так и в плане создании типов. Плюс когда запрос содержит кучу подобных методов notEqualsIfValue , greaterOrEqualsIfValue тяжело читать, но это уже дело вкуса.
Это и правда верно. Но вот проблему c тем, что везде, где подключается папка придется дописать /index, судя по всему не решается. И с ts-node и tsx как-то это все-равно не дружит из коробки.
На самом деле, не уверен, что остались ещё случаи, где это не приемлемо. Сможете привести пример?
TypeScript не может использовать директиву imports в package.jsonc настройкой "module": "commonjs". Получается итоговая сборка должна запускаться в Nodejs использующей esm модули, это далеко не всегда приемлемо. В результате, если хочешь использовать в итоговой сборке commonjs, то надо использовать сборщик, который сделает трансляцию... Это как-то слишком жирно для бэкенд кода.
А с path aliases делаешь просто замену регуляркой в коде /[\.\.\/]+model\/User => @model/User
Тут не совсем все просто. Нативные alias работают только с ESM модулями
Например:
// Не будет работать
const { ProductView } = require('#entities/product/components/ProductView');
const { addProductToCart } = require('#features/add-to-cart/actions');
// Необходимо прописать полный путь
const { ProductView } = require('#entities/product/components/ProductView.js');
const { addProductToCart } = require('#features/add-to-cart/actions/index.js');
Несмотря на то, что алиасы работают как для ES‑модулей, так и для CommonJS модулей, Node.js использует правила поиска модулей, которые применяются для ES‑модулей. Проще говоря, появляются два новых требования:
При импорте необходимо указывать полный путь до файла, включая расширение файла.
При импорте нельзя указывать путь до директории, ожидая импорта файла index.js. Вместо этого необходимо указывать полный путь до файла index.js.
Для легаси проектов получается этот способ не заведется без рефакторинга....
В большинстве случаев лучше спрятать его от внешнего мира, по тем же причинам, что и БД прячут.
Если все-таки надо RabbitMQ сделать доступным снаружи, то необходимо коннектиться через ssl ради безопасности, но это добавит приседаний с сертификатами и их обновлением, а также снизит скорость передачи данных
Если есть еще ноды с ролью manager и кворум может быть разрешен, то новая нода станет ведущей. Swarm использует алгоритм Raft поэтому следует использовать нечетное кол-во managerнод чтобы кворум работал. Да, контейнеры работать останутся, но добавлять и обновлять сервисы в кластере будет нельзя. Да, контейнеры с manager нод так же мигрируют, как и с обычных нод.
Ну, в swarm есть встроенный балансировщик, который прослушивает порты (указанные в сompose файле) на все нодах и пробрасывает трафик, либо в контейнер, который есть на этой ноде, либо на другую доступную в кластере.
При появлении новой ноды в кластере, manager нода автоматически запустит агента portainer на новой ноде. И весь функционал portainer будет доступен для контейнеров на этой ноде. Если логику запуска portainer надо поменять, то правим файл portainer-agent-stack.yml.
Нет, порт 9443 нужен только для веб морды portainer.
Это дас) Вообще хорошие разработчики дорого стоят, но если в NodeJS нет проблем с junior и middle, то в Perl остались только сеньор за которых надо еще конкурировать с Mail, Yandex и другими большими компаниями, где еще осталось много перла. Ну, и физически сеньоров на Perl меньше, чем на Node, многие ушли в Си++, Gо, Python и ту же Node. По крайне мере у нас был такой опыт поиска ...
Да, работает стабильно, технологии уже 13 лет, большинство болячек давно решено. Нет, не течет, если только разработчик не кладет целенаправленно данные в глобальный скоуп и не чистит его, но этого можно добиться в любом демон- процессе.
Участвовал в миграции проекта на Perl с историей в 15 лет на NodeJS/TypeScript. Это был проект одного из крупнейших ВУЗов страны, он состоял из сайта, мобильного приложения и админки.
Причины переписать были следующие:
Перловых разработчиков мало и хорошие стоят прям очень дорого, а джуны не рвутся поднимать скилл в Perl
Типизация TypeScript здорово облегчает работу с большой кодовой базой, а один язык и на бэке, и фронте, чуть облегчает переключение контекста.
Асинхронность в Node js в из коробки. А в perl есть решения типа AnyEvent, но они проигрывают по степени удобства и надежности работы языкам, у которых асинхронность базовая фича
В проект было много устаревших самописных решений от предыдущих команд, которые блокировали увеличение версии perl, но при этом без апгрейда perl невозможно было обновить другие либы, в которых были найдены уязвимости. Поэтому апгредить perl было аналогично переписыванию половины проекта.
Из-за того что мы были прибиты к apache и mod_perl, отсюда вытекали все классические проблемы с обслуживанием большого кол-ва запросов.
Исходя из вышеперечисленного переписать на другой язык, казалось не такой плохой идеи. Плюс мы хотели разбить монолит на 2-3 сервиса поэтому переезжали постепенно. NodeJS убрала проблему избытка потребления памяти, а за счет снижения кол-ва подключений к БД мы даже смогли убрать pgbouncer и кэш виде Redis.
Сложности были связаны в основном с размером системы и то, что портировать все надо было по кусочкам, но при этом не оказаться в ситуации, когда надо и новый код развивать и старый.
Мой первый язык программирования) Там много было интересных подходов, которые перетекли в другие языки. Жаль Perl 6 убил развитие Perl 5, на котором все писали...
По умолчанию, создаются идентификаторы, которые начинаются с цифр, что не подходит (причина описана в статье)
Отсутствует запрет на использование определенных символов в начале идентификатора
Если задать алфавит только из букв new Hashids('', 0, 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'); , то длина идентификатора достигнет 5 символов всего лишь через 39 304 вызовов, что как-то уж совсем мало...
Требовалась генератор, который независимо работает от сборщиков и другого специфичного окружения. Ибо значительная часть генерации html происходила на стороне сервера плюс в рантайме на клиенте, а css отдавался только тот, который нужен для данной страницы и название классов должны были меняться, если обновишь страницу (борьба с блокировщиками рекламы)
Пользуюсь Obsidian Git в связке с приватным репозиторием для того чтобы синхронизировать заметки на Ubuntu и MacOS
Полезная статья, спасибо. В примерах кода есть ошибки (дублирование кода, где пример теста
"broadcasts messages from one client to all others")Согласен с автором. GraphQL актуален для задач, когда есть очень «толстое» api с сотнями полей в запросе, и клиенту нужна небольшая их часть. Но это редкий кейс, как правило больших компаний, аля Facebook.
В остальных случаях не очень понятно, какие есть от него плюсы, когда есть кодогенерация REST клиента с типами на основе OpenAPI схемы, которая тоже генерится на основе сервера, а так же есть OpenAPI Editor для ручных запросов.
Я как правило для этого использую API Prometheus/API Portainer или что-то аналогичное для получения статуса контейнеров
100 из 100. Во многом из-за переусложнения как с технической части, так и с бизнесовой, проекты превращаются в макаранного монстра, где "идеальная архитектура" и за неделю не дает простую фичу добавить, а кол-во непонятно кем используемого функционала продукта тормозит дальнейшее развитие...
Да, пробовал ts-sql-query. Его несомненный плюс это поддержка больше кол-во типов БД, но как вы отметили kysely с типизацией через строки лаконичнее и прям очень похож на sql. А ts-sql-query при использовании выглядел очень многословно, как в плане запросов, так и в плане создании типов. Плюс когда запрос содержит кучу подобных методов
notEqualsIfValue, greaterOrEqualsIfValue тяжело читать, но это уже дело вкуса.Это и правда верно. Но вот проблему c тем, что везде, где подключается папка придется дописать
/index, судя по всему не решается. И сts-nodeиtsxкак-то это все-равно не дружит из коробки.Список отличий commonjs vs esm module для Node js. Любой код из npm или свой, который что-то из этого использует придется переписывать или искать альтернативу. Да, и плашка о esm у jest, пока не вдохновляет + плюс тесты придется переписывать
TypeScript не может использовать директиву
imports в package.jsonc настройкой"module": "commonjs". Получается итоговая сборка должна запускаться в Nodejs использующей esm модули, это далеко не всегда приемлемо. В результате, если хочешь использовать в итоговой сборке commonjs, то надо использовать сборщик, который сделает трансляцию... Это как-то слишком жирно для бэкенд кода.А с path aliases делаешь просто замену регуляркой в коде
/[\.\.\/]+model\/User=>@model/UserИ как бы все
Тут не совсем все просто. Нативные alias работают только с ESM модулями
Например:
Несмотря на то, что алиасы работают как для ES‑модулей, так и для CommonJS модулей, Node.js использует правила поиска модулей, которые применяются для ES‑модулей. Проще говоря, появляются два новых требования:
При импорте необходимо указывать полный путь до файла, включая расширение файла.
При импорте нельзя указывать путь до директории, ожидая импорта файла
index.js. Вместо этого необходимо указывать полный путь до файлаindex.js.Для легаси проектов получается этот способ не заведется без рефакторинга....
Спасибо, было полезно освежить некоторые моменты в голове.
Что же будет при массовом возгорании таких автомобилей на стоянке или в массовом ДТП....
В большинстве случаев лучше спрятать его от внешнего мира, по тем же причинам, что и БД прячут.
Если все-таки надо RabbitMQ сделать доступным снаружи, то необходимо коннектиться через ssl ради безопасности, но это добавит приседаний с сертификатами и их обновлением, а также снизит скорость передачи данных
Если есть еще ноды с ролью
managerи кворум может быть разрешен, то новая нода станет ведущей. Swarm использует алгоритм Raft поэтому следует использовать нечетное кол-воmanagerнод чтобы кворум работал. Да, контейнеры работать останутся, но добавлять и обновлять сервисы в кластере будет нельзя. Да, контейнеры сmanagerнод так же мигрируют, как и с обычных нод.Ну, в swarm есть встроенный балансировщик, который прослушивает порты (указанные в сompose файле) на все нодах и пробрасывает трафик, либо в контейнер, который есть на этой ноде, либо на другую доступную в кластере.
Я всегда об этом подозревал, ибо мою жену они жрут постоянно, а меня чуть ли не игнорят)
Данная команда, запускает контейнер с агентом portainer на всех нодах в кластере:
При появлении новой ноды в кластере, manager нода автоматически запустит агента portainer на новой ноде. И весь функционал portainer будет доступен для контейнеров на этой ноде. Если логику запуска portainer надо поменять, то правим файл portainer-agent-stack.yml.
Нет, порт 9443 нужен только для веб морды portainer.
Это дас) Вообще хорошие разработчики дорого стоят, но если в NodeJS нет проблем с junior и middle, то в Perl остались только сеньор за которых надо еще конкурировать с Mail, Yandex и другими большими компаниями, где еще осталось много перла. Ну, и физически сеньоров на Perl меньше, чем на Node, многие ушли в Си++, Gо, Python и ту же Node. По крайне мере у нас был такой опыт поиска ...
Да, работает стабильно, технологии уже 13 лет, большинство болячек давно решено. Нет, не течет, если только разработчик не кладет целенаправленно данные в глобальный скоуп и не чистит его, но этого можно добиться в любом демон- процессе.
Участвовал в миграции проекта на Perl с историей в 15 лет на NodeJS/TypeScript. Это был проект одного из крупнейших ВУЗов страны, он состоял из сайта, мобильного приложения и админки.
Причины переписать были следующие:
Перловых разработчиков мало и хорошие стоят прям очень дорого, а джуны не рвутся поднимать скилл в Perl
Типизация TypeScript здорово облегчает работу с большой кодовой базой, а один язык и на бэке, и фронте, чуть облегчает переключение контекста.
Асинхронность в Node js в из коробки. А в perl есть решения типа AnyEvent, но они проигрывают по степени удобства и надежности работы языкам, у которых асинхронность базовая фича
В проект было много устаревших самописных решений от предыдущих команд, которые блокировали увеличение версии perl, но при этом без апгрейда perl невозможно было обновить другие либы, в которых были найдены уязвимости. Поэтому апгредить perl было аналогично переписыванию половины проекта.
Из-за того что мы были прибиты к apache и mod_perl, отсюда вытекали все классические проблемы с обслуживанием большого кол-ва запросов.
Исходя из вышеперечисленного переписать на другой язык, казалось не такой плохой идеи. Плюс мы хотели разбить монолит на 2-3 сервиса поэтому переезжали постепенно. NodeJS убрала проблему избытка потребления памяти, а за счет снижения кол-ва подключений к БД мы даже смогли убрать pgbouncer и кэш виде Redis.
Сложности были связаны в основном с размером системы и то, что портировать все надо было по кусочкам, но при этом не оказаться в ситуации, когда надо и новый код развивать и старый.
Мой первый язык программирования) Там много было интересных подходов, которые перетекли в другие языки. Жаль Perl 6 убил развитие Perl 5, на котором все писали...
Не очень подходящее решение:
По умолчанию, создаются идентификаторы, которые начинаются с цифр, что не подходит (причина описана в статье)
Отсутствует запрет на использование определенных символов в начале идентификатора
Если задать алфавит только из букв
new Hashids('', 0, 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ');, то длина идентификатора достигнет 5 символов всего лишь через 39 304 вызовов, что как-то уж совсем мало...Требовалась генератор, который независимо работает от сборщиков и другого специфичного окружения. Ибо значительная часть генерации html происходила на стороне сервера плюс в рантайме на клиенте, а css отдавался только тот, который нужен для данной страницы и название классов должны были меняться, если обновишь страницу (борьба с блокировщиками рекламы)