NestJS *

Эта книга не столько о коде, сколько о целостном подходе к взаимодействию с продуктологами и подотчетными разработчиками. 

Она о том, как происходит переход, смена парадигмы или мышления у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы как с новыми, так и с унаследованными проектами во фронтенде, бэкенде и при развертывании». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

Когда команда разработчиков начинает активно расти, неизбежно возникают вопросы консистентности кода. Разные стили написания, различные подходы к форматированию и отсутствие единых стандартов могут серьезно замедлить разработку и усложнить поддержку проекта.

В данной статье мы рассмотрим пошаговую настройку ESLint и Prettier на примере нашего веб-приложения, построенного на Next.js и TypeScript.

Несмотря на обилие моделей (а я время от времени использую четыре топовые), всё-таки на стыке моих технологий GPT-4.1 даёт лучший результат по сравнению с другими.

 ... я каждый раз сохраняю эти компоненты в файл Google Документы. И каждый раз при генерации новой функции или целого компонента я "вскармливаю" текст из этого документа именно в формате текста. В общем, эта штука работает хорошо.

Пожалуйста, объясни как ты понял мою проблему, почему я считаю что это важно, как ты собираешься это решать и что будет правильным решением.

Как избежать хаоса в безопасности NestJS при применении guards. Вместо разнообразных наборов проверок на каждом контроллере лучше перейти на многослойную систему глобальных guards, что упростит масштабирование системы и повысит ее безопасность.

Привет, Хабр!

В этой статье — история запуска Telegram Mini App, куда за трое суток пришло 100.000 реальных пользователей.

Покажу, как мы масштабировали Node.js приложения на многоядерных серверах, увеличивали RPS в 10 раз, боролись с N+1 проблемой в MongoDB и снижали нагрузку на CPU. А ещё расскажу как мы быстро настроили мониторинг через Grafana, подключили Cloudflare и интегрировали Sentry. Поделюсь практическими инсайтами о том, на что стоит обращать внимание в первую очередь, и как эти инструменты помогли нам оперативно находить узкие места и устранять сбои в реальном времени. Всё, о чём будет в этой статье, основано на том, что действительно сработало. Кроме того, расскажу, какие моменты мы упустили до запуска.

Это разбор с цифрами, графиками и практическими выводами. Он может сэкономить вам время, нервы и деньги, если вы готовитесь к запуску Telegram Mini App или просто работаете с Node.js-приложениями, которые могут оказаться под серьёзной нагрузкой.

Это вторая часть истории — про то, как мы запустились и что сломалось первым после релиза. Тут будет про то, как мы это чинили и какие решения приняли, чтобы приложение продолжало работать под нагрузкой.

Первая часть про подготовку к запуску доступна здесь.

Привет, меня зовут Михаил Шпаков, я руковожу разработкой в Timeweb Cloud — это крупный облачный провайдер с большой командой и множеством внутренних и внешних продуктов.

Последние несколько лет в работе стало больше менеджмента: процессы, планирование, встречи, координация команд. Со временем я начал ловить себя на мысли, что очень хочется что-то поделать руками. Вернуться к коду, попробовать собрать продукт от начала и до конца, пройти путь не как менеджер, а как разработчик и автор идеи. Заодно — погрузиться в продуктовую часть, потрогать всё: интерфейсы, фичи, маркетинг, пользовательский опыт.

Так родился statuser.cloud — простой сервис для мониторинга доступности сайтов и серверов. Я хотел сделать его:

— с минималистичным и понятным интерфейсом,

— ориентированным в первую очередь на разработчиков, девопсов, админов,

— с набором действительно нужных фич, ничего лишнего.

В этой статье я расскажу, как вечерами и на выходных делал Statuser (и продолжаю делать): с какими проблемами сталкивался, как выбирал стек, как не бросил проект на полпути — и что получилось в итоге.

Привет, Хабр!

В этой статье — история запуска Telegram Mini App, куда за трое суток пришло 100.000 реальных пользователей.

