Още една причина поради която избягвам използването на NodeJS

Не, няма да хейтя, въпреки че NodeJs има толкова матял за хейт и сърказъм.

Проблемът за който искам да споделя не е бъг, а е фундаментална грешка в NodeJS, която едва ли някога ще се оправи. Говоря за асинхронността, и най-вече, че според NodeJS религията всичко трябва да бъде асинхронно.

Тази псевдо асинхронност (nodejs работи само на една нишка) често помага и много процеси са изградени и модифицирани за да се „възползват“ максимално от нея, обаче има едни ситуации в които става кошмарно. Нека да ви дам реалистична постановка.

Да приемем, че имаме библиотека, която има метода addAgent(). На този метод трябва да се подаде външен обект, писан от мен, който има метода invoke(param1,param2). Библиотеката в даден момент ще извика този мой метод с тези параметри и очаква отговор от него. Важното в случая е, че библиотеката очаква точно определен отговор (обект) с който да може да работи веднага.

До тук всичко е прекрасно, нали? Обаче аз искам в метода invoke() да направя мрежова заявка за да мога да си свърша работата. Обаче в NodeJs мрежата е асинхронна, което означава, че метода invoke() връща веднага с null, което чупи всичко. Отново казвам, че библиотеката чака отговор и иска да работи веднага с него. NodeJS няма решим на синхронна мрежова заявка, така в която метода чака или както е правилно да се каже „да блокира“.

Естествено, аз не съм експерт в NodeJS и започнах да разпитвам хората които уж го разбират. Много е интересна демографията на NodeJS програмистите, това си е за отделна тема, но всеки започна да ми обяснява, че не трябва да го правя синхронно, това било много грешно.

Отне ми доста усилия да обясня, че самата библиотека, алгоритъма и целия процес които правя фундаментално е синхронен и НЕ може да се направи асинхронно. Ако успея да го направя най-вероятно ще съм решил Halting problem, само че е доказано, че това е невъзможно.

Разбира се, предложиха се опции. Едната е да се използват Promises, проблема обаче е, че метода ще върне Promise а не обект с който библиотеката да може да работи веднага. Не става.

Предложиха да се използва yield, само че yield ще върне генератор, а не отговора. Имаше и други забавни, креативни и умни предложения, но нито едно не става, просто защото проблема е в това, че фундаментално синхронна операция се опитваме да я изпълним асинхронно.

Накрая ми казаха да пренапиша библиотеката – сериозно? Да пренаписвам библиотека заради това? Ок, да приемем, че реша да го направя, тогава ще трябва да почна да работя с Promise, което значи, че аз трябва да пренапиша абсолютно цялата библиотека почти от 0 и резултата ще бъде, че тя ще изпълнява последователни операции, ама всяка една от тях ще е асинхронна, и докато асинхронната операция върви, всичко ще чака тя да свърши. Сериозно?

Естествено започнаха да ми обясняват, че този който е писал библиотеката нищо не разбира от програмиране и целия и дизайн явно е объркан, щом не я е предвидим да работи асинхронно. Не знам защо, ама това е много типично поведение за NodeJS програмист, щом не става по неговия начин значи е грешния начин. Само че тази библиотека и реализацията и е синхронна защото решава синхронен проблем. Не ми се мисли колко комплексно ще стане всичко с Promises или callbacks, предвид факта, че има и динамично програмиране в нея. А и имам сериозни основания да смятам авторите на библиотеката за доста сериозни и кадърни хора, много по-добри програмисти от мен.

Накратко – асинхронността на NodeJS може да е полезна в много случай, но не и във всички случай, и когато човек удари такъв случай няма оправяне. Идеално би било да дадат възможността на програмиста да решава дали да изпълнява нещо по асинхронен или синхронен начин. Има синхронни файлови операции, нали? Защо са ги направили? Ами нали искат всичко да е асинхронно, да ги махнат, пък да видим тогава реване и гимнастика как ще пишат елементарни програми за работа с файлове…

Един от отговорите които получих на този въпрос бе „Ами като не им даваме възможност програмистите се учат да пишат асинхронно и не правят глупости и не се карат кое как да е“. На това аз ще отговоря следното – NodeJS има претенции да е general purpuse mature programing language. Ако иска да е такъв трябва да позволява да се правят general purpose неща, а не да ограничава практики доказвани над 60 години от академици.

Накрая намерих решение, на някой му е писнало от тези простотии и е написал nodejs модул на C++, който прави синхронни мрежови заявки. Казва се netlinkwrapper.

