Devs Hive

Сьогодні натрапив на твіт одного забутого Node.js фреймворка - Moleculer.

Загалом він дуже добре лягає на концепцію nanoservices. Але, на відміну від того ж Express.js, тут не потрібно писати власні велосипеди для transport, fault tolerance, discovery, tracing тощо.

З дуже приємного - наявність із коробки Circuit Breaker, Retry, Bulkhead та інших fault tolerance механізмів.

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

📎 - https://moleculer.services/

Знову поламали AWS🚬

Цікаво чи є кореляція з недавніми лейофами😁😁😁

Цікава новина для всіх хто цікавиться інвестиціями, будемо купувати на хаях?😄

До IPO звісно ще далеко, але перші кроки вже почались

📎 - https://www.anthropic.com/news/confidential-draft-s1-sec

Чому знання React, Angular і Vue не робить вас кращим розробником?

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

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

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

Суть допису така - зосереджуйтесь на реально важливих речах, від яких можна отримати вихлоп в вигляді 💸


П.С. Побачив в LinkedIn пост про порівняння React i Angular, на секундочку в 2026 році 😁

На додачу до допису про TDD хочу поділитися досвідом, який я колись отримав на одному проєкті. Це був досвід ще до AI, та й загалом у темні часи, які були увіковічені в треш-історіях ebanoe.it.

На одному з проєктів ми пробували запровадити BDD разом із популярною на той час бібліотекою Cucumber.js.

Ідея була дуже цікава, і загалом цей підхід багато чого спрощує та робить зв’язок із бізнесом тіснішим. Але ми вперлися в проблеми, і ця ідея заглохла. Переважно через те, що робота була через гал tру і нас розглядали суто як дешеву раб силу (суровий укр ринок). Та і в той час було важко отримати апрув навіть на звичайні тести, а тут - якесь незрозуміле BDD і Огірок.js.

З огляду на розвиток AI цей підхід може отримати друге дихання, адже писати тести стало набагато простіше й швидше, інженери набагато більше залучені в бізнес і BDD можна розглядати, як один з способів синхронізувати продукт і розробку навколо очікуваної поведінки системи, щоб тримати всіх "on the same page".

Хто не в курсі за BDD, дуже раджу ознайомитись🚬

Цікаво чи завезли реальних покращень🤞🚬

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

Наприклад, з бізнесової точки зору задача зрозуміла, і ви знаєте, як її імплементувати. Якщо це умовний API endpoint, то ви розумієте, які дані будете віддавати на фронтенд.

У такому випадку простіше в режимі Plan детально розжувати все для AI, після чого попросити його імплементувати тест, переконатися, що він відповідає вашим вимогам, і вже потім почати імплементацію.

Я вже давно використовую цей підхід, і він реально працює. Особливо корисно для складних flow, де, щоб протестувати все через умовний Swagger чи Postman, потрібно створити купу seeds.

Як на мене, для такого підходу, ідеальне поєднання - це e2e-тест + Testcontainers.

Оскільки я використовую свій акаунт у Cursor, то змушений трохи економити: якщо задача не суперскладна, використовую Opus 4.7 для планування, а Codex/Sonnet - для імплементації.

Згадав про хороший інструмент для симуляції проблем з мережею. По факту - це проксі, де ви можете додавати різні аномалії по типу timeouts, latency, обмеження body, обрив мережі і тд.

Toxyproxy - https://chaostoolkit.org/drivers/toxiproxy/

І назва в нього прикольна😁

Перемога? 👹

Microsoft скасовує ліцензії для Claude Code

В цілому я часто чую, що компанії ставлять низькі ліміти на AI і шукають способи зекономити. Це стосується всіх, починаючи від big tech, закінчуючи галерою перекупом.

Але всі ми знаємо, що vendor lock-in - це доволі жорстка штука. І якщо умовний Claude вже підсадив на свою голку, то оптимізувати витрати - задачка із зірочкою.

Дуже швидко про ACID, бо багато хто не до кінця розуміє, що воно таке. А це база, без якої важко зрозуміти болячки реляційних баз. Також ACID допомагає краще зрозуміти його протилежність у розподілених системах - BASE (як би дивно це не звучало).

Отже, ACID - це набір властивостей, які описують транзакцію.

1️⃣ Atomicity
Транзакція або виконується повністю (COMMIT), або не виконується взагалі (ROLLBACK).

