Очень жаль, было удобно принимать платежи на сайте через WebMoney для маленьких pet-projects.
Печально, все это... Идут похороны Рунета полным ходом: домен RU судя по всему скоро продлевать только через Госуслуги, QIWI и WebMoney "замочили", а Яндекс, Wildberries, Сбер и другие строят интернет в интернете.
Если и так понятно, в какие таблицы смотреть, тогда зачем шарить множество ID по таблицам?
Например, реальный кейс есть urls: /schedule_task/:id, /manual_task/:id, /osa_task/:id. Как написано в статье у них разный workflow, но при этом они в пользовательском приложении находятся в одном разделе. Например, достаточно дернуть url c неверным id, например, вместо /schedule_task/1 /osa_task/1 и мы получим битые данные(для sql запросов аналогично). С sequence такое провернуть нельзя.
Значит, все-таки существует кейз, когда непонятно?
Да, был кейс в legacy системе, в которой был один sequence вообще на все таблицы в БД, а вместо REST был RPC с невнятным наименование методов. Но как правило в бизнес-логике мы работаем с конкретной таблицей/таблицами и нам не особо требуется выяснять откуда взялся id из sequence или auto_increment.
И что мешает, например, запустить identity-генератор в первой таблице с 1, во второй - скажем с миллиарда, а в третьей - с двух?
Да, вообщем-то ничего, просто sequence поудобнее. Ведь придется диапазоны подгадывать или менять их при добавлении новых таблиц, плюс не все id будут заюзаны - в одной таблице 100 000 сущностей и больше не добавляются, а второй и миллиарда не хватит. Плюс можно sequence зацикливать.
Да, можно через union. Но если такая задача стоит на постоянной основе, а не в рамках дебага сложного кейса, то стоит иметь таблицу связи: тип сущности и id. Но с uuid будут те же проблемы. Вообще я редко сталкивался с необходимостью определить, откуда взялся id ибо если REST "/user/123/purchase/567", то довольно просто понять в какие таблицы смотреть.
Простите, но все это можно сделать не хватаясь за другой язык:
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены
Все worker получают сообщения из RabbitMQ, но только worker, который имеет соединение с конкретным пользователем делает acknowledgment для сообщения, иначе игнорит.
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены.
А то что в потоках нельзя шарить сокеты это не зря сделано. Многопоточное программирование двигается в сторону общения сообщения как в Erlang/Elixir, а не в шаринге всего подряд, что ведет к сложноуловимым ошибкам и использованию блокировок, которые убивают перфоманс
Иногда по быстрому надо накидать скриптик, который плотно работает с системным окружением. Например, работа с лог файлами, созданием бэкапов, автосоздание каких-нибудь директорий и т.д.
И тут встает вариант либо писать на bash, а на нем код довольно быстро превращается в лапшу. Либо писать логику на другом языке, но в Nodejs нельзя просто так вызвать, например tar надо использовать child_proccess, ну или реализовывать логику unix утилиты в коде. Это немного утомляет.
В данном случае мы получили тесную интеграцию полноценного языка программирования и unix окружения. И это удобно.
Хорошая статья. Печально, что революция сотворила с людьми. Сикорский еще хорошо отделался, того же Шидловского вообще вместе с сыном расстреляли в 1921. А ведь у нас мог быть нормальный автопром...
У автора странная тема с "русский и православными".
Автор про всех финов и т. д. подчеркнул, что (не русский и не православный),
а когда Рахманинов дал 5000$ не написал, что русский и православный.
Проблема поддержки async/await в Express решается одной строкой
require('express-async-errors');
После чего все middleware будут обернуты в promise.
Проблема, middleware hell скорей заключается в незнание разработчиками каких-либо других архитектурных паттернов, чем в самом Express.
Да, Express очень легковесный фреймворк, как впрочем и Koa, Fastify…
Несколько раз переписывал лапшу из middleware просто написанную с другим синтаксическим сахаром на этих фреймворках. Да, с ними надо на берегу спроектировать архитектуру, а фреймворк использовать лишь как изолированный транспортный уровень.
Но преимущество Express в том, что под него написано куча вспомогательных пакетов на npm для разных задач. А с Koa, Fastify и подобными все гораздо хуже и зачастую надо тратить много времени на написание оберток для интеграции с ними.
Если хочется "жесткий" фреймворк, то стоит смотреть на AdonisJS(аля Laravel), NestJS(аля Spring), LoopBack
Отвратительный клиент под Node js. Проблема в том, что клиент зависит от СИшной либы, а из нее сыпались ошибки в рантайме.
Очень слабое коммьюнити, полторы калеки на StackOverflow и т.д. В случае чего вам придется залазить в исходники. Кол-во вспомогательных инструментов в сравнении с другими брокерами равно нулю.
Для синхронных языков типа Python придется читать из топика через while(true) {}, что мягко говоря не очень удобно(1 топик — 1 скрипт). Да, это можно обойти через слушания топиков по маске, а потом парсить регуляркой название и заниматься роутингом сообщения. Но, блин, это не очень удобно
Отсутствие нормальной web морды как в RabbitMQ/Kafka
Очень жаль, было удобно принимать платежи на сайте через WebMoney для маленьких pet-projects.
Печально, все это...
Идут похороны Рунета полным ходом: домен RU судя по всему скоро продлевать только через Госуслуги, QIWI и WebMoney "замочили", а Яндекс, Wildberries, Сбер и другие строят интернет в интернете.
Очень интересная статья, теперь стало ясно как устроены АЭС.
Включение HTTP2 на стороне балансировщика разве не решает проблему ограничения кол-ва подключений?
Это относится и к рассматриваемой либе Structurae’s View
Например, реальный кейс есть urls:
/schedule_task/:id, /manual_task/:id, /osa_task/:id. Как написано в статье у них разный workflow, но при этом они в пользовательском приложении находятся в одном разделе. Например, достаточно дернуть url c неверным id, например, вместо/schedule_task/1 /osa_task/1и мы получим битые данные(для sql запросов аналогично). С sequence такое провернуть нельзя.Да, был кейс в legacy системе, в которой был один sequence вообще на все таблицы в БД, а вместо REST был RPC с невнятным наименование методов. Но как правило в бизнес-логике мы работаем с конкретной таблицей/таблицами и нам не особо требуется выяснять откуда взялся id из sequence или auto_increment.
Да, вообщем-то ничего, просто sequence поудобнее. Ведь придется диапазоны подгадывать или менять их при добавлении новых таблиц, плюс не все id будут заюзаны - в одной таблице 100 000 сущностей и больше не добавляются, а второй и миллиарда не хватит. Плюс можно sequence зацикливать.
Да, можно через union. Но если такая задача стоит на постоянной основе, а не в рамках дебага сложного кейса, то стоит иметь таблицу связи: тип сущности и id. Но с uuid будут те же проблемы.
Вообще я редко сталкивался с необходимостью определить, откуда взялся id ибо если REST "/user/123/purchase/567", то довольно просто понять в какие таблицы смотреть.
Простите, но все это можно сделать не хватаясь за другой язык:
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены
Все worker получают сообщения из RabbitMQ, но только worker, который имеет соединение с конкретным пользователем делает acknowledgment для сообщения, иначе игнорит.
Сообщения складываются в какую-нибудь БД, например, Redis. Откуда worker читает сообщения для пользователей, которые к нему подключены.
А то что в потоках нельзя шарить сокеты это не зря сделано. Многопоточное программирование двигается в сторону общения сообщения как в Erlang/Elixir, а не в шаринге всего подряд, что ведет к сложноуловимым ошибкам и использованию блокировок, которые убивают перфоманс
В свое время Dancer был первым моим фреймворком на Perl(а он был первым промышленным языком). Сколько воды утекло...
Иногда по быстрому надо накидать скриптик, который плотно работает с системным окружением. Например, работа с лог файлами, созданием бэкапов, автосоздание каких-нибудь директорий и т.д.
И тут встает вариант либо писать на bash, а на нем код довольно быстро превращается в лапшу. Либо писать логику на другом языке, но в Nodejs нельзя просто так вызвать, например
tarнадо использоватьchild_proccess, ну или реализовывать логику unix утилиты в коде. Это немного утомляет.В данном случае мы получили тесную интеграцию полноценного языка программирования и unix окружения. И это удобно.
Хорошая статья. Печально, что революция сотворила с людьми. Сикорский еще хорошо отделался, того же Шидловского вообще вместе с сыном расстреляли в 1921. А ведь у нас мог быть нормальный автопром...
У автора странная тема с "русский и православными".
Автор про всех финов и т. д. подчеркнул, что (не русский и не православный),
а когда Рахманинов дал 5000$ не написал, что русский и православный.
Полностью согласен со статьей. Сам тоже до такого подхода дошел и после этого стало гораздо проще ориентироваться в проектах.
Проблема поддержки async/await в Express решается одной строкой
После чего все middleware будут обернуты в promise.
Проблема, middleware hell скорей заключается в незнание разработчиками каких-либо других архитектурных паттернов, чем в самом Express.
Да, Express очень легковесный фреймворк, как впрочем и Koa, Fastify…
Несколько раз переписывал лапшу из middleware просто написанную с другим синтаксическим сахаром на этих фреймворках. Да, с ними надо на берегу спроектировать архитектуру, а фреймворк использовать лишь как изолированный транспортный уровень.
Но преимущество Express в том, что под него написано куча вспомогательных пакетов на npm для разных задач. А с Koa, Fastify и подобными все гораздо хуже и зачастую надо тратить много времени на написание оберток для интеграции с ними.
Если хочется "жесткий" фреймворк, то стоит смотреть на AdonisJS(аля Laravel), NestJS(аля Spring), LoopBack
Опыт использования Pulsar отрицательный.
Это миф, что Node жрет много памяти, если конечно не ставить бесконтрольно модули сомнительного качества.
Плюс в Node js можно включить ручное управление Garbage Collector, если вы ограничены в памяти и хотите более интенсивно чистить память.