Чтобы понять суть статьи, позвольте мне объяснить вам, что такое Schibsted Spain. Schibsted Media Group - один из мировых лидеров в области онлайн-рекламы, работающий в 22 странах мира и охватывающий более 200 миллионов человек по всему миру. Одна из таких стран - Испания 🇪🇸. В Испании, как Schibsted Spain, есть разные торговые площадки. Для недвижимости вы можете найти Fotocasa, Habitaclia, для вакансий InfoJobs, автомобили и мотоциклы в Coches.net, Motos.net. Для универсалов можно найти Milanuncios и Vibbo.

Фактически, все эти торговые площадки представляют собой разные продукты с разными командами и, да, разными разработчиками с разными мнениями, но, тем не менее, с очень похожими потребностями. Мы распространили одну и ту же компанию на дюжину разных инструментов для создания пакетов (Browserify, Webpack, ручные системы…), для каждого из них у нас были разные версии во многих разных репозиториях. И представьте себе, что у всех были разные конфигурации, которые поддерживали разные файлы по-разному. Одним словом: хаос.

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

Для этого мы начали создавать набор инструментов под названием SUI (Пользовательский интерфейс Schibsted), чтобы извлечь основные функции и инструменты для пакетов. Мы видели эти инструменты, такие как наш AAAS (Архитектура как программное обеспечение), и сосредоточились на следовании правилам Unix, чтобы сделать инструменты как можно более модульными, независимыми и заменяемыми. По сути, мы всегда могли изменить весь инструмент, чтобы параметры входа и выхода оставались неизменными.

