Я очень сильно уважаю отладчик (debugger) - он даёт возможность лучше понимать код, с которым ты работаешь. Даже если ты сам этот код и написал. Но отладчик - это очень низкоуровневый инструмент, зачастую хватает трассировки хода выполнения web-приложения (логирования). Самый простой способ логирования - console.log(). Он позволяет вывести сообщение на консоль браузера (DevTools по F12 в Chrome). Но что делать, если приложение отрабатывает в среде, где консоль для разработчика недоступна? Например, в мобильном устройстве клиента?

Ответ очевиден - перенаправить вывод с консоли браузера туда, где разработчик сможет видеть логи. Благо, что JavaScript позволяет это делать очень просто, достаточно вставить в HTML-файл в HEAD такой фрагмент:

В довольно длинном и скучном посте описывается пример аутентификации пользователя в веб-приложениях при помощи биометрических средств (FaceID, отпечаток пальца), встроенных в мобильные телефоны. Код проекта - тут, рабочее демо - тут. Пример написан на чистом JavaScript и может быть отдебажен как на бэке (nodejs), так и в браузере.

Сам-то я “сварщик не настоящий” и в искусственных интеллектах ничего не понимаю, но когда “вокруг только и разговоров, что о море и о закате”, возникает непреодолимое желание разобраться хотя бы на бытовом уровне, “что такое, товарищи, море и что такое, товарищи, закат”. Если кому интересна (ещё одна) точка зрения дилетанта на то, что делать с приближающейся технологической сингулярностью - добро пожаловать под кат. Но сразу предупреждаю, ничего нового вы там не обнаружите, просто рефлексия одного естественного интеллекта.

Распознавание речи — штука довольно прикольная и не очень полезная. С одной стороны голосовой интерфейс для общения с роботами в фантастике является обычным, наверное, годов с 60-х, а с другой стороны — в наше время голосовой интерфейс не продвинулся сильно дальше "Алиса, а какая у нас погода на завтра?". Для того, чтобы самому составить мнение о текущих возможностях систем распознования речи, я попробовал использовать сервис Deepgram в браузерном приложении. Команда сервиса в ноябре прошлого года привлекла дополнительное финансирование в размере $47 млн. и с оптимизмом смотрит в будущее. Сервис хорош тем, что распознаёт русский язык (не все STT-сервисы это делают), даёт приличный кредит для тестирования возможностей (из 150 промо-денег я израсходовал меньше 0.50 "на поиграться"), не требует серверной части (всё работает из браузера). Готовая демка — тут, детали — под катом.

При анализе откликов на свою статью "HTTP/1 и HTTP/2 сервера на nodejs" пришёл к выводу, что поддержка версии HTTP/2 в настоящее время в nodejs-приложениях находится в этакой суперпозиции: с одной стороны http2-библиотека nodejs позволяет без проблем использовать HTTP/2 в своих приложениях, с другой - наиболее популярный web-сервер (express) до сих пор нативно не поддерживает HTTP/2, а другие популярные web-сервера (koa, hapi) требуют от разработчика дополнительно кодирования для работы с HTTP/2. Под катом опрос, какие версии HTTP-протокола используются в ваших nodejs-приложениях.

Экспериментальная поддержка HTTP/3 уже встроена в основные браузеры и начинает потихоньку пробираться на сервера. А это значит, что уже можно полностью отказаться от использования в своих nodejs-приложениях от http-библиотеки и переключиться на http2. Насколько же отличается реализация http2-сервера от обычного http-сервера?

