OpenComponents (также известные как OC) были задуманы около 5 лет назад, когда в OpenTable нам понадобился лучший способ внести свой вклад в кодовую базу нашего потребительского сайта. Посвятив большую часть моих пяти лет работе с OC и микро-интерфейсом, я решил поделиться некоторыми из наиболее важных уроков.

1) Эта бессерверная штука 👍

Одна из основных функций OC - позволить разработчикам публиковать и распространять готовые к производству компоненты менее чем за 10 секунд. Во время публикации OC компилирует и сохраняет функцию JavaScript, которая будет выполняться Node.js на сервере по запросу. Запрос каждого компонента приводит к асинхронному выполнению замыкания, которое создает модель представления, которая затем используется в качестве данных для визуализируемого компонента.

export const data = (context, callback) => {
  const { name } = context.params;
  callback(null, { welcome: `Hello ${name}`});
};

OC внутри компании обрабатывает этот механизм аналогично «функции как услуга», позволяя командам последовательно и безопасно выпускать компоненты в производство, не тратя время на настройку и масштабируемость. Оказалось, что это ядро ​​«бессерверных» архитектур: Amazon стала популярной благодаря Lambda около 3 лет назад, и будущее бессерверных архитектур выглядит очень радужным.

2) Компоненты как конечные точки 👍

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

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

3) CSS с областью видимости и CSS-in-JS 👍

Я помню, что три года назад, когда говорили о OC на конференциях и публичных мероприятиях, люди не были уверены в идее встраивать CSS компонента в тег ‹style› или использовать для этого JavaScript. На самом деле, многие считали это безумием и ошибкой во многих смыслах.

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

<html>
<head>
  <link href="//cdn.com/bundle.min.css" />
</head>
<body>
  <oc-component href="//oc-registry.com/header/1.x.x">
    <div class="header-site">
      Server-side rendered header component
    </div>
  </oc-component>
  <oc-component href="//oc-registry.com/advert/1.x.x">
  </oc-component>
  ...
</body>
</html>

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

CSS-in-JS был именно тем, что нам было нужно. Когда каждый компонент начал иметь свой собственный стиль вместе со всем серверным и браузерным JavaScript (вместе с методами оптимизации и инкапсуляции), зависимости между стилями (и зависимости между командами) исчезли. Разработка, тестирование и развертывание стало проще и проще. Сегодня CSS-in-JS - это де-факто стандарт для микро-интерфейсов, а инструменты просто фантастические.

4) Множественные HTTP-соединения и HTTP / 2 🤓

Спорный момент в отношении композиции среды выполнения заключается в том, что фрагменты - это не просто фрагменты HTML. При составлении во время выполнения 10 фрагментов, каждый с тегом ‹script›, который будет выполнять HTTP-запрос, производительность может снизиться, поскольку браузеру потребуется сделать много запросов к CDN, чтобы получить все ресурсы для страница, которую нужно отобразить. К счастью, HTTP / 2 и мультиплексирование упрощают эту задачу. Возможностей для сжатия может быть меньше, но, по моему опыту, это часто приемлемый компромисс.

5) Внешнее заимствование 😍

Проблема чего-то вроде OC заключается в том, что это не для всех: когда мы открыли исходный код кодовой базы и выпустили весь продукт под MIT для 100% бесплатного использования и модификации, мы знали, что малые и средние организации, скорее всего, в этом не нуждаются. чего-то в этом роде. С другой стороны, средние и крупные организации очень часто либо предпочитают разрабатывать что-то вроде OC собственными силами, либо не хотят доверять фреймворку с открытым исходным кодом, который разрабатывается и поддерживается извне.

Но мы ошибались.

Пару лет спустя новые пользователи, такие как Skyscanner, Chegg, Cisco и другие, начали связываться с нами, внедрять OC в производство и вносить свой вклад в сообщество, создавая новые проблемы, предлагая новые идеи, и отправка изменений кода.
Я очень горжусь некоторыми историями, которыми многие авторы поделились здесь.

6) Внешний евангелизм 😎

