Переход от инфраструктуры Java Spring к архитектуре API ReactJS +

Мы видели это миллион раз. Старые платформы, созданные десятками разработчиков на протяжении стольких лет, с устаревшим кодом, созданным поколениями. Программа работает - но еле-еле. И он остро нуждается в ремонте.

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

Мы работали над подобными случаями несколько раз, преобразовывая платформы Java (также .Net, Rails, вы называете это) в современную архитектуру. И поверьте мне: это возможно. Проверьте эту ссылку с множеством громких тематических исследований. Это более приземленная статья с более конкретным примером после той, которую я написал некоторое время назад. Хотя это может быть хорошей ссылкой.

Зачем менять архитектуру платформы?

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

Текущая архитектура

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

Есть большая вероятность, что вы работаете над этой платформой в течение длительного времени, и по одной из причин, указанных выше, вы ДОЛЖНЫ измениться. Скорее всего, у вас нет тестов, вы не хотите ничего ломать и не знаете, с чего начать. Если это ваша ситуация, эта статья для вас.

Что мы хотим

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

Готово для мобильных устройств: мы можем работать над мобильными приложениями и легко подключать их к нашей бизнес-логике.
Ремонтопригодность: мы можем вносить изменения в бизнес-логику, не вызывая ошибок и не вызывая каких-либо проблем. Все изменения будут отражены на всех платформах (веб, мобильные, сторонние).
Автоматизировано: мы можем легко писать автоматизированные тесты, интегрировать серверы CI и проложить путь к среде компакт-дисков.
Чистый: чистый HTML и CSS. У нас будет хорошо структурированный, семантический и удобный в обслуживании пользовательский интерфейс.

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

Так что давайте делать это шаг за шагом.

Шаг 1 - Закладываем фундамент

Во-первых, немного предыстории. Мы не изобретаем велосипед здесь. Facebook сделал то же самое во всей своей экосистеме. Это возможно.

Сила ReactJS в том, что это библиотека, а не фреймворк. Это позволяет нам работать модульно, мигрируя по одному компоненту за раз, пока мы не сможем (в конечном итоге) достичь полного разделения пользовательского интерфейса и API, создавая основу для современной архитектуры. Чтобы узнать больше о ReactJS, посетите Pluralsight.

Первое, что нам нужно сделать, это определить автономный компонент приложения. Это может быть новая функция, простая или неприятная. Вы можете написать этот новый компонент с помощью ReactJS. Но затем сложная часть: как нам интегрировать новый компонент ReactJS в существующую платформу, когда его пользовательский интерфейс отображается на сервере и отправляется как HTTP-ответ?

У нас есть два варианта.

Метод 1: рендеринг полных страниц

Если компонент, который мы создаем, является полностраничным, мы можем создать полностью новый сайт ReactJS с его собственным URL-адресом и отделить его от Spring UI. Для этого нам понадобится обратный прокси, который можно настроить с помощью Apache, Nginx и т. Д.

Мы можем настроить наш новый блестящий сайт ReactJS, работающий на Node.js или просто на статической корзине Amazon S3. Нам нужен шаблон URL-адреса, чтобы решить, исходит ли конкретная страница со стороны Spring или ReactJS. В этом примере мы использовали / ui / *, поэтому все, что соответствует шаблону www.yoursite.com/ui/*, будет использовать ReactJS. Вот пример использования Nginx.

Долгосрочная цель - переместить все на ReactJS и отрезать пуповину до уровня пользовательского интерфейса фреймворка Spring. Это устранит необходимость в обратном прокси-сервере, но, опять же, давайте делать это постепенно.

В качестве дополнительного примечания, причина для запуска сервера узла только для SEO целей.

Метод 2: рендеринг определенных компонентов

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

1. Включите заполнитель в пользовательский интерфейс, созданный Spring framework.

Допустим, мы хотим отобразить список клиентов с помощью ReactJS. Затем мы должны включить заполнитель div (или раздел или таблицу). Что-то вроде:

<div data-react-class=“name-of-my-component” data-react-props=“<some JSON data>”>
</div>

2. Включите файл Javascript, который найдет все заполнители ReactJS и запустит средство визуализации для каждого из них.

Для этого можно использовать класс ReactDOM.

Мы можем передавать информацию с помощью props, но в идеале каждый компонент должен получать все данные из серверной части.

Мы обрабатываем ReactJS. Что теперь?

На данный момент у нас есть компонент ReactJS, который отображается либо как полная страница, либо как меньшие компоненты внутри существующего. Теперь нам нужно подключить его к API.

Мы можем создать этот API, используя выбранный нами язык. Я предполагаю, что у нас уже есть команда Java, так что давайте использовать Java. В идеале мы будем создавать красивый семантический RESTful JSON API. Этот API может использовать уровень сервисов нашего существующего кода.

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

Вот как это будет выглядеть:

Шаг 2. Итерируйте и откажитесь от устаревшего кода

По мере прохождения процесса идентификации компонентов, написания их с использованием ReactJS и построения конечных точек для этого может произойти несколько вещей. Большинство из них хорошие вещи.

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

Кроме того, мы сможем создавать мобильные приложения и подключать их к одним и тем же API. В качестве бонуса мы можем использовать ReactNative и повторно использовать некоторые из наших существующих компонентов ReactJS.

Вот как это будет выглядеть после этих изменений.

Шаг 3.Устаревший уровень представления фреймворка Spring

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

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

Теперь у нас будет веб-приложение, на 100% построенное с использованием ReactJS, и мы сокращаем зависимость от уровня представления Spring. Все наши данные доступны через сервисы Restful, и в качестве примера диаграмма содержит новый API, построенный с использованием другого языка (Go) и базы данных NoSQL (Redis).

Для простоты некоторые вещи опущены. Любой API может или не может обращаться к СУБД, в зависимости от потребностей. Разные компоненты ReactJS будут использовать разные конечные точки и разные API. Ничего страшного, если компонент использует более одного API, но если это происходит слишком часто, это, вероятно, означает, что ваша архитектура API нуждается в пересмотре.

Резюме и несколько дополнительных советов

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

Всегда не забывайте создавать семантический, хорошо структурированный HTML. Это занимает больше времени, но оно всегда того стоит. Если вы не уверены в CSS, используйте CSS-фреймворк, например Bootstrap или Grid. Сохраняйте простоту, гибкость и следуйте стандартам. Здесь вы можете найти последние стандарты, которые мы применяем для CSS. Никогда не недооценивайте, насколько важно писать высококачественный CSS.

Не забудьте протестировать компоненты ReactJS и, если возможно, написать сквозные тесты. Документируйте и тестируйте каждую веб-службу и будьте внимательны при создании нового API или среды. Сохраняйте простоту, реорганизуйте и повторяйте.

Ударь меня

Я надеюсь, что эта статья оказалась для вас полезной, и если у вас есть какие-либо вопросы по тонкостям капитального ремонта архитектуры, нет ничего, что я люблю больше, чем обсуждение процессов цифровой трансформации. Даже если это простой вопрос, я здесь, чтобы поговорить - не стесняйтесь, напишите мне на [email protected].

Переход от инфраструктуры Java Spring к архитектуре API ReactJS +