Перевод статьи Alister Scott: Five reasons why Playwright is better than Cypress
На основании проведенного сравнения, могу смело рассказать о причинах, почему Cypress все еще проигрывает конкуренцию.
Привет, друзья!
На досуге разработал шаблон Node.js-сервера для аутентификации/авторизации, которым хочу с вами поделиться. Надеюсь, кому-нибудь пригодится.
Обратите внимание: шаблон — это всего лишь хорошая отправная точка, с которой можно начать разработку собственного сервиса. Он не предназначен для использования в продакшне как есть, поскольку настройки, определяющие гибкость его архитектуры и уровень его безопасности, зависят от потребностей конкретного приложения и должны быть реализованы вручную.
Также обратите внимание, что в коде имеется несколько console.log для облегчения процесса разработки приложения. В продакшне они не нужны. В производственном режиме также не следует возвращать столь информативные message.
Если возможностей, реализованных в шаблоне, окажется недостаточно, вот парочка более продвинутых инструментов:
oidc-client — разработчик отказался от дальнейшей поддержки, новый мейнтейнер пока не нашелсяoidc-provider — рекомендация моих более опытных коллегЕсли вас интересует полноценная платформа для аутентификации/авторизации "из коробки", рассмотрите возможность использования Auth0.
Сервер реализован с помощью Express.js
В качестве базы данных используется MongoDB Atlas
Как безопасно и без лишнего труда открыть доступ к этим учетным данным и использовать их при разработке на Node.js? Ответу на этот вопрос посвящена эта статья.
Содержание:
Подключение к экземпляру Kafka
Безопасная передача учетных данных
Привязка сервиса в Kubernetes
Простота использования привязок сервисов с помощью kube-service-bindings
Настройка привязки сервисов в OpenShift
Node.js и Apache Kafka: дополнительные ресурсы
Node.js имеет несколько способов исполнения CPU-bound заданий:
1. Просто запустить CPU-bound задачу в одном процессе, блокируя event loop. Кто-то может возразить, что это совсем не вариант, но если этот процесс был специально создан для этой задачи, то почему бы и нет. Правда не у всех есть пара дополнительных ядер.
2. Создать отдельные процессы (Child Processes), распределить между ними задания.
3. Создать cluster и заставить работать отдельные процессы в нем.
4. Использовать Worker Threads и создать несколько дополнительных потоков исполнения.
5. Попросить C++ разработчика написать C++ Addon, который загадочным образом выполняет CPU-bound задания. В конце концов, думаю все слышали старинные легенды про компилируемые языки программирования и о том, что “нативная” реализация ― это всегда успех (на этой фразе где-то в мире должен заплакать React Native разработчик, смотря на перформанс своего приложения).
Зачем вам это нужно?
При разработке кода на стороне сервера время от времени возникает проблема, которую очень трудно воспроизвести, наблюдаются утечки памяти или скачки процессора, которые вы не можете смоделировать локально, либо необходимо добавлять специальные журналы в приложение. При локальной разработке приложения используется инспектор Node.js для отладки и создания снапшотов памяти/процессора, которые помогут вам найти проблему, но как сделать то же самое в удаленной среде? К счастью, Node.js располагает отличной поддержкой для удаленной отладки, и в этой статье мы рассмотрим, как использовать ее в kubernetes.
Авторизация в системах одна из ключевых частей. Можно использовать какие то мощные решения, Firebase например, или что то из множества хороших библиотек. Если хочется уменьшить количество зависимостей или для самообразования - то можно написать свое.
Данное решение с использованием Nginx и Node.js приложения. Все описанное является очень частным случаем используемого подхода, в том смысле что есть некоторые условия в которых требовалось создать решение, и данный вариант реализации хорошо подходит только в в этих условиях.
Давайте представим, что есть кандидат, и у него есть несколько этапов найма (интервью с hr, техническое интервью, согласование с руководством и тд.). По некоторым этапам HR сотруднику приходилось руками передавать информацию по кандидату в разные чаты, что неудобно и требовало время и внимание HR. Поэтому появилась идея это автоматизировать.
Добрейшего времени суток %HABRUSER% и проходящим мимо, в первую очередь я очень рад что ты открыл эту статью, без шуток :)
Данная серия публикаций посвящена созданию сервиса runwith суть которого вы сможете почитать ниже. Это мой первый независимый проект, поэтому буду очень рад вашим комментариям и конструктивной критике касаемо стиля написания статьи и кода в целом, надеюсь тебе будет полезно и интересно, приятного чтения!
Если вы используете монорепозиторий, то взаимодействие между клиентом и сервером с общей моделью данных будет проблемой. Без обслуживания дублирование кода приведет к рассинхронизации.
Если модель данных изменяется на серверной части - убедитесь, что клиентский код подхватит эти изменения. Иначе клиентский код сильно пострадает при получении несовместимых данных, либо из-за игнорирования дополнений. А это не то, чего вы хотите.
Давайте рассмотрим стратегии синхронизации клиентского и серверного кода.
Я думаю, все, кто использует node.js, понимает про что эта картинка.
npm - это ужасный менеджер пакетов. В этом признавался даже сам создатель node.js. Npm для каждого вашего проекта создает папку node_modules, в которую он качает из интернета и сохраняет на диске каждый пакет из всей иерархии зависимостей.
Если у вас 100 проектов с одними и теми же зависимостями, то npm 100 раз скачает из интернета и сохранит на диске 100 копий одних и тех же пакетов. Ему плевать. Популярный yarn, к сожалению, делает то же самое.
Всем доброго времени суток.
В данной статье я решил поделиться опытом, накопленным за многие годы работы во front-end`е. Как и все вы, я был молод и мечтал создать что-то бессмертное. Ах, как я был молод, и как же я был глуп. Ничего вечного не существует и всё рано или поздно умирает. Однако, можно создать то, что протянет гораздо дольше обычного и даже будет адаптироваться к изменениям какое-то время. Поэтому сегодня предлагаю поговорить о паттернах проектирования для front-end приложений, выборе технологий и о том, чего делать не стоит. В этой статье буду проводить много аналогий со строительной тематикой и причиной тому небезызвестная история: «Если бы программисты строили дома».
Из чего строить?
Тут как бы все просто, но не всегда явно. Как говорится, давайте разбираться. Суперновые технологии с прорывными идеями сразу мимо. Вы меня спросите почему? Так давайте пофантазируем на тему того, что вы взяли их в проект: через года полтора сам проект не получил поддержки сообщества, а его создатель забил на него. Вы остались с нерелевантным стеком, отсутствием возможности найти разработчиков для создания кода и дальнейшей поддержки проекта. Нет обновлений, читай через два года у вас на руках старая коричневая субстанция.
Посмотрим и на обратную сторону медали: беря сверхнадежное решение, которому много лет, вы обрекаете проект на скорый апдейт или умирание. Знавал я одну крупную компанию, которая использовала java 8. Мотивация звучала так: она надежна как швейцарский нож. На минуточку, на дворе 2021 год и она устарела не только морально, но и технически (на момент написания, актуальной версией является java 17).
Нативная поддержка JSON одно из преимуществ разработки full-stack JavaScript приложений. JSON является простым, не требующим схемы и человекочитаемым - качества особенно ценимые на ранней стадии разработки, когда ваша модель данных подвержена частым изменениям. Однако за все надо платить, а именно размером и скоростью обработки данных.
JSON будучи текстовым форматом кодирует все значения как UTF-8, что приводит к увеличению размера данных при работе с нетекстовыми данными. Отсутствие схемы означает, что мы должны кодировать нашу структуру данных (ключи объекта) вместе с самими данными. Мы также делаем дополнительную работу при обработке данных, поскольку нам необходимо преобразовать бинарные данные в их текстовое представление до превращения в JSON и соответственно наоборот в случае декодирования.
Привет, друзья!
В этом небольшом туториале я хочу показать вам, как разработать простой, но довольно-таки полноценный сервер для тестирования API.
Основной функционал нашего приложения будет следующим:
GET, POST, PUT и DELETE запросов к любому существующему проекту, включая GET-запросы, содержащие параметры и строки запроса;sort, order, limit и offset;Наша админка будет выглядеть так:
Для быстрой стилизации приложения будет использоваться Bootstrap.
Разумеется, с приложением, которое мы с разработаем, сразу в продакшн не пойдешь, но при необходимости довести его до производственного уровня не составит труда.
При разработке приложения мы будет придерживаться 2 важных условий:
JSON;Обратите внимание: статья рассчитана, преимущественно, на начинающих разработчиков, хотя, смею надеяться, что и опытные найдут в ней что-нибудь интересное для себя.
Вы готовы? Тогда вперед.
Рассмотрим следующую задачу. Нам необходимо делать вызовы стороннего API, которые считаются дорогими, и, следовательно, их необходимо кешировать в Redis. Мы используем современный NodeJS (версии 14+), а значит и конструкции async / await.
Напишем сначала класс обертку над вызовом API, где сам вызов будем эмулировать 2-секундным таймаутом.
Разработчик — натура творческая. У него нет времени на рутинные задачи, о которых может позаботиться машина. Поэтому все, что можно автоматизировать, должно быть автоматизировано.
Привет! Меня зовут Никита. Я разработчик Taiga UI, библиотеки Angular-компонентов, которая активно используется в нашей компании «Тинькофф». Я расскажу про решение одной из таких рутинных задач на нашем проекте с помощью написания с нуля своего Github App на Node.js.
Mongoose представляет специальную ODM-библиотеку (Object Data Modelling) для работы с MongoDB, которая позволяет сопоставлять объекты классов и документы коллекций из базы данных.
Redis (Remote Dictionary Server)- это быстрое хранилище данных типа «ключ‑значение» в памяти, активно используемое в разработке с целью повышения производительности сервисов
В рамках данного гайда мы рассмотрим связку Mongoose + Redis и посмотрим, как обеспечить максимально удобное взаимодействие между ними
Я написал интернет-магазин для магазинов мяса на Blazor Server(это не WebAssembly). Там фактически нет фронта, есть только бекенд. Всё события и изменения в DOM-дереве передаются на сервер через WebSocket и сервер генерирует новый html и шлет обратно. То есть onclick можно обработать прямо из C# и там же скачать, к примеру данные из базы. Это очень удобно, никаких проблем с HTTP запросами! Blazor абстрагирует меня от этого. Кстати, в React 17 появилась така штука как React Server Components, это чисто копия подхода Blazor. Теперь можно написать компонент и с него же обращаться, в базу, например.
Но, поначалу все было очень классно и удобно, что позволило мне быстрее написать интернет-магазин, но потом возникли проблемы.
Шаг 1. Установка NextJS
yarn create next-app
Шаг 2. Установка пакетов:
yarn add express redis node-gzip
Шаг 3. Создаем в корне проекта файл server.js
IT-экспресс TechTrain мчится в онлайн и открывает наш осенний сезон конференций.
Это бесплатное мероприятие, где с 8 докладами на самые разные темы выступят спикеры самого разного профиля. Пишете вы на Kotlin или C++, ближе вам DevOps или дата-инжиниринг — найдется доклад для вас.
Чтобы запрыгнуть на бесплатный осенний поезд, который отправится 18 сентября, достаточно пройти регистрацию на сайте.
А чтобы вспомнить или впервые увидеть доклады прошлого сезона, можете посмотреть их плейлист.
Все это, только в расширенном формате, ждет вас и на наших крупных осенних конференциях. Поэтому по программе TechTrain можно даже погадать: посмотрите на нее под катом, выберите самый интересный вам доклад, а в конце текста мы по вашему выбору нагадаем, на какой из наших конференций вам точно будет интересно.