#nestjs — Public Fediverse posts

Feature Based Clean Architecture. Часть 5: Масштабирование FBCA и теоретико-графовый анализ зависимостей

Если описать NestJS-архитектуру как граф — вершины это модули и классы, рёбра — зависимости между ними, — утверждение «архитектура не деградирует» перестаёт быть оценочным. Формально доказывается, при каких условиях циклы между модулями топологически невозможны, при каких размер публичного API не растёт с каждой новой ручкой, и при каких стоимость добавления фичи остаётся константой, а не растёт с числом существующих потребителей. Три измеримых структурных свойства, а не ощущение. Для типовой feature-based-структуры, которую сегодня продвигают как стандарт, ни одно из них не выполняется. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 5 — финал серии. Архитектурный подход, при котором эти три свойства соблюдаются (Feature-Based Clean Architecture), нагружается тем же сценарием годового роста, под весом которого деградирует обычный feature-based: партнёрка, анти-фрод, рефералки, расширенная аналитика, утроение модуля пользователей. Без художественности: реальный код, граф зависимостей «до» и «после», и формальное доказательство трёх свойств — DAG-инвариант, граница связности, O(1)-стоимость инкремента — на языке теории графов. Точка, в которой «архитектура не деградирует» становится не похвалой, а конкретным структурным утверждением.

https://habr.com/ru/articles/1038450/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #Теория_графов #Масштабирование #DAG #DomainDriven_Design

Feature Based Clean Architecture. Часть 4: FBCA: формализация границ ответственности в NestJS-модуле

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

https://habr.com/ru/articles/1038438/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #DomainDriven_Design #Слоистая_архитектура #Рефакторинг #SOLID

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

4 MVP за 4 месяца, 30 холодных DM, 1 регистрация: building in public по-русски

Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди-проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь). За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь. По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично. Если вы делаете свой инди-продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать. TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что-то одно. Email-верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram-релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).

https://habr.com/ru/articles/1035756/

#индиразработка #building_in_public #MVP #стартап #NestJS #Telegram_Bot_API #Cursor #Claude_Code #Proof_of_Work #солоразработчик

4 MVP за 4 месяца, 30 холодных DM, 1 регистрация: building in public по-русски

Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди-проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь). За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь. По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично. Если вы делаете свой инди-продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать. TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что-то одно. Email-верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram-релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).

https://habr.com/ru/articles/1035756/

#индиразработка #building_in_public #MVP #стартап #NestJS #Telegram_Bot_API #Cursor #Claude_Code #Proof_of_Work #солоразработчик

4 MVP за 4 месяца, 30 холодных DM, 1 регистрация: building in public по-русски

Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди-проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь). За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь. По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично. Если вы делаете свой инди-продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать. TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что-то одно. Email-верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram-релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).

https://habr.com/ru/articles/1035756/

#индиразработка #building_in_public #MVP #стартап #NestJS #Telegram_Bot_API #Cursor #Claude_Code #Proof_of_Work #солоразработчик

4 MVP за 4 месяца, 30 холодных DM, 1 регистрация: building in public по-русски

