В чем заключается работа врапперов в веб интеграции

Обновлено: 15.05.2024

Ни одна информационная система не способна решать все задачи компании. Между различными приложениями возникает необходимость обмена данными, делать это вручную сложно и занимает много времени. Необходима автоматическая интеграция с помощью таких технологий, как SOAP, REST, или готовых коннекторов. О технологиях интеграции и их применении в SimpleOne расскажем в нашей статье.

Интеграции в корпоративных приложениях

Корпоративные приложения получают, обрабатывают и передают данные. Зачастую для выполнения одного бизнес-процесса компания использует несколько информационных систем, и между ними происходит обмен данными. Одна система получает информацию от пользователя и передаёт в другие через каналы интеграции. Например, для авторизации на сервисном портале пользователь не создаёт новую учетную запись: система получает данные из Active Directory, а приложение контроля доступа загружает справочник сотрудников из базы данных ERP SAP.

Интеграция ускоряет решение задач, повышает качество, исключая человеческий фактор, снижает стоимость владения информационных систем без посредников и уменьшает издержки.

Технологии интеграции

SOAP и REST решают одинаковую задачу: позволяют разработчикам с помощью API настраивать обмен данными между приложениями. Но если SOAP является протоколом обмена информацией, то REST — это стиль или набор рекомендаций, которым должен следовать разработчик для предоставления веб-службы — RESTful, то есть разработанной с учётом требований REST и не нарушающей тех ограничений, которые он накладывает.

SOAP — протокол, REST — архитектурный стиль

REST (REpresentational State Transfer) — довольно молодой, но очень популярный архитектурный стиль для создания интеграционных API. Он приобрёл популярность у разработчиков в 2018 году, и на текущий момент большинство интернет-сервисов его используют как общедоступный API-интерфейс. Twitter, WordPress, Google Maps и другие известные приложения имеют REST API для взаимодействия с другими веб-сервисами и пользовательскими сайтами.

REST — простой, удобный и универсальный способ интеграции корпоративных приложений, в большинстве случаев веб-сервисы RESTful могут взаимодействовать с любыми другими сервисами.

Для чего нужны коннекторы

Настройку коннекторов администратор выполняет с использованием графического интерфейса приложения (GUI) без необходимости программирования, такой подход отлично вписывается в концепцию No Code.

Пример реализации коннектора — взаимодействие ITSM-системы и системы мониторинга. Для настройки их интеграции администратор ITSM вводит адрес внешней системы, настраивает набор событий, которые должен принимать коннектор, и правила их обработки. Таким образом, ITSM-система оперативно получает информацию от системы мониторинга — коннектор обрабатывает поступающие данные и в соответствии с заданными правилами производит действия с данными ITSM-системы.

Способы интеграции в SimpleOne

Интеграция SimpleOne с другими корпоративными приложениями настраивается через REST API, интерфейс позволяет создавать, читать и обновлять данные в таблицах платформы.

REST-клиент

Чтобы связать стороннее приложение с SimpleOne, администратор должен в редакторе REST-запросов (REST Client) создать запрос к внешнему сервису (REST Request), а также запланировать его регулярное исполнение. В панели администрирования создаётся REST-запрос, для него указывается заголовок, дополнительные методы запроса и их параметры при необходимости, а также профили аутентификации.

Настройку REST-запросов и REST Bot Engine может выполнить администратор платформы с помощью GUI без глубоких знаний API и навыков программирования.

Настройка REST API в SimpleOne: пример настройки запроса для интеграции co Slack Настройка REST API в SimpleOne: пример настройки заголовка запроса Настройка REST API в SimpleOne: пример настройки дополнительных методов

Коннекторы

REST API

ESM-платформа SimpleOne предлагает задокументированный набор готовых операций с данными для взаимодействия сторонних систем с нашей платформой посредством REST API.

Scripted REST API

Когда готовых методов для работы сторонней системы с данными SimpleOne недостаточно, можно создать свои собственные сценарии обработки запросов с помощью инструмента Scripted REST API. Для этого достаточно создать новый модуль API, с помощью low-code-инструментария настроить действия и параметры, после чего связать параметры запросов к API с созданными модулями и действиями.