Покажу, как мы масштабировали Node.js приложения на многоядерных серверах, увеличивали RPS в 10 раз, боролись с N+1 проблемой в MongoDB и снижали нагрузку на CPU. А ещё расскажу как мы быстро настроили мониторинг через Grafana, подключили Cloudflare и интегрировали Sentry. Поделюсь практическими инсайтами о том, на что стоит обращать внимание в первую очередь, и как эти инструменты помогли нам оперативно находить узкие места и устранять сбои в реальном времени. Всё, о чём будет в этой статье, основано на том, что действительно сработало. Кроме того, расскажу, какие моменты мы упустили до запуска.

Это разбор с цифрами, графиками и практическими выводами. Он может сэкономить вам время, нервы и деньги, если вы готовитесь к запуску Telegram Mini App или просто работаете с Node.js-приложениями, которые могут оказаться под серьёзной нагрузкой.

Это первая часть истории — про то, как мы готовились к запуску, что предусматривали и на что делали ставку.

Во второй части будет про то, что именно сломалось первым после релиза, как мы это чинили и какие решения приняли, чтобы приложение продолжало работать под нагрузкой.

Асинхронность в JavaScript, где и как использовать в web разработке на frontend и backend. Цепочка промисов и их параллельные выполнение.

Как собирать чистые и переиспользуемые DTO в TypeScript и NestJS с помощью миксинов? Модульность, валидация и никакого дублирования — всё в одном месте.

Эффективный мониторинг состояния веб-приложений остается одной из самых актуальных проблем в современной разработке. В погоне за быстрой реализацией продукта и выводом его на рынок, довольно часто приходится жертвовать настройкой системы мониторинга - даже базовой.

Однако здесь кроется скрытая угроза. Такой подход в разы усложняет отладку и дальнейшее сопровождение сервисов, а иногда это приводит к полнейшему хаосу при возникновении тех или иных непредвиденных ошибок...

Ситуация, знакомая многим: разрабатываем сервис, пилим в нём фичи, развиваем продукт… но постепенно всё выходит из под контроля. Кодовая база разрастается, зависимости становятся сложнее. Команда разработчиков тратит больше времени на распутывание существующих проблем, чем на создание новой функциональности.

Хорошая новость: распутать спагетти-код можно по-разному, и иногда срабатывают не самые очевидные способы. В нашем случае помогла комбинация действий: не просто выделение части кода в отдельные микросервисы, но и параллельная реализация архитектурного подхода DDD Lite (в связке с принципами чистой архитектуры).

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

ЕСИА даёт возможность пользователям зайти в государственный или негосударственный сервис, чтобы подать заявление, сдать отчет или обратиться в органы власти. ГИС ЖКХ, Работа России, портал ФНС России, ЦИАН и Авто.ру - этот список ежегодно пополняется. Для успешного подключения к системе важно соблюдать определенные требования и следовать установленным этапам интеграции.

В этой статье мы рассмотрим основные организационные аспекты подключения информационных систем к ЕСИА, а также один из вариантов его реализации.

Изначально интернет в современном его понимании Тимом Бёрнерс-Ли и Робертом Кайо задумывался для умных людей. Прежде всего для физиков-ядерщиков, а также для химиков, биологов и т.д. Но, к сожалению, со временем Интернет выродился в ресурсы для самых недумающих. В полном соответствии с мировым трендом на идиотократию. Сеть заполнили миллиарды постов с фото о том, кто что покушал, и кто где покакал. Я про FaceBook с Инстаграммами Вашими брюзжу. Нет, я понимаю, в мире, в котором 23% людей теоретически не в состоянии научиться читать, капиталистам глупо вкладывать деньги в ресурсы для умных - не окупятся! Лайкнуть котика может и даун, а вот вникнуть в сложные идеи Платона - мало лишь кто (на мой взгляд не более 2%). Но с другой стороны это что ж, умным людям вообще оставаться без созданных под их нужды ресурсов? Не порядок!