Под катом пример простого web-приложения, выполняющего типовые задачи (получение статики GET'ом, upload файлов, POST-запросы, server sent events) на серверах HTTP/1 и HTTP/2. HTTP/2 Server Push в данном примере не затрагивался. Приложение не использует внешних зависимостей (npm-пакетов), всё сделано при помощи собственного функционала nodejs.

Я уже публиковал свою точку зрения, что Progressive Web Applications - это, прежде всего, технология для мобильных устройств. Основная особенность классических web-приложений - это клиент-серверная архитектура, а основная особенность "прогрессивных" web-приложений - возможность работы в offline. Понятно, что это очень сильно разные подходы в архитектуре - "всегда на связи" и "всё своё с собой". Совместить два таких разных подхода в одном приложении "это очень дорого и ни к чему".

Отталкиваясь от этой своей точки зрения, я решил посмотреть текущую статистику по браузерами - какие на данный момент у PWA-приложения возможности стать популярным и на какие браузеры оно должно ориентироваться. Данные для публикации взяты с сайта gs.statcounter.com

Прочитал я хорошую статью "Обновление вашего PWA в продакшене" и задался вопросом - а как часто при обновлении PWA нужно обновлять непосредственно сам service worker? Ведь что такое service worker по сути? "Прокладка" (прокси) между приложением, работающим в браузере, и внешними серверами, с которых это приложение тянет нужные ему ресурсы. По большому счёту, функционал service worker'а сводится к некоторому набору стратегий и пониманию того, к какому ресурсу какую стратегию применять и когда (я сейчас не рассматриваю push notifications и background sync, но изложенное в какой-то степени применимо и к ним).

То есть, код service worker'а более стабилен по сравнению с кодом приложения и во многих случаях для его "обновления" достаточно программно обнулить кэш-хранилище браузера и обновить "понимание того, к какому ресурсу какую стратегию применять" - обновить конфигурацию service worker'а. А для этого нужно приложению нужно иметь возможность каким-то образом управлять состоянием service worker'а и передавать ему данные, что осложняется тем, что приложение и service worker работают в различных потоках.

Под катом пример того, каким образом можно настроить управление service worker'ом из основного приложения при помощи Channel Messaging API.

Для многих в разработке программ самыми большими проблемами являются (а) их сложность и (б) изменчивость требований. Решение обеих проблем — в декомпозиции целого приложения на более мелкие части (пакеты, модули, классы и функции). Декомпозиция для уменьшения сложности в целом достаточно проста (закон Миллера). Но нужно не просто разбить приложение на части, а сделать эти части устойчивыми к изменениям требований.

В этой публикации я пытаюсь поразмышлять на следующие вопросы: из каких элементов состоит JavaScript-код? каким образом эти элементы взаимодействуют друг с другом? можно ли как-то повысить устойчивость кода к изменениям?

В предыдущей статье я обозначил некоторые плюсы декларативного описания реляционных структур данных в web-приложениях с "WordPress-философией" (слабонагруженные, модульные, с единой БД). В этой статье я рассматриваю экспериментальную реализацию данного подхода. Сразу предупреждаю, что это не готовый рецепт того, как нужно делать (пусть даже и с моей точки зрения), а, скорее, публичные размышления. Ну нравится мне размышлять вслух, не пинайте сильно.

Реализуемая в приложении задача высосана из вакуума и практической пользы не имеет. Само приложение состоит из трёх npm-пакетов: основного и двух зависимых. Каждый пакет декларирует свою собственную структуру данных в JSON-формате. Основное приложение создаёт в двух различных базах данных две различные структуры, комбинируя свою собственную декларацию и декларацию из соответствующего пакета (own + pack1 & own + pack2). Совмещение различных фрагментов в общую структуру является типовой задачей модульных приложений с единой БД. Эту задачу я и рассматриваю ниже.

Лет 6 назад я задавался вопросом "Как правильно организовать распределенное проектирование БД?" Тогда ответа на свой вопрос я так и не получил, но за прошедшее с тех пор время я встретился с вариантом, наиболее близко подобравшимся к моему видению "прекрасного" — это декларативная схема описания данных в Magento 2.

Мне нравится философия таких программных систем, как Magento, Odoo, WordPress, Drupal — базовый функционал, расширяемый за счёт сторонних плагинов. Она значительно отличается от философии FAANG. Философия FAANG направлена на построение уникальных высокопроизводительных решений, а философия WordPress — на адаптируемость к требованиям бизнеса. Каждый из этих подходов имеет свои плюсы и минусы, но мне ближе второй и рассматривать вопрос, вынесенный в заголовок публикации, я буду именно в рамках WordPress-подхода (WP-подхода).

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

В процессе обсуждения статьи "Почему я «мучаюсь» с JS" у меня сложилось понимание, что связка export / import в JS является базой для указания зависимостей между элементами кода (классами и функциями). А так как современные приложения вышли за рамки однофайловых и давно уже строятся из блоков, то выстраивание зависимостей между элементами кода имеет весомое значение. Настолько весомое, что в знаменитой аббревиатуре SOLID этому посвящена отдельная буква — D (Dependency inversion — инверсия зависимостей, не путать с Dependency injection — внедрение зависимостей).

Размышляя над тем, как связываются зависимые элементы кода в JS через export / import, я пришёл к выводу, что не все зависимости в коде es6-модулей SOLID'ных приложений можно описать инструкциями import. Излагаю свои соображения, чтобы коллеги могли указать, где я ошибаюсь, или подтвердить мои выкладки.

Комментарии коллег к моей последней статье "Почему я 'мучаюсь' с JS" навели меня на мысль, что публикации, касающиеся Tequila Framework, нужно помещать в хаб "Ненормальное программирование".

Почему-то идеи:

• создание больших web-приложений на "ванильном" JS;
• отказ от упаковщиков и транспиляторов;
• логическое пространство имён для прямого доступа к es6-модулям зависимостей, вместо импорта-экспорта на уровне npm-пакетов;
• автозагрузчик кода и инъекция зависимостей, использующие пространство имен;
• es6-модули, работающие без изменений одинаково как в браузере, так на стороне nodejs и в тестах;
• отладка в браузере точно того же кода как тот, что создаётся в редакторе;

вот это всё относится к разряду "ненормального" в современной web-разработке.

В этой публикации — пример построения "нормального" PWA-приложения с использованием "нормальных" Vue 3 и Quasar UI на базе "ненормальной" платформы Tequila Framework.

Я не знаю TypeScript, поэтому и пишу эту статью. У меня есть некоторый опыт программирования на Java и PHP и этот опыт заставляет меня кодировать на JavaScript'е соответствующим образом. К последней моей статье коммент от коллеги Silverthorne был такой:

export default class TeqFw_Http2_Back_Server {
constructor(spec) {
// EXTRACT DEPS
/** @type {Function|TeqFw_Http2_Back_Server_Stream.action} */
const process = spec['TeqFw_Http2_Back_Server_Stream$'];
/** @type {TeqFw_Web_Back_Handler_Registry} */
const registryHndl = spec['TeqFw_Web_Back_Handler_Registry$'];

зачем все это, когда есть TypeScript?

В ответном комменте я попросил от него продемонстрировать TS-код, который делает то же самое. Он не ответил. Я добавил коммент с просьбой, чтобы кто-угодно продемонстрировал TS-код, который делает то же самое. Ничего. И вот я пишу уже статью с аналогичной просьбой.

Я очень долго не воспринимал JavaScript, как язык программирования общего пользования. Добавить падающих "снежинок" на корпоративную web-страничку перед Рождеством — вот, для чего на самом деле придумали JS, казалось мне поначалу. Ну что серьёзного можно было сделать на языке, который не имел в своём арсенале функционала по работе с файловой системой, не говоря уже про доступ к БД?

Однако сейчас, по прошествии двух десятков лет, я считаю, что JS развился достаточно, чтобы быть основным языком программирования для создания web-приложений. Сейчас у него есть всё для этого. На самом деле, эта статья не про то, как использовать HTTP/2 сервер в web-приложениях, а про то, как можно писать приложения с современным JS. И про HTTP/2.

В предыдущей публикации я описал обработку статики web-плагином из своего набора инструментов для построения web-приложений, который я назвал Tequila Framework. В этой публикации я опишу, каким образом этот же плагин обрабатывает запросы к API-сервисам.

Для тех, кто ещё не в курсе — у меня несколько нестандартный подход к созданию приложений, я программирую на "чистом" JavaScript (ES 2015+) с использованием пространств имён, собственного DI-контейнера (@teqfw/di) и обильным применением аннотаций JSDoc вместо статической типизации TypeScript'а. Некоторые считают это "некошерным", а я считаю, что JS и TS — как два рукава реки. Где-то в будущем они опять сольются и, по большому счёту, всё равно, по какому рукаву плыть. Для меня на данный момент аннотации JSDoc дают основные преимущества статической типизации (контроль типов) и не влекут за собой необходимость транспиляции.

Под катом — пару подробностей, какой интерфейс сторонним плагинам предоставляет web-плагин для добавления API-сервисов в web-приложение, и как можно использовать одни и те же DTO на сервере и в браузере.

Продолжаю описание своего видения того, какими могли бы быть web-приложения в нынешнее время. У меня не очень популярная точка зрения — предпочитаю чистый JavaScript (ES 2015+) на клиенте (браузер) и сервере (nodejs) и совсем не приемлю транспиляцию (даже из JS в JS для поддержки старых браузеров). Я назвал набор инструментов, разрабатываемый мной для создания таких приложений, "Tequila Framework". Просто потому, что мне нравится пустыня, кактусы и префикс "teq-".

В предыдущей публикации я показал пример практического использования пространств имён при создании консольных команд с помощью плагинов @teqfw/di и @teqfw/core. В этой статье я опишу использование плагина @teqfw/web для добавления в приложение web-сервера и предоставление доступа к статическим ресурсам приложения, в том числе и к файлам в каталоге ./node_modules/.

Эта статья не о том, как нужно писать приложения на JavaScript'е. Эта статья о том, как можно писать приложения на JavaScript'е. В прошлой публикации я описал свой "велосипед" — DI-контейнер @teqfw/di. В этой я покажу, каким образом его можно применять для создания консольных приложений.

Сразу отмечу, что речь идет о "чистом" JavaScript (ECMAScript 2015+ aka ES6+). Я признателен авторам TypeScript за то влияние, которое он оказал на развитие JS, но считаю, что в 2021-м году отличия TS от JS не столь драматические, как это было в году 2012-м, и не вижу для себя смысла использовать TS там, где достаточно JS. Если вы считаете по-другому и имеете острое желание высказать своё мнение, то можете сразу переходить к комментам, пропустив саму публикацию.

Те же, кому интересно, как же всё-таки в JS-приложении может использоваться "логическая адресация" элементов кода (пространства имён) вместо "физической" (файловая система) — добро пожаловать под кат.

Информационные системы предназначены для обработки данных, а DTO (Data Transfer Object) является важным концептом в современной разработке. В “классическом” понимании DTO являются простыми объектами (без логики), описывающими структуры данных, передаваемых “по проводам” между разнесенными процессами (remote processes). Зачастую данные "по проводам" передаются в виде JSON.

Если DTO используются для передачи данных между слоями приложения (база данных, бизнес-логика, представления), то, по Фаулеру, это называется LocalDTO. Некоторые разработчики (включая самого Фаулера) негативно относятся к локальным DTO. Основным отрицательным моментом локального применения DTO является необходимость маппинга данных из одной структуры в другую при их передаче от одного слоя приложения к другому.

Тем не менее, DTO являются важным классом объектов в приложениях и в этой статье я покажу JS-код, который на данный момент считаю оптимальным для DTO (в рамках стандартов ECMAScript 2015+).

Некоторые любят ездить велосипедах, а некоторые любят их изобретать. Я отношусь к тем, кто изобретает велосипеды, чтобы на них ездить. Пару лет назад я уже писал на Хабр про этот свой "велосипед" - контейнер внедрения зависимостей (DI container) для JavaScript. Последующее обсуждение принципов работы DI-контейнеров и их отличие от "Локатора Сервисов" достаточно сильно продвинуло меня в понимании работы моего собственного "велосипеда" и вылилось не только в ряд статей на Хабре (раз, два, три, четыре), но и в значительной доработке самого "велосипеда".

Под катом - описание работы DI-контейнера (@teqfw/di) по состоянию на текущий момент. Ограничения: контейнер написан на чистом JavaScript (ES2015+), работает только с ES2015+ кодом, оформленным в ES-модули с расширением *.mjs . Преимущества: позволяет загружать и использовать одни и те же модули как в браузере, так и в nodejs-приложениях без дополнительной транспиляции.