Это позволит настроить сложную логику обработки REST-запросов от внешних систем.

Заключение

Наличие API для веб-приложения — это общепринятый стандарт корпоративной интеграции. Он позволяет бизнес-платформам, решающим различные задачи, взаимодействовать без дополнительной разработки. В SimpleOne реализованы no-code-инструменты для настройки запросов к внешним системам, REST API с возможностью его расширения через интерфейс системы, а также универсальные и специализированные коннекторы к популярным информационным системам. Всё это позволяет быстро настраивать взаимодействие со сторонними сервисами, мессенджерами и другими приложениями. Основные настройки производятся с помощью графического интерфейса, не требующего глубоких знаний языков программирования от администратора.

Интеграция - процесс объединения одного приложения c другим с целью увеличения функциональности и уменьшения времени обработки запроса. Интеграцию проводят для облегчения работы операторам и автоматизации бизнес-процессов.

Что мы имеем до интеграции?

Имеется сервер Oktell и некоторый web-сервер, на котором установлена WebCRM-система.

Пользователи Oktell могут заходить в свое рабочее место через клиентское приложение. Стандартный функционал Oktell предоставляет пользователям:

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

Пользователи WebCRM могут заходить в свое рабочее место через браузер. Как правило, WebCRM предоставляет следующий функционал:

доступ к клиентской базе, истории взаимоотношений с клиентом
управление текущими задачами и проектами компании
управление заявками, счетами
предоставление информации о KPI сотрудника, расчет их показателей эффективности
управление бизнес-процессами в компании

Что мы должны получить после интеграции?

При входящем звонке Oktell идентифицирует абонента по его номеру телефон (CallerId), телефону, который он набрал (CalledId), время поступившего звонка. Затем, происходит обращение к серверу WebCRM, в котором сообщается полученная информация, по которой определяется тип клиента, ответственный менеджер, дополнительные данные. После получения необходимых данных, Oktell маршрутизирует звонок нужному сотруднику, а в браузере у этого сотрудника открывается карточка клиента.

Исходящие звонки

Чтобы совершить звонок на номер клиента, менеджеру необходимо открыть карточку клиента в CRM-системе и нажать на кнопку "Позвонить". Выбор линий и направлений для совершения звонка настраивается в Oktell. В случае, если абонент не доступен или занят, менеджеру должна быть выведена соответствующая информация о статусе звонка.

Внутренние звонки

Пользователь WebCRM-системы может в любой момент посмотреть внутренние номера сотрудников компании и при желании сразу совершить звонок коллегам. Помимо обычных звонков возможен сбор конференции.

Также должны быть доступны статусы всех сотрудников. Статусы могут быть: свободен, занят (т.е. находится в разговоре), в перерыве или недоступен. Менеджер видит кто из коллег занят в данный момент и подождать, пока он освободится, для совершения звонка.

Статистика / история звонков.

При любом входящем звонке от клиента (или исходящем к клиенту), Oktell отправляет запрос в WebCRM-систему на формирование “события” (“активности”). Данная “активность” привязывается к карточке клиента или заказа , таким образом формируя историю взаимодействия. “Активность” автоматически заполняется датой звонка, номером звонившего, именами участников разговора, а также дополняются комментариями ответственного менеджера. При таком подходе, ни одно взаимодействие с клиентом не будет упущено и менеджер может в любой момент оценить как продвигается сделка.

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

Oktell позволяет работать одновременно с сервером WebCRM и с клиентскими (браузерными) приложениями. Интеграция Oktell и WebCRM-системы проводится в два этапа:

1. Серверная интеграция — настройка канала обмена данными между WebCRM-системой и сервером Oktell.

2. Клиентская интеграция — организация интерфейса для передачи команд телефонии от браузерного приложения к серверу Oktell.

Схема работы

Например, Oktell соединяется с CRM-системой и получает от нее два динамических метода:

Первый динамический метод позволяет получить информацию о клиенте по номеру телефона. В методе описано, что необходимо передать номер телефона на сервер WebCRM. При входящем/исходящем звонке, Oktell с помощью компонента “CRM-действие” вызывает данный метод и передает в него номер телефона клиента. В ответ он получает всю необходимую информацию.

