Асинхронность в 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?
Я разработал небольшое фулстек-приложение в качестве примера REST + WebSockets бойлерплейта на NestJS и Angular. В приложении используется PostgreSQL для хранения данных, Redis для кэширования и Minio для работы с файлами. Изначально целевой средой для развертывания был Kubernetes, но для ускорения разработки и тестирования MVP я решил использовать бесплатные облачные сервисы: Supabase для инфраструктуры и Vercel для деплоя бэкенда и фронтенда.
Сложно внедрить DDD в NestJS, не запутавшись в абстракциях? В статье рассмотрены частые ошибки - от комбайна в контроллерах до формальных Value Objects. Разбираем, как выделять слои (Domain, Application, Infrastructure, Interface), правильно использовать Entities и репозитории и создавать поддерживаемую архитектуру.
NestJS — это прогрессивный фреймворк для построения эффективных и масштабируемых серверных приложений на Node.js. Он использует современные возможности JavaScript и TypeScript, вдохновлен архитектурными паттернами Angular и поддерживает модульность, инъекцию зависимостей и другие современные подходы.
TypeORM — это ORM (Object-Relational Mapping) инструмент, который позволяет взаимодействовать с базами данных, используя объекты и классы, что упрощает разработку и поддерживает различные СУБД, такие как PostgreSQL, MySQL, SQLite и другие.
Сочетание NestJS и TypeORM предоставляет мощный инструментарий для разработки REST API, обеспечивая высокую производительность, модульность и удобство поддержки кода.
В этой статье я расскажу о добавлении нового поля workUntilDate с типом timestamp(6) в таблицу Webhook базы данных Webhook.
На стороне фронтенда (в Angular-приложении) для этого поля будет реализован удобный календарь с возможностью выбора времени.
Пользователи смогут задавать дату и время в своей временной зоне, тогда как бэкенд (NestJS-приложение) будет сохранять введённые данные в базе данных в формате UTC+0.
Кроме того, интерфейс календаря и другие элементы, отображающие даты, будут адаптированы под язык и временную зону пользователя.
Как мы создали микросервисное приложение для анализа вакансий с hh.ru: Docker, Kafka, Elasticsearch и ещё немного магии
Этот пост не претендует на масштабность, но поскольку я последовательно документирую все этапы разработки бойлерплейта в формате статей, решил описать и эту задачу.
Здесь я приведу пример миграции базы данных для добавления нового поля, а также покажу, как реализовать соответствующий функционал на бэкенде и фронтенде для изменения этого значения.
В этой статье я хотел бы поделиться своим опытом по внедрению поддержки временных зон в фулстек-приложение, построенное на NestJS и Angular. Мы узнаем, как сохранить настройки таймзоны пользователя в базе данных и правильно использовать их при взаимодействии с сервером через REST и веб-сокеты.
В этой статье я добавлю поддержку нескольких языков в NestJS и Angular приложениях, для сообщений в ошибках, уведомлениях и данных полученных из базы данных.