В данной статье будут не только теоретически размышления об идеальном сайте для умных, но и заготовка прототипа реализации такого проекта, с открытым исходным кодом в github, и с предложением влиться в community. Всё как мы любим. Поехали!

Подписки в GraphQL позволяют клиенту подписаться на изменения данных на сервере. Например, в чате с их помощью можно получать уведомления о сообщениях, их удалении или изменении. В отличие от обычных запросов, подписки работают асинхронно, поддерживая постоянное соединение через WebSocket. В этом случае сервер может в любое время послать запрос клиенту. В то же время для обычных запросов(queries), чтобы увидеть изменение данных, клиенту нужно запрашивать их заново каждый раз. А ещё с помощью GraphQL Subscriptions и библиотеки Relay можно создать собственный мессенджер.

Если, когда вы смотрите на NEST.js вас гнетёт необъяснимая тоска. Если вы не можете понять воодушевления и радости от использования декораторов. Если рассмотрение очередного NEST-инструмента вызывает лёгкое недоумение — не стесняйтесь, вы не одиноки.

NEST.js – это фреймворк для написания REST серверов под Node.js на языке TypeScript, который потом транспилируется в JavaScript. Он написан поверх библиотеки Express (или Fastify – можно выбрать) и привносит модные концепции – Inversion of Control, Dependency Injection и т. п. в мир JavaScript. Нередко описание этого инструмента сопровождается восторженным настроением. Как мне кажется, эта восторженность несколько преувеличена, сложность излишняя, а чудо-сила отсутствует. Некоторые неудобства вынудили нас отказаться от его использования после нескольких лет разработки.

Если вас заинтересовала тема авторизации, подразумеваю, что вы уже итак знаете что такое Telegram Mini Apps. Поэтому не буду долго размусоливать вступление и перейду сразу к делу.

Поехали!

Привет, Хабр! Я - Frontend Developer в МТС Диджитал. Все чаще и чаще я натыкаюсь на сообщения и комментарии пользователей в различных социальных сетях про Server-Side Rendering.

Обычно эти жалобы о том, кто-то недоволен зависимостью Next.js от Node.js-сервера. Кто-то сталкивается с ограничениями динамического роутинга при статической генерации. Исходя из этого некоторые люди писали в комментариях что-то вроде: "Вы же не ожидали, что SSR-фреймворк решит все проблемы разом?"

Большинство моих коллег с других компаний в принципе не понимают зачем я беру Nuxt почти во все свои проекты и задают вопросы. На первый взгляд это вполне логично. Какой смысл брать SSR фреймворк, если ты выключаешь в нем SSR. На примере Nuxt, SSR можно выключить одним булевым флагом в конфиге:

Представьте мир, где каждый персонаж живёт своей жизнью: принимает решения, взаимодействует с окружающей средой и даже эволюционирует. Где почва, растения и ресурсы подчиняются сложным алгоритмам, а нейронные сети управляют поведением тысяч существ. Это не сценарий для нового блокбастера — это проект, над которым я работаю.

В этой статье я расскажу, как с помощью NestJS, TypeORM и Tensorflow.js создаю виртуальную вселенную, которая “дышит” и развивается. Мы разберём:

В мире разработки всегда наступает момент, когда необходимо переосмыслить используемые технологии. В Hikasami, наблюдая за ростом используемых ресурсов и усложнением бизнес-задач, мы столкнулись с выбором: продолжать использовать привычный NestJS или искать новое решение, способное обеспечить высокую производительность и масштабируемость. Ответ оказался очевиден - нужно перейти на Go.

NestJS давал нам возможность быстро и удобно создавать приложения благодаря своей структуре и широкому набору функционала. Однако со временем мы заметили, что стандартные средства фреймворка не вполне соответствовали требованиям по по скорости обработки запросов и эффективному использованию ресурсов. В условиях растущей нагрузки производительность играла ключевую роль, и нам пришлось искать альтернативы.

Почему Go?