Второй динамический метод позволяет сохранить “активность/звонок” в CRM-системе. При завершении звонка, Oktell передает идентификатор клиента, имя менеджера, который совершал звонок, время и длительность разговора и ссылку на запись.

Подробнее про динамические методы вы узнаете по этой ссылке.

Web-сервер по данному соединению может обратиться к серверу Oktell за получением данных по звонку (время ожидания, длительность разговора, время звонка), получения записи разговора (как самого файла, так и ссылки на этот файл). Также, WebCRM может запускать служебные сценарии в Oktell. Сценарии совершают необходимые действия, например, производят рассылку электронных писем.

Методы реализации

Задача серверной интеграции - организовать канал связи между WebCRM и сервером Oktell для выполнения различных запросов. При этом запросы могут идти, как от Oktell к WebCRM, так и наоборот. Для каждой технологии ниже приведено краткое описание, преимущества и недостатки использования.

Соединение по протоколу WebSocket

Преимущество использования WebSocket в создании постоянного канала, возможности двухстороннего обмена данными и, таким образом, оптимизации нагрузки на сетевую подсистему.

Чтобы использовать соединение по WebSocket в настройках соединения (Администрирование - Общие настройки - Web-интеграция с CRM) выберите Oktell к СRM (WebSocket) или Oktell к СRM (WebSocketSecure).

Для передачи запросов от WebCRM к Oktell используется тот же TCP-канал, поэтому этот канал называется двунаправленным. WebCRM может выполнять предустановленные методы (получать номерной план, запускать задачи и др.), выполнять служебные сценарии и получать от них результат. Протокол также позволяет выполнять хранимые процедуры в базе данных Oktell и получать результат выполнения.

Полное описание протокола вы можете прочитать по ссылке Oktell Web-Socket Protocol.

Для каждого запроса требуется базовая авторизация под учетной записью пользователя, имеющего привилегии исполнять методы Web-API. Удобнее всего, создать отдельного пользователя и выполнять от его имени все web-запросы.

Интеграция через базы данных

Интеграция посредством баз данных использует СУБД для записи и считывания значений из общих таблиц. В процессе работы Oktell и WebCRM записывают/изменяют значения ячеек, которые используются в работе. Со стороны Oktell работа происходит с помощью компонента SQL-запрос.

Например, во время входящего звонка, Oktell обращается в базу данных WebCRM, получает информацию о клиенте и маршрутизирует звонок в соответствии с полученной информацией. В свою очередь WebCRM может получить через базу данных Oktell сведения о последнем звонке клиенту и определить как давно не было активности с ним.

Подробнее вы можете прочитать по ссылке: Запрос SQL в БД

Схема работы

Сервер Oktell взаимодействует с телефонами и с браузерными приложениями с помощью клиент-серверного интерфейса. Между Oktell и каждым браузерным приложением организовывается свой независимый канал для двустороннего обмена командами управления и событиями.

Фактически, веб-приложение получает возможность взаимодействовать напрямую с сервером Oktell. Интерфейс позволяет

Принимать / совершать / переводить звонки
Создавать / управлять конференциями
Видеть номерной план / очередь звонков

Рекомендуется использовать одинаковые логины и пароли в WebCRM и в Oktell для упрощения процесса авторизации. При входе в WebCRM, пользователь автоматически авторизуется в Oktell с идентичными авторизационными данными.

ВНИМАНИЕ: Канал клиентского интерфейса не следует использовать для фиксации событий в базе WebCRM, таких как сохранение информации о входящих и пропущенных звонках. Если браузерное приложение будет отвечать за запись подобной информации, то в случае его недоступности, информация будет утеряна. Для учета подобных событий используйте только методы серверной интеграции.

Методы реализации

Задача клиентской интеграции — передача команд телефонии в браузерное приложение. Подключение происходит с помощью специально разработанных Javascript-библиотек. Соединение с Oktell устанавливается при загрузке Web-страницы. Следует отметить, что во время разговора Web-страницу нельзя перезагружать или закрывать, так как соединение будет потеряно, а значит и разговор будет тут же разорван. Для корректной работы используйте только одностраничные сайты.

Oktell.js