След приключването на този proof of concept по който работя се махам от nodejs и не искам и да го погледна повече. 4 дни прекарах в търсене на начин за една шибана синхронна операция…

Дори и хората които правят CUDA оставят възможност за синхронност, а те са водещите в момента по отношение на паралелизъм и асинхронност.

 

 

 

30 мнения по „Още една причина поради която избягвам използването на NodeJS

  1. Stilgar

    Няма никакъв проблем библиотеката да се направи асинхронна (никакъв Halting Problem няма, нито ще се забави значително, а с async/await или еквивалентните generators дори няма да е много по-сложна). Абсурдното е, че се налага да се разисква опцията „пренапиши библиотеката“ щото някой решил, че е много хитър и всичко ще е асинхронно.

  2. Васил Тошков

    А какво ти е мнението за премахването на синхронния режим в AJAX ? Той още си работи, но браузърите хвърлят deprecated. А има ситуации, когато просто няма как да стане с асинхронни заявки. Примерно при разработката на разширения и не само.

  3. ウォーロック

    Абе, кажи му JavaScript и няма нужда да го обиждаш повече 😀

  4. Георги Мирчев

    На моменти генерализацията ти „NodeJS програмистите така мислят“ е най-малкото грешна.
    Ако искаш нещата ти да се изпълнят синхронно защо не избереш Python. Ще ти свърши прекрасна работа. NodeJS е направен с идеята за асинхронност и ако на теб не ти харесва по-добре ни напиши тук защо си избрал асинхронно нещо, което да използваш синхронно.
    „NodeJS има претенции да е general purpose mature programming language“ – от кога NodeJS е език за програмиране?
    И ето npm модул за синхронни заявки – https://www.npmjs.com/package/sync-request . Ако пишеш библиотека за уеб и решиш да ползваш това, дано не попадна на нея 🙂 Нищо лично.

  5. gatakka Автор

    Асинхронността не е лошо нещо ама е невъзможно да правиш всичко асинхронно. Избрах го защото една част от логиката която искам я има готова като библиотека, а аз правя проверка на концепция, няма смисъл да губя време.
    Не очаквах, че има такива „специфики“. Вече знам, и ще карам на принципа „Доктор Радева ми забрани да пиша на Node.js“.
    Няма да споря за семантиката на термина „език за програмиране“, защото Node.js реално покрива всички критерии.
    А на мен ми трябва socket конекции, а не HTTP.
    И не, не пиша WEB, за WEB нямаше да се сблъскам с тези проблеми, но не всичко на този свят е WEB. За WEB в момента Node.js си върши работа, като научиш 1-2 неща. И не, не правя библиотека а проверявам концепция.

    Мисля, че проблема на Node е, че го специализират много, най-вече за WEB и разни real time комуникации. За обработка на данни, алгоритми и тежка бизнес логика ще му трябва още време.

    Но за едно си прав, не си избрах инструмента правилно, аз съм си виновен. Очаквах нещо узряло до версия 6 да е малко по-добро.

  6. tunnckoCore

    Добре де, странно, или съм изтрещял от курсови работи, или верно не схващам проблема.
    Какво пречи да си направиш асинхронно заявката от invoke и оттам, от callback-a, да подадеш резултата към тая библиотека?

    Иначе да, съгласен съм, че тая асинхронност и на мене ми идва малко в повече понякога. Но някак си се свиква, знам ли, то найстина си е според зависи какво ти трябва.

    Charlike

  7. gatakka Автор

    Библиотеката очаква отговор от функцията, и този отговор трябва да е точно определен и да се използва веднага. Ако я пусна асинхронно отговора на функцията е null, и кода се чупи.
    Ако върна „Обещание“ библиотеката не знае как да работи с него.
    Тя не е направена за асинхронна работа и промяната ще е кошмарна.

  8. ALF

    Нова технологие е все пак. Нормално е да носи нов вид проблеми. PHP 2000 година да не би да е бил по-цветущ?

  9. Нон

    „There’s been a lot of talk on PayPal moving to node.js for an application platform. As a continuation from part 1 of Set My UI Free, I’m happy to say that the rumors are true and our web applications are moving away from Java and onto JavaScript and node.js.“

    https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/

    Щом най-големият сайт за онлайн разплащания е мигрирал към Node.js онзачава че могат да се правят и доста по сериозни проекти с Node.js различни от тип комуникация (Снапчат, видеочат, стрийминг).

  10. tones

    Фен съм на Node, но това определено е много дразнещо. И в други модули има проблем с тая пуста асинхронност и то за елементарни неща, като взимане и записване в база данни, например.

  11. Киро Секирата

    Ами има решение, макар и не много елегантно – wrapva се библиотеката да работи в отделен thread и в твоя случай invoke си чака в този thread, докато ти си изпратил асинхронния request и т.н…..

    Ама Гатака – няма ли койда те застреля, че да спреш да се мъчиш?

  12. gatakka Автор

    Прекалено съм никой, че някой да изяви желание да ме застреля. Може би ако направя няколко хита като Джорджано ще стана популярен и някой може да ме отърве от мъките. Ама аз и неговите гласови качества нямам, ех тоя крив живот, ех тая крива нива, ех това счупено рало и тия куци волове начи…

  13. Yoan

    Поправете ме ако греша, но процесора може да изпълнява по едно нещо (на ядро) в даден момент, тоест всичко е „псевдо“ асинхронно, независимо на какъв език е написано.

    Иначе езика определено не става за всичко, асинхронноста понякога доста усложнява. Общо взето веднъж хванеш ли му цаката с Promises нещата стават доста по-приятни.

  14. gatakka Автор

    Не, не става по-лесно и по-приятно. Не получаваш нищо, ама нищо насреща. Ето ти пример. Имаш следния код (на псевдо език)

    function loadAgents(){
    for each agent in agents.list{
    agent.load()
    }
    }
    Като Agent.load прави мрежови заявки, връзки към базата такива неща. Броя на агентите може да е произволен. Кода трябва да продължи изпълнението си СЛЕД като всички агенти са си заредили нещата.

    Хайде напиши ми как ще стане с промиси врътки и чалъми.
    Защото по разумния начин става така:
    loadAgents()
    other code goes here….

    Хайде да видим колко е лесно да се направи това на Node.

    Вижте, а синхронността може да е хубава в някой случай, ама да ми казваш, че всичко било по-хубаво, красиво, лесно и четимо и бързо ако пишеш асинхронно…. Да бе, говорете си, не ми пречете….

  15. Yoan

    Ако ти си пишеш agent.load() става без проблем, ако е външна асинхронна библиотека и няма callback показващ кога нещото е свършило няма как да стане без пренаписване.

  16. gatakka Автор

    Кажи ми как ще стане, аз си пише loadAgent, и там имам асингронни операции. Функцията ще върне веднага. Дори и promise да ми върне ще трябва да има нещо което знае колко промиса са общо и да следи дали всички са приключили.

  17. Yoan

    Ето вариант:
    http://bluebirdjs.com/docs/api/promise.all.html

    Естествено ще трябва да wrap-ваш всичко в промиси, ако искаш нещата да са ти последователни. Другият вариант е с events някакси да се измисли, абе начини има, но със сигурност на синхронните езици ще е по-просто. Обаче при nodejs има голям плюс, докато правиш тези асинхронни операции, може да имаш например REST сървър и той да сервира докато даденото нещо се изпълнява. Не че не може да се направи нещо такова на друг език, но ще е по-сложно.

  18. gatakka Автор

    То бе ясно, че ще има някаква библиотека, която го прави. Аз питах чисто архитектурно как се прави. Ще я разгледам да видя как постигат синхронност върху асинхронен код 🙂

    А иначе за това, че си имал REST сървър който сервира, аз предпочитам да си имам един NGINX , отделен процес, евентуално Haproxy на отделен процес, да си се оправят те със заявките.

    Кода си оправя логиката,WEB сървъра да си оправя заявките. Така ще мога да използвам 2 ядра, понеже в Node няма как да работиш на повече от едно ядра.

    Не знам от къде идва това объркване, че щом било асинхронно винаги задължително е по-бързо. Работиш на едно ядро и един процес. Този процес прави нещо, смята нещо, прави операции. Това че не чакало да свърши нещо а пускало друга задача не означава, че тези задачи са ПАРАЛЕЛНИ. От къде ще ти дойде бързодействието?

    Ще се опитам да се обясня по-ясно.

    Имаме следните нужди:
    – приемане на заявка
    – оторизация
    – взимане на данни
    – връщане на отговора към клиента

    За да върнем отговора на клиента предишните задачи трябва да са готови. Ако всяка една от тях заема 25% от общото време и да се чакат и да не се чакат резултата ще се върне след като те се извършат. Времето е едно и също.

    Най-вероятно ще кажеш, че докато чака „взимане на данни“ може да почне да обработва „приемане на заявка“ на друг клиент. Да, може, но от къде печелиш бързодействие, при условие, че тази 2-ра заявка трябва да се нареди и тя на опашката за ресурси и процесорно време.
    Асинхронноста не е паралелност.

    Единствения реален случай където може да спечелиш нещо е ако „взимане на данни“ е дълга операция и заема много малко ресурси и не кара процесора да прави много превключване на контекста. Тоест е в idle или подобен режим, тогава може да използваш CPU времето за нещо полезно. Но ако операциите са „локални“ и няма idle даже губиш заради непрекъснатото превключване на контекст.

  19. Yoan

    Като цяло разбирам защо се дразниш, първото ти по-сериозно сблъскване, още не мислиш асинхронно и всичко ти се струва супер тъпо, след като преминеш тази фаза (ако си достатъчно упорит) нещата изглеждат различно. Има преимущества всичко да е асинхронно, както и отрицателни страни, но не бива с лека ръка да се казва, че nodejs е тъп.

    Не е вярно, че в node не може да работиш с повече от едно ядро:
    https://nodejs.org/api/cluster.html
    https://nodejs.org/api/child_process.html

  20. Yoan

    Например в PHP за да обработиш 50 заявки едновременно, apache-то трябва да има fork-нати 50 процеса по 50MB всеки, a в nodejs вероятно ще свършиш работа с един процес, който ще заеме не повече от 100MB.

    > За да върнем отговора на клиента предишните задачи трябва да са готови. Ако всяка една от тях
    > заема 25% от общото време и да се чакат и да не се чакат резултата ще се върне след като те се
    > извършат. Времето е едно и също.

    В повечето случай такива операции почти не товарят CPU-то, по скоро ако взимаш данни от базата, тя ще се товари, не процеса ти.

    Абе както и да е, може да продължаваме много така.. 😀

  21. gatakka Автор

    Нека да уточня нещо отново. Аз не се дразня на асинхронността, не се дразня на Node. Аз се дразня на факта, че се опитват ВСИЧКО да го накарат да е асинхронно, независимо от цената, а за някой елементарни проблеми има библиотеки и механизми, които симулират синхронност.

    Не им е проблем да оставят механизъм някой неща да са си синхронни. Ако на някого му трябва да си го напише, нека по дефолт да е асинхронно. Мога да ти давам много примери където синхрония код е много по-ефективен от гледна точка на писане, четене, подръжка.

    Има и много примери в които асинхрония код просто кърти (типичния пример комуникация през сокети)

    Дразни ме, че някой някъде е решил че това е подходящо за всички, и той е най-прав а останалите да се спасяват. За това не харесвам Apple и религиите като цяло 🙂

    И си малко в грешка, че за 50 заявки апачи ще направи 50 отделни форка. Може, ако искаш може и така да се държи, отделно определено апачи няма да заеме по 50М на форк, извинявай, но е забавно. Сметни колко RAM ще ми трябва по тази логика, при условие, че имаш сайт с 1000 заявки в секунда.

    Сега погледнах как те решават работата с много процесори. Цитат:
    „Node.js is one-thread-per-process. This is a very deliberate design decision and eliminates the need to deal with locking semantics“

    Ами какво да кажа, it’s something.

  22. Solid State

    Напълно подкрепям Gattaka за нещата , които е описал в статията и за избора му да се махне от NodeJS . Аз лично напуснах настоящата си работа именно основно заради тази технология и по – специално заради :

    – Callback hell-a – Тези дълги nested functions . Много трудни за проследяване и оправяне .
    – Async принципа – Аз лично много трудно се оправям с това .
    – npm – 8 от 10 пъти не работи и си прави каквото си иска (трие модули без да е зададено да го прави , хвърля грешки, като цяло трудна оправия с dependеnce-тата . А уж това се води едно от големите предимства на Нода .)
    – Бедна и много зле направена документация на доста от модулите и библиотеките , а някой дори и са тотално изоставени.
    – Debugging – тук тотално се загубих . Незнам как са го направили тук , но в PHP и Java доста по – бързо и лесно дебъгвам .

    Като цяло разбрах , че трябва да минеш през много сложни и огромни неща , за да направиш нещо минимално . Незнам може би бъркам , защото съм начинаещ , но правя разликата с писането на PHP и Java и писането на NodeJS . Факт е , че е най – бързо разратващата се технология и много се търси заради перформънса , но като гледам PHP как бързо се реагират , може този перформънс скоро да не е фактор . Не искам да се връщам към това нещо повече , много negative experience .

  23. DevIt

    „Нека да уточня нещо отново. Аз не се дразня на асинхронността, не се дразня на Node. Аз се дразня на факта, че се опитват ВСИЧКО да го накарат да е асинхронно, независимо от цената, а за някой елементарни проблеми има библиотеки и механизми, които симулират синхронност.“

    Нека и аз да уточня нещо, не е задължително да се ползва node.js за всяко приложение, за някои е просто неподходящо. Специално тук Вие се опитвате да решите проблема по начин който е, поне на пръв поглед, неграмотен. Ако самата архитектура на рън тайма е асинхронна, a Джон като типичен Старопланински джентълмен ще го преправя на синхронно. Естествено че ще доведе до проблеми.

    Специално за това ми се струва, че можеш да решиш проблема си с отличната библиотеката на caolan – async, за не повече от пет минути и само с примерите средно интелигентен човек ще разбере как да работи с нея. series метода е това, от което мисля че е нужно. Друг вариант е да се ползва и написана с Event emitter функция, която ще е 30-40 реда, но async има много други преимущества. НЕ приемам че се симулира синхронност с тази библиотека, тя единствено запълва „дупка“, в типичен за платформата стил (не всичко е вградено за да може да се избере решение според личното предпочитание). Не може човек да обвинява за собственото си невежество цяла екосистема в която, вярвате или не има (и) доста талантливи разработчици.

    Мисля че не е нормално някой да има мнение за себе си като сериозен разработчик, а да плюе нещо, защото не върши нещата по начин който не му харесва. Има много други възможности да се реализира един проект с най-различни платформи/езици.

    Поздрави.

  24. gatakka Автор

    Уважаеми @DevIt дали съм добър, грамотен или прост селянин може да казват само хората с които и за които съм работил.
    Много лошо впечатление прави когато някой коментира без да е разбрал проблема,да вади изводи и дава определения.
    Въпросната библиотека (caolan/async), колкото и да е велика е абсолютно непрактична в случая, това бе потвърдено от поне 3-ма изключително добри Nodejs разработчици, с които се консултирах в търсене на проблема.

    Почувствахте се обиден от това, че споделям „недъг“ на езика, който сте избрали да използвате и който, най-вероятно, върши прекрасна работа за вашите нужди? Понеже когато разговора премине в лични напатки и няма аргументи за и против конкретния проблем под въпрос аз приемам, че не разполагате с такива аргументи.

    Решенията които предлагате (и подобни ) са коментирани преди да напиша статията включително и с доказани nodejs професионалисти, някой от които приеха задачата като предизвикателство, и не успяха без хакове.

    Приемам че явно не разбирате конкретния проблем за който говоря. Нека да го онагледя:
    А,B,C са серия функции във външна библиотека които се изпълняват последователно в реда A->B->C,
    Функция B взима данни от твърдия диск синхронно.

    Задачата (в най-простата си форма е) Функция B да вземе данни през мрежата, след като получи тези данни да направи лека обработка и да подаде резултата на C.

    Тоест искам да сменя един поток (файлова система) с друг поток (socket).

    Библиотеката не може да се променя заради комплектността си, не мога да променя функция C така че да получава promise или да разбия нормалния поток на изпълнение на библиотеката.

    Не мога да стартирам директно функция B, тя трябва да се извика от самата библиотека, отново поради сложността на целия процес в самата библиотека.

    Покажете ми лесен начин да го направя с nodejs, без да се налага да пренаписвам библиотеката, да пиша C/C++ разширения за синхронна мрежова комуникация и без да губя бързодействие използвайки някакви изчаквания или логика подобна на мутекси или семафори.

    Ще се радвам да споделите вашият опит и да обогатите моето скромно несъстоятелно съществуване

    И да, накрая реших проблема написвайки тези неща на Golang, което се оказва изключително ефективно.

    И за финал, вие твърдите, че Nodejs не е подходящ за всякакви задачи, аз твърдя същото давайки пример. Тоест,ние сме на едно мнение, а вие давате негативни квалификации за това, че съм на вашето мнение?

  25. DevIt

    Ами решението е значи супер елементарно. Пишете си на Go и не се занимавате с Node.js . Въпросните специалисти които сте питали е много вероятно не са имали никакво желание или възможност да разберат от вас какво точно и защо искате да го постигнете по този начин. Не съм писал нито употребявал нито един от изразите ::добър, грамотен или прост селянин:: спрямо Вас. Интересното е, че прехвърляте проблем, който е най-вероятно ( от твърде неясното обяснение на проблема което предагате ) на външна библиотека, във проблем на цяла еко система. Оплювайки е. В node.js има стрийминг от сокет -> файл -> към каквото друго е нужно, но явно има още нещо което пречи на осъществяването. Писали сте и отново за промиси? Вие като голям специалист не Ви ли пречи че се изпълняват само веднъж с resolve или reject и при мрежова комуникация може да се наложи да направите втори и тн. рикуест ?
    Доколко въобще правите разлика и реално знаете какво е мутекс и семафор, е тема за цял друг разговор.

    Не е редно да оплювате и да твърдите, че нещо не е ОК, само защото сте или неспособен или, макар и малко вероятно, неподходящо за вашите цели.
    Все едно да се оплаквам че с нож трудно забивам пирони, и затова ножа е малоумно измислен. Не забива пирони добре? Че за какво ми трябва тогава?

  26. gatakka Автор

    Дадох ви доста ясно описание на проблема, по-ясно от това не мисля, че има нужда да обяснявам.

    Споделям промиси, писане на c/C++ модули, семафори и подобни защото това са неща които бяха обсъждани, предлагани и коментирани, респективно отхвърлени като непрактични или ненужно сложни за такава проста задача.

    Не чух вашето решение на зададеният по-горе проблем!
    Не успявам да намеря нищо по темата socket -> file. Не говорим за Unix sockets, нали?

    Явно нещо лично го приемате, че показвам ситуация в която Nodejs не се справя, както примерно PHP е кошмарен за десктоп приложения.

    Бихте ли разяснили какво имате предвид socket ->file и какво е елементарното решение на простия проблем зададен от един неспособен дилетант в невероятния свят на nodejs.

    И не ми говорете, ако обичате, дали съм знаел какво е мутекс и семафор, моля! Нито знаете техническото ми минало, проектите и екипите с които съм работил, нито каквато и да е друга информация за моите умения. И не, не съм PHP full stack разработчик.

    Видял ли сте мой код някъде който използва мутекси и семафори че коментирате? Ако сте видели ще ми е много, ама много интересно, къде е това и как точно се е случило това и с чие разрешение!

    Отново, ако обичате, вашето решение на този проблем:
    A->B->C A->B->Bn->C

  27. DevIt

    Не се съмнявам, че сте PHP Full Stack разработчик, а ако сте такъв , поздравления (!).
    Всъщност никъде не съм писал нищо за PHP ?!?
    Ето тук е написано „socket ->file“ като за дилетанти, с туториал и много хубави, големи букви:
    https://www.safaribooksonline.com/blog/2013/05/01/using-streams-in-node-js/
    и не, не става въпросТ за unix socket

    Има и един таен сайт, като напишете в него „node.js socket to file“ излизат, много, много резултати.

    Сайта е google.com. Но не го споделяйте, за да остане таен.
    Бъди щастлив.

  28. gatakka Автор

    Сериозно ли?
    Аз НЕ съм PHP full stack, моля, четете правилно, защото целия този разговор щеше да е ненужен.

    Първо, смятате ли, че не съм използвал търсачка за node js socket file?

    Второ смятате ли, че някой от nodejs програмистите с които говорих нямаше да знаят за тази мистериозна функционалност socket->file.

    Трето – сериозно ли?
    Това което сте дали като линк е pipe на Stream с евентуална опция да се приложи логика върху самия Stream. Това не решава горния проблем по никакъв начин.

    Ако намерите решение на проблема ще се радвам да го споделите, сигурен съм, че има nodejs програмисти, които ще използват решението ви с удоволствие.

    Но преди това, моля, прочетете правило проблема, за да може да намерите правилното решение! Ще ви подскажа – как да симулираме синхронна мрежова заявка в nodejs, или как да изчакаме отговора от мрежата без да се минава към извикването на функция C от горното обяснение на проблема

    Благодаря, и вие бъдете щастлив, както се чувствам и аз.

  29. DevIt

    „Не успявам да намеря нищо по темата socket -> file. Не говорим за Unix sockets, нали?“

  30. gatakka Автор

    Добре, коригирам изказването си от:
    „Не успявам да намеря нищо по темата socket -> file. Не говорим за Unix sockets, нали?“
    на
    „Не успявам да намеря нищо по темата socket -> file което може да ми бъде полезно в контекста на текущият проблем. Не говорим за Unix sockets, нали?“

    Други предложения и решения, или да спрем да си губим времето?

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *