Node.JS *

Привет, друзья!

В этой серии из 2 статей-туториалов мы с вами разработаем клиент-серверное (фуллстек — fullstack) приложение с помощью Next.js и TypeScript.

• Руководство по Next.js.
• Карманная книга по TypeScript.

1. Наше приложение будет представлять собой блог — относительно полноценную платформу для публикации, редактирования и удаления постов.
2. Мы реализуем собственный сервис аутентификации на основе JSON Web Tokens и HTTP-куки.
3. Данные пользователей и постов будут храниться в реляционной базе данных SQLite.

В первом туториале мы подготовим и настроим проект, а также реализуем серверную часть приложения с помощью интерфейса роутов (API Routes), во втором — разработаем клиента и проверим работоспособность приложения.

Обратите внимание: данный туториал рассчитан на разработчиков, которые имеют некоторый опыт работы с React и Node.js.

Для тех, кого интересует только код, вот соответствующий репозиторий.

Интересно? Тогда прошу под кат.

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

Стал делать и подумал, а почему бы мне не добавить туда своих тараканов. Я решил добавить две конструкции:

{namesubexpression} - вызов под выражения по имени "namesubexpression",
($namesubexpression:BodyExpression) - описание под выражения с именем "namesubexpression".

Само описание под выражения может встречаться в любом месте структуры регулярного выражения и игнорируется при поиске, подобно закоментированым: (#MeComment).
Сразу же возникает проблема бесконечной рекурсии.
Вот пример рекурсивного регулярного выражения, который недопустим: ($E:{E}){E}

Конечно, я сделал стадию валидации и такие поисковые конструкции просто не допустятса в поисковую машину. Также валидацию не пройдет выражение, которое содержит в себе вызов не описанного под выражения.

Вот пример текста, который можно спарсить рекурсивным регулярным выражением (РРВ): [[[[[A]]]]]
А вот его РРВ: ($RRE:\[({RRE}|A)\]){RRE}

Я также решил добавить три зарезервированные конструкции:
{:String} соответствует выражению: (("(\\.|[^"])*")|('(\\.|[^'])*'))
{:Digit} соответствует выражению: (-?[0-9]+.?[0-9]*[Ee]?-?[0-9]*)
{:Name} соответствует выражению: ([A-Za-z][A-Za-z0-9]*)
Но их поисковая система не использует структурные элементы аналогичных выражений, а организованна встроенным машинным поиском, который работает значительно быстрее и возвращает одну целую строку текста, в которой содержится всё тело найденного соответствия а не части для каждого компонента в аналогичных регулярных выражениях.

Node.js это кроссплатформенная среда выполнения JavaScript с открытым исходным кодом для выполнения JavaScript вне браузера. Он поддерживается движком Google V8, что делает его чрезвычайно производительным.

Асинхронная среда выполнения, управляемая событиями

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

Технически, тот факт, что Node.js использует один поток не на 100% верно. Node.js на самом деле использует много потоков, но цикл событий (Event Loop - о котором мы упомянем позже), и пользовательский код выполняются в одном потоке. Если мы ознакомимся с документацией, то увидим, что Node.js использует управляемым событиями неблокирующую модель ввода-вывода (event-driven, non-blocking I/O model), которая делает его легким и эффективным.

Что такое управляемая событиями неблокирующая модель ввода-вывода?

Согласно руководству по Node.js, блокирующие методы выполняются синхронно, а неблокирующие методы выполняются асинхронно. Предположим, что нам нужно написать некоторый код, чтобы прочитать содержимое файла и распечатать его в консоли. Есть два способа сделать это в узле: синхронно и асинхронно.

Давайте сначала посмотрим синхронную версию:

В приведённом ниже коде происходит следующее: во-первых, нужно подключить модуль FS. Во второй строке вызывается метод readFileSync, и результат сохраняется в переменной data. Основной поток Node.js блокирует эту строку до тех пор, пока не будет прочитано все содержимое файла. Затем содержимое выводиться в консоль, и, в самом конце будет выведено в консоль “Done”.

На примере простой задачи клонирования ключей объекта посмотрим, есть ли реальные альтернативы по производительности столь презираемой JavaScript-разработчиками функции eval().

Подобная задача возникает, если оригинальное значение ключа надо оставить у объекта, а как-то обработанное - положить рядом в новый соответствующий ключ. То есть, для начала, из {"a" : 1, "b" : 2} надо получить {"a" : 1, "a-copy" : 1, "b" : 2, "b-copy" : 2}.

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

Привет, друзья!

В этой статья я немного расскажу вам о Bun — новой среде выполнения JavaScript-кода.

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

К слову, в рейтинге "Восходящие звезды JavaScript 2022" Bun стал победителем в номинации "Самые популярные проекты".

Интересно? Тогда прошу под кат.

Однажды я захотел создать небольшую NPM библиотеку по всем “best practices” - с покрытием тестами, написанием документации, ведением нормального версионирования и changelog'а и т.п. Даже написал пару статей, которые в деталях описали, какие вопросы решает библиотека и как её использовать. И одной из интересных для меня меня задач при создании библиотеки была задача по максимальному уменьшению размера выходного NPM пакета - того, что в конечном итоге в теории будет использовать другой программист. И в этой статье я бы хотел описать, к каким методам я прибегал для того, чтобы достигнуть желанной цели.

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

Эта статья подробно описывает создание небольшого скрипта на Node.js для выгрузки векторных иконок из Figma в проект, а также универсального компонента для разных видов иконок, который удобно использовать в своём приложении.

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

Под катом – довольно длинный (мы предупредили!) и подробный текст, но с большим количеством полезного кода.

На одном из прошлых мест работы я поддерживал консольную Node.js-утилиту, которая публиковалась в NPM. Утилита использовала commander, содержала довольно большое количество подкоманд, и все они требовали описания в README-файле, которое нужно было не забывать обновлять при каждом изменении. Несколько лет спустя я нашел решение, используя не слишком привычные для экосистемы Node.js технологии.

В этой статье: много моей любви к Jupyter-подобным ноутбукам, инструкция про то, как затащить Python-пакет в NPM и чуть-чуть анализа трекерной музыки.

Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрали, как создать аутентификацию с помощью библиотеки Passport, а сегодня мы рассмотрим такие манипуляции, как добавление, редактирование, удаление и получение задач. Для начала давайте разберём HTTP и некоторые типы запросов.

Правительство РФ анонсировало выделение до $50 млрд для выхода РФ в топ-20 стран—разработчиков Игр к 2030 году. Возможно в скором времени разрабатываемый мной сервис наконец увидит свет.

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

Привет, меня зовут Анастасия Пласкевич, я фронтенд-разработчик. Недавно на проекте я разбиралась с зависимостями и углубилась в эту тему так, что собрала небольшой доклад о том, что такое Lockfile, как работает yarn.lock, как решать проблемы с зависимостями в проекте и делать базовую проверку безопасности, а доклад адаптировали в эту статью.

Статья будет полезна разработчикам JS/TS приложений, которые столкнулись с некорректным поведением пакетов в своем проекте, или со старым кодом, который содержит уязвимости. Базовый аудит зависимостей будет уместен на любом проекте: всегда находятся вещи, которые можно поправить. 

По разным причинам я уже как пару лет я не использовал ВК для связи с друзьями/коллегами - все ушли в telegram. Но в ВК все равно приходилось заходить, так как там осталось самое дорогое - группы с мемами, картиночками, анекдотами и всякое такое. Самому смотреть неудобно, друзьям - не отправить. Если интересно, как я решил эту проблему за один вечер - добро пожаловать под кат.

Назначение

Этот документ призван расширить текущую модель угроз и предоставить подробные рекомендации по обеспечению безопасности приложения Node.js.

Почти 15 лет назад Райан Томайко (Ryan Tomayko) написал книгу "The Thing About Git" (Про Git). Это было время, когда SVN (Subversion - система управления версиями) все еще активно использовался. Мало кто понимал, почему Git такой особенный, и тогда я тоже не принадлежал к их числу. Статья Райана уловила суть Git'а и убедила меня перейти на него.

Уже было написано множество статей о том, почему и как следует принимать Fastify, но сейчас 2022 год, а Express - самый традиционный фреймворк веб-сервера для Node.js - по-прежнему имеет примерно в 49 раз больше еженедельных загрузок npm, чем Fastify:

Скорее всего, вы слышали о «12 стартапах за 12 месяцев» или о продуктах, которые родились на хакатонах. Такие истории всегда вдохновляли меня, поэтому я придумал свой челлендж: я сделал простой сервис за выходные.

Всем, привет! Меня зовут Данильян, я работаю в Самокате фронтенд-разработчиком и разрабатываю бэкофисное приложение с использованием React. Помимо работы, у меня есть несколько сайд-проектов, в которых я широко использую Deno. В последнее время этот проект радует новыми фичами чуть ли не каждую неделю и об одной из них я хотел бы рассказать в этом посте.

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

Основным языком разработки у нас, в TIMELESS, является TypeScript, как на frontend,  так и на backend.  Поэтому в рамках идеи типизации всего и вся для работы с БД мы выбрали Prisma, которая позиционирует себя как “Next generation ORM for Node.js and TypeScript”.

Спустя год применения Prisma хотелось бы поделиться опытом ее использования при работе с PostgreSQL из Node.js приложения.

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

Прогресс в этой области действительно поражает. От галлюциногенных картинок DeepDream до шедевров от Stable Diffusion прошло каких-то 8 лет. И ведь это не единственный лидер сейчас. Здесь же мы имеем Midjorney, Imagen, Dalle, Kandinsky в конце концов. И знаете, мне это что-то напоминает.

Можно ли, зная Ruby, писать код на Node.js? А можно ли с командой Ruby-разработчиков успешно поддерживать и развивать большой легаси монолит на ноде? Можно! А как, расскажет Дмитрий Матвеев, СТО «Поток.Диджитал» и спикер Ruby Russia 2022.