Oktell.js — Javascript-библиотека для встраивания функционала управления звонками в CRM-систему. Oktell.js использует WebSocket-протокол для соединения с сервером Oktell. Преимущество этого протокола заключается в создании постоянного соединения с сервером, которое позволяет без задержек получать события с сервера Oktell и выполнять определенные команды. Однако, WebSocket-протокол достаточно сложен для реализации и его методы не очень просты. Библиотека Oktell.js оборачивает внутри себя методы WebSocket-протокола, предоставляя простой функционал для управления.

Oktell.js позволяет управлять звонками, управлять конференцией, получать события из Oktell, получать доступ к данным. Работа с гарнитурой производится с помощью библиотеки Oktell-voice.js.

Инструкция по первоначальной настройке по ссылке Oktell.js

Oktell-panel.js

Oktell-panel.js — представляет собой закреплённый в браузере интерфейс, в котором отображается список контактов, статусы сотрудников, а также оптимальный набор инструментов, позволяющих управлять вызовами и конференциями.

В отличие от Oktell.js является полностью готовым решением для управления звонками. Веб-панель позволяет также использовать гарнитуру с помощью библиотеки Oktell-voice.js.

Инструкция по первоначальной настройке по ссылке Oktell-panel.js

Использование телефона

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

Гарнитура

Для подключения гарнитуры в браузере используется библиотека Oktell-voice.js, которая выполняет функцию софтфона, работающего на веб-странице. При работе используется технология передачи голоса WebRTC. Технология пока поддерживается только в браузерах Google Chrome.

Если для навигации внутри CRM-системы используется полная перезагрузка страницы или открытие окон в новых вкладках, то в Oktell постоянно будет происходить регистрация/разрегистрация устройств, что повысит нагрузку на сервер в целом, так как это трудоемкая операция. При работе десяти пользователей, количество регистраций линий может превышать 800-1000 раз в день.

Решением является использование одностраничных сайтов. При переходе между вкладками, страница не должна перезагружаться. Предлагаем следующие решения:

Решение 1. На веб-странице используется фрейм, растянутый на 100% высоты и 100% ширины страницы. Внутри фрейма происходит переход по ссылкам, внешние веб-страницы полностью подгружаются на текущую. Таким образом переход между ссылками не перезагружает текущую страницу.

Решение 2. Сервер WebCRM присылает все необходимые данные, которые динамически отрисовываются веб-страницей. При переходе с одного раздела на другой, веб-страница запрашивает данные для отрисовки, которые при получении отображает в браузере. Перезагрузки самой веб-страницы не происходит. Примером такого решения является веб-приложение Okapp.

Подробнее вы можете прочитать в статье Okapp.

IP-телефон

Чтобы использовать IP-телефон при работе в CRM-системе, необходимо в карте сети создать телефон с тем же логином, как и у сотрудника. Тогда при входе сотрудника, за ним автоматически будет закрепляться его устройство. Данный функционал доступен, начиная с версии Oktell 2.9.

Если телефоны имеют отличные логины от пользователей, то необходимо вручную закрепить устройство за сотрудником. Зайдите в Администрирование -> Карта сети -> Настройки телефона. Выберите сотрудника в поле Пользователь WebCRM.

После авторизации менеджера в браузерном приложении, телефон автоматически закрепляется за сотрудником, и при звонке будет использоваться именно это устройство.

Софтфон

Также вы можете использовать любые другие приложения, выполняющие роль софтфона. Софтфон — приложение, которое устанавливается на компьютер и позволяет совершать/принимать звонки с использованием гарнитуры. Подключение софтфона производится аналогично настройке IP-телефона.

Приведенный ниже пример не является готовым решением, а предоставлен как демонстрационный материал. Обратите внимание на взаимосвязанность процессов, зоны ответственности серверной и клиентской интеграции.

1. При входящем звонке Oktell обращается к Web-серверу с целью получения информации об абоненте, ответственном операторе и маршрутизирует звонок в соответствии с полученной информацией. Используется динамический метод “Получить информацию об абоненте по номеру телефона”.

2. Oktell маршрутизирует звонок, следуя логике сценариев. Как только сотрудник отвечает на звонок, сервер Oktell сообщает об успешной коммутации Web-серверу. Используется динамический метод “Занести информацию о звонке в WebCRM”. Если на входящий звонок никто не ответил, абоненту предлагается оставить голосовую почту, в базу WebCRM заносится информация о пропущенном звонке.

