Node.JS *

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

Что такое Backend-for-Frontend (BFF)?

Backend-for-Frontend (BFF) — это архитектурный паттерн, который помогает устранить разрыв между фронтендом и бэкендом. BFF выступает промежуточным слоем, который адаптирует данные и логику бэкенда под нужды конкретного фронтенда. Это позволяет фронтенд-командам работать с API сразу, а бэкенд-разработчикам подключать логику по мере готовности, что значительно ускоряет процесс разработки и снижает количество доработок.

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

WhatsApp выглядит привлекательным способом оповещения. К примеру, в нашем ТСЖ недавно создали WhatsApp-группу и предполагается что WhatsApp есть у всех жителей. А ещё бывают люди, подключающие домовой чат в качестве эпизодического развлечения: отключают для него уведомления и просто копят непрочитанные.

Уже более десяти лет я регулярно читаю Хабр, однако, как и многие другие пользователи, обычно концентрируюсь на статьях из своей ленты новостей. Это практично, но существует вероятность упустить интересные публикации, которые остаются вне моего внимания. Чтобы разобраться в актуальных тенденциях, я решил провести собственный анализ самых популярных публикаций на Хабре за январь 2025 года.

Для сбора данных я использовал свой парсер на Node.js. Работать пришлось напрямую с HTML, так как скрытого API Хабра я не нашёл. К счастью, внутри HTML разметки каждой статьи находится JSON с ключевыми параметрами: автор, дата, просмотры, рейтинг — это упростило парсинг.

Я обработал все статьи, опубликованные в январе, но в итоговый список попали только те, что набрали более 30 тысяч просмотров или рейтинг выше +30.

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

Что мы НЕ будем делать: разрабатывать чат-бота, который «любит» за вас. Эту задачу лучше оставить вам.

Цель - организовать начало диалога.

Со времен появления скринсейвера «Ленты» (ориг. «Ribbons») на Windows 7, эта заставка была стандартом для всех моих рабочих мест, благо в новых версиях Windows (8, 10, 11) эта заставка остается и по сей день. Однако с момента «импортозамещения» десктопной Windows на десктопную Linux, особенно актуального с 2022 года, хотелось получить эту или хотя бы похожую заставку и на этой свобоной платформе. Но вот незадача — нормальный порт найти мне не удалось. Может, конечно, плохо искал (скиньте ссылку в комментариях, если кто‑то нашел что‑то работоспособное).

И тут на просторах github очень удачно нашелся вот этот репозиторий. Автор в canvas с использованием JS наваял на мой взгляд очень даже симпатичную анимацию по мотивам того самого скринсейвера «Ленты».

Причем он в README отметил, что пытался сделать из этой анимации PWA (Progressive Web App), но почему‑то у него ничего из этого не вышло, читай «failed». Вопрос, почему человек, наваявший такой годный «генератор лент», не смог в PWA, оставим за скобками.
А тут как раз я, начавший недавно по служебной необходимости, изучать всем известный фреймворк Electron для создания кроссплатформенных настольных web‑приложений... Чем не альтернатива PWA?

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

С самого начала разработки курьерки мы генерировали много идей по улучшению алгоритмов. Мы не стеснялись выкатывать кучу фичей и проверять их работоспособность А/Б тестами. Не было ни дня, когда у нас не крутились эксперименты в продакшене. Что-то мы выкидывали, что-то оставляли, но не хардкодили, чтобы иметь гибкость. Страна большая и у каждого региона свои особенности, которые влияют на плотность заказов, логистику и потребность в курьерах. Поэтому наборы фичей и их значения различаются. Мы поняли, как отдельная фича влияет на продуктовые метрики, но как набор фичей в совокупности влияет на итоговый результат?

Запускать А/Б тесты для каждого набора фичей слишком долго и затратно, ведь команде надо создавать и тестировать новые фичи. Но найти наилучшие комбинации фичей для разных регионов и городов быстро с наименьшими затратами ресурсов команды — было жизненно необходимо. Поэтому мы создали копию реального мира, чтобы внутри неё пробовать самые смелые идеи.

Так как я активно использую возможности Flyway, такие как repeatable migrations и callbacks, и не хочу от них отказываться, а аналогов этих функций в других системах миграции нет, я решил написать собственный лёгкий клон Flyway на Node.js для PostgreSQL.

Недавно я познакомился с сервисом Strapi и почти сразу получил задачу "Настроить отправку файлов в S3 из Strapi". Это мой первый опыт в работе со Strapi, но не первое подключение к S3.

В данной записи я хотел бы поделиться своим опытом и показать пару кастомных скриптов для работы с облачным хранилищу S3.

Привет, Хабр! Мне нравятся всякие скрипты и автоматизация, но ведь и социальную жизнь поддерживать как-то надо, правда? Вот и я подумал: если не хватает времени лайкать посты друзей ВКонтакте, почему бы не автоматизировать этот процесс?

Социальные сети пожирают время – и не заметить это сложно. Кажется, только открыл VK, чтобы посмотреть один пост друга, а уже утонул в бесконечной ленте новостей, чужих историй и рекламы!

Как уследить за всеми постами "друзей" и родственников ВКонтакте? И стоит ли оно того?

А ведь это особенно сложно, если у тебя насыщенная работа, дедлайны или проект горит. Хочется быть в курсе, поддерживать контакты, но постоянно мониторить ленту – путь в никуда.

И всё же, как остаться на связи, не тратя свою жизнь на бесконечный скроллинг? Лайк – это цифровой жест внимания, который приятен другому человеку, ведь вы в друзьях друг у друга.