Меня зовут Никита, я бэкендер из Краснодара. Плотно сижу на NestJS/TypeScript в продуктовой команде. Параллельно с основной работой веду формат Proof of Work — 30-дневные публичные спринты по своим инди-проектам: каждый день рассказываю, что сделал, и не бросаю свои идеи в заметки Obsidian/Notion на годы (по крайней мере, теперь). За последние четыре месяца провёл четыре таких сезона: четыре продукта, четыре разных стека, четыре разных способа облажаться. Один продукт вообще не дожил до релиза. Три выпустил, ими пользуются люди, у одного есть публичный дашборд с метриками. Ни один пока не зарабатывает — и это часть истории, к которой я ещё вернусь. По итогам четырёх сезонов я мог бы написать «10 советов как сделать стартап», но таких текстов и без меня хватает. Здесь — конкретный разбор того, что у меня сработало, что не сработало и какой ценой. С цифрами, с названиями инструментов, с граблями, на которые я наступил лично. Если вы делаете свой инди-продукт или думаете начать — возможно, часть моего опыта сэкономит вам пару недель и замотивирует наконец начать. TL;DR. Без одного конкретного человека, который скажет «да, я этим воспользуюсь», лучше не начинать. Учить новый стек и параллельно гнать сроки — не получается, что-то одно. Email-верификация как блокер на регистрации убивает воронку. В РФ холодный аутрич без явного обмена «делаю → получаю» работает плохо. И выпуск продукта — начало работы, а не конец. Ниже подробно по каждому пункту, плюс отдельный раздел про юридическую часть и Telegram-релей в обход блокировок российского хостинга (которые как раз недавно начались в 2026).

https://habr.com/ru/articles/1035756/

#индиразработка #building_in_public #MVP #стартап #NestJS #Telegram_Bot_API #Cursor #Claude_Code #Proof_of_Work #солоразработчик

Откуда пришли пользователи: first-touch attribution для NestJS + React + Telegram Mini App в 100 строк кода

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах: веб-сайт speakwithai.pro , Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди? Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000 просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app). Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь. Если интересно посмотреть на сам продукт — он живёт здесь: 🤖 Telegram-бот 🌐

https://habr.com/ru/articles/1030560/

#attribution #firsttouch_attribution #UTMметки #Telegram_Mini_App #start_param #NestJS #React #вебаналитика #TypeScript #маркетинговая_аналитика

Откуда пришли пользователи: first-touch attribution для NestJS + React + Telegram Mini App в 100 строк кода

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах: веб-сайт speakwithai.pro , Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди? Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000 просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app). Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь. Если интересно посмотреть на сам продукт — он живёт здесь: 🤖 Telegram-бот 🌐

https://habr.com/ru/articles/1030560/

#attribution #firsttouch_attribution #UTMметки #Telegram_Mini_App #start_param #NestJS #React #вебаналитика #TypeScript #маркетинговая_аналитика

Откуда пришли пользователи: first-touch attribution для NestJS + React + Telegram Mini App в 100 строк кода

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах: веб-сайт speakwithai.pro , Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди? Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000 просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app). Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь. Если интересно посмотреть на сам продукт — он живёт здесь: 🤖 Telegram-бот 🌐

https://habr.com/ru/articles/1030560/

#attribution #firsttouch_attribution #UTMметки #Telegram_Mini_App #start_param #NestJS #React #вебаналитика #TypeScript #маркетинговая_аналитика

Откуда пришли пользователи: first-touch attribution для NestJS + React + Telegram Mini App в 100 строк кода

Я делаю голосовой AI-репетитор английского. Продукт живёт в трёх местах: веб-сайт speakwithai.pro , Telegram Mini App и Android-приложение в RuStore. У меня одна и та же база пользователей на NestJS + Postgres, и мне очень нужен ответ на вопрос: откуда вообще приходят люди? Yandex.Metrika и Google Analytics показывают только сайт. Telegram Mini App для них — чёрный ящик. Android-приложение через WebView — тоже. Из 6000 просмотров статьи на Habr я не мог сказать, сколько оттуда пришло в продукт, и через какой канал (TG, веб, app). Я не хотел тащить большую CDP вроде Mixpanel или Amplitude — для соло-разработчика это overkill. Вечером сел и сделал simplest-thing-that-could-possibly-work: одна колонка в БД, парсится при первом визите, читается на регистрации. 100 строк кода. Делюсь. Если интересно посмотреть на сам продукт — он живёт здесь: 🤖 Telegram-бот 🌐

https://habr.com/ru/articles/1030560/

#attribution #firsttouch_attribution #UTMметки #Telegram_Mini_App #start_param #NestJS #React #вебаналитика #TypeScript #маркетинговая_аналитика

