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

Я Дипак, технический руководитель WebStudio Team, который помогает разрабатывать структуру для DBS-компонентов и стандартов кодирования в DBS Bank. WebStudio используется на шести рынках, во многих продуктах и ​​сотнями разработчиков. Смысл существования команды WebStudio заключается в улучшении общего пользовательского опыта (UX) веб-приложений.

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

Принятие важного решения

Когда мы начали изучать инструменты для создания безопасного, отказоустойчивого и масштабируемого фреймворка, мы решили сначала обновить UI / UX внешнего веб-сайта, чтобы обеспечить более плавный переход от одной функции к другой. Для этого мы сравнили Angular и React.js по нескольким параметрам. К параметрам относятся количество звездочек на GitHub, количество открытых проблем на GitHub, простота использования и наличие сообществ разработчиков. Решение было непростым. Обдумав все это, мы решили использовать React.js., Который стал нашим языком для фронтенд-разработки.

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

Однако после понимания концепции микро-интерфейса (описанной ниже) действительно не имеет значения, какой язык вы выберете для написания микроприложения.

Строительные блоки и Лего

Пока React.js установил этот флажок, нам также нужно было выяснить, как поддерживать большой набор модулей, особенно для крупномасштабных проектов. Помимо поддержки нескольких проектов и более 200 разработчиков, у нас также есть индивидуальные кодовые базы для разных стран. Количество наборов инструментов и библиотек, которые мы должны создать, может быть ошеломляющим!

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

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

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

Например, предположим, что вы пишете функцию небольшой суммы, которая может суммировать только 2 числа. Как вы пишете код на JavaScript?

// Sample 1: No validation
function sum(num1, num2) {
  return num1 + num2;
}
// Sample 2: Better name
function sumNumbers(num1, num2) {
  return num1 + num2;
}
// Sample 3: Handle errors
function sum(num1, num2) {
  if (typeof num1 !== "number") throw Error("Not a Number");
  return num1 + num2;
}
  1. Теперь в первой функции нет проверки. Но что произойдет, если пользователь решит передать строку и число вместе?
  2. Во втором примере мы создали функцию с более подробной информацией о том, что эту функцию можно использовать для суммирования только двух чисел.
  3. В третьем подходе мы можем добавить проверки. чтобы пользователь не мог передать значение, кроме числа.

Это лишь некоторые из множества проблем, которые могут возникнуть при работе с JavaScript. Чтобы этого не произошло, нам нужна была строгая проверка типов. Есть много способов провести строгую проверку. Мы решили использовать TypeScript, так как работали с ним ранее. Чтобы поддержать разработку в таком большом масштабе, мы использовали formium / tsdx, отличный инструмент для создания библиотеки TypeScript.

Примечание. Мы создали структуру и библиотеку Angular для поддержки внутренних приложений. Angular хорошо работает с TypeScript.

Учимся на своих ошибках

Мы допустили ошибки при создании фреймворка Angular. В то время мы экспериментировали, пытаясь выполнить поставку быстро. Чтобы сэкономить время и усилия, мы обернули наш код сторонней библиотекой, что привело к последующим проблемам с поддержкой платформы, особенно когда нам пришлось перейти на более новую версию сторонней платформы. . Мы также старались не быть единственной точкой отказа для команд. Эти знания в конечном итоге привели к тому, что мы решили использовать модель с открытым исходным кодом для создания компонентов, которые доступны пользователям в Банке и в которые они могут внести свой вклад. Конечно, этот режим работы требует надлежащего управления - нам нужно было убедиться в наличии необходимых сдержек и противовесов,

Качественные ворота

Некоторые люди могут пренебречь нашими усилиями и сказать, что React.js - это не ракетостроение, но перемещение бизнес-логики намного сложнее, чем кажется! Вот почему важно иметь базовое представление о React.js и среде node.js, хотя мы помним, что нет необходимости изобретать велосипед.

С помощью нашей команды DevOps мы создали общий конвейер для всех типов моделей фреймворка, включая те, которые поддерживают сборку, модульное тестирование, регрессионный тест, статический анализ кода, тестирование брандмауэра / уязвимости и продвижение в репозиторий nexus. Как только мы защитим код, мы сможем сделать его доступным для других команд.

Почему сейчас все в моде о MFE

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

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

Чтобы заархивировать все эти параметры, нам потребовались четкие инструкции по созданию чего-то нового. Но сначала нам пришлось преодолеть несколько препятствий. Первой задачей было познакомить людей с концепцией MFE, потому что наши разработчики имели разный опыт. Мы придумали гибридный подход, вместо того, чтобы создавать микро-интерфейс и развертывать его на отдельном сервере. Мы создали отдельные репозитории для каждого MFE, которые можно было легко развернуть и протестировать отдельно. Чтобы использовать MFE, команда разработчиков приложения должна импортировать MFE как модуль nexus / npm. При каждом обновлении MFE команда разработчиков приложений должна перестроить и развернуть. Таким образом, мы можем добиться повторного использования и провести тестирование без единой точки отказа.

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

Недостающее звено

Когда мы создавали фреймворк WebStudio, мы не хотели, чтобы разработчики пропускали наши обновления. Чтобы информировать пользователей о последней информации, мы создали автоматизированный сайт документации с использованием Gatsby. Гэтсби поставляется с несколькими плагинами. Используя некоторые основные плагины и наш собственный плагин, мы заполнили всю необходимую информацию, связанную с компонентами и MFE. И задокументировал наши библиотеки с использованием пользовательских компонентов React.js и файлов MDX (уценка с реакцией). Мы также создали конвейер для документации, который компилирует и объединяет страницы из модулей npm в портал WebStudio во время сборки.

Хотя Гэтсби облегчает нашу работу, чем больше кода мы добавляем, тем медленнее она становится. В настоящее время мы работаем над его оптимизацией, одновременно ищем альтернативы, которые улучшат работу наших разработчиков.

Вывод

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