3. Oktell отправляет запрос на открытие карточки клиента в браузерное приложение. Используется динамический метод “Открыть карточку у пользователя”. Передаваемым параметром является идентификатор клиента. Заметим, что на этом этапе Oktell не может предоставить информации о клиенте, она хранится на сервере WebCRM.

4. Браузерное приложение, получив событие на открытие карточки, запрашивает информацию у WebCRM-сервера. Получив информацию, в браузере отображается карточка клиента.

5. По окончанию разговора, Oktell может снова обратиться к CRM-серверу с целью обновления информации о звонке. Заносится длительность разговора и ссылка на запись разговора.

Исходящий звонок

1. Пользователь открывает карточку клиента в браузерном приложении, нажимает кнопку “Позвонить”. Браузерное приложение отправляет на сервер Oktell запрос на совершение звонка по данному номеру телефона.

2. Oktell маршрутизирует звонок, следуя логике настроенных сценариев. После установления связи, Oktell отправляет на сервер WebCRM информацию о звонке — имя оператора, идентификатор клиента, было ли установлено соединение. Используется динамический метод “Занести информацию о звонке в WebCRM”. В свою очередь, WebCRM привязывает этот звонок к истории взаимодействия с клиентом.

3. По окончанию разговора, Oktell может снова обратиться к CRM-серверу с целью обновления информации о звонке. Заносится длительность разговора и ссылку на запись разговора. Также можно предусмотреть открытие карточки формирования новой активности в WebCRM.

Развитие Интернет сделало веб-браузеры доминирующим ПО для доступа к содержанию, приложениям и системам по всему миру. В компаниях уже сложилась тенденция предоставлять своим сотрудникам, партнерам и клиентам доступ ко всем типам информации и сервисов посредством веб. Однако в корпоративных сетях компаний функционирует огромное число разнородных бизнес-приложений, созданных в различное время, различными организациями, на базе различных технологий. Задача веб-интеграции объединить разнородные веб-приложения и системы в единую среду на базе веб.

Содержание

Типы интеграции

Интеграция на уровне представления. Уровень представления — веб-базированный пользовательский интерфейс, платформозависимый графический пользовательский интерфейс (GUI) или консоль терминала. Данный уровень позволяет пользователю взаимодействовать с приложением. Интеграция на уровне представления даёт доступ к пользовательскому интерфейсу удаленных приложений.
Интеграция на уровне функциональности. Данная интеграция подразумевает обеспечение прямого доступа к бизнес-логике приложений. Это достигается непосредственным взаимодействием приложений с API (программному интерфейсу приложений) или же взаимодействием посредством веб-сервисов.
Интеграция на уровне данных. В данном случае предполагается доступ к одной или нескольким базам данных, используемых удаленным приложением.
Комплексная интеграция. Коммерческие решения по веб-интеграции, как правило, включают все три типа интеграции.

Преимущества веб-интеграции

Веб-интеграция позволяет развертывать информационные системы на базе сторонних приложений без необходимости разбираться в их родительских системах, программных средах и архитектурах баз данных.
SOA и веб-сервисы используют программный язык и платформонезависимые интерфейсы между приложениями корпоративной инфраструктуры ИТ. Это дает очевидные преимущества в поддержке, управляемости, развертывании информационных сетей.
Веб-интеграция позволяет конструировать комплексную функциональность, комбинируя разнородные компоненты посредством протоколов веб-сервисов.
Веб-интеграция позволяет использовать веб-сервисы разработчиков.
Веб-интеграция позволяет развивать программные интерфейсы приложений через протоколы веб-сервисов без программирования.

Для веб-интеграции используется коммерческое ПО или популярные технологии, такие как PHP/Python/Perl, XForms, SOAP и т. д.

Коммерческое ПО для веб-интеграции

Интеграция Бизнес Приложений Предприятия

Связанные технологии

Примеры

Статьи

Веб-программирование
Распределённые вычисления
Парадигмы программирования

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое "Веб-интеграция" в других словарях:

