Демон для обработки очереди

[флоппик]

Вообще не вижу особых проблем с протоколами, реализованными на php.

Мне хочется, чтоб модельки получать на выходе, а не голенький sql.

Как вы передаете данные из reactphp-сервера в обработчик с базой?

Ну вот в соседней теме я писал про phpreact/http-client - ну вот им как раз и передаем. Он тоже асинхронный, и тоже событиями всунут в тот же евент-луп, что и сама серверная часть. И пока там фпм ходит в базу, все спят.
Примерно так:
https://gist.github.com/gorbunov/4cdc1eedb9ba29001abe6fde91351f8f

 

[fixxxer]

Мне хочется, чтоб модельки получать на выходе, а не голенький sql.

А, ну это уже вопрос адаптера для какого-нибудь datamapper-а. Не уверен, что такое есть (и фиг lazy load сделаешь. Хотя если вместо arrayObject-коллекций генератор... Ну, в общем, непросто в любом случае).

Мне в том, что у меня на reactphp в базу ходит, надо только read models, так что голого sql хватает.

Впрочем оно у меня вообще маленькое и только суппортится, я щас вообще все больше typescript-разработчик, хехе. Вот https://nestjs.com/ пока что очень нравится.

 

[grigori]

А в ноде-несте запрос к базе в отдельном потоке исполняется, или в главном цикле?
Насколько я помню, потоков там нет, только несколько воркеров. Получается, приложение асинхронное, но должно оставаться stateless, без данных в памяти, чтобы запросы балансировались между воркерами. Happy scaling!

 

[fixxxer]

@grigori, в цикле. Все io операции в nodejs - всегда асинхронные. Потоков нет, соответственно, никаких там семафоров с мьютексами и блокировками тоже нет. Более того, nodejs кроссплатформенный, и из коробки там только то, что одинаково работает на всех ОС, включая винду.

Конечно, если очень хочется, то есть всякие врапперы типа node-shm, но такой подход для платформы нетипичен, это примерно как pthreads в php - в принципе, прикрутить можно, но никто так не делает.

Если нужен кэш, обычно берут какой-нибудь redis/memcached, и работают с ним по сети. Тут уже без разницы, несколько процессов на одной машине или на разных, это удобно на самом деле.

Разумеется, это годится не для любой архитектуры. Нода хорошо подходит для 12factor microservices, с балансировкой тут прекрасно справится банальный upstream pool в nginx.

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

 

[grigori]

Ну вот в соседней теме я писал про phpreact/http-client - ну вот им как раз и передаем. Он тоже асинхронный, и тоже событиями всунут в тот же евент-луп, что и сама серверная часть. И пока там фпм ходит в базу, все спят.
Примерно так:
https://gist.github.com/gorbunov/4cdc1eedb9ba29001abe6fde91351f8f

Код приятный, но от чуваства лишнего слоя протестует перфекционизм.

 

[grigori]

@fixxxer, помню, как ты плевался на ноду несколько лет назад. Почему не golang, питон, джава?

Работал я год с большим приложением на JS.
Допустим, ты пишешь stateless service, прекрасно. Твой сервис работает с базой и файлами. База растет, данные на дисках растут - это общее правило. Однажды начинаются локи, задержки при UPDATE, выборки больших объемов. Все надо обрабатывать, каждое состояние.
Удаление файла - асинхронная операция, fs.unlink(path, callback). Однажды приходится дописать обработку ошибок удаления, потом этот файл отправить в очередь.
NestJS и TypeScript ничего на эту тему не дают, тут или нативный JS, или ручками оборачивать в промисы.
Ты каждый вызов в просмисы оборачиваешь, или у тебя каскад коллбеков на 20 экранов?

 

[WMix]

Ты каждый вызов в просмисы оборачиваешь, или у тебя каскад коллбеков

сами по себе промисы не намного лучше коллбеков, выгода только в async await появляется.

Однажды начинаются локи, задержки при UPDATE, выборки больших объемов.

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

 

[fixxxer]

@grigori, с тех пор все стало намного лучше.