Приложение полностью написанное AI

У меня возникла идея провести эксперимент, чтобы лучше понять текущие возможности агентов для написания кода. Ну и кроме этого протестировать рынок и понять что нас ожидает в ближайшем будущем в плане изменения подходов к разработке. Я хочу написать мобильные приложения для iOS и Android начиная от дизайна и до деплоя с помощью Claude Code.

https://habr.com/ru/articles/1021492/

#ai #tailwind #angular #nestjs #postgresql #mobile_development

Приложение полностью написанное AI

У меня возникла идея провести эксперимент, чтобы лучше понять текущие возможности агентов для написания кода. Ну и кроме этого протестировать рынок и понять что нас ожидает в ближайшем будущем в плане изменения подходов к разработке. Я хочу написать мобильные приложения для iOS и Android начиная от дизайна и до деплоя с помощью Claude Code.

https://habr.com/ru/articles/1021492/

#ai #tailwind #angular #nestjs #postgresql #mobile_development

Приложение полностью написанное AI

У меня возникла идея провести эксперимент, чтобы лучше понять текущие возможности агентов для написания кода. Ну и кроме этого протестировать рынок и понять что нас ожидает в ближайшем будущем в плане изменения подходов к разработке. Я хочу написать мобильные приложения для iOS и Android начиная от дизайна и до деплоя с помощью Claude Code.

https://habr.com/ru/articles/1021492/

#ai #tailwind #angular #nestjs #postgresql #mobile_development

Приложение полностью написанное AI

У меня возникла идея провести эксперимент, чтобы лучше понять текущие возможности агентов для написания кода. Ну и кроме этого протестировать рынок и понять что нас ожидает в ближайшем будущем в плане изменения подходов к разработке. Я хочу написать мобильные приложения для iOS и Android начиная от дизайна и до деплоя с помощью Claude Code.

https://habr.com/ru/articles/1021492/

#ai #tailwind #angular #nestjs #postgresql #mobile_development

152-ФЗ и LLM несовместимы по умолчанию: как мы это исправили без потери качества AI

Строим AI-ассистента для бизнеса — и обнаруживаем, что каждое сообщение пользователя с персональными данными уходит в Google. Рассказываю, как это исправить, не сломав UX. Когда мы запускали AI-ассистента для квалификации лидов в строительном бизнесе, первый же вопрос от клиента поставил меня в тупик: «А куда уходят персональные данные, которые люди вводят в чат?» Я знал ответ. И он мне не нравился. Пользователь пишет: «Меня зовут Дмитрий, наша компания ООО Ромашка, телефон +7 903 123-45-67, email [email protected] » . Это сообщение в том же виде уходит в Google Gemini API для генерации ответа. Google получает PII — имя, телефон, email конкретного человека. Каждый раз. С каждым пользователем. Для бизнеса в России это три проблемы одновременно. Юридическая. 152-ФЗ требует, чтобы персональные данные российских граждан обрабатывались на территории РФ. Передача данных на серверы Google — даже для обработки, не хранения — это трансграничная передача данных, которая требует уведомления Роскомнадзора и согласия субъекта. Штрафы начинаются от 3 млн рублей. Бизнес-риск. Контактная база клиентов — главный актив отдела продаж. Отдавать её в третьи руки, пусть даже крупной корпорации — вопрос корпоративной гигиены. Этика. Клиент пишет в ваш чат. Он доверяет вам свои данные. Не Google. Задача сформулировалась чётко: большая языковая модель должна вести диалог естественно — обращаться по имени, знать компанию, упоминать email — но никогда не получать реальные персональные данные. Звучит как противоречие. Решение оказалось элегантным.

https://habr.com/ru/articles/1015694/

#информационная_безопасность #персональные_данные #152ФЗ #LLM #большие_языковые_модели #защита_данных #NestJS #Gemini_API #PII #разработка

