Читаю тут деяких коментаторів і дивуюся. АЛООО!!! Це гра зроблена вашими співвітчизниками, настільки української гри раніше впринципі ще не виходило в світі, команда розробки пройшла через багато випробувань, щоб її випустити. Гра звісно не ідеальна, є мінуси, але казати, що гра не грабельна це якийсь сюр, особливо з останніми патчами. Особисто для мене, порівнюючи з плюсами гри, її мінуси просто ніщо. До того ж тут наче більшість розробників і щось багато з них чомусь не розуміє на скільки важко імплементовувати якісь механіки на рушії (фактично фреймворку) який є для команди новий, це перший проєкт з яким команда працює викортстовуючи його, при чому порівнюють з попереднім рушієм який був створений з 0 чисто під деякі механіки гри, по типу того ж A-Life. Підсумовуючи все сказане, плюсів у гри явно набагато більше, ніж мінусів, а наявні мінуси швидше всього не є чимось невиправним, з часом думаю все пофіксять

Ніщо не заважає мати багато команд на моноліті, якщо нормально спроектовані модулі і їх зони відповідальності

Те про що ви говорите є прикладом асиметричного навантаження, коли таке є, то модуль на який створюється це надмірне навантаження виносити в окремий сервіс. Коли ж асиметричного навантаження нема, то сенсу в мікросервісах мало

Особисто у моєму досвіді ніколи не бачив, щоб мікросервіси обирали за можливість створення зоопарку) тут навпаки можуть бути проблеми, що одна команда не зможе підмінити іншу якщо у різних сервісів будуть різні мови програмування.
На мою думку, моноліти сильно недооцінені, а мікросервіси переоцінені. Якщо застосовувати патерни і грамотне розділення відповідальності між модулями і абстракціями, то не буде ніяких проблем з розширенням і зміною такої апки, ну і можна буде перевіряти ті самі гіпотези, бо модулі апки автономні, але в той же момент ранаються в одному процесі. Якщо розробники не можуть написати моноліт без High Coupling то розділення на мікросервіси нічим їм не допоможе, просто розмазування лайна на більше шматків і площу.
На мою думку краще рухатися по дефолту з монолітом, окрім ситуацій коли на різні модулі є асиметричне навантаження, потрібна асинхронність певних фіч, або якщо моноліт вже на стільки великий, що його білд займає занадто багато часу; от тоді вже є сенс ділити його на сервіси (не плутати з мікросервісами), якщо цих умов нема, то мікросервіси створюють більше проблем, ніж допомагають

Чудова стаття!

Внє палітікі?

Тейк про Притулу, це щось від Радикальні? З чого ви взяли, що про продукт ніхто не чув в Україні?

Вже вдалося використати Drizzle на кількох проєктах, це просто космос, не потрібно ломати голову як написати певну SQL кверю на функціях ORM, звісно в документацію треба підглядати на початках, але швидко вчишся розуміти логіку як писати SQL квері на Drizzle. Також дуже радує, що все строго типізовано, і можна якщо в самому Drizzle не вистачає якихось SQL конструкцій по типу WHEN CASE, то можна просто завернути sql`` у функцію і воно все так само органічно виглядає, без шматків Raw SQL у TS. Prepeared Statements це взагалі кілер фіча. До речі про Prisma, з неї досить легко переїхати на Drizzle завдяки drizzle-prisma-generator, який конвертує схему Prisma в схему Drizzle, єдиний мінус, що не підтримуються мапінги нативних типів з Prisma Schema, але там на це вже висить PR. Ще щодо міграцій і схеми додам, що схема Prisma мені все ж подобається більше, бо вона лаконічніша, але завдяки своїм особливостям Drizzle, можна менеджити схему через Prisma, а квері робити через Drizzle, робив так на одному з проєктів

Щодо вбудованого кешу by-default плюсую, був на проєкті, де використовувалася ця ORM, і просто рвали з колегою волосся на голові не розуміючи чому виникає баг, аж потім зрозуміли що це через кеш, подумали ми на це в останню чергу, так як не підозрювали, що керування може бути увімкнене за замовчуванням. Я думаю, що ця ORM гарно підходить лише в якихось специфічних ситуаціях, де Unit of Work патерн дійсно потрібен, я б не використовував її як go to solution, навідмінну від божественного Drizzle)

Молодці, так тримати!

P.S. коли там вже Drizzle v 1.0?))

Думаю багато людей напише, про те, що як погано, що українська студія робить гру, події якої розгортаються у Москві, алеее, події розгортаються не просто в Москві, а в її руїнах)) у грі немає нічого проросійського. Ну і от уявімо ситуацію, якби події гри перенесли у Київ, от вам би було приємно бачити розвалений Київ в умовах повномасштабної війни, що триває? Мені б не було приємно це бачити

