Тэхналогіі
Node.js Recipes
Тэхналогіі
24.04.202516:46
Команда Node.js опублікувала в блозі звіт про Test CI Security Incident
Тобто проблему вже вирішили, і команда розповідає деталі інциденту.
🔍 У чому була проблема?
У конфігурації CI/CD знайшли вразливість класу TOCTOU (Time-of-Check-Time-of-Use) — ситуація, коли перевірка коду відбувається до його фактичного виконання, і зловмисник встигає підмінити код між цими етапами. Нею скористались і заразили кілька серверів, на яких запускався CI/CD. Детальніше
⚖️ Цей інцидент добре ілюструє вічну дилему “Security vs. Developer Experience”.
Команда прямо заявляє:
Тобто для Node.js team це не “або-або”, а постійний процес пошуку балансу. Тому що при занадто жорсткій безпеці розробники перестають контриб’ютити, а при занадто м’якій – виникає ризик компрометації інфраструктури.
✅ Висновок:
Цей кейс — приклад відповідального, прозорого підходу до безпеки в опенсорс-екосистемі. Node.js не створює ілюзію ідеального захисту, а замість цього будує стійку систему, де можливі загрози передбачені, контрольовані і публічно обговорюються. У продуктовій розробці також варто використовувати ті ж принципи.
The reported issue did not impact the Node.js runtime and there is no risk to users of Node.js
Тобто проблему вже вирішили, і команда розповідає деталі інциденту.
🔍 У чому була проблема?
У конфігурації CI/CD знайшли вразливість класу TOCTOU (Time-of-Check-Time-of-Use) — ситуація, коли перевірка коду відбувається до його фактичного виконання, і зловмисник встигає підмінити код між цими етапами. Нею скористались і заразили кілька серверів, на яких запускався CI/CD. Детальніше
⚖️ Цей інцидент добре ілюструє вічну дилему “Security vs. Developer Experience”.
Команда прямо заявляє:
“Існуючий дизайн CI-системи враховує можливість компрометації, визнаючи необхідність балансу між безпекою та зручністю для розробників.”
Тобто для Node.js team це не “або-або”, а постійний процес пошуку балансу. Тому що при занадто жорсткій безпеці розробники перестають контриб’ютити, а при занадто м’якій – виникає ризик компрометації інфраструктури.
✅ Висновок:
Цей кейс — приклад відповідального, прозорого підходу до безпеки в опенсорс-екосистемі. Node.js не створює ілюзію ідеального захисту, а замість цього будує стійку систему, де можливі загрози передбачені, контрольовані і публічно обговорюються. У продуктовій розробці також варто використовувати ті ж принципи.
19.04.202515:09
Дві хронічні помилки, через які ваші улюблені фічі зникають із інструментів
1️⃣Не навчаєте колег користуватися улюбленими фічами
Дистанційна робота знизила популярність парного програмування. Хоча, парадоксально, з’явились чудові інструменти для цього — від Code With Me до Tuple.
Парне програмування — це можливість підгледіти круті патерни використання інструментів у колеги або, навпаки, показати йому фічу, яку обожнюєш сам.
🔁 Використовуйте цей формат частіше. Це інвестиція не лише у команду, а й у виживання ваших улюблених можливостей.
2️⃣Вимикаєте збір телеметрії
Багато сіньйорів вимикають збір телеметрії — і в IDE, і в інших інструментах. Але мова не про “злив даних для чергової LLM”, а про анонімну статистику використання фіч: що, коли і як часто використовується.
Вимикання збіру телеметрії не має сенсу:
✅ телеметрія не навантажує мережу або CPU;
✅ вона дозволяє інженерам, які розвивають інструменти, ухвалювати проактивні рішення на основі даних;
❌ без неї фічі зникають “бо ніхто не користується”. Хоча користуються — просто без сліду.
Цей пост — реакція на обговорення фічі modal commit, яку винесли в окремий плагін, і розмову з інженером JetBrains на Google Cloud Next’25. У них багато техборгу, і фічі, які виглядають “непопулярними” за телеметрією, вони змушені виносити або прибирати.
1️⃣Не навчаєте колег користуватися улюбленими фічами
Дистанційна робота знизила популярність парного програмування. Хоча, парадоксально, з’явились чудові інструменти для цього — від Code With Me до Tuple.
Парне програмування — це можливість підгледіти круті патерни використання інструментів у колеги або, навпаки, показати йому фічу, яку обожнюєш сам.
🔁 Використовуйте цей формат частіше. Це інвестиція не лише у команду, а й у виживання ваших улюблених можливостей.
2️⃣Вимикаєте збір телеметрії
Багато сіньйорів вимикають збір телеметрії — і в IDE, і в інших інструментах. Але мова не про “злив даних для чергової LLM”, а про анонімну статистику використання фіч: що, коли і як часто використовується.
Вимикання збіру телеметрії не має сенсу:
✅ телеметрія не навантажує мережу або CPU;
✅ вона дозволяє інженерам, які розвивають інструменти, ухвалювати проактивні рішення на основі даних;
❌ без неї фічі зникають “бо ніхто не користується”. Хоча користуються — просто без сліду.
Цей пост — реакція на обговорення фічі modal commit, яку винесли в окремий плагін, і розмову з інженером JetBrains на Google Cloud Next’25. У них багато техборгу, і фічі, які виглядають “непопулярними” за телеметрією, вони змушені виносити або прибирати.
15.04.202513:13
На цьому тижні OpenAI надала безкоштовний доступ до ChatGPT 4.1 через API. Інструменти для розробників, такі як Cursor, Windsurf та GitHub Copilot, вже інтегрували це. Рекомендую спробувати!
Якщо ви ще не працювали з жодним з цих інструментів, то у кожного з них є безкоштовний тариф щоб разпочати. Але я привіз з Google Cloud Next промо-код на місяць безкоштовного користування Windsurf Pro. Тому рекомендую спробувати саме його.
Вводити промокод необхідно на сторінці checkout у Stripe. Підписку можна відключити одразу. Потрібна дійсна кредитна картка.
Для тих, хто вже користується Windsurf, можна відключити підписку і включити її знову, використавши промокод.
🔗 Вебсайт windsurf.com
💰Промокод gcn2025
Якщо ви ще не працювали з жодним з цих інструментів, то у кожного з них є безкоштовний тариф щоб разпочати. Але я привіз з Google Cloud Next промо-код на місяць безкоштовного користування Windsurf Pro. Тому рекомендую спробувати саме його.
Вводити промокод необхідно на сторінці checkout у Stripe. Підписку можна відключити одразу. Потрібна дійсна кредитна картка.
Для тих, хто вже користується Windsurf, можна відключити підписку і включити її знову, використавши промокод.
🔗 Вебсайт windsurf.com
💰Промокод gcn2025
04.04.202515:50
1 квітня Amazon анонсував MCP Servers, і це була не жартівлива новина. По суті, це зручна заміна AWS CLI, яка значно прискорює процес розробки. Проєкт поки що перебуває у глибокій альфа-версії, але я вже протестував його разом із Claude Desktop та Cursor і хочу поділитися власними враженнями.
При використанні Cursor ефективність виявилась нижчою через те, що змішувалися код, архітектура та інфраструктура. Була ідея налаштувати кастомний режим, але я вирішив цього не робити і переключився на Claude Desktop. Там мені вдалося зосередитись виключно на одному рівні й успішно вирішити кілька робочих завдань, не покидаючи інтерфейсу Claude. Вони були пов’язані з Visual Prompt Engineering, але це зовсім інша історія.
Короткий огляд AWS MCP серверів:
🔸Core MCP Server – відповідає за підключення та конфігурацію інших MCP серверів, а також забезпечує логування. Ідея окремого сервера для керування всією екосистемою мені сподобалася.
🔸AWS CDK MCP Server – генерує інфраструктуру як код (IaC), дотримуючись рекомендацій AWS Well-Architected. Особисто не тестував, бо використовую Terraform, лише переглянув source code. CDK підтримує багато ресурсів, включно з Lambda Powertools. Планую повернутись до нього під час запуску наступного проєкту на serverless AWS, щоб додатково протестувати AWS Lambda Powertools (TypeScript).
🔸Nova Canvas MCP Server – дозволяє створювати зображення. Саме цей сервер я використовував найактивніше, щоб протестувати кілька гіпотез на моделі від AWS Nova Canvas.
🔸Cost Analysis MCP Server – створений для аналізу та оптимізації витрат на AWS. Конкретних завдань із ним ще не вирішував, перше враження не дуже. Проте сама ідея дуже корисна, і як тільки вийде стабільна версія, планую активно застосовувати його під час архітектурних рев'ю.
🔸Bedrock Knowledge Base Retrieval – сервер для роботи з Amazon Bedrock Knowledge Bases. Поки не маю проєктів із Bedrock KB, тому навіть не переглядав source code.
Корисні посилання:
🔗 Офіційний анонс на AWS Blog
🔗 AWS MCP Servers на GitHub
🔗 Для встановлення більшості Python-based MCP серверів потрібен uv (сучасний Python package manager)
Резюме:
MCP Servers — перспективні інструменти, які вже зараз варто вивчати та пробувати застосовувати у своїх проєктах, а цей AWS проєкт хороший вибір для цього.
При використанні Cursor ефективність виявилась нижчою через те, що змішувалися код, архітектура та інфраструктура. Була ідея налаштувати кастомний режим, але я вирішив цього не робити і переключився на Claude Desktop. Там мені вдалося зосередитись виключно на одному рівні й успішно вирішити кілька робочих завдань, не покидаючи інтерфейсу Claude. Вони були пов’язані з Visual Prompt Engineering, але це зовсім інша історія.
Короткий огляд AWS MCP серверів:
🔸Core MCP Server – відповідає за підключення та конфігурацію інших MCP серверів, а також забезпечує логування. Ідея окремого сервера для керування всією екосистемою мені сподобалася.
🔸AWS CDK MCP Server – генерує інфраструктуру як код (IaC), дотримуючись рекомендацій AWS Well-Architected. Особисто не тестував, бо використовую Terraform, лише переглянув source code. CDK підтримує багато ресурсів, включно з Lambda Powertools. Планую повернутись до нього під час запуску наступного проєкту на serverless AWS, щоб додатково протестувати AWS Lambda Powertools (TypeScript).
🔸Nova Canvas MCP Server – дозволяє створювати зображення. Саме цей сервер я використовував найактивніше, щоб протестувати кілька гіпотез на моделі від AWS Nova Canvas.
🔸Cost Analysis MCP Server – створений для аналізу та оптимізації витрат на AWS. Конкретних завдань із ним ще не вирішував, перше враження не дуже. Проте сама ідея дуже корисна, і як тільки вийде стабільна версія, планую активно застосовувати його під час архітектурних рев'ю.
🔸Bedrock Knowledge Base Retrieval – сервер для роботи з Amazon Bedrock Knowledge Bases. Поки не маю проєктів із Bedrock KB, тому навіть не переглядав source code.
Корисні посилання:
🔗 Офіційний анонс на AWS Blog
🔗 AWS MCP Servers на GitHub
🔗 Для встановлення більшості Python-based MCP серверів потрібен uv (сучасний Python package manager)
Резюме:
MCP Servers — перспективні інструменти, які вже зараз варто вивчати та пробувати застосовувати у своїх проєктах, а цей AWS проєкт хороший вибір для цього.
14.03.202516:14
Anders Hejlsberg (автор TypeScript) та Matt Pocock (автор TypeScript) зараз у прямому ефірі обговорюють TypeScript’s Go Rewrite Port
Рекомендую послухати, а також спробувати задати своє питання. А раптом його обговорять?
https://www.youtube.com/watch?v=NrEW7F2WCNA
Рекомендую послухати, а також спробувати задати своє питання. А раптом його обговорять?
https://www.youtube.com/watch?v=NrEW7F2WCNA
10.03.202515:22
Що повинен знати Node.js розробник у 2025-Q1?
У вересні минулого року я висловлював свою думку Що має знати Senior Node.js Developer. Зараз я спробував зробити аналіз на основі зрізу усіх українських вакансій. Для цього я звернувся до знайомих з DOU. Мене познайомили з Оксаною Лобко. Саме вона той надзвичайно продуктивний інженер, що створював Джинні у 2017-2021. Зараз вона працює над своїм проєктом JobNote.ai та part-time допомагає у DOU.
Оксана надала агреговані дані про вакансіям з українського ринку. JobNote парсить вакансії на сайтах Dou, Джинні та recruitika. Ось так виглядає зріз даних для Node.js: https://jobnote.ai/skills/Node.js/
Прокоментую, що там таке:
– Cеред даних є як чисті Node.js розробники, так і FullStack.
– Title визначається за потрібними роками досвіду. Junior (0,1), middle (2,3,4), senior (>=5).
– Популярність технології визначається кількістю вакансій, де вона вказується як вимога.
– У рамках цього аналізу дані salary/application per job я відкинув
Для зручності аналізу я перейшов від абсолютних показників до відносних. Отже, що нам показують дані?
Що стабільно потрібно? TypeScript, NestJS, React та бази даних стабільно затребувані незалежно від рівня:
- TypeScript – є у 70% вакансій незалежно від рівня.
- NestJS – у 40% вакансій. Express.js/Fastify/etc майже не зустрічаються.
- PostgreSQL – у 50% вакансій.
- MongoDB – у 30% вакансій.
- MySQL – 20%, SQL – 20%, NoSQL – 15%.
- Redis – 25% (але для Junior трапляється рідше).
- React – у 40% вакансій, Next.js/HTML/CSS – у 10%.
Що менше вимагають з розвитком? Очевидно, що певні знання стають само собою зрозумілими:
- JavaScript – важливий для 70% Junior, але для Middle/Senior це знижується до 40%.
- API – 50% для Junior, 40% для Middle та 30% для Senior.
- Git – 30% для Junior, 20% для Middle і Senior.
Що стає актуальніше з розвитком? Явно зростає попит на Cloud Native
- AWS – Junior (35%), Middle (40%), Senior (50%).
- CI/CD – Junior (10%), Middle (20%), Senior (27%).
- Docker – Junior (23%), Middle (28%), Senior (33%).
- Kubernetes – Junior (10%), Middle (12%), Senior (24%).
Топ-3 хмарних провайдерів:
- AWS – Junior (35%), Middle (40%), Senior (50%)
- Google Cloud – Junior (5%), Middle (8%), Senior (15%).
- Azure – Junior (?), Middle (7%), Senior (12%).
Окремо виділю зростання попиту на GraphQL
- GraphQL – Junior (6%), Middle (15%), Senior (18%)
Чого ми не бачимо у вакансіях?
LLM/AI/Agents/etc. Я очікував побачити це у вакансіях у 2025-Q1
Воно ще занадто нове, щоб бізнес розумів, як це інтегрувати в існуючі технічні та бізнесові процеси.
Висновки
Можливо, я упереджений, тому дані лише підтвердили мої припущення:
1. У 2025 Node.js — Boring Technology
2. На ринку найбільше затребувані Node.js розробники, які знають TypeScript, NestJS, React та CloudNative (AWS/K8s/etc).
3. Використовувати ринок, як джерело правди, що варто вивчати, можна тільки до middle рівня. На senior/senior+ потрібно самостійно складати план подальшого розвитку.
У вересні минулого року я висловлював свою думку Що має знати Senior Node.js Developer. Зараз я спробував зробити аналіз на основі зрізу усіх українських вакансій. Для цього я звернувся до знайомих з DOU. Мене познайомили з Оксаною Лобко. Саме вона той надзвичайно продуктивний інженер, що створював Джинні у 2017-2021. Зараз вона працює над своїм проєктом JobNote.ai та part-time допомагає у DOU.
Оксана надала агреговані дані про вакансіям з українського ринку. JobNote парсить вакансії на сайтах Dou, Джинні та recruitika. Ось так виглядає зріз даних для Node.js: https://jobnote.ai/skills/Node.js/
Прокоментую, що там таке:
– Cеред даних є як чисті Node.js розробники, так і FullStack.
– Title визначається за потрібними роками досвіду. Junior (0,1), middle (2,3,4), senior (>=5).
– Популярність технології визначається кількістю вакансій, де вона вказується як вимога.
– У рамках цього аналізу дані salary/application per job я відкинув
Для зручності аналізу я перейшов від абсолютних показників до відносних. Отже, що нам показують дані?
Що стабільно потрібно? TypeScript, NestJS, React та бази даних стабільно затребувані незалежно від рівня:
- TypeScript – є у 70% вакансій незалежно від рівня.
- NestJS – у 40% вакансій. Express.js/Fastify/etc майже не зустрічаються.
- PostgreSQL – у 50% вакансій.
- MongoDB – у 30% вакансій.
- MySQL – 20%, SQL – 20%, NoSQL – 15%.
- Redis – 25% (але для Junior трапляється рідше).
- React – у 40% вакансій, Next.js/HTML/CSS – у 10%.
Що менше вимагають з розвитком? Очевидно, що певні знання стають само собою зрозумілими:
- JavaScript – важливий для 70% Junior, але для Middle/Senior це знижується до 40%.
- API – 50% для Junior, 40% для Middle та 30% для Senior.
- Git – 30% для Junior, 20% для Middle і Senior.
Що стає актуальніше з розвитком? Явно зростає попит на Cloud Native
- AWS – Junior (35%), Middle (40%), Senior (50%).
- CI/CD – Junior (10%), Middle (20%), Senior (27%).
- Docker – Junior (23%), Middle (28%), Senior (33%).
- Kubernetes – Junior (10%), Middle (12%), Senior (24%).
Топ-3 хмарних провайдерів:
- AWS – Junior (35%), Middle (40%), Senior (50%)
- Google Cloud – Junior (5%), Middle (8%), Senior (15%).
- Azure – Junior (?), Middle (7%), Senior (12%).
Окремо виділю зростання попиту на GraphQL
- GraphQL – Junior (6%), Middle (15%), Senior (18%)
Чого ми не бачимо у вакансіях?
LLM/AI/Agents/etc. Я очікував побачити це у вакансіях у 2025-Q1
Воно ще занадто нове, щоб бізнес розумів, як це інтегрувати в існуючі технічні та бізнесові процеси.
Висновки
Можливо, я упереджений, тому дані лише підтвердили мої припущення:
1. У 2025 Node.js — Boring Technology
2. На ринку найбільше затребувані Node.js розробники, які знають TypeScript, NestJS, React та CloudNative (AWS/K8s/etc).
3. Використовувати ринок, як джерело правди, що варто вивчати, можна тільки до middle рівня. На senior/senior+ потрібно самостійно складати план подальшого розвитку.
23.04.202515:24
🚀 Вийшов реліз Node.js v22.15.0
#nodejs_api
У цьому мінорному оновленні є два важливі моменти, на які варто звернути увагу.
1️⃣ Оновлення бази часових поясів: tzdata 2024b → 2025a
Деталі змін у реліз-нотах tzdata 2025a.
Якщо ваш застосунок має бізнес-логіку, що залежить від таймзон, це оновлення може стати breaking change. Щоб уникнути подібних ризиків у майбутньому, краще використовувати system-ICU, щоб оновлювати таймзони незалежно від оновлень Node.js.
2️⃣ Зʼявився новий метод process.execve() — системний виклик, який повністю замінює поточний процес на новий, зберігаючи той самий PID. Приклад:
Що це означає для Node.js розробників?
🐳 Мінімалістичний init-процес на JS у Docker-контейнерах: наприклад, можна спочатку отримати секрети з AWS Secrets Manager, а потім запускати основну програму, як треба по 12 Factor.
🔁 Hot-reload без втрати PID: перезапуск застосунку без його зупинки — актуально для IoT-пристроїв або embedded-систем.
⚠️ Новий вектор атак: тепер можливе підміщення логіки без зміни PID, що вимагає додаткової уваги до безпеки.
#nodejs_api
У цьому мінорному оновленні є два важливі моменти, на які варто звернути увагу.
1️⃣ Оновлення бази часових поясів: tzdata 2024b → 2025a
Деталі змін у реліз-нотах tzdata 2025a.
Якщо ваш застосунок має бізнес-логіку, що залежить від таймзон, це оновлення може стати breaking change. Щоб уникнути подібних ризиків у майбутньому, краще використовувати system-ICU, щоб оновлювати таймзони незалежно від оновлень Node.js.
2️⃣ Зʼявився новий метод process.execve() — системний виклик, який повністю замінює поточний процес на новий, зберігаючи той самий PID. Приклад:
console.log('Before execve pid:', process.pid);
try {
process.execve('/bin/sh', ['sh', '-c', 'echo After execve pid: $$']);
} catch (err) {
console.error('execve failed:', err);
}Що це означає для Node.js розробників?
🐳 Мінімалістичний init-процес на JS у Docker-контейнерах: наприклад, можна спочатку отримати секрети з AWS Secrets Manager, а потім запускати основну програму, як треба по 12 Factor.
🔁 Hot-reload без втрати PID: перезапуск застосунку без його зупинки — актуально для IoT-пристроїв або embedded-систем.
⚠️ Новий вектор атак: тепер можливе підміщення логіки без зміни PID, що вимагає додаткової уваги до безпеки.
18.04.202516:31
Я вирішив підтримати Діму Малєєва та Влада Кампова та створив свій профіль на mentor.sh
Я оформив як послуги для менті те, чим вже давно займаюся як Fractional CTO для компаній.
1️⃣ Mock Hiring Process – Готуємося до реальних інтерв’ю
У 2025 році як в Україні, так і у світі, кандидатів більше, ніж вакансій. Тестове завдання стало стандартним етапом ще до першої розмови. Для компаній я:
– складаю тестове завдання,
– перевіряю його,
– а вже потім проводжу технічне інтерв’ю.
Для менті це оформлено як імітація реального процесу найму:
– Ви отримуєте тестове завдання відповідно до вашого рівня та спеціалізації;
– Проходите годинне технічне інтерв’ю;
– Отримуєте детальну зворотну відповідь.
Послуга на mentor.sh називається Hourly Session і коштує $200, підходить для ролей:
– Cloud Engineer (Node.js + Cloud Native),
– Node.js Developer (NestJS),
– Fullstack Developer (NestJS + Next.js),
– Frontend Developer (Next.js).
Технології обрані відповідно до актуального попиту на ринку.
2️⃣ Learning by doing – Менторство через практику
Те, що я називаю технічним наглядом у компаніях, я оформив у формат для менті: “Get hands-on experience by building real-world skills with a new fullstack web project every two weeks.”
Як це працює:
– Аналізуємо вимоги до продукту або фічі,
– Обираємо технологічний стек (з PoC),
– Проектуємо архітектуру,
– Реалізуємо рішення,
– В кінці кожного циклу ви отримуєте фідбек + еталонне рішення.
Для цього є два дзвінки на місяць зі мною - обговорюємо результати, робимо новий крок.
Створенно для Fullstack-інженерів, або тих, хто рухається у цей бік. Вартість — $250/місяць.
Я оформив як послуги для менті те, чим вже давно займаюся як Fractional CTO для компаній.
1️⃣ Mock Hiring Process – Готуємося до реальних інтерв’ю
У 2025 році як в Україні, так і у світі, кандидатів більше, ніж вакансій. Тестове завдання стало стандартним етапом ще до першої розмови. Для компаній я:
– складаю тестове завдання,
– перевіряю його,
– а вже потім проводжу технічне інтерв’ю.
Для менті це оформлено як імітація реального процесу найму:
– Ви отримуєте тестове завдання відповідно до вашого рівня та спеціалізації;
– Проходите годинне технічне інтерв’ю;
– Отримуєте детальну зворотну відповідь.
Послуга на mentor.sh називається Hourly Session і коштує $200, підходить для ролей:
– Cloud Engineer (Node.js + Cloud Native),
– Node.js Developer (NestJS),
– Fullstack Developer (NestJS + Next.js),
– Frontend Developer (Next.js).
Технології обрані відповідно до актуального попиту на ринку.
2️⃣ Learning by doing – Менторство через практику
Те, що я називаю технічним наглядом у компаніях, я оформив у формат для менті: “Get hands-on experience by building real-world skills with a new fullstack web project every two weeks.”
Як це працює:
– Аналізуємо вимоги до продукту або фічі,
– Обираємо технологічний стек (з PoC),
– Проектуємо архітектуру,
– Реалізуємо рішення,
– В кінці кожного циклу ви отримуєте фідбек + еталонне рішення.
Для цього є два дзвінки на місяць зі мною - обговорюємо результати, робимо новий крок.
Створенно для Fullstack-інженерів, або тих, хто рухається у цей бік. Вартість — $250/місяць.
11.04.202506:03
На сьогодні Model Context Protocol (MCP) від Anthropic є де-факто стандартом для передачі структурованого контексту в LLM. Більшість сучасних інструментів та сервісів вже впроваджують або анонсують підтримку MCP.
На цьому тлі починає формуватись нова конкуренція — за протокол взаємодії між агентами. Цього тижня Google анонсував Agent2Agent (A2A) Protocol, який має забезпечити повноцінну взаємодію агентів у складних корпоративних середовищах з ізольованими системами та даними. На ринку вже є альтернативи, зокрема Agent Communication Protocol від IBM / LF Projects, і цілком можливо, що з’являться нові гравці.
Хто саме отримає статус індустріального стандарту — покаже час. Бо ключове тут не в тому, яка специфікація краща, а наскільки широко вона буде інтегрована у фреймворки, інструменти та робочі процеси розробників.
image by Matt Pocock
На цьому тлі починає формуватись нова конкуренція — за протокол взаємодії між агентами. Цього тижня Google анонсував Agent2Agent (A2A) Protocol, який має забезпечити повноцінну взаємодію агентів у складних корпоративних середовищах з ізольованими системами та даними. На ринку вже є альтернативи, зокрема Agent Communication Protocol від IBM / LF Projects, і цілком можливо, що з’являться нові гравці.
Хто саме отримає статус індустріального стандарту — покаже час. Бо ключове тут не в тому, яка специфікація краща, а наскільки широко вона буде інтегрована у фреймворки, інструменти та робочі процеси розробників.
image by Matt Pocock
02.04.202517:14
Використання AI інструментів (ChatGPT, GitHub Copilot, Cursor, etc) створює проблему необхідності ручного копіювання деталей контексту з одного інструмента в інший. Конкретний приклад: копіювання деталей дизайну з Figma у вашу IDE для реалізації. Model Context Protocol (MCP) чудово вирішує цю проблему.
Тому, якщо у процесі вашої розробки не використовується жодного MCP сервера, то настійно рекомендую почати це виправляти.
Ось три посилання, щоб дізнатися, що таке MCP:
- https://modelcontextprotocol.io/
- https://addyo.substack.com/p/mcp-what-it-is-and-why-it-matters
- https://www.aihero.dev/model-context-protocol-tutorial
Ось дві ключові MCP новини, які потрібно знати сьогодні:
- OpenAI буде підтримувати MCP у своїх продуктах. https://x.com/sama/status/1904957253456941061
- Вийшла нова версія MCP specification з підтримкою OAuth 2.1. https://spec.modelcontextprotocol.io/specification/2025-03-26/changelog/
Та ось ще один протокол, який, можливо, стане стандартом:
- Agent Communication Protocol ACP – https://docs.beeai.dev/acp/alpha/introduction
Тому, якщо у процесі вашої розробки не використовується жодного MCP сервера, то настійно рекомендую почати це виправляти.
Ось три посилання, щоб дізнатися, що таке MCP:
- https://modelcontextprotocol.io/
- https://addyo.substack.com/p/mcp-what-it-is-and-why-it-matters
- https://www.aihero.dev/model-context-protocol-tutorial
Ось дві ключові MCP новини, які потрібно знати сьогодні:
- OpenAI буде підтримувати MCP у своїх продуктах. https://x.com/sama/status/1904957253456941061
- Вийшла нова версія MCP specification з підтримкою OAuth 2.1. https://spec.modelcontextprotocol.io/specification/2025-03-26/changelog/
Та ось ще один протокол, який, можливо, стане стандартом:
- Agent Communication Protocol ACP – https://docs.beeai.dev/acp/alpha/introduction
14.03.202513:34
Хочу нагадати вам, що Alpine, найпопулярніша ОС для докеризації Node.js, також має релізний цикл. У версії 3.18 він завершиться менше, ніж через 2 місяці.
Чому я про це згадав і вирішив поділитися з вами? Бо GitHub Copilot, який в мене налаштуваний вказувати точні версії, згенерував мені ось такий перший рядок у Dockerfile:
Класно, що він встановив версію Alpine. Це потрібно робити. На жаль, у Copilot немає доступу до актуальних версій. У цьому міг би допомогти, якийсь MCP сервер, але це вже зовсім інша історія.
Чому я про це згадав і вирішив поділитися з вами? Бо GitHub Copilot, який в мене налаштуваний вказувати точні версії, згенерував мені ось такий перший рядок у Dockerfile:
FROM node:20.10.0-alpine3.18Класно, що він встановив версію Alpine. Це потрібно робити. На жаль, у Copilot немає доступу до актуальних версій. У цьому міг би допомогти, якийсь MCP сервер, але це вже зовсім інша історія.
07.03.202512:02
🤩🙌 Зустрічайте останнє відео з конференції React+ fwdays'24!
👨💻 Доповідь: "Effortless API Integration: SDK Generation as Best Practise" від Nikita Galkin
🎙️ Опис: «Many developers create a separate layer for working with APIs, but Nikita believes that this approach is inefficient — it is better to generate code from your API contract. The talk will cover the following topics: how does SDK differ from API, and why is SDK preferable for development? How can you automatically generate an SDK for Swagger and GraphQL? What should you do if you don’t have an API contract? And finally, why is it important for backend developers to understand React? The talk will help optimize development processes and simplify team interactions, making working with APIs more predictable and convenient».
🗣️ Мова – англійська
Дивіться відео на нашому новому каналі Fwdays Global та не забудьте підписатись! ➡️ https://youtu.be/bjp5Poutb7w?si=nCGJUcF2260EI07f
👨💻 Доповідь: "Effortless API Integration: SDK Generation as Best Practise" від Nikita Galkin
🎙️ Опис: «Many developers create a separate layer for working with APIs, but Nikita believes that this approach is inefficient — it is better to generate code from your API contract. The talk will cover the following topics: how does SDK differ from API, and why is SDK preferable for development? How can you automatically generate an SDK for Swagger and GraphQL? What should you do if you don’t have an API contract? And finally, why is it important for backend developers to understand React? The talk will help optimize development processes and simplify team interactions, making working with APIs more predictable and convenient».
🗣️ Мова – англійська
Дивіться відео на нашому новому каналі Fwdays Global та не забудьте підписатись! ➡️ https://youtu.be/bjp5Poutb7w?si=nCGJUcF2260EI07f
21.04.202516:50
Переглядаючи новини за минулий тиждень, я побачив цікавий момент, пов’язаний із інструментами на основі AI. OpenAI веде переговори щодо придбання Windsurf. Оцінка – 3 мільярди доларів.
Якщо угода відбудеться, що це означатиме для нас, як для розробників? Посилення конкуренції в інструментах для розробників, включно з потенційною зміною лідера. Мій довгостроковий прогноз щодо лідера довгий час залишався незмінним: VS Code + GitHub Copilot. Ця команда випускає функції повільніше, але робить це якісніше та з кращим користувацьким досвідом.
Різниця між конкуренцією Microsoft проти стартапів (на кшталт Cursor, Windsurf тощо) і конкуренцією Microsoft проти OpenAI буде суттєвою. Попереду – боротьба екосистем. Тому нагадаю собі й вам також:
Якщо угода відбудеться, що це означатиме для нас, як для розробників? Посилення конкуренції в інструментах для розробників, включно з потенційною зміною лідера. Мій довгостроковий прогноз щодо лідера довгий час залишався незмінним: VS Code + GitHub Copilot. Ця команда випускає функції повільніше, але робить це якісніше та з кращим користувацьким досвідом.
Різниця між конкуренцією Microsoft проти стартапів (на кшталт Cursor, Windsurf тощо) і конкуренцією Microsoft проти OpenAI буде суттєвою. Попереду – боротьба екосистем. Тому нагадаю собі й вам також:
Ми обираємо не один інструмент або фреймворк, а цілу екосистему та спільнотуsource
17.04.202515:25
Давно не проводив #like_and_share. Мета гри - поділитися своїм досвідом та дізнатися про досвід інших учасників. Правила:
1. Публікація в каналі визначає тему. Сьогодні це MCP servers.
2. У коментарях кожен може залишити посилання на MCP server i коротко описати, чим цей сервер корисний у повсякденній розробці.
3. Учасники голосують, використовуючи лайки. Не ставте негативні лайки, бо вони також зараховуються як позитивні.
4. У понеділок ми підведемо підсумки на YouTube-стрімі, де я зроблю огляд представлених MCP серверів і тих, які використовую я. Переможець отримає 12-місячну персональну підписку на будь-яке IDE від JetBrains.
1. Публікація в каналі визначає тему. Сьогодні це MCP servers.
2. У коментарях кожен може залишити посилання на MCP server i коротко описати, чим цей сервер корисний у повсякденній розробці.
3. Учасники голосують, використовуючи лайки. Не ставте негативні лайки, бо вони також зараховуються як позитивні.
4. У понеділок ми підведемо підсумки на YouTube-стрімі, де я зроблю огляд представлених MCP серверів і тих, які використовую я. Переможець отримає 12-місячну персональну підписку на будь-яке IDE від JetBrains.
09.04.202514:01
Мене там знову запитують про
Якщо ви фреймворк-розробник, а не інженер, то рано чи пізно вас можуть скоротити. Інженери ж вивчать нові інструменти і залишаться потрібними для бізнесу.
Як зрозуміти, ви інженер чи розробник?
⏳Подивіться, скільки часу ви витрачаєте безпосередньо на написання коду.
Інженер витрачає час, щоб зрозуміти, що потрібно зробити, навіщо це робити, як це декомпозувати, як це алгоритмізувати і мало часу на написання коду.
⚙️Подивіться на ваш технічний стек, як часто він змінюється.
Інженери беруть інструменти, що підходять під задачу, а не обирають задачі під ті інструменти, з якими вони звикли працювати.
🆕Подивіться на те, що ви робите.
Якщо це тисячна форма авторизації чи чергове казино, то навряд чи там є якась інженерна новизна.
На завершення поділюся відео з Las Vegas Sphere. Там Учора Google показав, як вони створюють технологію для адаптації старих фільмів під сферичні екрани. Відео не передає і десятої частини вражень. Інженерні задачі, які їм довелося вирішувати, значно складніші, ніж просто розфарбувати чорно-біле кіно чи підвищити якість зображення.
Загальний тренд це впровадження «АІ як помічника» для збільшення делівері і немає тенденції до зменшення кількості девелоперів?
Якщо ви фреймворк-розробник, а не інженер, то рано чи пізно вас можуть скоротити. Інженери ж вивчать нові інструменти і залишаться потрібними для бізнесу.
Як зрозуміти, ви інженер чи розробник?
⏳Подивіться, скільки часу ви витрачаєте безпосередньо на написання коду.
Інженер витрачає час, щоб зрозуміти, що потрібно зробити, навіщо це робити, як це декомпозувати, як це алгоритмізувати і мало часу на написання коду.
⚙️Подивіться на ваш технічний стек, як часто він змінюється.
Інженери беруть інструменти, що підходять під задачу, а не обирають задачі під ті інструменти, з якими вони звикли працювати.
🆕Подивіться на те, що ви робите.
Якщо це тисячна форма авторизації чи чергове казино, то навряд чи там є якась інженерна новизна.
На завершення поділюся відео з Las Vegas Sphere. Там Учора Google показав, як вони створюють технологію для адаптації старих фільмів під сферичні екрани. Відео не передає і десятої частини вражень. Інженерні задачі, які їм довелося вирішувати, значно складніші, ніж просто розфарбувати чорно-біле кіно чи підвищити якість зображення.
01.04.202519:18
Мене в особистих повідомленнях запитали:
Ця тема цікавить багатьох, тому відповідаю публічно.
Про фріланс-платформи:
Щоб досягти успіху на платформах на кшталт Fiverr, Toptal чи Upwork, потрібно мати дві речі:
👉 Чітка спеціалізація: підтверджений досвід у конкретній сфері, наприклад, розробка сайтів у певній ніші, створення 3D-анімації, налаштування веб-аналітики тощо. Важливо чітко представляти цю спеціалізацію як на платформі, так і на власному сайті чи в соцмережах.
👉Репутація/рейтинг: історія успішно виконаних замовлень, відгуки та рекомендації від клієнтів.
Розвивати спеціалізацію та репутацію одночасно важко. Якщо спеціалізації немає, краще спочатку здобути її на власних проектах чи через замовлення знайомих. Інакше ви ризикуєте витратити час на безрезультатні пошуки клієнтів.
Фріланс має свою особливость. Це не довстроково, тому що:
👉 Або ви залишаєте цю справу через брак замовлень чи складнощі;
👉 Або знаходите постійних клієнтів і перестаєте активно шукати нових. Просто працюю з постійними клієнтами на прямих контрактах без фрілансу
👉 Або той 0.1% намагається масштабуватись, наймаючи працівників і, по суті, створюючи бізнес.
Про як обирати компанію для роботи:
Зараз ринок праці належить роботодавцям, тобто в працівників не так багато вибору. Проте, нагадаю
⚠️Працюйте в тих компаніях, де ваша цінність на ринку зростатиме завдяки або технічному стеку, або перспективному бізнес-домену.
Для оцінки перспективності домену можна скористатися ChatGPT у режимі DeepResearch і визначити, чи збільшуються витрати кінцевих клієнтів у конкретній ніші. Наприклад, український стартап OnlyMonster.ai автоматизує процеси для OnlyFans-індустрії, яка зараз швидко зростає.
Щодо технічного стеку, звертайте увагу на компанії, що використовують сучасні технології: Cloud Native, AI, Data-driven рішення тощо.
…Останні 7-8 років я працював в одній фірмі, невелика інтернет студія…
Хотів би запитати вашу думку:
На які компанії зараз варто звернути увагу?
Що ви думаєте про фріланс-платформи типу Fiverr, Toptal, Upwork? Чи варто пробувати та які є плюси/мінуси?
Ця тема цікавить багатьох, тому відповідаю публічно.
Про фріланс-платформи:
Щоб досягти успіху на платформах на кшталт Fiverr, Toptal чи Upwork, потрібно мати дві речі:
👉 Чітка спеціалізація: підтверджений досвід у конкретній сфері, наприклад, розробка сайтів у певній ніші, створення 3D-анімації, налаштування веб-аналітики тощо. Важливо чітко представляти цю спеціалізацію як на платформі, так і на власному сайті чи в соцмережах.
👉Репутація/рейтинг: історія успішно виконаних замовлень, відгуки та рекомендації від клієнтів.
Розвивати спеціалізацію та репутацію одночасно важко. Якщо спеціалізації немає, краще спочатку здобути її на власних проектах чи через замовлення знайомих. Інакше ви ризикуєте витратити час на безрезультатні пошуки клієнтів.
Фріланс має свою особливость. Це не довстроково, тому що:
👉 Або ви залишаєте цю справу через брак замовлень чи складнощі;
👉 Або знаходите постійних клієнтів і перестаєте активно шукати нових. Просто працюю з постійними клієнтами на прямих контрактах без фрілансу
👉 Або той 0.1% намагається масштабуватись, наймаючи працівників і, по суті, створюючи бізнес.
Про як обирати компанію для роботи:
Зараз ринок праці належить роботодавцям, тобто в працівників не так багато вибору. Проте, нагадаю
⚠️Працюйте в тих компаніях, де ваша цінність на ринку зростатиме завдяки або технічному стеку, або перспективному бізнес-домену.
Для оцінки перспективності домену можна скористатися ChatGPT у режимі DeepResearch і визначити, чи збільшуються витрати кінцевих клієнтів у конкретній ніші. Наприклад, український стартап OnlyMonster.ai автоматизує процеси для OnlyFans-індустрії, яка зараз швидко зростає.
Щодо технічного стеку, звертайте увагу на компанії, що використовують сучасні технології: Cloud Native, AI, Data-driven рішення тощо.
13.03.202515:18
Сьогодні хочу поділитися з вами метафорою, яку я використовую для пояснення “технічного боргу” бізнесу.
У вас вдома є горище для зберігання речей (attic for storage)? В ідеалі ми акуратно складаємо туди предмети, але зазвичай буває інакше. Особисто я, коли поспішаю, навіть не піднімаюсь повністю сходами: просто привідкриваю люк і закидаю чергову коробку кудись усередину.
Так само відбувається й у розробці: інженери в поспіху не «піднімаються нагору», щоб грамотно структурувати код, написати тести й оновити документацію. Вони просто «закидають» фічі, аби швидше рухатися далі. Такий підхід накопичує технічний борг.
Настає момент, коли речі перемішані, коробки не підписані або банально закінчується місце. У мене так теж було. Повернувшись із поїздки, я не зміг покласти на горище валізу, яку брав звідти тиждень тому. Довелось влаштовувати генеральне прибирання, на яке пішли всі вихідні. Так само й із технічним боргом: що довше відкладаєш, то дорожче обходиться «прибирання».
Цю метафору можна чудово розвинути й на «технічну смерть» (горище просто обвалилося), і на зміну архітектури/framework (горище вже замале, потрібен повноцінний склад), і на регулярний технічний аудит (періодична інвентаризація горища).
У вас вдома є горище для зберігання речей (attic for storage)? В ідеалі ми акуратно складаємо туди предмети, але зазвичай буває інакше. Особисто я, коли поспішаю, навіть не піднімаюсь повністю сходами: просто привідкриваю люк і закидаю чергову коробку кудись усередину.
Так само відбувається й у розробці: інженери в поспіху не «піднімаються нагору», щоб грамотно структурувати код, написати тести й оновити документацію. Вони просто «закидають» фічі, аби швидше рухатися далі. Такий підхід накопичує технічний борг.
Настає момент, коли речі перемішані, коробки не підписані або банально закінчується місце. У мене так теж було. Повернувшись із поїздки, я не зміг покласти на горище валізу, яку брав звідти тиждень тому. Довелось влаштовувати генеральне прибирання, на яке пішли всі вихідні. Так само й із технічним боргом: що довше відкладаєш, то дорожче обходиться «прибирання».
Цю метафору можна чудово розвинути й на «технічну смерть» (горище просто обвалилося), і на зміну архітектури/framework (горище вже замале, потрібен повноцінний склад), і на регулярний технічний аудит (періодична інвентаризація горища).
21.02.202515:02
У середу готовув контент по курсу AI-Enabled Developer Experience та спіймав комплекс самозванця. Усвідомив, що багато функцій WebStorm та Visual Studio я не тільки не використовую, а й навіть не знаю про них.
Тому сьогодні хочу поділитися з вами фічею для WebStorm, що називається Endpoints та чудова працує з NestJS. Згідно з документацією вона повинна працювати з Express, можливо, з Fastify, але, здається, зараз вона зламана. Демонстрація фічі на відео.
Можливо зробити ще простіше, ніж на відео shift+shift /url feed
Catch that DevEx vibe!
Учора вперше використав її під час парного програмування з колегою. Відкрив мікросервіс, над яким він працює. Знайшов у Endpoint потрібний роут, поставив Breakpoint, та почав дебаг. Зворотний зв'язок від колеги, він автор цього мікросервісу, так швидко це не зміг би зробити.
Тому сьогодні хочу поділитися з вами фічею для WebStorm, що називається Endpoints та чудова працує з NestJS. Згідно з документацією вона повинна працювати з Express, можливо, з Fastify, але, здається, зараз вона зламана. Демонстрація фічі на відео.
Можливо зробити ще простіше, ніж на відео shift+shift /url feed
Catch that DevEx vibe!
Учора вперше використав її під час парного програмування з колегою. Відкрив мікросервіс, над яким він працює. Знайшов у Endpoint потрібний роут, поставив Breakpoint, та почав дебаг. Зворотний зв'язок від колеги, він автор цього мікросервісу, так швидко це не зміг би зробити.
21.04.202514:02
Цікавий результат у #like_and_share MCP.
Переможцем став Bohdan з його коментарем
Виходить, що запланований стрім по огляду MCP серверів не актуальний.
Переможцем став Bohdan з його коментарем
не юзаю жодного МРС 😢
Виходить, що запланований стрім по огляду MCP серверів не актуальний.
16.04.202515:32
Навіщо потрібен пакет sentences-per-line?
Сьогодні хочу порекомендувати вам пакет, але спочатку поясню, навіщо він потрібен. Почнемо з документації.
Стандартним форматом документації в розробці є Markdown. Причому ми все частіше пишемо її не лише для інженерів, а й для LLM. Приклади – .cursor/rules, copilot-instructions.md. Важливо підтримувати документацію в актуальному стані. Її оновлення завжди було частиною Definition of Done, але зараз це стало простіше – багато завдань можна делегувати AI-агентам. Нам залишається лише зробити ревʼю.
Під час ревʼю виникає проблема: великі абзаци складно перевіряти. Звичайні Markdown-лінтери не вирішують цю задачу. І тут на допомогу приходить пакет sentences-per-line:
- Кожне речення – на окремому рядку. Якщо потрібно, можна скористатися auto-fix.
- Зміни стають читабельними: diff показує, що саме змінилося на рівні речення.
- При цьому Markdown автоматично обʼєднує рядки в один абзац, тож візуально нічого не змінюється.
Пакету вже понад 7 років. Дивно, чому цей пакет досі не додали як частину markdownlint. Переглянути приклади конфігурації пакета можна у автора Josh Goldberg, наприклад, тут.
Якщо ви хочете, щоб ваша документація була зручною для ревʼю та адаптованою до сучасного дев-процесу, sentences-per-line – обовʼязковий інструмент.
Сьогодні хочу порекомендувати вам пакет, але спочатку поясню, навіщо він потрібен. Почнемо з документації.
Стандартним форматом документації в розробці є Markdown. Причому ми все частіше пишемо її не лише для інженерів, а й для LLM. Приклади – .cursor/rules, copilot-instructions.md. Важливо підтримувати документацію в актуальному стані. Її оновлення завжди було частиною Definition of Done, але зараз це стало простіше – багато завдань можна делегувати AI-агентам. Нам залишається лише зробити ревʼю.
Під час ревʼю виникає проблема: великі абзаци складно перевіряти. Звичайні Markdown-лінтери не вирішують цю задачу. І тут на допомогу приходить пакет sentences-per-line:
- Кожне речення – на окремому рядку. Якщо потрібно, можна скористатися auto-fix.
- Зміни стають читабельними: diff показує, що саме змінилося на рівні речення.
- При цьому Markdown автоматично обʼєднує рядки в один абзац, тож візуально нічого не змінюється.
Пакету вже понад 7 років. Дивно, чому цей пакет досі не додали як частину markdownlint. Переглянути приклади конфігурації пакета можна у автора Josh Goldberg, наприклад, тут.
Якщо ви хочете, щоб ваша документація була зручною для ревʼю та адаптованою до сучасного дев-процесу, sentences-per-line – обовʼязковий інструмент.
09.04.202513:05
Сьогодні стартує Google Cloud Next. Я приїхав раніше, щоб взяти участь в GDE Mini-Summit. Нас (Google Developer Experts) і product manager-ов з Google зібрали, щоб поділитися анонсами та планами розвитку продуктів, а також зібрати відгуки. Поділюсь частиною своїх інсайтів за вчорашній день.
AI Related:
- Більшість не використовують Fine Tuning, натомість користуються Few-Shot Prompting.
- У Google немає визначення AI-агента, хоча мають інструменти для їх створення, причому не один.
- AI is game-changer, but we are only learning new rules.
Development:
- Shift left is for suckers. Shift down instead
- Успішність вашої команди та технологічного стека визначається кількістю продуктових експериментів, які ви можете провести за одиницю часу.
AI Related:
- Більшість не використовують Fine Tuning, натомість користуються Few-Shot Prompting.
- У Google немає визначення AI-агента, хоча мають інструменти для їх створення, причому не один.
- AI is game-changer, but we are only learning new rules.
Development:
- Shift left is for suckers. Shift down instead
- Успішність вашої команди та технологічного стека визначається кількістю продуктових експериментів, які ви можете провести за одиницю часу.
27.03.202514:39
Шановні читачі, потрібен ваш зворотний зв'язок. Чотири роки тому, коли я створював цей канал, моя основна експертиза була пов'язана з Node.js та Cloud Native технологіями. За останній рік більшість консалтингу, а отже, і рецептів, якими я можу поділитися з вами, стали пов'язані з AI для розробки або AI у створення продукту. У зв'язку з цим маю таке питання.
11.03.202519:13
Через 5 хвилин проведу стрім, щодо новини дня TypeScript -> Go:
- https://devblogs.microsoft.com/typescript/typescript-native-port/
Ця новина чудово підходить для розповіді про те, що таке LSP і чому це важливо для нас як розробників.
Навколо цієї теми вже починають з'являтися міфи, які викликані неточності, що виникають під час пересказу.
- https://www.totaltypescript.com/typescript-announces-go-rewrite
Отож давайте розберемо цю новину і додамо технічної глибини та розуміння цієї теми.
Приєднуйтесь до стріму або перегляньте його в записі
https://youtube.com/live/13dWqnuuNlk?feature=share
- https://devblogs.microsoft.com/typescript/typescript-native-port/
Ця новина чудово підходить для розповіді про те, що таке LSP і чому це важливо для нас як розробників.
Навколо цієї теми вже починають з'являтися міфи, які викликані неточності, що виникають під час пересказу.
- https://www.totaltypescript.com/typescript-announces-go-rewrite
Отож давайте розберемо цю новину і додамо технічної глибини та розуміння цієї теми.
Приєднуйтесь до стріму або перегляньте його в записі
https://youtube.com/live/13dWqnuuNlk?feature=share
18.02.202515:03
Сьогодні ділюся спостереженням, яке часто зустрічається в проектах, де я проводжу Architecture Board Review.
Багато команд використовують лише одну базу даних, зазвичай PostgreSQL. Хоча це зручно і забезпечує консистентність, ми все одно використовуємо інші сховища даних (наприклад, S3) та інтегруємося з 3rd parties, як-от Stripe чи Firebase Auth. Через це питання узгодженості між DB та 3rd parties все одно доводиться вирішувати.
Не бійтеся додавати ще одну базу даних до проєкту - це може спростити розробку та архітектуру застосунку. Ось кілька прикладів:
1) SQLite для даних, що рідко змінюються. У додатку його монтують як Docker Volume з доступом лише для читання, а зміни здійснюються через адмінку, яка використовує той же volume з правами на запис.
2) Окрема база для аналітики. Наприклад, додатковий PostgreSQL або спеціалізована база для аналітичних даних, щоб основна база не була перевантажувана і це не впливало на користувацький досвід.
3) Realtime база. Firestore або Supabase можуть бути використані для реалізації повідомлень у реальному часі. Підключення серверних подій або веб-сокетів часто вимагає великих змін в архітектурі, тому окрема база для realtime notifications може бути зручною альтернативою.
4) Redis для кешування. Використання Redis або його аналогів допомагає зменшити навантаження на бази даних, пришвидшити доступ до часто використовуваних даних та забезпечити кращу масштабованість проєкту.
На завершення нагадаю про PostgreSQL Extensions. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.
Багато команд використовують лише одну базу даних, зазвичай PostgreSQL. Хоча це зручно і забезпечує консистентність, ми все одно використовуємо інші сховища даних (наприклад, S3) та інтегруємося з 3rd parties, як-от Stripe чи Firebase Auth. Через це питання узгодженості між DB та 3rd parties все одно доводиться вирішувати.
Не бійтеся додавати ще одну базу даних до проєкту - це може спростити розробку та архітектуру застосунку. Ось кілька прикладів:
1) SQLite для даних, що рідко змінюються. У додатку його монтують як Docker Volume з доступом лише для читання, а зміни здійснюються через адмінку, яка використовує той же volume з правами на запис.
2) Окрема база для аналітики. Наприклад, додатковий PostgreSQL або спеціалізована база для аналітичних даних, щоб основна база не була перевантажувана і це не впливало на користувацький досвід.
3) Realtime база. Firestore або Supabase можуть бути використані для реалізації повідомлень у реальному часі. Підключення серверних подій або веб-сокетів часто вимагає великих змін в архітектурі, тому окрема база для realtime notifications може бути зручною альтернативою.
4) Redis для кешування. Використання Redis або його аналогів допомагає зменшити навантаження на бази даних, пришвидшити доступ до часто використовуваних даних та забезпечити кращу масштабованість проєкту.
На завершення нагадаю про PostgreSQL Extensions. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.
Паказана 1 - 24 з 676
Увайдзіце, каб разблакаваць больш функцый.