152-ФЗ и LLM несовместимы по умолчанию: как мы это исправили без потери качества AI

Строим AI-ассистента для бизнеса — и обнаруживаем, что каждое сообщение пользователя с персональными данными уходит в Google. Рассказываю, как это исправить, не сломав UX. Когда мы запускали AI-ассистента для квалификации лидов в строительном бизнесе, первый же вопрос от клиента поставил меня в тупик: «А куда уходят персональные данные, которые люди вводят в чат?» Я знал ответ. И он мне не нравился. Пользователь пишет: «Меня зовут Дмитрий, наша компания ООО Ромашка, телефон +7 903 123-45-67, email [email protected] » . Это сообщение в том же виде уходит в Google Gemini API для генерации ответа. Google получает PII — имя, телефон, email конкретного человека. Каждый раз. С каждым пользователем. Для бизнеса в России это три проблемы одновременно. Юридическая. 152-ФЗ требует, чтобы персональные данные российских граждан обрабатывались на территории РФ. Передача данных на серверы Google — даже для обработки, не хранения — это трансграничная передача данных, которая требует уведомления Роскомнадзора и согласия субъекта. Штрафы начинаются от 3 млн рублей. Бизнес-риск. Контактная база клиентов — главный актив отдела продаж. Отдавать её в третьи руки, пусть даже крупной корпорации — вопрос корпоративной гигиены. Этика. Клиент пишет в ваш чат. Он доверяет вам свои данные. Не Google. Задача сформулировалась чётко: большая языковая модель должна вести диалог естественно — обращаться по имени, знать компанию, упоминать email — но никогда не получать реальные персональные данные. Звучит как противоречие. Решение оказалось элегантным.

https://habr.com/ru/articles/1015694/

#информационная_безопасность #персональные_данные #152ФЗ #LLM #большие_языковые_модели #защита_данных #NestJS #Gemini_API #PII #разработка

152-ФЗ и LLM несовместимы по умолчанию: как мы это исправили без потери качества AI

Строим AI-ассистента для бизнеса — и обнаруживаем, что каждое сообщение пользователя с персональными данными уходит в Google. Рассказываю, как это исправить, не сломав UX. Когда мы запускали AI-ассистента для квалификации лидов в строительном бизнесе, первый же вопрос от клиента поставил меня в тупик: «А куда уходят персональные данные, которые люди вводят в чат?» Я знал ответ. И он мне не нравился. Пользователь пишет: «Меня зовут Дмитрий, наша компания ООО Ромашка, телефон +7 903 123-45-67, email [email protected] » . Это сообщение в том же виде уходит в Google Gemini API для генерации ответа. Google получает PII — имя, телефон, email конкретного человека. Каждый раз. С каждым пользователем. Для бизнеса в России это три проблемы одновременно. Юридическая. 152-ФЗ требует, чтобы персональные данные российских граждан обрабатывались на территории РФ. Передача данных на серверы Google — даже для обработки, не хранения — это трансграничная передача данных, которая требует уведомления Роскомнадзора и согласия субъекта. Штрафы начинаются от 3 млн рублей. Бизнес-риск. Контактная база клиентов — главный актив отдела продаж. Отдавать её в третьи руки, пусть даже крупной корпорации — вопрос корпоративной гигиены. Этика. Клиент пишет в ваш чат. Он доверяет вам свои данные. Не Google. Задача сформулировалась чётко: большая языковая модель должна вести диалог естественно — обращаться по имени, знать компанию, упоминать email — но никогда не получать реальные персональные данные. Звучит как противоречие. Решение оказалось элегантным.

https://habr.com/ru/articles/1015694/

#информационная_безопасность #персональные_данные #152ФЗ #LLM #большие_языковые_модели #защита_данных #NestJS #Gemini_API #PII #разработка

152-ФЗ и LLM несовместимы по умолчанию: как мы это исправили без потери качества AI