Безумные штуки иногда можно найти в интернете. Листая 2024 JavaScript rising stars (https://risingstars.js.org/2024/en#section-all) обнаружил там удивительного зверя - Postgres скомпилированный через emcc в WASM версию, и допиленный до состояния, когда его можно запустить внутри JS-процесса (браузер/Node.js/Bun/etc).

Как он устроен, как им пользоваться, и, самое главное, зачем? Добро пожаловать под кат :)

JSON - наш повседневный помощник, но вместе с другими текстовыми форматами он может преподнести неприятные сюрпризы: потеря точности чисел, громоздкие файлы, путаница с датами. Рассказываю, как этих проблем избежать и повысить эффективность с помощью стриминга в Node.js, а также MessagePack и Protobuf. Узнайте, где подводные камни и как их обходить на практике!

Если хотите понять, в чём именно проблема на иллюстрации, загляните в статью — там всё разобрано :-)

Сложно внедрить DDD в NestJS, не запутавшись в абстракциях? В статье рассмотрены частые ошибки - от комбайна в контроллерах до формальных Value Objects. Разбираем, как выделять слои (Domain, Application, Infrastructure, Interface), правильно использовать Entities и репозитории и создавать поддерживаемую архитектуру.

Я уже давно пишу статьи про различные аспекты IT-технологий, инвестиции, автоматизацию и умные дома на разных площадках: Хабр, Т—Ж, СмартЛаб, Пикабу, VC.ru и других.

За всё время накопилось примерно 250 статей, которые по итогу свёл в таблицу. Но вот задумываться о популярности статей и их реальном эффекте стал относительно недавно.

Почему я решил собирать статистику публикаций?

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

Однако очевидно одно - статистика заставляет посмотреть на материалы со стороны. Например статья про то, как я при помощи двух скриптов смог автоматически сгенерировать опись документов для 700 страниц на непрофильном Пикабу собрала три месяца назад почти 75 тысяч просмотров и 80 комментариев, а на Хабре эта же тема была не особо популярна.
Или статья про то, что читали на Хабре в 2024 году: анализ статей с Node.js, Google Sheets и каплей ChatGPT - собрала на Хабре три недели назад рейтинг +68, но «всего» 7 тысяч просмотров.

Зачем я написал Open Source скрипт?

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

Это Open Source скрипт, размещенный на Гитхабе, который состоит из Google Apps Script и Node.js частей и обе эти части работают с итоговой сводной Google Таблицей.

Добро пожаловать в путешествие по динамичному миру реактивного программирования! Эта увлекательная парадигма направлена ​​на создание быстро реагирующих, отказоустойчивых и адаптируемых приложений, которые легко и практически мгновенно управляют огромными объемами данных.

Представьте себе, что вы пишете программу, которой необходимо мгновенно реагировать на изменения — будь то ввод пользователя, сообщения из других систем или потоки данных в реальном времени. Именно здесь проявляется реактивное программирование, которое делает его краеугольным камнем современной разработки программного обеспечения, особенно веб-приложений и мобильных приложений.

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

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

В этой статье мы углубимся в суть реактивного программирования, сосредоточив внимание на его реализации с использованием JavaScript/TypeScript в среде Node.js. Мы также будем следить за глобальным контекстом, который применим ко многим языкам программирования и платформам.

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.

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

Эта статья предназначена в первую очередь для веб-разработчиков. Я не являюсь экспертом в области сетей, администрирования или DevOps, поэтому представленный материал не углубляется в сетевые аспекты.

Из любопытства, я как то задался вопросом практического использования разных номеров портов: что они означают для разработчиков, почему используются определенные порты, и какие приложения чаще всего запускаются на них. Цель статьи — пролить немного света на эти “магические” циферки с точки зрения их прикладного применения веб-разработчиками.

Исторически приложения на Node.js (например, с использованием фреймворков Nest.js или Express) и Webpack по умолчанию запускаются на 3000 порту, если не вносить изменения в базовую конфигурацию. Vite, напротив, изначально использует порт 5173. Это может быть связано с отсылкой к названию "Vite" (если подключить немного воображения).

С технической точки зрения нет разницы, на каком порту запускать локальный сервер для разработки — это может быть 1050, 10900 или любой другой. Главное, чтобы порт был:

Приветствую Хабр!

Решил поделиться своим проектом, который позволяет быстро создать инструмент для тестирования нагрузки HTTP-запросов (GET и POST) к заданному API. Этот инструмент идеально подходит для разработчиков и тестировщиков, которые хотят проверить производительность своих API с минимальными затратами времени на настройку.

Ничто так не бесит при изучении новых пакетов/библиотек, как неработающие примеры из официальной документации. До последнего не веришь, что авторы библиотеки так лоханулись с исходниками примеров. Считаешь, что программисты потратили кучу своего времени на разработку, тестирование и продвижение пакета. И что они не могли выложить неработающие примеры. А если примеры не работают, то значит что-то не так у тебя. То ли VPN новый глючит, то ли антивирус душит библиотеку, то ли устаревшие версии какого-то ПО/драйверов/библиотек конфликтуют. В данной статье рассказывается о моем опыте делания рабочим примера npm пакета 'csrf-csrf' из официальной документации.

Кому нужно срочно - вот github с исходниками: https://github.com/korvintaG/csrf-csrf_demo. Важно - обращайте внимание на комментарии, особенно те, в которых много звездочек.