Как мы добираемся до текущего уровня сложности, шаг за шагом
Веб-разработка, особенно интерфейс, несомненно, является одной из самых сложных профессий в разработке программного обеспечения. Его ландшафт постоянно меняется. Инструменты и технологии устаревают и заменяются новыми с поразительной скоростью. Это также стало обширной областью, выходящей далеко за рамки HTML, CSS и Javascript. Возвращаясь на десять лет назад, могли ли вы представить себе, что разработчикам внешнего интерфейса, которые используют интерпретируемый язык для написания кода, придется возиться со всеми видами инструментов компиляции в своей повседневной работе? Довольно безумно, не так ли?
Но Рим строился не за один день. Давайте отправимся в прошлое, чтобы шаг за шагом посмотреть, как мы сюда попали.
«История не может дать нам программу на будущее, но она может дать нам более полное понимание самих себя и нашей общей человечности, чтобы мы могли лучше смотреть в будущее».
— Роберт Пенн Уоррен
Счастливые файловые серверы
Веб-архитектура началась с нулевой архитектуры. Самые ранние веб-сайты были просто общедоступными файловыми серверами, которые понимали HTTP-запросы и отправляли HTML-файлы клиентам.
К удивлению многих людей, такие веб-сайты все еще существуют и работают очень хорошо. Например, Craigslist выглядит как живое ископаемое — полностью статичный контент, чистые HTML-файлы, никаких изображений, никакого дизайна; тем не менее, он по-прежнему занимает 78-е место по трафику среди всех веб-сайтов в мире. Это свидетельство силы простоты.
Но не каждый бизнес может поддерживать себя как живое ископаемое. Данные, которыми владеют онлайн-компании, вскоре стали слишком сложными, чтобы ими можно было управлять в виде простых файлов. В то же время пользователи стали недовольны пассивным участием в Интернете; они хотели взаимодействия. Эти два фактора вызвали первый скачок веб-архитектуры.
Переход к динамическому контенту
Произошло два существенных изменения. Во-первых, стала привлекаться база данных — гораздо более универсальная, чем статические файлы. Во-вторых, сервер начал запускать программу для генерации HTML-документов, позволяющую разным клиентам видеть разный контент.
С точки зрения клиента все примерно так же. Веб-страница заполняется одним запросом HTML-документа. Когда пользователи перемещаются или отправляют данные, вся страница обновляется. Порталы и новостные сайты были хорошими примерами такой архитектуры. Они хранили и генерировали большое количество контента и могли обеспечить индивидуальную доставку в зависимости от профиля пользователя. Они также допускали некоторые взаимодействия, но были минимальными по сравнению с современными веб-приложениями.
Все это работало нормально какое-то время, пока на веб-сайтах не стало так много взаимодействий, что постоянное обновление страниц стало невыносимо раздражающим. Таким образом, следующим скачком веб-архитектуры было сделать взаимодействие более плавным.
Расцвет СПА
Как видите, дела внезапно пошли в гору, как на стороне клиента, так и на стороне сервера. Это осложнение было вполне оправдано по нескольким причинам:
- Сеть стала болтливым двусторонним каналом связи. Взаимодействие с пользователем происходит всегда, в результате чего содержимое страницы меняется вместе с ним. Это включает в себя много динамического обмена данными и быстрое манипулирование элементами страницы.
- Многие веб-сайты получали огромное количество трафика и данных, и возможность «масштабирования» стала критической темой.
Несколько достижений в области технологий пришли вовремя и сделали этот скачок возможным:
- Браузеры стали намного сильнее, особенно в области динамической выборки данных (AJAX) и манипулирования DOM.
- Сетевая инфраструктура стала более надежной и быстрой, а CDN теперь является товаром.
- Технологии виртуализации на стороне сервера (Docker, Linux Container и т. д.) созрели.
- Рассвет фреймворков компонентов пользовательского интерфейса — Angular, React, Vue.
В отличие от предыдущих архитектур, SPA (одностраничные приложения) — это настоящие приложения, работающие внутри браузеров. У них есть свои собственные среды разработки, они развертываются отдельно, имеют расширенные состояния и могут быть такими же сложными, как несколько миллионов строк кода. Портал Microsoft Azure претендует на звание крупнейшего SPA в мире, и к 2016 году это его LOC.
То, как работают SPA, также полностью отличается от предыдущих веб-сайтов. Интерфейсное приложение упаковано в несколько больших файлов Javascript. Браузеры загружают их из CDN, запускают для извлечения данных из серверных API, а затем отображают пользовательский интерфейс.
Это было время, когда умы фронтенд-разработчиков взорвались, и их работа начала разваливаться. Старые добрые времена прошли. Есть так много вещей, которые нужно изучить, инструменты, которые нужно запустить, и проблемы, которые нужно отладить. В результате сложность фронтенд-разработки вышла на новый уровень.
Гибридная эра
СПА — это круто, но не без недостатков. Вот две основные проблемы:
- Хотя они обеспечивают отличный опыт взаимодействия, их начальная загрузка может быть довольно медленной. Все приложение должно быть загружено и выполнено до того, как будет отображено первое значимое содержимое. Они также имеют тенденцию показывать счетчик за счетчиком из-за водопада динамической загрузки данных.
- Они вредны для SEO, потому что сервер возвращает не HTML. Даже сегодня сканеры поисковых систем не могут обрабатывать большинство SPA-сайтов.
Если сомневаетесь, развивайте архитектуру 😄.
Идея довольно проста: давайте использовать старый статический файловый сервер для обслуживания исходного HTML-документа, а затем пусть SPA возьмет на себя все остальное. Таким образом, время первоначальной загрузки значительно сокращается, а проблема SEO решается.
Новые вещи, которые сделали возможной эту новую парадигму, — это «мета-фреймворки», такие как Next.js, Nuxt.js и т. д. Они оборачивают фреймворки компонентов пользовательского интерфейса и превращают их в фреймворки приложений. Они отвечают на HTTP-запросы и доставляют предварительно обработанный HTML. Они также предоставляют способ предварительного рендеринга статических страниц и отправки их в CDN во время сборки.
Здесь произошел один удивительный побочный эффект: у фронтенда появился свой «бэкенд». Должны ли мы называть это «фронтенд» или «мидл-энд»? Хотя его основной обязанностью является предварительный рендеринг страниц, со временем люди проявили творческий подход и позволили ему взять на себя больше обязанностей. Мы постепенно перешли к следующему этапу веб-архитектуры.
Безсерверный — новый черный
Сейчас мы находимся на последней итерации развития архитектуры. Честно говоря, я думаю, что «безсерверный» здесь плохой термин, потому что он может означать многое и лишь частично совпадает с тем, что происходит здесь, но я все равно буду его использовать.
Все началось с глупого вопроса: «Раз у моего фронтенда теперь есть свой блестящий бэкэнд, зачем мне еще нужен отдельный бэкэнд?» Ответ: нет. Во многих случаях метафреймворк может покрыть все ваши потребности в бэкенде.
Несколько важных изменений:
- Отдельного бэкенда больше нет.
- Бэкенд нашего фронтенда в значительной степени заменяется «краем». Edge — это новое поколение вычислительных узлов, развернутых по всему миру. Они похожи на CDN, но могут выполнять пользовательский код, что делает их идеальными для обработки веб-вычислений.
- Хранение управляется новым поколением «бессерверных» баз данных (размещенных отдельно), которые хорошо работают с возможностью подключения с периферии.
Новая архитектура приносит два улучшения:
- С исчезновением отдельного бэкэнда стало меньше движущихся частей, и система стала намного проще с точки зрения разработки, развертывания и эксплуатации.
- Поскольку вычисления происходят на границе, рендеринг страниц на стороне сервера и динамическая загрузка данных выполняются намного быстрее из-за большей близости.
Цена? Теперь вам нужно не только внедрить метафреймворк, но и развернуть приложение на совместимой бессерверной платформе — Vercel, Netlify, Fly.io и т. д.
Архитектуры развиваются, а обязанности меняются
Теперь пришло время, чтобы все больше и больше фронтенд-разработчиков с гордостью называли себя разработчиками полного стека. Они свободны от привязки к бэкэнд-команде и могут выполнять комплексные задачи автономно. Однако с большой силой приходит большая ответственность. То, что нужно, чтобы стать полноценным разработчиком, выходит далеко за рамки HTML/CSS/JavaScript. По мере консолидации архитектуры меняются и обязанности:
Это лучшие времена или худшие из всех? Наверное оба. Инструменты и фреймворки, которыми мы располагаем сегодня, были невообразимы десять лет назад. Между тем, по мере того, как ожидания пользователей растут, а потребности бизнеса становятся все более изощренными, внутренняя сложность, с которой приходится сталкиваться при разработке полного стека, растет.
Сообщество все больше осознает, как развивались сложные вещи, и начало систематически упрощать вместо того, чтобы перемещать проблемы. Именно поэтому мы создаем ZenStack, чтобы упростить создание серверной части веб-приложений, чтобы разработчики могли лучше сосредоточиться на том, что действительно важно — на пользовательском опыте и ценности для бизнеса.
Нравится вам это или нет, но эволюция архитектуры будет продолжаться все более быстрыми темпами. Хотя все изменения неизбежно сопровождаются дискомфортом, учиться и работать в такой динамичной сфере — большая удача.
Want to Connect? I'm the creator of ZenStack. Our goal is to let you save time writing boilerplate code and focus on building what matters - the user experience.