Строим AI-ассистента для бизнеса — и обнаруживаем, что каждое сообщение пользователя с персональными данными уходит в Google. Рассказываю, как это исправить, не сломав UX. Когда мы запускали AI-ассистента для квалификации лидов в строительном бизнесе, первый же вопрос от клиента поставил меня в тупик: «А куда уходят персональные данные, которые люди вводят в чат?» Я знал ответ. И он мне не нравился. Пользователь пишет: «Меня зовут Дмитрий, наша компания ООО Ромашка, телефон +7 903 123-45-67, email [email protected] » . Это сообщение в том же виде уходит в Google Gemini API для генерации ответа. Google получает PII — имя, телефон, email конкретного человека. Каждый раз. С каждым пользователем. Для бизнеса в России это три проблемы одновременно. Юридическая. 152-ФЗ требует, чтобы персональные данные российских граждан обрабатывались на территории РФ. Передача данных на серверы Google — даже для обработки, не хранения — это трансграничная передача данных, которая требует уведомления Роскомнадзора и согласия субъекта. Штрафы начинаются от 3 млн рублей. Бизнес-риск. Контактная база клиентов — главный актив отдела продаж. Отдавать её в третьи руки, пусть даже крупной корпорации — вопрос корпоративной гигиены. Этика. Клиент пишет в ваш чат. Он доверяет вам свои данные. Не Google. Задача сформулировалась чётко: большая языковая модель должна вести диалог естественно — обращаться по имени, знать компанию, упоминать email — но никогда не получать реальные персональные данные. Звучит как противоречие. Решение оказалось элегантным.

https://habr.com/ru/articles/1015694/

#информационная_безопасность #персональные_данные #152ФЗ #LLM #большие_языковые_модели #защита_данных #NestJS #Gemini_API #PII #разработка

been getting back into working on my rss reader, lionsmane! still looking for help if anyone wants to collab! #nestjs #typescript #react #rss

https://tangled.org/0x4d6165.synth.download/lionsmane

Парсинг, боль и AI-напарник: Как я в 16 лет строил Open Source API и оптимизировал Postgres

Рассказываю историю создания Mumin API — современной Open Source платформы для работы с хадисами. Внутри: битва с «кривыми» PDF-сканами через регулярки Python, ускорение Fuzzy Search в PostgreSQL почти в 2 раза с помощью GIN-индексов, публикация Kotlin SDK в Maven Central и опыт работы с AI как с Senior-напарником. Без «воды», только код, архитектура и реальные грабли 16-летнего разработчика

https://habr.com/ru/articles/1002178/

#NestJS #PostgreSQL #Prisma #Open_Source #API #Kotlin #Claude #Парсинг #Trigrams #Fullstack_разработка

RE: https://mastodon.social/@h4ckernews/116105137504773423

I have a good story with #dependabot
I was working with a team that depended totally in #bots #llms #ai stack. So one day checking PRs I noticed a PR that overrides the dependencies of the framework that we used to build an API( #NestJS ) Yeah it was overriding the depends of Nestjs in our repo, I mean the dependencies of the dependencies

Why?

They told me that dependabot warnings about it.

I'm pretty sure the solution came from #chatgpt hahahahaahhaa

RE: https://mastodon.social/@h4ckernews/116105137504773423

I have a good story with #dependabot
I was working with a team that depended totally in #bots #llms #ai stack. So one day checking PRs I noticed a PR that overrides the dependencies of the framework that we used to build an API( #NestJS ) Yeah it was overriding the depends of Nestjs in our repo, I mean the dependencies of the dependencies

Why?

They told me that dependabot warnings about it.

I'm pretty sure the solution came from #chatgpt hahahahaahhaa

RE: https://mastodon.social/@h4ckernews/116105137504773423

I have a good story with #dependabot
I was working with a team that depended totally in #bots #llms #ai stack. So one day checking PRs I noticed a PR that overrides the dependencies of the framework that we used to build an API( #NestJS ) Yeah it was overriding the depends of Nestjs in our repo, I mean the dependencies of the dependencies

