Продолжаю описание своего видения того, какими могли бы быть 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-приложениях без дополнительной транспиляции.

Какие характеристики должны быть у web-приложения, чтобы соответствовать критерию "прогрессивное"? Понятно, что, как и обычные web-приложения, прогрессивные строятся на базе "большой тройки" web-технологий - HTML/CSS/JS. Но что именно делает web-приложения прогрессивными?

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

В индустрии сложилось устойчивое мнение, что Service Locator является анти-паттерном.

Из wiki: "Стоит заметить, что в некотором случае локатор служб фактически является анти-шаблоном."

В этой публикации я рассматриваю тот случай, когда, на мой взгляд, Service Locator анти-шаблоном не является.

Недавно открыл для себя термин “гипертимезия” — способность личности помнить и воспроизводить предельно высокое количество информации о её собственной жизни. Гипертимезия считается нарушением памяти и значительно осложняет жизнь человеку. Вольно или невольно сосредотачиваясь на прошлом, он перестаёт уделять внимание настоящему и забывает о будущем. И чем дольше человек живёт, тем больше у него прошлого. Тем проще соскользнуть в него, тем сложнее удержаться в настоящем.

В своей прошлой статье я прикидывал, какие namespace'ы мне нужны для упорядочивания кода в ES6-модулях. В этой статье я описываю, какие namespace'ы у меня получились и как их использовать при порождении объектов и разрешении зависимостей (dependency injection).

Что лучше для web-приложений - монолит или микросервисы? Многие ответят на этот вопрос, что, мол, все инструменты хороши, если их использовать по назначению. В таком случае у меня, как у человека, в силу своего возраста, довольно консервативного и неохотно воспринимающего непроверенные временем концепции, возникает другой вопрос - а чем хорош монолит? Где его ниша? Стоит ли переключаться на микросервисы или монолит ещё не изжил себя и на мой век хватит?

В фокусе моих интересов не гигантские web-приложения типа Gmail, Facebook, Twitter, а web-приложения, созданные на базе таких платформ, как Wordpress, Drupal, Joomla, Django, Magento и им подобным. Под катом мои субъективные мысли на этот счёт. Ничего нового - всё те же 33 буквы кириллицы и 26 букв латиницы вперемешку.

Мне очень сильно импонируют namespace'ы в таких языках программирования, как Java и PHP. Настолько сильно, что я даже как-то запилил о них статью на Хабре. С тех пор прошло уже почти два года, но namespace'ы в Javascript за это время так не появились. "А если бы я делал namespace'ы в JS для самого себя, то какими бы они были?" - подумалось мне. Под катом - мои соображения, какие же namespace'ы мне нужны в JavaScript'е.

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

Как-то неожиданно для меня подключение своего nodejs-приложения к Google Calendar API оказалось довольно нетривиальной задачей. Несмотря на подробное описание вариантов подключения на русском языке пришлось продираться через лес различных настроек и конфигураций. В статье подробно изложены шаги, которые приходится совершить, чтобы интеграция завершилась успехом.

В комментах к моей предыдущей статье о service worker'ах была высказана мысль, что PWA на десктопах - вещь малополезная. Примерно полгода назад я разбирался с тем, как прикрутить Vue Storefront (PWA) к магазинам на платформе Magento и мне понравилось, как шустро крутилось в моём компьютере PWA-приложение по сравнению с оригинальным web-интерфейсом. Мой персональный опыт показывал, что PWA на десктопах имеет неплохую перспективу, но дальнейшее углубление в тему показало, что коллега @sumanai со своим отрицанием PWA на десктопах был прав.

Web-приложения всё больше "затачиваются" под мобильные устройства, а service worker'ы являются фундаментом прогрессивных web-приложений (PWA). При первом ознакомлении с данной технологией может сложиться впечатление, что основной задачей service worker'ов является кэширование контента. И это так. Задача service worker'ов — обеспечение функционирования web-приложения в условиях нестабильного или вообще отсутствующего подключения к Сети, что достигается при помощи кэширования данных.

Под катом пара мыслей о том, к каким последствиям для web-приложений привело появление возможности кэшировать данные посредством service worker'ов.

Многие люди думают о волнующих их проблемах перед сном или по пробуждении. Я не исключение. Сегодня с утра у меня в голове всплыл один коммент с Хабра:

Коллега в чате поделился историей:

У меня в позапрошлом году был офигенный клиент, это ещё когда я брал чистый «кризис».
У клиента в девгруппе две команды, каждая занимается своей частью продукта (условно, бэкофис и сторфронт, т.е. софт работающий над формированием заказа и софт, работающий над исполнением заказа), изредка между собой интегрирующийся.
Команда бэкофиса прям вот совсем в днище ушли: полгода сплошных косяков, собственники грозятся всех уволить, наняли консультанта, после консультанта наняли более другого (меня). Причём вторая команда (сторфронт) работала норм и продолжала работать норм, именно бэкофисная, которая до этого тоже норм работала, стала косячить. Команды в разных офисах сидят, друг на друга привыкли псить.

Причина: стор и бэк это одна система, в ней куча зависимостей, команды в разных офисах, между собой не общались. На сторфронт все время «смотрят» собственники, соответственно у них там новые фичи, идеи и контроль. В ней был мальчик-на-все-руки, такая комбинация из БА, дизайнера и «принеси нам кофе». Вот этот мальчик, незаметно для своей команды, выполнял кучу мелких задач типа «предупредить вторую команду о деплое», «проапдейтить документацию» и т.п. рутину, вплоть до «внести в жире в тикет всякие номера версий и компоненты». Но код мальчик не писал и в один момент собственники решили его оптимизировать, нафиг уволив. Для команды стора ниче не поменялось, они просто не вносили и не апдейтили доки, а команда бэкофиса оказалась в ситуации, когда релизы стора ломают у них что-то, и это их проблемы, а если их релизы ломают что-то у стора, это опять их проблемы, потому что стор на виду у собственников :)

Чем меня зацепил этот коммент и что обрящет ищущий из заголовка — под катом.

Пятый и завершающий пост о моём знакомстве с Vue Storefront. IMHO, самым современным с технической точки зрения решением в сфере e-commerce на данный момент. Ссылки на предыдущие посты:

• Vue Storefront: Второй подход к снаряду
• Vue Storefront: Поднимаем backend
• Vue Storefront: Заливаем данные в ES
• Vue Storefront: Импорт каталога из Magento 2

Под катом краткое описание особенностей этого этапа и итоговое резюме.

Zabbix — замечательный продукт для администраторов крупных программно-аппаратных комплексов. Он настолько хорош, что может использоваться не только крупным бизнесом, но и средне-малым бизнесом, и даже в pet-проекте. В общем, у меня есть небольшой опыт работы с Zabbix'ом и я смело могу рекомендовать его к использованию.

Правда я не могу сказать, что понимаю "философию Zabbix'а". Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix'а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.

Тем не менее, для запуска Zabbix'а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix'а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix'а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.

Под катом — пример Zabbix-плагина с моим пояснением по терминологии Zabbix'а. Кому-то этот пример покажется наивным, ну а кому-то поможет проще освоиться с понятиями. В любом случае, Zabbix достаточно велик для того, чтобы ощупать его с разных сторон.

В мире серверного JavaScript'а я — новичок с чистым, практически незамутнённым разумом. Поэтому когда я узнал о существовании менеджеров процессов, а конкретно — о pm2, то сразу же попробовал применить его для запуска какого-нибудь простейшего backend-сервиса на nodejs в целях самообразования. Мне очень импонирует возможность подключения модулей в JS-коде через import (ES6 modules), т.к. он позволяет использовать один и тот же код как в браузере, так и на серверной стороне, и я запилил простой сервис с ES6-модулями.

Если вкратце, то запустить ES6-версию приложения под pm2 у меня не получилось, для запуска таких приложений лучше использовать либо forever, либо systemd. Под катом — отчёт о результатах для тех, кто любит тексты подлинее.

Наконец-то получилось увидеть данные из Magento (категории и продукты) в приложении Vue Storefront (VSF). Это уже четвёртая статья (1, 2, 3), в которой я описываю процесс изучения возможностей интеграции VSF с электронным магазином на базе Magento 2, и первая, где данные из Magento проскочили в браузер покупателя.

Под катом ссылка на скрипты развёртывания и краткое описание шагов.

Ещё один пост в рамках рекламной кампании по продвижению своей реферальной ссылки. В первой и второй публикации я поднял фронт-сервер, api-сервер и два вспомогательных сервиса (Elasticsearch & Redis), которые используются api-сервером. На этом шаге я попытался залить какие-то данные из существующего Magento-проекта в моё тестовое VSF-приложение.

На третьем шаге появился некоторый прогресс. PWA-приложение в браузере перестало сообщать об ошибке и начало показывать более-менее пристойную домашнюю страничку. Пусть даже и не с теми данными, которые были в моём Magento-проекте. Любое изменение лучше, чем топтание на месте.

Под катом описание того, каким образом залить данные из своего Magento-магазина в приложение Vue StoreFront так, чтобы вместо них клиенту показывались демо-данные. Да, результат опять не очень, но для рекламной кампании это не самое главное.