Щодо місця дії, то тут неоднозначно, типу події гри у розваленій Москві (мабуть мрія кожного українця)), а от якби події гри були скажімо у розваленому Києві, враховуючи війну.. ну таке собі

Категорично не погоджуюсь з цим підходом, можливо ви вирішуєте проблему падіння у рантаймі, але разом з тим створюється неймовірний простір для багів і якихось логічних помилок, коли апка наче працює, не викидає помилки але не виконує те, що від неї очікується. Ну і щодо скажімо аргументи функції, обов’язкові аргументи вони на те і обов’язкові, що вони необхідні для коректного виконання функції, припустимо у мене є функція, яка має відправляти емейл з певним контентом, її обов’язкові аргументи це емейл отримувача і його контент, і мене (як і тестувальника чи кінцевого користувача) взагалі не влаштує що помилки не було, але емейл не надіслався куди потрібно, якби була помилка, було б хоча б одразу зрозуміло, що щось пішло не так. Тому підхід «Fall Fast» є набагато більш дієвішим, ніж описаний у статті, цей підхід полягає у тому, що якщо у нас є якась некоректний стейт чи поведінка, ми викидаємо помилку, або взагалі крашимо апку, таким чином ми швидко можемо зрозуміти, що є проблема і її треба вирішувати, і по стек трейсу помилки, за умови коректно налаштованого логування, можна ще й одразу зрозуміти де вона виникла, а з підходом запропонованим у статті можна годинами ходити колами і розбиратися що пішло не так

Щодо спідрану, то це дивлячись скільки часу ви на гру витрачаєте) я наприклад пройшов на 3 кінцівки десь за 145 годин, виконував усі сайдквести, що бачив) особисто мені надмірне розтягування не дуже подобається, бо починаєш забувати про що були попередні сюжетні квести і нащо робиш те що робиш)

Пройшов на 3 кінцівки, особисто мені не траплялися прям критичні баги, чи софт локи, що доводилося б фіксити модами, найнеприємніша було це застрягання NPC у вхідних дверях у хаб, що доводилося оббігати, також спавн NPC там де вони не повинні це робити, ну і ще фрізи і шейдери дещо підбішували. На 4-ту кінцівку планую перепроходити з самого початку, поки зробив паузу, бо треба роботу робити) ну і хочу спершу дочекатися хоча б анонсу що собою будуть являти DLC, чи це продовження сюжету, чи це якісь великі сайдквести, додаткові закінчення чи може ще щось. Ну і дійсно хотілось би пограти у ту версію гри куди повернуть вирізаний контент)

Так, знаю що uWebSockets.js вміє робити кластер на воркер тредах, до речі тепер він це вміє робити і на MacOS, не впевнений щодо Windows. Штука то прикольна з однієї сторони, а з іншої у нас та сама проблема що з node:cluster чи PM2, що у нас скейлинг всередині контейнеру, а не поза ним і те що у нас один тред який відповідає за лоад балансинг буде навантажений більше за інші треди.

Так, про цю бібліотеку мало хто знає, але знаючі люди можуть інтегрувати у свої проєкти, показати на скільки бекенд апка може краще працювати і часто отримати премію за це) на жаль я не серед тих щасливчиків, але чув такі історії) Так чув що в Bun вона використовується під капотом, але як на мене в Node.js від неї толку більше, бо в Ноди більша екосистема.

Так, бачив ultimate-express, крута штука дійсно беквард компатібл з Express, навідміну від hyper-express, можливо вона дійсно зробить Express Great Again

так, його і мав на увазі під Raw SQL

так компанії у яких я працював спеціалізуються не лише на Node.js, було і багато спеціалістів на Java, Go, C#. Я спілкувався з архітектами які власне беруть участь у пре-сейлах, і якраз на більшість проєктів Node.js найкраще підходить за рахунок тайм-ту-маркету і інших її плюсів

перепрошую, але читаю те що ви пишете, і у мене виникають якісь сумніви, що ви брали участь в розробці проєктів зі складними фічами, якщо вважаєте, що динамічна типізація і GRASP легко роблять складні, комплексні фічі легкими. Якщо фіча комплексна, то і код буде комплексний, так, він може слідувати всім бест практісам по рідабіліті, GRASP та SOLID, але це на вирішує проблеми, що коду буде багато, що може бути якась комплексна взаємодія між модулями і сервісами, на те щоб вникнути в цю інфраструктуру потрібен час, що вже говорити коли треба вносити у неї зміни

можете ось глянути код мого пет проєкту, як на мене там код виглядає досить читабельно)
github.com/...​a-vuiko/fin-control-be-rs