2️⃣ Consistency
Після транзакції база має залишатися у валідному стані. Важливо розуміти, що валідний стан описується на рівні DB за допомогою інструментів, які перевіряють дані під час транзакцій: constraints, foreign keys, unique indexes, checks...

У реальному житті це завжди компроміс. Критичні правила краще залишати на рівні бази, а менш важливі валідації можна тримати на рівні application layer.

3️⃣ Isolation
Основна ідея, що транзакції не повинні заважати одна одній. Це теж компроміс, так як чим вищий рівень ізоляції тим менше аномалій при паралельних транзакціях, але менша паралельність.

Те що треба розуміти:
- Read Uncommitted
- Read Committed
- Repeatable Read
- Serializable

4️⃣ Durability
Якщо транзакція закомічена, база даних має гарантувати, що ці зміни були записані на диск.

Також, це часто запитують на інтервʼю тому про ACID я писав на сайті

Згадав про одну цікаву книжку, яка скрасить вашу поїздку в поїзді чи літаку📕

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

Також, непогано підійде для підготовки до system design interview і в цілому підніме рівень проходження інервʼю.

З найцікавішого, можна виділити:
- Fitness Functions
- Evolutionary Architecture Pitfalls and Antipatterns
- Architectural Coupling

З мінусів, це поверхневість книги, що в принципі не дивно, бо вона доволі тонка

оця варта уваги

+1 рекомендація. Я не читав, але @yurarrr поганого не порадить⬇️

Є дві пляшки книги

Вони написані дуже давно, і більшість розробників про них чули - це Чистий код і Чиста архітектура. Чи пережили вони випробування часом?

Як на мене, Чистий код - однозначно ні.

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

А от із книгою Чиста архітектура усе цікавіше.

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

Це завжди цінувалось набагато більше, ніж вміння писати код (за нього вже давно ніхто не платить).

В кого які думки з цього приводу?

Додав нове відео на канал 🔥

У ньому розповів про ідею індексів і про те, як вони прискорюють пошук. Також розібрав кілька типів індексів: B-Tree, Hash, Vector - і висвітлив основні підводні камені, які трапляються під час використання індексів.

📎 - https://youtu.be/gBauJAfvBSo?si=Or_FvIwzph9zOimJ

Чи треба розуміти Big O Notation?😱

Це доволі холіварна тема, але, як на мене, якщо ви Middle чи вище, то загальне розуміння Big O все ж потрібне. І ось чому.

Краще бачення системи
Ми щодня працюємо з різними інструментами: cache, message brokers, databases... Розуміння ефективності структур даних допомагає краще бачити, коли і яку структуру варто використовувати.

Співбесіди 😁
Big O часто питають у різних контекстах. Іноді просять оцінити складність рішення під час лайвкодингу, тому для інтервʼю з цим все одно доведеться розібратися на базовому рівні.

Ефективний код
Усі ми пишемо гівнокод - хоча з приходом AI, він став трохи кращим. Але іноді доводиться вирішувати не зовсім тривіальні задачі. Наприклад, паралельно обробити велику кількість даних.

У такому випадку від ефективності вашого коду може залежати, скільки машин доведеться запустити для цієї задачі і, відповідно, скільки ви за них заплатите.

Доречі, якось писав про це на сайті

Одна з причин чому я використовую JetBrains IDEs - це наявність всіх інструментів з коробки, без необхідності встановлювати плагіни сумнівної якості 😈

Поки інфоцигани продають курси з АІ непотребом, по типу N8N, LangChain запустили свою академію де можна безкоштовно розібратись з LangChain, LangGraph i LangSmith.

Здебільшого курси використовують Python SDK, але також є TS. Я вже давно слідкую за ними і TypeScript SDK дуже гарно розвивається і цілком production ready, що в рази спрощує інтеграцію АІ в продукти де використовується Node.js.

📎 - https://academy.langchain.com

Security в WEB

Так як рівень API чи Frontend - це зазвичай відповідальність інженерів, потрібно розуміти основні болячки в безпеці.

Як на мене, найкращий ресурс - це OWASP Top 10. Тут зібрані найбільш критичні вразливості на поточний період (останній репорт за 2025).

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

Попалось цікаве відео від каналу IBM, про RAG

В цілому, нічого нового чи магічного, але для тих хто тільки почав знайомитись з AI в розробці буде цікаво

📎 - https://www.youtube.com/watch?v=UabBYexBD4k