Функцию можно объявить асинхронной. Внутри асинхронной функции можно использовать оператор await, который "разворачивает" promise в обычный return value. И даже try-catch для rejection работает.
Это уже безо всяких там транспайлеров, из коробки.

» node
> const test = () => new Promise(resolve => setTimeout(resolve("OK"), 1))
> (async () => { let result = await test(); console.log(`Got result: ${result}`); } ) ()
Got result: OK

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

 

[fixxxer]

Почему не golang, питон,

Потому что TypeScript. Я крайне некомфортно чувствую себя в языках без классического ООП с человеческими классами и интерфейсами. Хочу чтобы был DI, чтобы работал рефакторинг, вот это вот все.

Хотя на самом деле, началось по принципу "на чем в команде умеет писать кто-то, кроме меня", а там втянулся, гы-гы.

джава?

Сам по себе язык нормальный (хотя шарп лучше), но инфраструктура и общепринятый подход к проектированию библиотек - это п-ц.

 

[fixxxer]

fs.unlink(path, callback)

Ну вот все эти модули, которые были с ноды 0.1 - тут тяжелое наследие. Но все решается через promisify.

 

[grigori]

в браузерах await не работает, конечно
но промисы намного читабельнее колбеков в любом случае, особенно promseAll

короче, от PHP осталась привычка к Java-style OOP потому как с объектностью в питоне и голанге все в порядке, этот свободный duck typing очень даже интересный

 

[fixxxer]

@grigori, для браузеров typescript компилирует в адовый конечный автомат со свитчами.

 

[grigori]

который феерически тормозит и греет аккум на телефонах

 

[fixxxer]

этот свободный duck typing очень даже интересный

Интересно, не спорю. Мне не интересно хочется, а так, чтобы открыл код, и в нем все понятно и мне, и всей команде, и инструментам рефакторинга и навигации в IDE.

 

[fixxxer]

который феерически тормозит и греет аккум на телефонах

Не, ну там не тупой цикл же. Все намного интереснее. Await компилируется в генераторы, а генераторы в... эмм... вот в это: https://blog.mariusschulz.com/2016/12/09/typescript-2-1-async-await-for-es3-es5

И, кстати говоря, в нормальных браузерах это уже все из коробки работает.

https://caniuse.com/#search=await

 

[grigori]

А в TypeScript у тебя не duck typing? разница с golang только в синтаксисе, причем, у последнего нет очень многих проблем - ему не нужна совместимость с JS

 

[fixxxer]

А в TypeScript у тебя не duck typing? разница только в синтаксисе

Разница с классическим duck typing в том, что хрен знает что не скомпилируется.

Да, интерфейсы сопоставляются не по имени, а по структуре. Это решение обусловлено тем, что нужна совместимость с js-кодом, где таковые интерфейсы "фактические". Вот есть одна js-библиотека и .ts.d для нее с интерфейсами. Есть другая, и у нее свои .ts.d со своими интерфейсами. И есть код, который передает одно в другое, и это все работало безо всяких typescript-ов, потому что интерфейсы фактически одинаковые. Вот чтобы продолжало работать на typescript с подключением ts.d-шек - именно так и сделано.

Это не значит, что я могу как в php4 передавать любое говно в любую жопу и валиться с фаталами в compile time. (Нет, ну, конечно, могу, но это надо специально затычку в виде any подсунуть).

А на golang это похоже, только в нем вообще слова implements нету. В нем, правда, и классов нету. Хотя это-то в принципе еще ничего, у golang огромный недостаток в отсутствии дженериков. В результате начинается либо кодогенерация кодогенерации, либо полный ад с interface{}.

 

[grigori]

как-раз передавать любое говно в TS ты можешь компилятор проверяет только наличие полей в объекте в соответствии с интерфейсом, и все - никакой runtime-проверки нет по определению, потому что исполняется голый JS

 

[fixxxer]

Рантайм проверки в ts быть не может, потому что он всего лишь генерирует js.

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

 

[grigori]

я писал на TS, хорошо я к нему отношусь - плохо я отношусь к JS и к ноде с безумным пакетным репозиторием и с колбеками