Многие разработчики, включая Nick, Mattia, Ant, Maria, Dev, Genar и я, имели возможность поговорить о OC и микро-интерфейсах на более чем 30 мероприятиях по всему миру, собрав обратная связь и встречи с некоторыми из величайших экспертов сообщества для обсуждения технических и культурных проблем, связанных с этой архитектурой. Это позволило нам разработать систему, имея в виду не только конкретный сценарий в качестве варианта использования, но и постоянно подвергая сомнению наши предположения, чтобы иметь возможность рассказать историю кому-то, у кого очень мало контекста. Когда вы годами работаете над базой кода и вам нужно представить ее незнакомой аудитории за 25 минут, вам нужно, чтобы история оставалась простой, и лучший способ сделать это - сделать вашу систему простой, модульной и хорошо документированной.

7) Внешние взносы 😎

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

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

Когда мы начали получать отзывы и пожелания сторонних разработчиков, было легко решить, как продолжить работу и расставить приоритеты. Все, что технически соответствовало видению, было тем, на что мы выделили время, чтобы рассмотреть и объединить. Например, группа разработчиков помогла расширить Rest API, чтобы разработать специальный клиент Node.js, который обрабатывает кеширование и аннулирование несколько иначе, чем официальные клиенты OC. Теоретически мы могли бы считать этот аспект отвлечением и, возможно, потерей времени, но на практике открытие новых идей привело к увеличению внешнего вклада, от которого мы все выиграли.

8) Управление и сообщество 🤗

Одним из инвестиций, которые мы сделали в прошлом году, было перемещение всей платформы, включая ядро, библиотеки, плагины и инструменты, в совершенно новую открытую организацию Github: https://github.com/opencomponents. Это позволило нам безопасно выйти за рамки внутренней организации и расширить круг наших участников. Принцип работы прост: если у вас есть репозиторий вокруг OC, мы помогаем переместить его, и мы не будем мешать вам, пока код и участники соблюдают «наш Кодекс Поведение". Если вы сделаете запрос на слияние , это означает, что вам не все равно, и вы станете администратором репо, как только он будет объединен. Таким образом, каждому доверяют, чтобы все было в соответствии с видением и, возможно, совершало достаточно ошибок и внедряло инновации, обучаясь вместе с другими.

Одна из частей, которыми я очень горжусь, - это адаптеры хранилища: мы вместе работали над абстрагированием всех зависимостей вокруг AWS, чтобы внешние участники создали и теперь поддерживают адаптеры для Google Cloud Platform, Azure и других. Это, очевидно, облегчает принятие и внесение вкладов. (Большой привет Нику, Кену Кроуфорду и Петру за то, что это произошло.)

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

9) Не отставайте от сообщества 😢

Ведение блогов о OC - это то, что нам нужно делать больше. Последний пост в блоге о OC был написан мной более 2 лет назад, то есть очень давно. Мы надеемся улучшить это, написав в будущем частые небольшие статьи.

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

Заключение

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

В будущем, работая над подобным проектом, OC обязательно повлияет на мое решение. Вот некоторые из самых важных выводов для меня после сотен ошибок:

  • Откройте базу кода с 0 дня
  • Будьте открыты в отношении архитектурных решений, процессов, документации, разговоров. Сделайте все общедоступным
  • Будьте открытыми и усердно работайте, чтобы создать разнообразную группу участников.
  • Будьте организованы и следите за всеми проблемами и прогрессом
  • Автоматизируйте все, что вы можете, и инвестируйте в поддержание работы автоматизации
  • Всегда приветствуем отзывы и критику
  • Обратитесь за помощью, когда она вам понадобится
  • Рискуйте при разработке программного обеспечения, но не заходите слишком далеко - заплатите технический долг и извлеките уроки из своих ошибок.
  • При работе над инструментами разработчика часто используйте свои собственные инструменты, чтобы иметь короткий цикл обратной связи и улучшить сочувствие.
  • Продолжайте совершать ошибки и не бойтесь показать это - быть человеком - это прекрасно и здорово