Devs Hive
1.03K subscribers
18 photos
86 links
Для звʼязку пишіть @o_kazm

Розповідаю про сучасне ІТ, System Design і інженерний розвиток.
Download Telegram
Топ 3 нормальних Node.js фреймворка 🔥

Багато хто досі говорить про те, що backend потрібно писати на Express.js чи навіть Koa.js. Це круті рішення, але вони не є повноцінними фреймворками. По суті, це роутери, які вирішують тільки одну проблему - роутинг.

Для всього іншого доведеться будувати свої велосипеди, які скоріше всього, з часом перетворяться на технічний борг.

Тому доцільніше відразу вибирати фреймворк, який дозволить зосередитися на продукті, а не на тому, як прикрутити Dependency Injection в Express.js.

Ось список непоганих рішень, які перевірені часом і добре показують себе в production:

Nest.js - зараз це найпопулярніший фреймворк. Таке собі імпортозаміщєніє Java Spring у світі TypeScript.

Adonis.js - теж дуже круте рішення. Не такий популярний, як Nest.js, але також має розвинену екосистему і часто використовується в проді.

Serverless - якщо вам потрібен зрілий фреймворк для AWS Lambda, то кращого рішення ви не знайдете. Підходить тільки для serverless архітектури, тому використовується не так часто.

Я б ще додав Fastify, але як на мене, він підходить тільки для невеликих мікросервісів.

#nodejs
👍15
Що почитати по Backend?

Не так давно я відповідав на допис у LinkedIn, де запитували, що почитати по Backend-розробці. Я думаю, що буде круто поділитися цим і в TG, щоб воно не загубилося.

Загалом це практичні навички, і паралельно з теорією треба робити пет-проєкти, де можна буде пропустити все через руки тому основий фокус потрібно робити на практиці.

З теорії я б порадив наступні книги:

Clean Architecture (Robert C. Martin) - класика, яка дасть розуміння основ і того, як у теорії можна будувати системи.

Microservices Patterns (Chris Richardson) - як на мене, її можна сприймати як вступ у розподілені системи. Все описано доволі просто, із зануренням у деталі реалізації, що є великим плюсом для початківців.

Building Microservices (Sam Newman) - більш advanced-книга по розподілених системах. Висвітлює багато проблем, тому краще читати після того, як розібрався з основами в теорії і на практиці.

Designing Data-Intensive Applications (Martin Kleppmann) - цю книгу можна розглядати як вступ до даних у розподілених системах.

System Design Interview — An Insider’s Guide (Alex Xu) - хоч це і гайд по підготовці до інтервʼю, але там розглядаються різні проблеми, які розширять ваш кругозір і дадуть розуміння того, як можна вирішувати ті чи інші ситуації.

#microservices
🔥26👌2👀2👍1🥰1
Перемога підʼїхала🔥

Зʼявилась інформація того, що буде додано в Nest.js 12, який по ідеї мав би відбутись до кінця вересня.

Покращень тут цілий список і ось основні:
- Перехід з CommonJS на ESM. Це прям топчик
- Rspack замість webpack. Не знаю, що таке Rspack, але webpack вже давно пора викинути😁
- Перехід на Vitest. Це теж перемога, бо існуючі інструменти мʼяко кажучи застарілі
- Oxlint замість ESLint🔥🔥🔥

Загалом виглядає дуже потужно, так як основний мінус Nest.js був в тому що він сильно відстає від сучасних підходів.

Раджу почитати всі оновлення тут - https://trilon.io/blog/nestjs-12-is-coming

#news
9🔥9
Знайшов крутий репозиторій по ML💊

Мета цього репозиторію - просто й доступно пояснити, як працюють популярні алгоритми. Особисто мені буде цікаво розібратися з деякими алгоритмами, дотичними до LLM.

І ні - це не AI slop, бо репозиторій створений 9 років тому 😁

https://github.com/eriklindernoren/ML-From-Scratch

#ai
4👍1
Цікавий пост з каналу Мамкін Архітектор🔥

Суть в тому що Scarf, який був написаний на Haskell почали переносити на Python (добре хоч не на JS), по доволі очевидним як на мене причинам.

Найцікавіша з них - Haskell погано підходить для паралельної роботи великої кількості AI-агентів. І це наштовхує на певні роздуми про життєздатність різних «трушних інструментів» у сучасній розробці.

Під «трушними я маю на увазі технології, які часто обирають за їхню технічну правильність, навіть якщо вони менш популярні, мають меншу екосистему й ппц який високий поріг входу.

Як думаєте, чи почнуть поступово всі підлаштовувати свої технології та інструменти під AI?

