Введение Недавно я наткнулся на проект по улучшению CRM, который когда-то написал.
Целью доработки было повышение производительности системы при взаимодействии с пользователем и добавление некоторого нового функционала, а также преодоление утечек памяти, обнаруженных предыдущими разработчиками и никогда не преодоленных в JavaScript, на котором был реализован весь пользовательский интерфейс.
Начав работу над проектом, углубившись в недра огромного количества используемых и не очень дружелюбных библиотек и фреймворков, проведя ряд экспериментов, мы пришли к неожиданному выводу, что виной всему.
SPA-архитектура.
Несколько слов о SPA-архитектуре Говоря о современной Сети, все чаще можно услышать о технологии Single Page Application (SPA), хотя, если быть точным, SPA — это собирательное название набора технологий, позволяющих реализовать WEB-приложение, исполняемое WEB-браузером как единое целое.
ВЕБ-страница, как, например, реализована служба Gmail от Google. С точки зрения пользователя данная технология привлекательна прежде всего скоростью реакции на действия в пользовательском интерфейсе, поскольку не требуется полная или даже частичная перезагрузка WEB-страницы с сервера, а все визуальные элементы конструируются непосредственно в браузер использует JavaScript, манипулируя DOM. структура документа.
Таким образом, WEB-приложения становятся очень похожими на обычные приложения для рабочих станций, загружающие информацию из Интернета, только средой исполнения для них является не операционная система, а браузер, который в результате вынужден нести всю нагрузку, связанную с выполнением.
стороннего кода, а именно управление памятью, обеспечение безопасной среды, предоставление функционала для работы с функциями системы и аппаратной среды и т.д. Центральное место в SPA-архитектуре занимает Представление — то, что видит пользователь и с чем взаимодействует. Вывод представления — это простой HTML, отображаемый браузером.
В отличие от «переходных» приложений «WEB 2.0», активно работающих с DOM-структурой документа, например, с помощью jQuery или подчеркивания, SPA-приложение использует DOM только для записи изменений, но не для чтения, то есть не для хранения.
данные .
Для хранения данных теперь используется еще один компонент архитектуры SPA — Модель.
Модель — это набор данных, функций для манипулирования данными и событиями.
Все данные модели полностью сохраняются в памяти.
Чтобы гарантировать целостность данных в модели и данных, отображаемых представлением, представление подписывается на события модели, тем самым отслеживая изменения данных в модели.
В свою очередь, модель также реагирует на уведомления о просмотре и обеспечивает бесшовное соединение WEB-приложения с сервером, выполняя запросы на получение или отправку данных (в частности, с использованием методологии REST).
Но вернемся к шоу.
Презентация – самая важная и самая сложная часть современного СПА.
Обычно представления строятся на основе так называемых шаблонов — шаблонов, конвертируемых в HTML. Представление также обновляет результирующий HTML при изменении модели, и наоборот — оно уведомляет модель о действиях пользователя с представлением, таких как щелчок мыши, ввод с клавиатуры или вращение устройства, в результате чего модель может выполнять данные.
манипуляции, а затем снова уведомить представление об изменении данных, чтобы представление могло обновить или сгенерировать новый HTML. Работа классического WEB-приложения (или WEB-сайта) полностью построена на кэшировании данных: на сервере, на прокси-сервере и на клиенте.
Если данные и состояние приложения обновляются очень часто, преимущества использования кэширования практически сводятся на нет. Теоретически одностраничное приложение должно использовать меньше кэша, поскольку данные загружаются один раз в течение жизненного цикла страницы, но на практике это не всегда так, как мы обсудим ниже.
Особенности CRM, не вписывающиеся в реализацию SPA Давайте посмотрим, как мы можем использовать технологию SPA для реализации простой системы управления взаимоотношениями с клиентами или CRM. Прежде всего нас интересуют операционный и аналитический уровни обработки информации.
Возьмем, к примеру, сильно упрощенный набор разделов простой CRM: • Рабочий стол (Панель мониторинга) — сводка всех системных данных, имеющих значение для конкретного пользователя.
• События — просмотр совместных действий пользователей из отделов маркетинга, продаж и производства.
• Клиенты – управление клиентской базой, контактами и компаниями.
• Проекты и сделки – управление взаимоотношениями с клиентами.
• Задачи – управление рабочим процессом внедрения.
• Отчеты – просмотр и управление аналитическими отчетами по накопленной информации.
• Профиль — управление профилем пользователя.
В каждом разделе пользователь работает с образцами часто меняющихся данных.
Одним из критических требований к CRM на оперативном уровне является высокая производительность взаимодействия с пользователем при выполнении таких операций, как частый доступ к реестру информации, широкое использование сложной фильтрации и сортировки больших объемов результатов.
Также на аналитическом уровне требуется быстрое получение отчетов, статистики, анализа и прогнозирования по различным метрикам и показателям.
В одностраничном приложении мы работаем не со страницами, а с «экранами».
Каждый экран является частью подсистемы со своим набором шаблонов, модулей, контроллеров, маршрута и модели.
Когда пользователь переходит в другой раздел приложения, загружаются данные, шаблоны и модули, необходимые для работы этого раздела, но важно, чтобы пользователь находился на той же странице, и текущее состояние сохранялось при переходе на новый экран.
нагрузки.
Общая модель всей системы сложна и состоит из независимых моделей для каждого экрана.
Переключение между экранами приводит к очистке текущего слоя представления и созданию нового слоя, что нередко реализуется таким образом, что предыдущий слой просто становится невидимым и вместо него отображается новый, то есть происходит процесс переключения Между экранами устроено таким образом, что готовые виды после первоначальной загрузки в последующие просто скрываются и отображаются.
Это сильно отличается от классического способа работы с WEB-приложением, где нажатие ссылок приводит к полной загрузке страниц, что автоматически приводит к освобождению ресурсов и обновлению данных, и пользователь может ожидать, что данные всегда будут актуальными.
.
В условиях быстрого изменения данных в CRM для подтверждения ожиданий пользователей при внедрении SPA в процессе перехода между экранами также возникает необходимость повторной загрузки всех данных с сервера, что сводит на нет преимущество хранения всех данных.
на клиенте, а, следовательно, и использование SPA-архитектуры.
Проблемы, возникающие при использовании SPA в CRM Технология SPA заставляет разработчика писать код крайне внимательно, поскольку любая ошибка или оплошность может привести к утечкам памяти и, как следствие, к «тормозам» всей системы.
Почему память течет? Огромный объем данных, накопившийся на клиенте за время длительной работы, быстро становится неактуальным.
Но пока эти данные хранятся в модели, а представления — в DOM-структуре документа, если только очистка не производится намеренно.
Чтобы поддерживать модель и DOM в «чистоте», необходимо периодически заниматься «сборкой мусора», так как в этом случае не стоит полагаться на встроенный JIT-сборщик мусора, поскольку ссылки на объекты, как правило, остаются достижимыми, следовательно, ранее созданные и уже не нужные объекты по-прежнему остаются в памяти.
Также необходимо учитывать, что в JavaScript всегда есть риск потерять все ссылки, но данные не будут очищены.
Почему все медленно? Замедление страниц в основном вызвано утечками памяти и сложной моделью с большим количеством обработчиков событий.
При переходе с экрана на экран, при открытии каждой новой формы в процесс браузера загружаются данные, а также исполняемый код (в случае AMD), который часто реализуется с помощью конструкций eval().
Модульные конструкции для построения СПА также имеют свою инфраструктуру со своими затратами.
Самая распространенная причина — ошибки и упущения разработчиков, которые очень легко допустить, но крайне сложно отследить.
Профилирование и отладка сложных одностраничных приложений — дорогостоящее мероприятие: хотя инструменты отладки сегодня хорошо развиты, сложность отладки возрастает экспоненциально вместе со сложностью приложения.
В результате проблему можно решить только путем модульной отладки и тестирования, что, в свою очередь, увеличивает затраты на разработку.
Как эти проблемы отражаются на разработке CRM? При разработке CRM большое количество экранов и форм, различная логика в зависимости от типа пользователя, его прав и разрешений, очень быстро устаревающие данные, необходимость периодического обновления состояния всей системы являются основными факторами, усложняющими работу.
разработка CRM с использованием технологии SPA. Кроме того, в процессе эксплуатации по мере увеличения объёма данных модель растёт, а, следовательно, и время обработки данных увеличивается, в результате система начинает тормозить даже там, где в тестах вела себя приемлемо.
Проблема «многоэкранности» Пользователи браузеров с вкладками, находясь на одной и той же странице, часто открывают отдельные страницы по ссылкам в отдельных вкладках браузера, совмещая их с переходом по ссылкам внутри одной вкладки.
Хотелось бы иметь подобную возможность при работе с WEB-приложением: например, открывать страницу проекта в отдельной вкладке и держать ее «на пульсе».
В случае со SPA такое тоже возможно, но в этом случае резко возрастают накладные расходы на разработку - там, где была экономия в случае загрузки страниц, теперь наблюдается перерасход, так как в каждой вкладке приложение будет загружать весь свой код. нужно работать; теряется смысл SPA как одностраничного приложения, поскольку для пользователя Интернета очевидно, что при работе в браузере ссылка должна открывать новую страницу, а не вести себя как обычное приложение.
Таким образом, при разработке CRM-систем архитектура SPA, на наш взгляд, менее предпочтительна, чем классическая архитектура многостраничного приложения с активным использованием AJAX для обновления данных.
Изложение проблемы получилось довольно обширным, поэтому рассказ о ее решении оставим для отдельной статьи.
Спасибо всем, кто читает, следите за публикациями.
Теги: #одностраничное приложение #архитектура приложения #crm #CRM-системы #.
NET #разработка #веб-разработка #.
NET #дизайн и рефакторинг
-
Использование Удостоверений Личности
19 Oct, 24 -
4 Нелепых Требования Венчурных Капиталистов
19 Oct, 24 -
Почему Нло Прилетело Нагрязный.ру?
19 Oct, 24