Why?

They told me that dependabot warnings about it.

I'm pretty sure the solution came from #chatgpt hahahahaahhaa

RE: https://mastodon.social/@h4ckernews/116105137504773423

I have a good story with #dependabot
I was working with a team that depended totally in #bots #llms #ai stack. So one day checking PRs I noticed a PR that overrides the dependencies of the framework that we used to build an API( #NestJS ) Yeah it was overriding the depends of Nestjs in our repo, I mean the dependencies of the dependencies

Why?

They told me that dependabot warnings about it.

I'm pretty sure the solution came from #chatgpt hahahahaahhaa

My friend works here, and they're hiring a junior frontend dev. ⚛️

Onsite / hybrid in San Francisco

https://fablesecurity.com/careers/?ashby_jid=aa900256-a8c4-4491-9d69-9f36d865ea71

("Hiring a junior dev!? In 2026!?")
I know, right!

#fedihire #react #nestjs #dev

Tạo bộ starter kit full-stack với Vue, Element Plus, NestJS, Astro, PostgreSQL, Valkey. Ai sẽ sử dụng bộ công cụ này? #FullStack #Vue #NestJS #Astro #PostgreSQL #Valkey #BộCôngCụ #PhátTriểnWeb #FullStackDevelopment #VueJS #NestJSDramework

https://www.reddit.com/r/SaaS/comments/1qpzh0j/would_you_use_a_fullstack_starter_template/

Повторяющиеся задачи без RRULE: мой опыт реализации в своём таск-трекере

Повторяющиеся задачи кажутся базовой функцией любого таск-трекера, но мне пришлось их реализовывать с нуля в уже работающем проекте с десятками тысяч пользователей. У меня был выбор: внедрять тяжелый стандарт RRULE или писать свой велосипед? Для своего трекера задач в Telegram «OK, Bob!» я выбрал второй путь. В статье рассказываю про подход «буферизированной материализации»: как хранить бесконечные серии в MongoDB, не убивая базу, зачем нужно «скользящее окно» генерации и почему работа с таймзонами сложнее, чем просто хранение в UTC. Разбор архитектуры, кода и неочевидных UX-компромиссов.

https://habr.com/ru/articles/986794/

#тасктрекер #таскменеджер #повторяющиеся_задачи #nestjs #agenda #rrule #dayjs

Повторяющиеся задачи без RRULE: мой опыт реализации в своём таск-трекере

Повторяющиеся задачи кажутся базовой функцией любого таск-трекера, но мне пришлось их реализовывать с нуля в уже работающем проекте с десятками тысяч пользователей. У меня был выбор: внедрять тяжелый стандарт RRULE или писать свой велосипед? Для своего трекера задач в Telegram «OK, Bob!» я выбрал второй путь. В статье рассказываю про подход «буферизированной материализации»: как хранить бесконечные серии в MongoDB, не убивая базу, зачем нужно «скользящее окно» генерации и почему работа с таймзонами сложнее, чем просто хранение в UTC. Разбор архитектуры, кода и неочевидных UX-компромиссов.

https://habr.com/ru/articles/986794/

#тасктрекер #таскменеджер #повторяющиеся_задачи #nestjs #agenda #rrule #dayjs

Повторяющиеся задачи без RRULE: мой опыт реализации в своём таск-трекере

Повторяющиеся задачи кажутся базовой функцией любого таск-трекера, но мне пришлось их реализовывать с нуля в уже работающем проекте с десятками тысяч пользователей. У меня был выбор: внедрять тяжелый стандарт RRULE или писать свой велосипед? Для своего трекера задач в Telegram «OK, Bob!» я выбрал второй путь. В статье рассказываю про подход «буферизированной материализации»: как хранить бесконечные серии в MongoDB, не убивая базу, зачем нужно «скользящее окно» генерации и почему работа с таймзонами сложнее, чем просто хранение в UTC. Разбор архитектуры, кода и неочевидных UX-компромиссов.

