Зачем нам нужна платформа для фронтенд-рендеринга

Зачем нам нужна платформа для фронтенд-рендеринга

(и как мы к этому добираемся)

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

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

Чтобы знать, как куда-то добраться, нужно знать, где вы находитесь.

Позвольте мне вкратце отвезти вас туда, где мы находимся сегодня, чтобы я мог объяснить вам, куда мы идем завтра.

Этап 1. Доказательство ценности

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

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

Этап 2: повторное использование компонентов

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

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

Этап 3: изолировать объекты

Мы начали добавлять функции, но решили не добавлять их в текущую настройку. Каждое изменение, которое мы вносим в наше решение, связано с одним и тем же вопросом. Что было бы, если бы мы разделили это на услугу? Чтобы снизить риск чрезмерного усложнения вещей, мы предпочитаем готовиться, а не делать большие шаги, чем жизнь. Небольшие итерации и обучение. Иногда это означает, что услуга может быть реализована с нуля, но часто это также означает, что услуга использует функциональность монолита. Тем не менее, это хорошо: мы можем узнать о том, что нам действительно нужно и что используем, и о том, как, по нашему мнению, должно выглядеть будущее, не полагаясь полностью на то, с чем мы (пока) не уверены в полной мере. .

Теперь, когда функции вынесены за пределы монолита, а компоненты перемещены в отдельные библиотеки, мы подошли к следующему узкому месту. Чем больше функций мы передаем, тем меньше монолит может их отобразить. Видите ли, VUE - это технология Javascript, а визуализация интерфейса / шаблона - это отдельная возможность. Спрос изменился, и улучшение монолита в этом аспекте не имеет большого смысла. Я написал статью о том, как сделать это таким образом, чтобы не требовать больших вложений, и в то же время получить немедленное SEO и повышение производительности в Подавление единорога (безопасное отделение интерфейса от монолита) »

Этап 4. Передача ответственности за внешний рендеринг

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

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

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

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

Фаза 5 (вот где мы): нефть! Теперь создайте платформу

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

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

Мы хотим четких границ ответственности и интеграции.

И это то, что нам нужно предоставить. Мы уже реализовали некоторые этапы взаимодействия с клиентом в этом одном большом репозитории Nuxt, и число невыполненных заказов растет. Пришло время выделить эти проекты (части пути клиента) в их собственные репозитории.

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

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

Это начало потребности в платформе, прямо здесь.

Платформа: «ровная поверхность, на которой могут стоять люди или предметы».

Это определение платформы. И это именно то, что есть. Стабильная поверхность кода, которая берет на себя часть тяжелой работы со всем, что на ней стоит.

Поскольку все проекты должны быть объединены, чтобы хорошо работать вместе, нам придется внести некоторую сложность в это единственное место, чтобы все проекты сами стали менее сложными.

Давайте посмотрим, что вы можете ожидать от этой платформы:

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

Новые сложности

Перенося все эти факторы в платформу (и, следовательно, уменьшая сложность репозиториев проектов), мы по сути создаем новые сложности.

• Как код работает вместе после объединения?
• Как, например, компоненты по-прежнему влияют на проекты (и, следовательно, потенциально нарушают обещание автономии и безрискового сотрудничества)
• Как интегрально проверяется и гарантируется поведение
• Если одна платформа объединяет все, чтобы стать одной, прежде чем она сможет работать, как это повлияет на производительность, в частности, на процесс разработки?
• Какие возможности следует передать проектам, а какие - на уровне платформы?

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