Посилання на допис (там і оригінал знайдете) - https://t.me/mamkin_architect/661
3👍1
ІТ волонтерство і його вплив на карʼєру🚬

Ваші пет проєкти - це звісно добре, але вони про прокачку Hard Skills.

В ІТ велику роль грають Soft Skills і один з способів їх прокачати - доєднатись до проєкту, який робить щось хороше.

Звісно, ви можете попрацювати безкоштовно на чийсь бізнес, але волонтерство дасть вам цікаві знайомства, які вам допоможуть в подальшому розвитку.

Частіше всього - це набагато важливіше, якщо дивитись на горизонт в декілька років.

Цьому фото вже майже 10 років, я тут ще піздюк. Відкриваємо черговий філіал Code Club UA в одній з львівських бібліотек😁

#news
😁9👍52
Який database GUI ти використовуєш?

В спільноті доволі багато початківців в backend і frontend розробників, які його вивчають.

І я подумав, що скоріше за все ви зіштовхувались з питанням, а де нормально глянути базу даних 😁

Рішень багато, але я хочу порекомендувати інструмент, який використовую вже дуже давно - Table Plus.

Його основна перевага в тому що він окрім корисного функціоналу, має нормальний UI/UX.

Також, підтримує багато баз даних, як SQL так і NoSQL. Дуже зручно, коли в одній вкладці в тебе PostgreSQL, а в іншій Redis і не потрібно переключатись між апками.

Там є безкоштовна версія, яка цілком підходить для навчання.

А якщо купувати, то можна з кимось розшарити і взяти дешевше. В мене дружина бекендекиня (чи як там зараз правильно) і ми платимо за 2 seats акаунт з нормальною знижкою.

📎 - https://tableplus.com/

#databases
👍13
Підписаний я значить на таку платформу, як Nx

Деколи читаю, що там в них відбувається і думаю буде непогано її розшарити. Думаю, любителям страждати Monorepos сподобається.

В цілому тут є все, що потрібно для проєктів, які повністю на JS/TS. Ви можете створювати бібліотеки? перевикористовувати код як з бекенду, так і з фронтенду. Окрім цього, багато функціоналу для тестування і розгортання.

Але зворотня сторона медалі - це колосальний vendor lock-in.

Я б його не обирав для проєкту, бо не дуже зрозуміло як його масштабувати і скоріше за все згодом доведеться випилювати 😁

📎 - https://nx.dev/

#news
3👍1
Якщо вам сьогодні прийшов подібний рахунок від AWS, не панікуйте

Це АІ знову заміняє інженерів😁

Почитати про issue можна тут - https://health.aws.amazon.com/health/status

Прийшло моїй дружині і я мʼяко кажучи офігів😅😅😅

#news
😁14👏2
AWS Lambda тепер в S3 🔥

Тепер ваш код можна зберігати в контрольованому S3 storage, а не використовувати AWS managed bucket.

Що це дає?

- S3 стає єдиним джерелом правди для артефактів.
- Повний контроль над encryption, access policies, lifecycle rules і так далі.
- Швидше оновлення, через відсутність необхідності в копіюванні ZIP.
- Простий rollback, через версійність S3 bucket (просто відкочуєтесь до потрібної версії).

Варто зазначити, що працює воно тільки для функцій і layers, які розгортаються через ZIP. Якщо ви використовуєте container images, то для вас нічого не змінюється.

#aws
🔥7👍3
Трохи інтерактиву, щоб розбавити дописи чимось цікавим і пізнавальним 😁

Як пов'язані Elasticsearch та Apache Lucene?

A. Elasticsearch і Lucene - це конкуруючі search engines.

B. Elasticsearch - це distributed layer поверх Lucene.

C. Lucene - це distributed layer поверх Elasticsearch.

D. Elasticsearch - це нова версія Lucene, яка повністю замінила його.

Відповідь: B

Elasticsearch - це distributed layer поверх Lucene, який забезпечує координацію кластера, зовнішнє API, шардінг та майже миттєве оновлення індексу (near real-time).

Apache Lucene - це вбудована бібліотека, яка безпосередньо виконує індексування та пошук документів в окремих шардах.


#quiz
🔥8
Хто такий HTTP/3?

Про HTTP/3 поки пишуть не так багато, тому є сенс коротко розібрати, які проблеми вирішує нова версія протоколу.

Найперше, що варто розуміти: HTTP/3 працює поверх QUIC/UDP, а не TCP, як HTTP/1.1 та HTTP/2.

QUIC підтримує незалежні потоки даних, кожен із яких має власний порядок доставки. Завдяки цьому HTTP/3 вирішує одну з типових проблем TCP — head-of-line blocking.

