Я кодирую, потому что я кодирую…
В предыдущих публикациях (раз, два) я рассматривал возможности использования внедрения зависимостей в чистом JavaScript (без TypeScript, аннотаций и транспиляции). В данной публикации я продолжаю погружаться в вопросы использования DI в JS и более пристально рассматриваю роль идентификатора зависимости в создании объектов контейнером.
Внимание! В данной публикации я не рассказываю, как надо программировать, я лишь показываю, как можно.
В своём предыдущем посте я попытался объяснить, что такое "инверсия контроля" и в каких случаях использование внедрения зависимостей в JS (ES6+) становится оправданным (если у вас в кодовой базе десятки npm-пакетов, в каждом из которых сотни, а то и тысячи es6-модулей). В этом посте я шаг за шагом покажу, как можно построить собственный контейнер объектов, который будет загружать исходный код es6-модулей, создавать нужные зависимости и вставлять их в нужные места. Сразу предупреждаю, что для упрощения изложения в демо-коде будут использоваться определённые допущения, связанные с генерацией объектов. Целью статьи является демонстрация собственно технологии внедрения зависимости, а не готового "всепогодного" решения. По итогу у вас должно сложиться понимание, как в ES6+ можно сделать свой контейнер объектов, если он вам вдруг по какой-то причине понадобится.
Этот пост является ещё одной попыткой сформулировать идею, зачем нужно внедрение зависимостей в ванильном JavaScript (именно в ES6+, а не в TS).
Основная сложность в том, что шаблон «внедрение зависимостей» (DI) есть следствие применение на практике «принципа инверсии зависимостей» (DIP). Классическая формулировка этого принципа выглядит так:
• A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
• B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Для JS‑программиста данная формулировка представляет определённую сложность в силу того, что в JS нет классических абстракций (в виде «интерфейсов» из других ЯП). В JS вообще нет абстракций, тут всё очень конкретно: вот объекты, вот примитивы — комбинируй.
Тем не менее, если спуститься с уровня теории на уровень практики, внедрение зависимостей вполне успешно может применяться даже в таком «конкретном» языке.
“Введение менеджера пакетов в веб-браузеры является интересной идеей, и на самом деле такой функционал уже существует в некоторых формах. Однако, на данный момент он не является стандартной функцией браузеров.” (с) da Vinci, text-002, OpenAI
Я очень сильно уважаю отладчик (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-разработке.
В этой публикации — пример построения "нормального" 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 на сервере и в браузере.