Интеграция данных — включает объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде. Этот процесс становится существенным как в коммерческих задачах (когда двум похожим компаниям необходимо объединить их… … Википедия

Веб-разработка — Веб разработка процесс создания веб сайта или веб приложения. Термин включает в себя веб дизайн, программирование для веб на стороне клиента и сервера, а также конфигурирование веб сервера. Содержание 1 Основные этапы веб разработки … Википедия

Мэшап (веб) — У этого термина существуют и другие значения, см. Мэшап. Мэшап это веб приложение, объединяющее данные из нескольких источников в один интегрированный инструмент; например, при объединении картографических данных Google Maps с данными о… … Википедия

Машап — Развитие Интернет сделало веб браузеры доминирующим ПО для доступа к содержанию, приложениям и системам по всему миру. В компаниях уже сложилась тенденция предоставлять своим сотрудникам, партнерам и клиентам доступ ко всем типам информации и… … Википедия

Doom 3 — У этого термина существуют и другие значения, см. Doom (значения). Doom 3 Разработчик id So … Википедия

Gemini (программа) — Gemini технологическая дорожная карта в Gemini 3.6 Тип управление проектами Разработчик CounterSoft Операционная система Windows Языки … Википедия

История Mozilla Firefox — Объединить Mozilla Firefox … Википедия

Список расширений Firefox — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей … Википедия

Микросервисный подход в веб-разработке: micro frontends

В этой статье поговорим о микросервисном подходе в веб-разработке пользовательских интерфейсов.

Типичное веб-приложение состоит из HTML-верстки, CSS-стилей и JavaScript-кода, который позволяет достичь максимального уровня интерактивности и отзывчивости. Чем выше сложность приложения, тем сложнее пользовательский интерфейс, а вследствие этого — и инструменты, которые нужны для его разработки. Именно поэтому фронтенд-разработка превратилась из простого набора дополнений для пользовательского интерфейса в сложную экосистему с большим количеством инструментов и высоким порогом входа.

Проблема и решение

Пользовательские интерфейсы в вебе продолжают развиваться. Подтверждение этому можно увидеть и на сайте:

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

время разработки в связи с высоким уровнем сложности кода;
время тестирования;
временной интервал между релизами.

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

Монолитная архитектура — это архитектурный подход, в котором вся основная логика приложения собрана в одном месте. Монолитное приложение состоит из однослойного объединения разных компонент в одно целое.

Микросервисная архитектура — это полная противоположность монолитной архитектуры. Используя такой подход вместо одного большого приложения, мы создаем набор небольших слабосвязанных и легко заменяемых модулей, которые взаимодействуют друг с другом. Одно из главных достоинств микросервисной архитектуры — возможность использовать наилучший технический стек для каждой отдельной задачи.

Помимо этого, можно выделить и другие достоинства микросервисной архитектуры в сравнении с монолитной:

модульность;
уменьшение времени на тестирование;
сокращение времени на деплой и возможность делать это параллельно;
возможность горизонтального масштабирования команды.

А можно ли использовать микросервисный подход в веб-разработке пользовательских интерфейсов? Ответ: да! Можно и нужно! Именно такой подход и называют микрофронтенд (micro frontends).

Микрофронтенд (Micro frontends)

Микрофронтенд (micro frontend) — архитектурный подход, в котором независимые приложения собраны в одно большое приложение. Он дает возможность объединить в одном приложении разные виджеты или страницы, написанные разными командами с использованием разных фреймворков (см. рис. ниже).

Главные преимущества микрофронтенд-подхода — в разработке больших энтерпрайз-приложений:

модульная архитектура. Отдельные виджеты или страницы — это полностью независимые приложения;
скорость тестирования. Изменения в одном виджете или странице можно протестировать изолированно и только в этом приложении, не тратя времени на тестирование всего остального функционала;
параллельные деплойменты. Отдельные виджеты или страницы могут и должны деплоиться независимо.

Помимо очевидных достоинств такого подхода, у него есть и существенные недостатки:

увеличение общей сложности приложения;
дублирование кода. Каждое приложение разрабатывается отдельной командой, которая принимает свои технические решения. Это ведет к повторной загрузке одинаковых фреймворков, библиотек и общему дублированию кода, который мог быть использованным повторно;
JS-бандл монолитного приложения всегда будет меньше, чем совокупность бандлов в микрофронтенд-архитектуре;
возможные проблемы с кешированием и версионностью приложений;
глобальные переменные или CSS-стили — это вещи, о которых стоит забыть в микрофронтенд-архитектуре, если приложения полностью не изолированы.

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

К сожалению, пока не существует конкретной спецификации для построения микрофронтенд-архитектуры. Вот, пожалуй, самые доступные и простые способы и техники для построения микрофронтенд-приложений:

IFrames;
библиотека Tailor.js;
фреймворк single-spa.

Пройдемся по каждому из перечисленных подходов.

IFrames

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

производительность;
сложность поддержки.

Крайне не рекомендую строить микрофронтенд-архитектуру, используя IFrame. Сегодня существуют другие способы сделать это проще и эффективней.

Библиотека Tailor.js

Здесь вы можете прочитать больше о самой библиотеке. Компания Zalando создала целую экосистему для построения микрофронтенд-архитектуры, и Tailor.js — это часть экосистемы. Особенность Tailor.js — то, что это пакет для Node.js, и ориентирован он на построение микрофронтенд-архитектуры с серверным рендерингом.

Для меня дополнительная особенность этого пакета — недостаток документации. Живые примеры проектов я смог найти только в отдельных топиках GitHub, где обычные пользователи спрашивают совет и прикрепляют ссылки на свои репозитории с кодом. Если вам нужен серверный рендеринг, то эта библиотека точно пригодится.

Single-spa

Основной и, по моему мнению, лучший подход в построении микрофронтенд-архитектуры — это фреймворк single-spa. Вот основные причины, по которым я советую выбрать single-spa:

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

Single-spa — это фреймворк, который дает возможность объединить разные приложения, независимо от используемой библиотеки или фреймворка, в одно целое. Под капотом single-spa набор существующих инструментов вместе с собственными решениями:

SystemJS — загрузчик модулей, который нужен для асинхронной загрузки отдельных приложений;
врапперы — single-spa предоставляет отдельные врапперы под каждый фреймворк, который создает обертку над приложением, нужную для интеграции и подключения отдельного приложения в общее single-spa;
API — single-spa предоставляет набор инструментов, которые нужны для коммуникации между отдельными приложениями, подписку на события и т. д.

Типичное приложение с использованием single-spa выглядит так:

А вот так выглядит коммуникация между отдельными элементами микрофронтенд-архитектуры, построенной с использованием single-spa:

Root Application — это корень приложения. Именно здесь происходит подключение sigle-spa как основного фреймворка, а также конфигурация SystemJS для корректной загрузки внешних приложений.

Каждое дочернее приложение для корректной интеграции должно предоставлять публичные методы bootstrap, mount, unmount, которые используются фреймворком single-spa для мануального бутстрэппинга приложения. Почти под каждый современный фреймворк существует готовый враппер, который упрощает эту задачу и автоматизирует некую часть процесса. На сайте single-spa можно найти список всех фреймворков, под которые существуют готовые врапперы.

Построить набор приложений с использованием микрофронтенд-подхода и single-spa можно как путем создания полностью всей инфраструктуры и приложений с нуля, так и на основе существующего приложения. Рассмотрим примеры того, как это выглядит, создавая набор полностью новых приложений с использованием React.js и Angular 8.

Конфигурация билда для React.js под single-spa представлена здесь.

Используя существующий враппер single-spa для React.js, мы создаем интерфейс с методами bootstrap, mount, unmount, где соответственно описываем, как должно бутстрэппиться наше приложение. Враппер помогает инкапсулировать внутреннюю имплементацию и создать API для правильного подключения в single-spa фреймворка.

Похожим образом это выглядит и для Angular 8.

Так же, как и в случае с React.js, мы предоставляем интерфейс для ручного бутстрэппинга приложения на Angular 8.

Кроме использования специфичных врапперов, приложение должно быть собрано как amd-модуль. Каждый такой модуль асинхронно подключается в корень всей микрофронтенд-архитектуры — Root Application. Ниже пример элементарной имплементации.

Две главные части, на которые стоит обратить внимание:

script-тег, в котором нужно описать маппинг названия приложения, на адрес, с которого single-spa будет подгружать amd-модуль для этого приложения;
script-тег, где нужно непосредственно зарегистрировать приложение с помощью метода registerApplication. Здесь нужно указать адрес, при переходе на который system.js будет загружать соответствующий модуль.

Как можно увидеть, Root Application — простой HTML-файл с основными конфигурациями для загрузки других приложений. В одном микрофронтенд-приложении можно зарегистрировать множество микроприложений. Если при регистрации приложения в 3-м параметре метода registerApplication указать просто /, такое приложение будет загружаться для каждого доступного адреса. Именно такой подход желательно использовать для создания навигационной панели или частей приложения, которые являются общими и не должны загружаться повторно при переходе между приложениями.

Полностью рабочий пример того, как это работает, можно найти в моем GitHub-репозитории.

В этом репозитории представлена пошаговая имплементация микрофронтенд-архитектуры, финальная рабочая версия — в ветке с названием step-7.

Нам, разработчикам, далеко не всегда приходится создавать приложения с нуля. Single-spa дает возможность полностью использовать существующие приложения как элементы микрофронтенд-архитектуры, будь то Root Application или асинхронно загружаемые микроприложения.

Если из существующего приложения нужно создать Root Application, тогда в первую очередь нужно в index.html подключить библиотеки для single-spa и добавить все необходимые для загрузки других микроприложений конфигурации. После того как ваш index.html стал Root Application в single-spa, можно приступить к настройке остальной части приложения для корректной работы в single-spa-архитектуре так, как это описано в предыдущем абзаце.

Проблемы и недостатки

зависимости — очень много зависит от того, каким образом в вашем приложении загружаются зависимости. Все, что не import, потенциально может вызвать проблемы на этапе сборки или выполнения;
стили, картинки, шрифты — скорее всего, все это будет поломано или с багами после первой успешной сборки вашего микроприложения.

На этапе конфигурации проблемы, с которыми вы столкнетесь, будут самые разнообразные, поэтому запаситесь терпением 😉

Кроме сложной конфигурации, выделим проблемы, которые могут возникнуть при построении микрофронтенд-архитектуры с использованием single-spa:

кеширование микроприложений. Без правильной стратегии по кешированию микроприложения, как и Root Application, будут кешироваться в браузере и игнорировать любые новые изменения, которые будут релизнуты;
дебаггинг. Если что-то не работает, дебаггинг без дополнительных конфигураций и надстроек может быть довольно тяжелым процессом, так как вам придется дебажить не приложения, а отдельные amd-модули без сорс мап;
общий размер приложения вместе со всеми асинхронными микроприложениями увеличится, в сравнении с монолитным подходом;
общая производительность микрофронтенд-приложения будет ниже, чем у монолита;
повторение кода. Повторная загрузка кода — как библиотек, так и целых фреймворков — ведет к ухудшению быстродействия всего приложения, а не только отдельной страницы. Single-spa дает возможность шарить зависимости между приложениями, но помните: чем больше у вас зависимостей, библиотек, компонент, которые шарятся между приложениями, тем больше ваша микрофронтенд-архитектура похожа на монолитную;
SEO-оптимизация. Загрузка отдельных приложений вместе с бутстрэппингом полностью проходит на клиенте, что значительно усложняет SEO-оптимизацию. Single-spa не поддерживает серверный рендеринг, для добавления поддержки можно использовать связку single-spa + Tailor.js.

Выводы

Микрофронтенд-архитектура, как и любая другая архитектура, решает одни проблемы, создавая другие. Микрофронтенд-архитектура усложнит вашу жизнь и жизнь вашей команды, если:

над проектом работает меньше 10 человек и нет планов к расширению;
ваше приложение не состоит из абстрактных изолированных модулей, которые в перспективе могут быть отдельными приложениями;
багфиксинг вместе с разработкой новых фич проходит быстро и без трудностей, связанных с размером вашего приложения.

Один из частых вопросов: можно ли использовать single-spa для миграции с одного фреймворка на другой (например, с AngularJS на Angular 2+)? Можно, но не нужно: практически всегда есть более легкий и нативный способ миграции, который требует меньше конфигурационной работы и который будет работать быстрее.

Читайте также: