Забудьте ви за це Zoneless + signals ось що варто знати

З того що мені пропонували на собесах, це ти повноцінний фронт, який ще на додачу продумує всю архітектуру, CI/CD, деплоймент, AWS, кеші, і такий самий повноціний бек, з редісом, чергами, свагером, логами, графанами, кубіком, алертами... за одну ЗП :D

Ще можна розвити в сторону гексагональної архітектури ) де все крутится на вколо портів та адапторів

відповідаю як той хто робив Розетку — ні! Досягти ідеальних показників на великих проєктах з купою фічей неможливо.

Плюсую, якась фігня про інтерфейси написана

Крутяк!

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

Зараз коли бачу якийсь додаток і опис починається з AI-tools, одразу скіпаю )

Хочу додати, що продуктовий і сервісний фронтенд — це різні речі. Розробка фіч для продукту і створення інструментів для продуктових команд (наприклад, UI Kit або Design System) вимагають різних підходів і навичок. Зробити інструмент, на основі якого інші команди збиратимуть фічі, значно складніше. І якщо ви команда, яка намагається робити і те, і те одночасно, то у мене для вас погані новини )

Bun вже класний для деву й окремих продакшн-кейсів, але як повна заміна Node.js навряд

👀👀👀

Дякую, що поділились цим досвідом. Дуже чесно! Успіхів у 2026 💪

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

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

Друге питання, навіщо вам ssr для всього цього? у вас респонс тайм 1.5 сек... на кожну дію

Зараз фронтент це вже дефакто BFF, взяти той же Next. А там і база і пошла жара :D

😂

Поділюсь своїм :D

eurusik.tech — це все крутиться на домашньому кластері homelab.eurusik.tech

Так, cамі по собі Signals синхронні, вони просто тримають значення і сповіщають підписників при зміні. А для асинхронності в Angular придумали Resource, який обгортає async-логіку в реактивний шар: завантажує дані, трекає статус (loading / error / success) і синхронно оновлює сигнал зі станом результату.

У React поки прямого аналога Resource немає, там або useEffect + useState/useReducer, або зовнішні штуки типу React Query чи Zustand

Так, у статті хотілось максимально спростити, але ваш поінт валідний!
хочеш «подешевше» — через namespace, хочеш «подорожче» — окремі кластери 🙂

Дякую за фітбек, врахую це для наступної статті!

Він був на момент написання цієї статті. Чомусь на зараз його прибрали з сайту...