Хотите верьте, хотите нет, но это актуальная тема.

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

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

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

Что касается микрофронтендов, есть несколько вопросов, на которые еще нет ответа:

  • Как концепция, когда она родилась?
  • Как конкретная (и общедоступная) реализация, когда она появилась? Кто это сделал?

Попробуем ответить на эти вопросы.

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

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

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

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

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

Тем не менее, это может не дать полного представления о том, что на самом деле происходит в отрасли.

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

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

Возвращаясь к микрофронтендам…

Первый вопрос:
"Как концепция, когда она родилась?"

Ответ: Oracle в 1995 году с "Java-апплетом"
(падение которого началось примерно в 2013 году и завершилось в 2017–2018 годах).

Но почему это важно? И почему вперемешку с микрофронтендами?

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

«Апплеты Java работают с очень высокой скоростью, и до 2011 года они были во много раз быстрее, чем JavaScript. В отличие от JavaScript, Java-апплеты имели доступ к аппаратному 3D-ускорению, что делало их подходящими для нетривиальных визуализаций, требующих больших вычислительных ресурсов (…).

После компиляции полученный файл .class можно поместить на веб-сервер и вызвать на HTML-странице с помощью тега «апплет» или «объект».

(Википедия)

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

Пример:

<applet code="HelloWorld.class">
    <!-- This is where HelloWorld.class runs. -->
</applet>

Этот тег `applet` напоминает веб-компонент, верно?

Итак, Oracle с Java-апплетами положили начало концепции микрофронтендов, но их технология умерла, и они так и не распространили ее вовремя, как того заслуживала тема.

Это идеально подошло бы для микрофронтендов:

  • Меньшие кодовые базы
  • Независимо развертываемый
  • Изолированный
  • Вертикальная нарезка
  • …

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

Второй вопрос:
«Как конкретная (и общедоступная) реализация, когда она появилась?
Кто это сделал?”

Ответ: Facebook, 2009 г. с BigPipe.

И снова Facebook в выигрышной позиции.
Я не удивлен, вы тоже не должны быть удивлены.

Facebook, взяв в качестве примера домашнюю страницу (или новостную ленту), настолько неоднороден, что, конечно, они подумали о «независимо от результатов, которые должны быть составлены в большее целое». Это было секретное оружие Facebook для выступлений на их собственном сайте, но, может быть, оно оказалось чем-то большим?

Современные веб-сайты стали значительно более динамичными и интерактивными, чем 10 лет назад, а традиционная модель обслуживания страниц уже не соответствует требованиям скорости современного Интернета.

(…)

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

BigPipe был вдохновлен конвейерами микропроцессоров. Сначала BigPipe разбивает веб-страницы на несколько фрагментов, называемых «страницами», а процесс генерации страниц — на несколько этапов, некоторые из которых выполняются на стороне сервера, а другие — на стороне клиента. По первому запросу клиента сервер возвращает незакрытый HTML-документ, при этом продолжает генерацию страниц. Этот неполный документ имеет логику javascript BigPipe для управления и создания оставшейся части страницы после отправки страниц с сервера.

Хорошо, мы не знаем, какова их архитектура и стратегии интерфейса Facebook, но абсолютно точно это архитектура для микроинтерфейсов.

Под изображением старомодной домашней страницы Facebook:

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

Ссылка на оригинальный пост в блоге Facebook: https://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919/

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

Выводы

В этой статье я дал непредвзятые ответы на следующие вопросы о микрофронтендах

  • Как концепция, когда она родилась?
  • Как конкретная (и общедоступная) реализация, когда она впервые появилась? Кто это сделал?

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

Личное примечание: понимание проблем, стоящих за созданием нового решения, очень важно для освоения технологии.

Надеюсь, вам понравилось чтение.
Я призываю вас оставить комментарий с вашим мнением.

#микрофронтенды #мифы #раскрытые