Что лучше для вашего следующего приложения - Angular или React? Почему не оба? 

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

Но ты не можешь.

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

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

Либо это, либо переписать всю систему. Потому что перезаписи эквивалент начать все заново - просто цикл повторяется снова и снова.

Это проблема, с которой сталкиваются многие организации. Так как мы можем это исправить?

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

Вопрос с монолитами

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

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

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

Искусство отделить ваше приложение от фреймворков

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

У вас могут быть части страницы, работающие в React, в Angular или даже Vue. Устаревший код не нужно выбрасывать полностью и использовать повторно, пока бизнес не решит его устранить. Хотя это звучит как приложение Франкенштейна, это более дружелюбный и более современный зверь, чем тот, который требуется для использования старых технологий.

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

Преимущества Angular, React и даже Vue в том, что они могут работать в контейнере. Модули в структурах на основе компонентов Angular и React позволяют каждому работать самостоятельно. Для этого потребуется изменить способ кодирования вещей, например, перейти от структуры контроллера представления модели к структуре на основе компонентов с ограниченными и изолированными областями.

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

Преимущества перехода на микро-фронт

В мире agile способность команды эффективно производить также связана с их автономией в создании.

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

Если одна часть не работает, то это не должно повлиять на остальную часть приложения. Это также может снизить скорость загрузки и повысить удобство работы пользователей, поскольку они могут взаимодействовать с приложением до того, как все будет загружено.

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

Заключительные слова

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

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

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

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

Перевод статьи: Which is better for your next app — Angular or React? Why not both?