Наприклад, браузер одночасно завантажує зображення, CSS і JavaScript. Якщо загубився пакет із частиною зображення, браузер чекатиме повторної доставки даних лише цього потоку. Потоки з CSS і JavaScript зможуть продовжити роботу.

Можна подумати, що в HTTP/2 це працює так само, бо в статтях на Medium (від наших братів з Індії) пишуть про паралельне завантаження і потоки. Але не все так просто.

Усі HTTP/2-потоки передаються через одне TCP-з’єднання і якщо один TCP-пакет загубився, наступні отримані дані не будуть передані браузеру, доки втрачений пакет не надійде повторно.

Тому в HTTP/2 втрата одного пакета може тимчасово заблокувати всі логічні потоки, а в HTTP/3 — лише той потік, до якого належать втрачені дані.

З опису вище, можна прикинути де він буде корисний:

- Мобільні застосунки де потрібно враховувати поганий інтернет.
- Медіасервіси.
- Сайти з великою кількістю ресурсів.

Шо там в Node.js?

В нашому болоті активно працюють над підтримкою QUIC тому при бажанні можна погратись увімкнувши його - https://nodejs.org/api/cli.html#--experimental-quic
👍142
Яка стратегія масштабування розподіляє дані між кількома екземплярами бази даних на основі вибраної колонки?
Anonymous Quiz
35%
Horizontal partitioning
9%
Read replicas
50%
Horizontal sharding
6%
Connection pool
🔥8
Ранкова зарядка😁

Який патерн допомагає уникнути повторної обробки одного й того самого повідомлення, якщо брокер доставив його кілька разів?
Anonymous Quiz
13%
Transactional Outbox
61%
Idempotent Consumer
16%
Dead Letter Queue
9%
Competing Consumers
Transactional Outbox

Хочу розповісти про один з реально корисних патернів, який спрощує життя при роботі з legacy системами.

Сучасне legacy - це не завжди стара система. AI вніс свої поправки в розуміння legacy і тепер це може бути відносно новий продукт, який важко розвивати і мінорні зміни можуть призвести до каскадного падіння всієї системи.

Які є варіанти роботи з такими системами?

1️⃣ Переписати з нуля 😁😁

Найочевидніше, що може прийти в голову - знести все і зробити по нормальному.

Але на практиці таке не працює через велику кількість нюансів і бізнес-аспектів, які не видно на поверхні тому зазвичай або виходить така сама какуля або проєкт згортається і приймається рішення розвивати існуючу систему.

2️⃣ Залишити як є і найняти більше розробників

Це робочий варіант, який часто використовують. Але тут є важливий нюанс - чим складніша система тим дорожче будуть коштувати розробники. При цьому технічний борг продовжуватиме рости і на довгостроковому горизонті вам все одно потрібно буде щось робити з системою.

3️⃣ Залишити legacy і паралельно створювати нову систему

Найбільш робочий варіант, суть якого полягає в тому щоб паралельно з legacy-системою розробляти нову систему, яка буде сумісна з поточною і поступово її замінить.
Тут багато підходів, патернів і набитих шишок, про які я буду писати в Telegram. Один з них - це Transactional Outbox.

Суть його в тому, щоб синхронізувати legacy і нову систему за допомогою подій, не ризикуючи втратити дані в момент їх передачі. Для цього буде використовуватися окрема таблиця (Outbox) де ми будемо зберігати інформацію про зміни в базі даних

Окрім цього, в нас буде окремий worker, який буде читати outbox таблицю і передавати події в брокер, який відправить їх в нову систему для синхронізації даних.

У спрощеному вигляді це працює так:

Legacy → таблиця Outbox → брокер → нова система.

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

Детальніше читай тут.

#microservices
8👍6
Трохи забив сайт через брак часу 😐🚬

Але бачу, що за останній місяць там зареєструвалося доволі багато людей, тому планую потроху його розвивати.

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

📎 - https://devs-hive.tech/interview-qa
18👍2
Що з наведеного можна використовувати для кешування результату SQL запиту?
Anonymous Quiz
25%
VIEW
8%
TRIGGER
41%
MATERIALIZED VIEW
26%
React.memo()
Code Review Graph (CRG)🔥🔥🔥

Натрапив на цікавий інструмент для code review, який будує структурний граф кодової бази і дає доступ AI через MCP.

Можна сказати, що це такий собі Obsidian для code review де описуються звʼязки між файлами, функціями, класами і так далі.

Скоріше за все для стартапчиків буде overhead, але для legacy кріпто казіно - це може бути дуже крутим інструментом.

Детально описувати не буду, бо вони заморочились і створили дуже гарний і зрозумілий README де все гарно розписано - https://github.com/tirth8205/code-review-graph
14👍1