https://habr.com/ru/articles/986794/

#тасктрекер #таскменеджер #повторяющиеся_задачи #nestjs #agenda #rrule #dayjs

Повторяющиеся задачи без RRULE: мой опыт реализации в своём таск-трекере

Повторяющиеся задачи кажутся базовой функцией любого таск-трекера, но мне пришлось их реализовывать с нуля в уже работающем проекте с десятками тысяч пользователей. У меня был выбор: внедрять тяжелый стандарт RRULE или писать свой велосипед? Для своего трекера задач в Telegram «OK, Bob!» я выбрал второй путь. В статье рассказываю про подход «буферизированной материализации»: как хранить бесконечные серии в MongoDB, не убивая базу, зачем нужно «скользящее окно» генерации и почему работа с таймзонами сложнее, чем просто хранение в UTC. Разбор архитектуры, кода и неочевидных UX-компромиссов.

https://habr.com/ru/articles/986794/

#тасктрекер #таскменеджер #повторяющиеся_задачи #nestjs #agenda #rrule #dayjs

Recrutement – Lead Backend Developer Node.js

On renforce notre pôle backend et on cherche un·e lead pour concevoir des archis solides, accompagner l’équipe et piloter la migration d’un projet clé de Symfony vers NestJS.

🔗 Détails & candidature : https://www.linkedin.com/jobs/view/4351480594/

#recrutement #backend #nodejs #nestjs #fediverse #techjobs

Dicen que la IA no le va a quitar el trabajo a los desarrolladores, pero llevo todo el año diciéndole a copilot y chatgpt que me hagan el trabajo, ojalá para el próximo año sí aprenda #TypeScript #React #NestJs

Một người đã xây dựng công cụ phân loại ticket hỗ trợ AI trong 4 giờ bằng NestJS & OpenAI. Ứng dụng này tóm tắt, xác định ý định và mức độ ưu tiên của ticket từ văn bản thô. Ý tưởng tập trung vào việc giúp các doanh nghiệp B2B xử lý email hiệu quả hơn.

#AI #OpenAI #NestJS #phanloai #trive

https://www.reddit.com/r/SideProject/comments/1p95inj/i_built_an_ai_support_ticket_triage_tool_in_4/

Универсальный Backend for Frontend для всех платформ RUTUBE

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя. А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

https://habr.com/ru/companies/habr_rutube/articles/970690/

#bff #nestjs #nodejs #архитектура_приложений #рефакторинг #fastify #redis #backend #frontend #видеосервисы

Универсальный Backend for Frontend для всех платформ RUTUBE

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя. А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

https://habr.com/ru/companies/habr_rutube/articles/970690/

#bff #nestjs #nodejs #архитектура_приложений #рефакторинг #fastify #redis #backend #frontend #видеосервисы

Универсальный Backend for Frontend для всех платформ RUTUBE

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя. А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

https://habr.com/ru/companies/habr_rutube/articles/970690/

#bff #nestjs #nodejs #архитектура_приложений #рефакторинг #fastify #redis #backend #frontend #видеосервисы

Универсальный Backend for Frontend для всех платформ RUTUBE

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя. А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

https://habr.com/ru/companies/habr_rutube/articles/970690/

#bff #nestjs #nodejs #архитектура_приложений #рефакторинг #fastify #redis #backend #frontend #видеосервисы

В России блокируют доступ к документации #NestJS, поэтому я решил создать Pull Request, который позволит публиковать её в #GitHubPages.
Кто не может получить доступ к документации вы можете сделать это по этой ссылке https://vladimirleonidovich.github.io/docs.nestjs.com/ или самостоятельно сделать форк репозитория из этого Pull Request https://github.com/nestjs/docs.nestjs.com/pull/3348 с возможностью публикации документации в GitHub Pages. Будет работать до тех пор, пока не заблокируют #GitHub.
#цензура