В этом посте я попытаюсь формализовать и систематизировать своё собственное понимание, какой должна быть структура SPA-приложений. Это очень субъективное изложение, отражающее мой собственный опыт. Оно относится к определённому классу веб-приложений (SPA, PWA) и не претендует на универсальность.

В контексте данной статьи SPA-приложение - это классическое клиент-серверное приложение, где клиент существует в браузере (как правило, в пределах одной страницы) и взаимодействует с сервером посредством HTTP-запросов. Приложение разрабатывается в виде набора npm-пакетов в стиле “модульный монолит”. Серверная часть реализована на движке Node.js.

Мне тут на днях попеняли, что, мол, я не в курсе, "что из esm до сих пор нельзя собрать бандл без транспиляции". Ну что я могу сказать... я действительно не в курсе :) На мой взгляд, es-модули придумали как раз для того, чтобы загружать по мере необходимости JS-код непосредственно в браузер, и собирать модули в бандлы - это, ну... как гладить кошку против шерсти.

Я понимаю, что традиции / привычки / требования бизнеса / обратная совместимость / корпоративная этика и т.п. говорят о том, что код для браузерных приложений должен поставляться в бандлах и точка! Тем не менее, в некоторых случаях (малые приложения, быстрое прототипирование, распределённая разработка) сборка бандлов является излишней и код в браузер можно и нужно загружать непосредственно в виде es-модулей.

Когда писал код очередной функции по форматированию даты, поймал себя на мысли, что делаю это уже с стотысячпятисотый раз. Разные ЯП, разные проекты, разные предметные области - а делать приходится одно и то же. Шлёпать формы на фронте, пилить CRUD на бэке, гонять между ними XML/JSON - вот и всё веб-программирование, по большому счёту. Раз за разом делаешь очень похожую работу, которая всегда чуть-чуть отличается от того, что было ранее.

Эта статья — изложение персонального опыта работы с кэшем на стороне браузера при создании веб‑приложений. В повседневной разработке я использую десктопный Chrome. У него есть панель инструментов и он в принципе удобен для разработчика. Но когда нужно проверять приложение на смартфонах, начинается геморрой — каким образом доставить на смартфон новый код, если там уже есть старый? Больше всего меня бесит Safari on iPhone. Если в Chrome есть возможность удалить все данные для отдельного сайта, то в iPhone все данные удаляются для всего Safari. Если и есть в iPhone какой‑нибудь способ удалить через конфигурацию смартфона/приложения данные для отдельного сайта, то мне так и не удалось его найти. Буду благодарен, если кто‑либо мне о нём сообщит в комментах.

Эта публикация является развитием идей, сформулированных в предыдущей статье - "Идентификация пользователей в Web 3.0". После предыдущей публикации я понял, что в массах нет однозначного определения, что же именно называть Web 3.0 - виртуальную реальность, интернет вещей или децентрализацию на базе блокчейна. С моей точки зрения, Web 3.0 - это архитектура веб-приложений, обусловленная спросом пользователей на конфиденциальность их собственных данных.

Развитие идей Web 2.0 привело к тому, что пользователи сами стали товаром. Вернее, товаром стала информация об их связях и предпочтениях, которую собирают и монетизируют корпорации типа Google и Facebook. В ответ на это у многих пользователей появилось желание не делиться своими персональными данными с корпорациями, а хранить свои данные в недоступном для корпораций месте. Размышлениям о том, к каким последствиям может привести персонализация хранимых данных, и посвящена данная публикация. Сразу предупреждаю - это просто моё растекание мыслью по древу, а не "сборник рецептов" или разъяснения "как всё устроено". Не очаровывайтесь, чтобы не разочароваться :)

В данной статье я публикую свои размышления по поводу идентификации пользователей в плавно привходящей третьей версии веба - Web 3.0. Если коротко, то, в отличие от стремящегося к гипер-централизации Web 2.0 (в пределе - по одному веб-приложению разного типа на всё человечество с центром у какой-нибудь глобальной корпорации), Web 3.0 отличается как раз таки децентрализацией и повышенным вниманием к конфиденциальности пользовательских данных (хотя ничего не мешает тем же глобальным корпорациям контролировать функциональность этих децентрализованных приложений на уровне кода приложения или среды его выполнения - браузера или ОС).

Так какие же требования к идентификации могут предъявлять веб-приложения современного настоящего и ближайшего будущего?

Написать этот пост меня побудила статья "В чем конечная цель программирования?" и её обсуждение в комментах. Я поставил свой плюс за статью сразу же, как прочитал первое предложение:

> В том, чтобы иметь код, который легко изменять.

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

Но статья с таким очевидным (ну, лично для меня) выводом имеет, по состоянию на сегодня, оценку "-5" ("8" - в плюс, "13" - в минус). Под катом мои размышления о возможных причинах этого.

Этот пост не является прямым продолжением вот этого, скорее он является следствием. Как раз тот случай, когда “после” - таки значит “вследствие”. В оригинальном посте утверждалось, что Вселенная виртуальна, что прошлое вычисляется на лету, а случайности - псевдослучайны (что даёт возможность вычислять будущее). Я так широко не замахиваюсь, я лишь хочу изложить свою точку зрения, чем, на мой взгляд, Вселенная похожа на экран дисплея. Абсолютно ненаучное изложение, пригодное лишь для размягчения айтишных мозгов, утомлённых "греблей на галерах”. Заранее прошу прощения у тех, чей интеллект почувствует себя оскорблённым чтением сего опуса - я пока ещё не научился мыслить красиво. Тех же, кто не боится запачкать себя “псевдонаукой” - прошу под кат. Не волнуйтесь, длинных формул не будет.

В предыдущих публикациях (раз, два) я рассматривал возможности использования внедрения зависимостей в чистом 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.