Мы также внедрили другие вещи: Javascript с нулевой конфигурацией (# 0CJS), чтобы избежать точек с точками и файлов конфигурации в наших проектах и ​​репозиториях; и Совместимое управление версиями, чтобы всегда полагаться на основную версию, получать новые функции и исправления бесплатно и быть как можно менее деструктивным. Обе характеристики заставляли нас очень осторожно подходить к своим решениям, но по прошествии одного года я могу сказать, что решение было успешным.

@ s-ui / bundler, используя Webpack в качестве платформы для сборки

Итак, одна из самых важных вещей, которые объединяли все наши проекты, - это способ создания пакетов. В то время как некоторые использовали Browserify, некоторые использовали Gulp, а другие начали использовать Webpack. Мы создали новый инструмент под названием @ s-ui / bundler, чтобы унифицировать способ его создания на основе Webpack, так как это явно был де-факто способ объединения приложений во внешний интерфейс.

Это предлагает набор правил, основанный на минимально возможных предположениях. Например, поддержка файлов Sass и ES6 с помощью Babel с babel-preset-sui. Мы старались сохранить эти предположения как можно меньше, чтобы иметь возможность быстро выполнять итерацию и быстро развивать наши зависимости. Например, от Webpack 1 до фактического Webpack 4 нам не пришлось делать больших изменений, и нам не пришлось создавать много основных @ s-ui / bundler, чтобы пользователи приняли его.

Но, как вы могли заметить, @ s-ui / bundler не является простой предустановкой для Webpack, поскольку он также обеспечивает:

  • Никаких настроек для начала. Просто поместите index.html и app.js, и все готово.
  • Режим разработки с некоторыми полезностями, такими как горячая перезагрузка, ошибки на экране и где вы можете легко связать внешние пакеты с помощью параметра link-package. Основное отличие от npm link заключается в том, что файлы компилируются на лету с помощью babel, что обеспечивает быструю горячую перезагрузку. Также совместим с файлами SASS.
  • Пакет приложений, режим Lib и компиляции сервера.
  • Встроенный интерфейс командной строки для всех команд, а также способ анализа пакета.
  • Набор оптимизаций для CSS и чанков.

Итак, @ s-ui / bundler дает вам возможность создать свое веб-приложение за несколько секунд с минимальным шаблоном, но с желаемой структурой и технологией, которым мы хотим следовать в Schibsted Spain во всех проектах. Но, тем не менее, это еще не все ...

Развитие платформы, строительство на ней

В Schibsted Spain мы решили принять React и использовать его для создания всего нашего пользовательского интерфейса, чтобы, как вы могли представить, создание приложения с помощью @ s-ui / bundler позволило вам использовать React с нуля. Вы просто устанавливаете зависимость, и все готово.

Очевидно, что все наши проекты нацелены на SPA. Кроме того, мы хотели предложить нашим разработчикам очень простой способ создания рендеринга на стороне сервера для их продуктов. Для этого мы создали два отдельных инструмента: @ s-ui / react-initial-props и @ s-ui / ssr.

@ s-ui / react-initial-props, первый камень для универсальных приложений

Если вы создаете SPA в React, у вас может возникнуть соблазн получить данные для своего приложения в componentDidMount. Таким образом, вы можете контролировать, когда данные будут доступны, чтобы показать заполнитель. Это может быть правильно, но если вы планируете создать универсальное приложение, это может быть неудобно, так как на стороне сервера компонент жизненного циклаDidMount не выполняется.

Пакет @ s-ui / response-initial-props предлагает способ легко сделать ваше приложение изоморфным. Он позволяет вам создать статический метод getInitialProps для вашего компонента страницы. Этот метод, который возвращает Promise, будет загружать фрагмент вашего приложения.

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

Этот подход удобен, поскольку он позволяет избежать повторного рендеринга, как другие варианты, такие как React-Transmit, которые вызывали долгое время ответа, особенно на сервере.

@ s-ui / ssr, превратите свой SPA в приложение для рендеринга на стороне сервера

Если бы вы использовали @ s-ui / bundler и @ s-ui / response-initial-props… что бы вы подумали, если бы я сказал вам, что вы можете бесплатно получить приложение для рендеринга на стороне сервера, не написав ни единого строка кода?

@ s-ui / ssr package в основном полагается на соглашение, используемое в @ s-ui / response-initial-props, поэтому вам не нужно писать строку кода для преобразования вашего SPA в полноценное приложение с SSR. Кроме того, он не только генерирует код, но и создает контейнер Docker, готовый к развертыванию, и добавляет некоторые интересные функции, такие как предложение Google выполнять динамический рендеринг, чтобы выполнять SSR для ботов и получать данные в клиенте для ваших пользователей. .

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

Некоторые частые вопросы 🤔 и комментарии…

🗣 Разве это не простая обертка?

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

🗣 Разве это не беспокоит разработчиков о том, какие инструменты использовать?

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

Позвольте мне сказать, что работать в «одной команде» во фронтенде непросто. Если дебаты о «точках с запятой или нет в Javascript» могут развязать войну, представьте себе бесконечные дискуссии о библиотеках пользовательского интерфейса, фреймворке и различных архитектурных подходах. Мы стараемся выслушать и собрать все отзывы, прежде чем принимать решения, но

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

🗣 Но я думаю, что лучше, если каждый волен выбирать, что хочет!

Я не хотел бы начинать дискуссию о конвергенции и расхождении. С моей точки зрения, у обоих есть достоинства и недостатки. По моему опыту в Schibsted Spain, объединение набора инструментов ускорило разработку, улучшив DX и TTM (время выхода на рынок) функций и новых продуктов. Начало было нелегким, но затраты, которые мы предполагали вначале, были более чем компенсированы.

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

🗣 Тем не менее, есть лучшие решения!

create-react-app и next.js будут наиболее похожими решениями, которые мы могли бы принять. Тем не менее, есть некоторые важные отличия. Нам нужно было построить нашу платформу как можно более модульной, чтобы ее можно было постепенно адаптировать ко всем продуктам.

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

NextJS, например, предоставляет вам целый фреймворк в виде единого фрагмента, который необходимо сразу же внедрить. Не поймите меня неправильно, мне нравится ❤️ команда NextJS и Zeit, но для нас нам пришлось создать платформу для нескольких проектов одновременно, и возможность постепенного внедрения платформы - необходимость.

🗣 Я хочу обсудить это подробнее!

Что ж, вас более чем приглашают. sui-bundler и другие инструменты имеют открытый исходный код. Также просто оставьте свой комментарий или следите за беседой в Twitter. 😊 Мы будем рады услышать отзывы об итерации или улучшении платформы, поскольку каждое улучшение, которое мы выполняем, будет использоваться во всех наших проектах. Спасибо за чтение!

Привет мир! Я Мигель!

Привет, я Мигель Анхель Дюран, и хотел бы поблагодарить вас за чтение этой статьи. Я разрабатываю вещи и прочее. В основном в Javascript и React ⚛️. Я работаю в качестве клиентского интерфейса в Schibsted Spain и являюсь партнером-основателем компаний Sublime Codes и @coworkingElPrat. А я живу в солнечной Барселоне.

Вы можете подписаться на меня в Твиттере, если хотите читать материал о разработке #Javascript и #ReactJS: @midudev.

Кроме того, я веду блог со статьями о внешнем интерфейсе.