Напредване в .Нет и изоставане от ПХП 5

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

Гледам ицата държи някакви смислени коментари, евалата.

Релаксчо, може би ме помниш, компа ми обсъждахме преди години тук (стюи), какво се случиа в чужбина с теб, гледам в пхп си напреднал?

Сънчо пак е същия тираджия, уникални анализи и коментари, върна ли си изгубените пари от пандемията? Гледаш ли още СКАТ и Алфа за да не заспиш пред ц++ кода ти де 20 години го копаеш?

Яначков е уникален в халюцинациите си, но поне не е думнал аеца, което е добре. Да видим като дойдат краварите с горивото си какво ще направи. Сигурно нещо на VB6.

Това мнение е било редактирано от WizardKing на 12-08-2023, 11:56

Там съм си. Като цяло напредвам в .NET. Изостанал съм с новите неща в PHP като цяло (от практическа гледна точка) и минавам бавно от PHP 5.6 на .NET 5+.

Там съм си. Като цяло напредвам в .NET. Изостанал съм с новите неща в PHP като цяло (от практическа гледна точка) и минавам бавно от PHP 5.6 на .NET 5+.

Не, че. Нет е велик, но си бие пхп, питон и други интерпретативни нетипизирани езици. Гледам и заек mq ползваш, какъв ти е use case-a?

Определено е в пъти по-добре.

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

Но текущия use case е, че имаме един сървиз, който събира определена информация от различни портали и публикува real-time за всички, които слушат за тези съобщения. В момента това е едната legacy платформа, която е на PHP, и имаме още един сървиз за reporting.

Определено е в пъти по-добре.

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

Но текущия use case е, че имаме един сървиз, който събира определена информация от различни портали и публикува real-time за всички, които слушат за тези съобщения. В момента това е едната legacy платформа, която е на PHP, и имаме още един сървиз за reporting.

Хм не лош случай за ползване, може да пробвате да пуснете и паралелни консуматори ако имате проблеми с по-бавна обработка на съобщения. В един проект си направих експеримент в асинхронен хендлър на много консуматори да обработвам паралелни съобщения в рамките на няколко часа всяко - никакви проблеми. Единствено изисква настройка за лайфтайма на консуматора, който е 30 минути по дефолт. Учудващо заека става за паралелна обработка на процеси.

Определено е в пъти по-добре.

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

Но текущия use case е, че имаме един сървиз, който събира определена информация от различни портали и публикува real-time за всички, които слушат за тези съобщения. В момента това е едната legacy платформа, която е на PHP, и имаме още един сървиз за reporting.

Хм не лош случай за ползване, може да пробвате да пуснете и паралелни консуматори ако имате проблеми с по-бавна обработка на съобщения. В един проект си направих експеримент в асинхронен хендлър на много консуматори да обработвам паралелни съобщения в рамките на няколко часа всяко - никакви проблеми. Единствено изисква настройка за лайфтайма на консуматора, който е 30 минути по дефолт. Учудващо заека става за паралелна обработка на процеси.

Да, заека се справя много добре с fair dispatching. Мога да стартирам колкото искам консуматора. За това и исках да ги пускам чрез systemd, за да мога да управлявам броя инстанции и да дам вариант на IT-то добави мониторинг, че с PHP е по-голяма галамация, отколкото в .NET.

Заека като цяло не го интересува почти нищо. Той само знае, че трябва да изпрати съобщението и има списък с конекции. Според prefetch count-а, ще изпраща по определен брой съобщения на един консуматор и ще прати още само, ако същия консуматор е върнал някакъв вид ack/nack обратно за всички съобщения. Иначе ще се опита да изпрати следващите на друг консуматор за същата опашка.

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

Да точно аз на това разчитам за паралелиризъм - един единствен канал с 50 консуматора и някой консуматор като е зает (няма върнат ack/nack) другите свободни вземат месиджа произволно.

А за какъв чеп ви е тоя MassTransit като надстройка на заека?

Това мнение е било редактирано от WizardKing на 12-08-2023, 21:46

Уж за по-опростеното сетъпване. До някъде е доста удобен, особено, когато става дума за сага, но в доста отношения е неконсистентен, когато се правят дефиници за producers и consumers.

Също по-подразбиране взима неймспейса + името на класа, за да създаде exchange-а, който винаги е fanout.

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

Тези простотии лично аз не ги одобрявам (и мултрикратно вече ни правят проблеми и ненужна работа), но ми омръзна да споря.

Иначе в старата система на PHP бяхме леко дръпнати да въвеждаме rabbitmq, но със симфони бъндъла нещата стават доста изчистени и в момента това отваря доста възможности. Имаме доста неща, които са сравнително бавни за изпълнение и в момента лесно можем да ги делегираме към rabbitmq worker-и, вместо да караме потребителите да чакат сума време.

Малко омацахме темата с rabbitmq неща. Може да продължим на лично или ако сънчо не го мързи да екстрактне в нова тема.

Уж за по-опростеното сетъпване. До някъде е доста удобен, особено, когато става дума за сага, но в доста отношения е неконсистентен, когато се правят дефиници за producers и consumers.

Също по-подразбиране взима неймспейса + името на класа, за да създаде exchange-а, който винаги е fanout.

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

Тези простотии лично аз не ги одобрявам (и мултрикратно вече ни правят проблеми и ненужна работа), но ми омръзна да споря.

Иначе в старата система на PHP бяхме леко дръпнати да въвеждаме rabbitmq, но със симфони бъндъла нещата стават доста изчистени и в момента това отваря доста възможности. Имаме доста неща, които са сравнително бавни за изпълнение и в момента лесно можем да ги делегираме към rabbitmq worker-и, вместо да караме потребителите да чакат сума време.

Малко омацахме темата с rabbitmq неща. Може да продължим на лично или ако сънчо не го мързи да екстрактне в нова тема.

Цялата тая боза дето са ти я сипали колегите ми звучи като хайде да ползваме MediatoR, че така да вкараме CQRS архитектура. Как да е, булашик да има, проекти като лукум да се разпъват и мангизи да падат.
Съни бой ще направи обратното на това, което аз бих желал. Няма да разводняваме темата, малко от другия форум идвам и съм забравил, че тука има правила и банове.

Ами като цяло аз и още един колега сме "новобранците" в .НЕТ. Всички останали колеги са си .НЕТ-аджии, но са от старата школа като цяло на .NET Framework.

За новия продукт се остави на нас "новобранците" в .НЕТ да разучаваме какво да се ползва и какво не.

Като гледах имплементации на Clean Architecture все се ползваше MediatR и е много известена библиотека като се имплементира CQRS, за това я използвам и като цяло си ми харесва какво предоставя. Ако имаш друго предложение за това ще се радвам да чуя.

За MassTransit стана същата работа и там беше моя колега "новобранец" и реши, че ще е полезна за нас.

Естествено като повечето неща, с повече практика и по-обширен поглед над нещата се стига до заключение, че май все пак дадена библиотека може би не е толкова beneficial.

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

Но така де. Човек като сменя езици и рамки и се опитва да разбере какво ползват хората, за да не откриваме топлата вода. В PHP в това отношение се чувствам доста по-комфортно, заради по-дългия ми опит там.

Ако в момента мина на Java ще стане същото. Ще се разучава какво е модерно там и т.н.

Това мнение е било редактирано от relax4o на 12-08-2023, 23:04