предисловие
Эта статья из тематического открытого класса тренировочного лагеря компьютерщиков, не оригинальная.
об авторе
World Sang Long (wolf t), эксперты по передовым технологиям Alibaba, автор «волчьей книги» nodejs.
На фоне бурного развития
Разработка внешнего интерфейса идет слишком быстро.До 2004 года было очень полезно знать «Трех мушкетеров Интернета» (набор мощных инструментов для веб-редактирования, изначально разработанный Macromedia, состоящий из Dreamweaver, Fireworks и Flash). end все еще относительно "чист" в то время. После вступления в эпоху Web 2.0, представленную Ajax для улучшения взаимодействия с пользователем с помощью асинхронного обновления, стало появляться большое количество библиотек, таких как Prototype, jQuery, MooTools, YUI, Ext JS, kissy и т. д., все из которых предназначены только для совместимость с браузерами и Инкапсуляция функций инструмента, но с момента появления Backbone и Angular 1.x интерфейс оживился, с MVC, MVVM, IOC (инверсия управления, концепция в известном Java-фреймворке Spring), фронт -конечная маршрутизация (аналогично маршрутизации Express, Koa и других фреймворков), Virtual DOM (виртуальный DOM, алгоритм DOM Diff, сокращение операций DOM), JSON API (спецификация интерфейса), среда выполнения JavaScript (Coffee, Babel, TypeScrpt) и т. д. , различные форматы фреймворков, такие как Он рос как грибы после дождя. Раньше на появление фрейма могло уйти полгода или даже больше. Теперь новый фрейм может родиться за несколько недель, и передняя часть вступила в беспрецедентную взрывную стадию.
Графические изменения 2004-2016 гг.
Этапы, которые прошел фронтенд
Сейчас фронтенд-разработка тоже в определенной степени усложнилась, по сравнению с предыдущим методом разработки ее можно назвать современной веб-разработкой. Здесь я подведу итоги. Front-end разработка прошла 4 этапа:
1. HTML/CSS/JavaScript (базовый уровень)
2. jQuery, jQuery ui, Ext JS (используется для популярности)
3. Backbone (MVC), AngularJS, Vue.js (раньше были популярны)
4. Компонентный React, Vue.js (тренды)
Текущее состояние разработки
В настоящее время весь большой интерфейс все еще находится в стадии разработки, и нет фиксированной модели, поэтому это период роста с точки зрения тенденций.Сложные, хаотичные и разнообразные результаты также делают текущий интерфейс более популярен, и все называют его «денежным концом». Многие студенты спросят, должны ли мы изучать интерфейсные технологии прогрессивным образом или нам следует изучать непосредственно React/Vue.js и другие фреймворки? На самом деле, я думаю, оба метода существуют.Если есть экономическое давление, посмотрите на «деньги», вы можете напрямую изучить React/Vue.js и другие фреймворки, но после его изучения вы должны изучить остальные три этапа; -ступенчатое обучение - лучший способ учиться, если нет финансового давления, времени и терпения. В программировании нет легких путей, несмотря ни на что, нужно быть приземленным и много практиковаться.
Когда вы напишете больше кода, вы обнаружите:
Когда всем надоедает писать HTML, начинают внедрять шаблонизаторы.
Когда всех раздражает CSS, например, он не поддерживает вложенность, начали внедрять препроцессоры CSS Sass, Less, Stylus, Postcss и т.д.
Когда всем надоедает писать на JavaScript, начинают вводить более дружественные языки, используют CoffeeScript для тех, кто знаком с Ruby, и TypeScript для тех, кто знаком с Java/C#.
В результате фронтенд-разработка усложнилась и вступила в эпоху современной веб-разработки.
nodejs
Для Node.js все интерфейсные фреймворки — это всего лишь технология представления слоя представления (View), которую можно легко интегрировать с различными фреймворками и лучше реализовать в соответствии с требованиями бизнеса. Кроме того, все интерфейсные фреймворки используют Node.js и NPM в качестве вспомогательных инструментов разработки и используют большое количество модулей Node.js, но модули, используемые внешними фреймворками, аналогичны. и NPM, необходимо изучить интерфейсную технологию, все, что вам нужно изучить, — это чистую интерфейсную часть, а ценность повторного использования очень высока.
Модулей фронтенд-разработки, связанных с Node.js, слишком много, вот лишь некоторые из них:
Из этих модулей и вытекает тема, о которой мы сегодня поговорим — практика и размышления о большом фронтенд-инжиниринге.
инструменты для сборки
Сначала поговорим об инструментах сборки. Препроцессор — это продвинутая интерфейсная игра.
Я часто шучу, что дни HTML/JavaScript/CSS были слишком чистыми, и теперь все, что вы пишете, должно быть скомпилировано/переведено. Преимущество в том, что эффективность разработки можно повысить с помощью расширенных возможностей, недостаток также крайне очевиден, то есть человеческий мозг должен обладать трансформационным мышлением. Это на самом деле довольно болезненно.Изначально HTML/JavaScript/CSS недостаточно развиты.Если вы включите его снова, он нуждается в процессе адаптации для новичков. Так что на это дело все же надо смотреть диалектически, счастье и несчастье зависят друг от друга.
Говоря об инструментах сборки, вы, вероятно, думаете о Make, Ant, Rake, Gradle и т. д. На самом деле в мире Node.js существует больше реализаций.
Исходный код инструмента сборки не особенно сложен, поэтому в мире Node.js существует множество реализаций, и некоторые люди написали версию Make для Node.js, приятного вам времяпрепровождения!
Основная цель выбора инструмента сборки — автоматизация. Для задач, которые необходимо повторять, таких как минификация, компиляция, модульное тестирование, линтинг и т. д., автоматизированные инструменты могут облегчить ваш труд и упростить вашу работу. В частности, чем сложнее проект, тем выше ценность автоматизации. Компиляция здесь включает в себя компиляцию шаблонов, язык предварительной обработки CSS, дружественный к JavaScript язык и т. д., а при написании исходного кода используется расширенный игровой процесс.
В дополнение к компиляции кода есть тесты, проверки стиля кода и оптимизации перед запуском (слияние, сжатие, обфускация), и можно сказать, что системы сборки повсеместно используются во всей разработке программного обеспечения.
grunt
Grunt — это первый популярный инструмент построения в стиле DSL (язык определения домена) в области клиентской части, и его появление сыграло очень хорошую направляющую роль в разработке клиентской части. Он описывает задачи через Gruntfile и расширяет различные инженерные возможности с помощью механизма плагинов.
Когда вы находитесь в правильном файле конфигурации GruntFile хорошей задачей, задача автоматически запустится для вас или вашей группой.
Хрудное дополнение к сложности конфигурации, существует проблема с производительностью, многие студенты никогда не сможете найти проблемы с производительностью. Grunt считывается и запись файлов, поэтому, когда несколько файлов, большая обработка файлов - это узкое место для производительности.
Дизайн Grunt все еще очень тонкий, но конфигурация сумасшедшая, и естественно будет много недовольных людей, поэтому Gulp потихоньку поднимается.
Gulp
Короче говоря, Gulp — это инструмент сборки, написанный на Node.js, инструмент потоковой сборки, основанный на Stream, и он включает в себя большое количество плагинов. Orchestrator — это основная библиотека, связанная с задачами, на которую опирается Gulp в самом низу.Она определяет методы и зависимости выполнения задач и поддерживает максимально возможный параллелизм.От этого зависит эффективность Gulp. Сам по себе Stream очень хорош при чтении и записи больших файлов, а упомянутые выше возможности делают Gulp популярным.
Gulp имеет широкий спектр сценариев приложений и может использоваться во внешних проектах или проектах Node.Даже веб-пакет можно использовать с Gulp через модуль gulp-webpack. Если вы хотите подробно изучить Gulp, вы можете взглянуть на stuq-gulp (GitHub.com/i5tee/пытается уйти…), в статье в качестве примера рассматривается использование Gulp в WeUI, от поверхностного к глубокому, от использования к принципу.
модульный
Развязка — вечная тема разработки ПО, а модульность — лучший метод развязки, так что от этого надо пройти долгий путь. Сегодня развитие HTML в 1993, 1995 родилось в JavaScript, выпустило CSS1 в 1996, а затем вступило в первоначальную и варварскую фазу развития. От Интернета до 2000 пузырей веб-технологии действительно растут. В то время я был особенно чист, и люди, которые написали это, были очень трусливы, а Флэш когда-то был очень горячим. После этого я перешел в эпоху Web 2.0, начал появляться AJAX, начал иметь различные библиотеки шин, затем начал модульность, Node.js в 2009 году полностью изменил разработку JavaScript и интерфейсную разработку, начиная с основы браузера. поддерживает режим MVC, к MVVM, поддерживаемому ANGluarjs, к текущим React/Vue и WebPack и т. д.
Здесь я пытаюсь классифицировать с точки зрения макросов, которые примерно разделены на 5 этапов, а именно исходный этап, менеджер пакетов, спецификация модуля, загрузчик модуля и упаковщик модуля. Ниже я объясню их один за другим.
примитивная стадия
Загрузка скрипта по-прежнему относительно примитивна и реализуется следующими способами: использовать несколько тегов скрипта для загрузки, вручную управлять порядком и вручную выбирать, какие теги загружать.
После многих попыток веб-разработки я также сделал много грязных вещей, таких как
Динамически создавать теги сценария XHR Eval, XHR Injection, $.getScript(), сценарий в Iframe, элемент DOM сценария, отложенный сценарий.
Если загрузка отвратительная, то порядок скриптов еще более отвратительный, а в JavaScript есть "фича", которая сообщает об ошибке, и все последующие будут падать, так что разработчикам будет изо всех сил поддерживать порядок загрузки скриптов.
менеджер пакетов
Если есть проблема с кодом, как насчет обновления версии пользовательского интерфейса jQuery? Пользовательский интерфейс jQuery зависит от jQuery. Сначала загрузите код пользовательского интерфейса jQuery, затем найдите зависимую версию jQuery, замените существующий файл, а затем протестируйте его. Если проблем нет, замените его напрямую.
Очевидно, что выполнять операции с файлами напрямую очень неэффективно, а лучше разобраться с версиями и зависимостями невозможно. В результате появились менеджеры пакетов, такие как Bower и NPM.Все модули обновлены, а зависимости управляются менеджером пакетов.Можно сказать, что повторяющаяся работа внешнего интерфейса в значительной степени устранена.
Спецификация модуля
Суть модульной загрузки заключается в загрузке по требованию.
Есть еще 3 общие спецификации: (1) модули AMD, CommonJS и ES6; (2) использование стандартной модульной системы для обработки зависимостей и экспорта.
Каждый файл представляет собой модуль; и (3) использование модуля загрузки для обработки или упаковщика
загрузчик модулей
Загрузчик модуля должен выполнять две основные функции:
1 Реализовать спецификацию определения модуля, которая является основой модульной системы.
2 Запуск и работа модульной системы
Распространенными являются RequireJS, Sea.js и SystemJS. В качестве примера возьмем загрузчик модулей AMD RequireJS.Обычно, если используется RequireJS, нам нужно только импортировать RequireJS, и нам не нужно явно импортировать другие библиотеки JS, потому что эта работа будет выполнена RequireJS.
сборщик модулей
Загрузчик модулей предоставляет среду выполнения, которая позволяет указать работающий в ней модуль соответствия кода, поэтому преимущества модульности очевидны. Но для реального проекта вам потребуется сборка, упаковка и другие операции.
Для разработки вам нужно сосредоточиться только на бизнес-модулях, и вам не нужно разбираться в загрузчиках модулей и процессах сборки.Очевидно, что это очень идеально, и поэтому рождается сборщик модулей, такой как webpack.
Gulp идеально подходит в качестве универсального инструмента сборки. Однако технологические изменения происходят слишком быстро.Применение различных препроцессоров и компонентизация фронтенда делают фронтенд чрезвычайно сложным.Появление вебпака в самый раз, который отлично решает проблему фронтенд-инжиниринга.
Базовое введение в веб-пакет
Webpack — известный модуль, написанный Node. Это сборщик. Он поддерживает не только модули CommonJS, но и более модные модули ES6. Vue) Большинство из них используют webpack.
loader && plugins
Он предоставляет два отличных механизма: загрузчики и плагины.
Погрузчики: WebPack учитывает каждый файл, чтобы быть модулем ресурса, и совместно называется погрузчиками для исходных файлов обработки (JSX, SCSS, меньше ..) В процессе упаковки и строительства.
плагины: плагины могут выполнять больше функций, чем загрузчик. Плагин не работает напрямую с одним файлом, он напрямую влияет на весь процесс сборки, и большинство функций контента выполняются на основе этой системы плагинов; конечно, плагины веб-пакетов с открытым исходным кодом также могут разрабатываться и использоваться для удовлетворения различных потребностей. Например, всем известные плагины autoprefixer, html-webpack-plugin, webpack-dev-middleware, webpack-hot-middleware.
процесс упаковки webpack
(1) Найдите точку входа в файле конфигурации
(2) Модульная система анализа
(3) Разрешить зависимости
(4) решить управление зависимостями (прочитано, анализируемое, разрешено)
(5) объединить все используемые модули
(6) Среда выполнения объединенной модульной системы
(7) Создание упакованных файлов
процесс загрузки браузера
(1) пройти<script>Загрузите файлы, упакованные webpack
(2) среда выполнения модуля загрузки
(3) Точка входа загрузки
(4) Чтение зависимостей
(5) Разрешить зависимости
(6) Выполнить точку входа
Если вы сравните понимание процесса упаковки веб-пакета и процесса загрузки браузера, вы сможете лучше понять внешний модульный речевой процесс. От определения спецификации модуля до среды выполнения (загрузчика) модульной системы и более продвинутого упаковщика этот процесс эволюции также упрощает и упрощает разработку внешнего интерфейса, поэтому упаковщик становится все более и более популярной причиной.
Понимание возможностей веб-пакета
На самом деле, это верно из результатов. Конечная цель инженерии - позволить разработчикам сосредоточиться на написании бизнес-модулей, а другие вещи делают Packats. С этой точки зрения WebPack по-прежнему более успешно, чем глотал.
Тем не менее, кривая обучения веб-пакету также относительно крутая. От базового использования и концепций до встряхивания дерева, кодового плевка, до того, как упаковывать, как распаковывать браузеры, до разработки, до того, как оптимизировать крупномасштабное строительство, тест заключается в том, есть ли у вас прочный фундамент, действительно ли вы понимаете принципы, и Понимание ли идей оптимизации и исходного кода. Сравнивать с Gulp, как с аналогичным модулем, с Stream (ядро Gulp), с event (базовый класс Stream), с HTTP (Stream применяется в HTTP), с eventloop, с libuv и v8, реализованным на C++, это ужасно, почти положено Все в Волчьей Книге покрыто.
webpack строит большие проекты
обертка веб-пакета
Существует множество методов упаковки для веб-пакетов, таких как хорошо известные af-webpack, ykit и easywebpack.
af-webpack — это настроенный Alipay веб-пакет, который напрямую упаковывает в него модули Node.js, такие как webpack-dev-server, и в то же время лучше обрабатывает конфигурацию и плагин.
ykit — это веб-пакет с открытым исходным кодом от Qunar, который имеет встроенный Connect в качестве веб-сервера в сочетании с программным обеспечением для разработки и горячим промежуточным ПО, что значительно повышает эффективность создания нескольких проектов и является хорошей практикой для выпуска файла версии.
easywebpack также является подключаемым модулем, но он сделал большую интеграцию с такими решениями, как шаблоны.Например, у ssr яйца есть глубокое мышление, хотя я не согласен с таким подходом.
CRA и UMI
После того, как фреймворк и основные исследования станут стабильными, люди начинают думать о том, как его использовать лучше и проще. Все крупные производители думают о том, как выбрать модели и снизить затраты в стеке передовых технологий, а также унифицировать стек технологий.
В проекте Create React App (CRA) в качестве стартового скрипта используется react-scripts, он похож на egg-scripts, но по соглашению скрывает конкретные детали реализации, чтобы разработчикам не нужно было обращать внимание на построение .
UMI похож на CRA. Это набор лучших практик, основанный на технологическом стеке Ant Financial. Это набор готовых "соглашений важнее конфигурации" без настройки и интерфейсной среды, разработанной в соответствии с к лучшим практикам: React Family Bucket + dva + jest + antd (мобильный) + less + eslint.
Ядром UMI является chainwebpack, который подключается к сложной конфигурации webpack, позволяет свободно переключаться между несколькими проектами и устраняет различные проблемы с конфигурацией webpack.
UMI мыслит относительно комплексно, от выбора технологии, построения до многотерминального вывода, оптимизации производительности, выпуска и т. д., что делает границы UMI более четкими.В качестве передовой практики в этом нет ничего плохого. , большинство интерфейсных групп также реализованы аналогичным образом. Проще говоря, это комбинация существующих технологических стеков, инкапсулирующих детали, что упрощает использование разработчиками. В будущем подобных пакетов будет больше, ведь нововведений на уровне фреймворка не так уж и много, и все потихоньку перенаправят свою энергию на уровень приложения.
строительные леса
обработка параметров cli
Более известным был Commander в первые дни, автор TJ, по сути это версия Ruby, мигрировавшая на Node, знаменитый экспресс-генератор — это скаффолд, написанный на основе этого модуля.
Проблема с ним в том, что зависимости пакетов немного велики, что неприемлемо для обсессивно-компульсивных разработчиков. Так появились такие модули, как Yargs, которые являются мощными и имеют мало зависимостей.
Метод шаблона
Yeoman — известный модуль строительных лесов. По установке шаблонов, расширяющихся по команде йо, понятно, что это результат централизованного мышления. Преимущество заключается в том, что сложность разработки невелика, что полезно для инженерной конвергенции.
репозиторий git в качестве шаблона
Шаблон хороший, но немного громоздкий. Если шаблон размещен на Github, его очень удобно обновлять и поддерживать. Типичными из них являются Vue CLI (предыдущая версия) и saojs.
Суть в том, чтобы загрузить git-repo, а затем создать шаблоны для файлов внутри. Этот метод очень гибкий и в настоящее время является основным методом.
Подводя итог, скаффолдинг шаг за шагом развивается, но в целом, за исключением некоторых оптимизаций в инженерной конвергенции, другие оптимизации не особенно велики.Причина очень проста, сложность скаффолдинга сделать невозможно. Как и UMI, он достаточно сложен, но CLI-часть невелика и особо гибкой настройки не требует.
Что касается создания каркасов с помощью Node, то очень просто написать генераторы с помощью Node.js. Вы можете обратиться к «Научить вас писать генераторы с Node.js за десять минут с нуля: вам нужно всего 5 шагов» (GitHub.com/i5tine/write…).
Будущее клиентского рендеринга и построения
Давайте посмотрим на эволюцию интерфейса:
Эпоха чистого рендеринга на стороне сервера оригинальной эпохи Java и PHP.
Разделение интерфейса и сервера, то есть использование JavaScript для запуска на стороне клиента, получение данных интерфейса на стороне сервера через запросы, управление или создание DOM страницы с помощью интерфейсных фреймворков, таких как JQuery, Angular, React. , Vue и т. д., позволяют в полной мере использовать ресурсы клиентской стороны и снизить нагрузку на серверную. Сквозное разделение труда очевидно, и до сих пор это наиболее часто используемый метод разработки.
Изоморфная разработка, такая как Meteor, Next.js, Nuxt.js и другие фреймворки, предоставляет различные применимые сценарии и методы разработки, но цель состоит в том, чтобы один и тот же набор кода можно было применять как к серверу, так и к клиенту.
Эволюция ССР
Разумеется, учитываются все JSP/ASP, шаблоны рендеринга Node также учитываются, и шаблоны мира Node являются наиболее распространенными.
BigPipe, хотя и очень старый, имеет очевидные преимущества блочной передачи и удобен для браузера. Facebook и Weibo, Qunar — все бенефициары. Node естественным образом поддерживает его и очень дружелюбен к res.write.
SSR на основе компонентов, например React SSR. Времена изменились, и SSR должна идти в ногу со временем. Вдом + гидрат может быть очень весело играть, и даже BigPipe можно комбинировать. UMI SSR и Rax SSR можно ожидать в будущем.
Истинный изоморфизм, то есть CSR и SSR пишутся одинаково, и в дальнейшем понятия больше не будут различаться.В Servless API и рендеринг — это функции.
Изменения во front-end технологиях за последние годы можно охарактеризовать как потрясающие.Прежде чем выбирать стек технологий, вы должны увидеть свои собственные сценарии применения.Нет лучшего фреймворка, есть только наиболее подходящий фреймворк для сценария приложения.Изоморфность Метод разработки не является исключением.Преимущества и недостатки изоморфной разработки.
В качестве примера проекта,GitHub.com/Haokoufuoh/яично-горячий…. Это написано как:
Основные моменты:
render — это метод рендеринга представления React.
getInitialProps — это метод получения данных и присвоения возвращаемого значения состоянию компонента.
КСО реализуется через компоненты более высокого порядка
SSR выполняется узлом
Фактически, CSR требует от разработчиков заботы о React и создании веб-пакетов.
Beidou — это решение SSR, разработчики заботятся о сборках React, egg и webpack.
UMI SSR выигрывает от встроенного веб-пакета UMI, поэтому разработчикам нужно сосредоточиться только на написании React и развертывании в яйцах.
В будущем мы надеемся, что все сервисы будут бессерверными, чтобы пользователям нужно было обращать внимание только на написание React. Сборки выполняются локально, аналогично UMI. Egg не нужно связывать, потому что он использует бессерверную среду выполнения.
CSR и SSR написаны одинаково, и их можно использовать на Serverless.Его преимущества:
Приложения на стороне C, прямой SSR, могут повысить эффективность, производительность гарантирована, оптимизирована для SEO.
Для промежуточных и фоновых приложений этот метод может повысить эффективность и снизить сложность разработки и обслуживания кода. Каждая страница независима, а реинжиниринг системы чрезвычайно прост.
После перехода на Serverless, в дополнение к локальным сборкам CLI, также могут быть предоставлены облачные сборки. Например, каждая страница — это функция, так как же объединить несколько страниц? Например, в типичном многостраничном приложении UMI код, реализованный react-loadable+react-router, загружается по запросу, в этом случае можно сначала опубликовать несколько страниц на Serverless, а затем настроить несколько страниц на облачном построении. и, наконец, встроить в многостраничное приложение.
Кроме того, слой рендеринга легкий, что тоже очень удобно для Web IDE в будущем. Вы можете себе представить, в будущем будет процесс завершения разработки, разве это не прекрасно? Али рассматривает безсерверные технологии и IDE как два основных направления, что действительно требует тщательного рассмотрения.
Фронтенд и бэкэнд совместная работа
После этого давайте поговорим о фронтенде и бэкенде совместной работы. Первоначальное определение интерфейса относится к разработке на основе браузеров, но по мере того, как браузеры становятся все более и более широко используемыми, определение интерфейса становится все более и более размытым. В настоящее время интерфейс охватывает компоненты ПК, H5 и мобильных терминалов.Практически все интерфейсы с интерфейсами, которые контактируют с пользователями, считаются интерфейсами.Поэтому была разработана концепция больших интерфейсов, которая в целом относится ко всей терминальной разработке, которая взаимодействует с пользователями.
Кроссбраузерность (веб-просмотр) всегда была направлением в области разработки, от Native к Hybrid, к React Native/Weex, к Electron, PWA и небольшим программам, вы можете видеть, что все движутся в сторону облегчения, унификации технологии стек и сократить расходы. Другими словами, терминал надеется быть унифицированным, а интерфейс является ядром разработки, поэтому его все вместе называют большим интерфейсом.
JavaScript пересек три конца, давайте поговорим о Node, включая инженерные и серверные возможности. Многие крупные компании объединили свои мобильные и внешние интерфейсы в одну группу для управления, и ситуация с большим внешним интерфейсом предрешена.
Переднее и заднее разделение
Разделение интерфейса и сервера, то есть использование JavaScript для запуска на стороне клиента, получение данных интерфейса на стороне сервера через запросы, управление или создание DOM страницы с помощью интерфейсных фреймворков, таких как JQuery, Angular, React. , Vue и т. д., позволяют в полной мере использовать ресурсы клиентской стороны и снизить нагрузку на серверную. Сквозное разделение труда очевидно, и до сих пор это наиболее часто используемый метод разработки.
BFF
Есть много причин для появления BFF (API Proxy), независимого слоя API:
С появлением мобильных терминалов все начали разрабатывать API, но они игнорировали тот факт, что большой внешний интерфейс — это не только мобильный, но и клиент для ПК и PC/H5 Web. Основная причина в том, что размер экрана разный, что приводит к очевидным различиям в UI/UE.
При разработке API на серверной части мне не нравится поддерживать несколько наборов API одновременно.
Помимо затрат на связь, возникают недоразумения, вызванные непониманием реализации внешнего интерфейса.
Проще говоря, BFF — это независимое предоставление API на каждом конце. Однако делать это явно невыгодно. Итак, необходимо ли обновлять архитектуру?
Таким образом, отдельный BFF становится единым серверным API-сервисом. Это то же самое, что и принцип Ajax, потому что есть дополнительный уровень XHR, интерфейс и сервер могут обрабатываться асинхронно, что и послужило толчком к рождению Web 2.0. BFF апгрейдится до унифицированного серверного API-сервиса, по сути то же самое, фронтенд и бэкенд могут разрабатываться асинхронно, каждый выполняет свою работу, а все API регистрируются на уровне API. На самом деле это последнее очень большое обновление архитектуры интерфейса.
GraphQL
GraphQL — это язык запросов к данным, разработанный Facebook внутри компании в 2012 г. Он был открыт в 2015 г. и призван предоставить альтернативу системе архитектуры RESTful.Это не только графический (визуальный) язык запросов для API, но и язык запросов. который удовлетворяет вашим данным.
Распространенным сценарием для традиционных веб-приложений является предоставление интерфейсов клиентам путем разработки служб. Когда требования или данные меняются, приложения должны модифицировать или воссоздавать новые интерфейсы. В долгосрочной перспективе серверный код будет продолжать расти, а внутренняя логика интерфейса будет сложной и трудной в обслуживании. GraphQL решает эту проблему благодаря следующим функциям:
декларативный. Формат результата запроса определяется запрашивающей стороной (т. е. клиентом), а не ответчиком (т. е. сервером). Вам не нужно писать много дополнительных интерфейсов для обработки запросов клиентов.
Комбинируемый. Структуру запросов GraphQL можно свободно комбинировать для удовлетворения потребностей.
Сильная типизация. Каждый запрос GraphQL должен соответствовать заданному типу, чтобы его можно было выполнить.
Другими словами, с помощью трех вышеуказанных функций, когда требования меняются, клиенту нужно только написать структуру запроса, которая может соответствовать новым требованиям.Если данные, которые может предоставить сервер, соответствуют требованиям, код сервера вряд ли нуждается в быть изменены.
GraphQL определяется моделью и очень дружелюбен как к переднему, так и к внутреннему интерфейсу, что, несомненно, является очень хорошим решением. Конечно, у него тоже есть проблемы: само соглашение — непростая задача, и еще есть некоторые затраты на фронт и бэкенд.
Serverless
Итак, как можно по-настоящему освободить переднюю часть? Один не заботится об эксплуатации и обслуживании, два не заботятся о расширении, а третий не заботится о веб-фреймворках. Для фронтенд-разработчиков мне просто нужен интерфейс или оболочка интерфейса, зачем мне разбираться в веб-фреймворке Node?
Node.js преуспевает в Eventloop и терпит неудачу в Eventloop. Сам Eventloop представляет собой черный ящик. Вам трудно охватить все коды, которые вы вложили в разработку. Иногда Eventloop блокируется, что крайне болезненно для расследования.
Использование Serverless может эффективно предотвратить блокировку Eventloop. Например, шифрование является распространенным сценарием, но эффективность его выполнения очень низкая. Если шифрование и дешифрование объединены с другими вашими задачами, Eventloop может легко заблокироваться.
Разработайте функцию локально и опубликуйте ее в бессерверном облаке через интерфейс командной строки.Все так просто, и это должно быть тенденцией будущего.
Вы можете увидеть картинку ниже.
Понимание будущего фронтенд-инжиниринга
CRA, UMI позволяют нам не заботиться о настройке веб-пакета, это будущее локального CLI.
CSR и SSR — это унифицированная однородная разработка, упаковка и создание локальной командной строки, а также публикация в бессерверном облаке, что является простым и эффективным.
API чрезвычайно прост в зависимости от Severless. Не нужно понимать веб-каркас. Это может просто составить API. Там нет операций и обслуживания, и она не боится высоких сценариев параллелизма.
Здесь мы должны упомянуть, в Serverless в этой среде, если API решен, передняя природа может сделать все дело. Фронтальная вещь может сделать все больше и больше в будущем будет больше внешнего прикладного слоя.
Например, с развитием экономики и бизнеса в будущем будет больше приложений и больше терминалов, что хорошо для внешнего интерфейса, потому что можно сделать больше, и ценность может быть очень хорошо отражена.
Так что, будучи твердым сторонником Интернета, я считаю, что будущее интерфейса очень светлое.
Более
Ссылка на оригинальный язык:вооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо.
Если вы хотите узнать больше статей о фронтенд-инжиниринге, обратите внимание на мой альбом Yuque, который постоянно собирается и сортируется:вооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо.
Подтверждение: эта статья является последней статьей, написанной на платформе Nuggets, и в будущем она будет перенесена в Yuque и в блог.