Мы продолжаем серию статей "Введение во фронтенд" - и это уже предпоследняя :)
Архитектура
Современный фронтенд зачастую бывает сложнее бэкенда (серверной части). Помимо того что он является смесью браузерных технологий (JS, HTML, CSS), он очень серьезно реализует бизнес-логику прямо на клиенте, разгружая тем самым сервер. Сервер, по сути, превращается в слой доступа к пользовательским данным (в различных базах данных), и этот слой доступа един к различным клиентам: сайтам, мобильным и десктоп-приложениям, вплоть до... всего что вы можете придумать. А фронтенд - может быть способом отображения любых API!
Минутка лирики
Мой коллега недавно потратил порядка 500 рублей на всё и припаял к плате-контроллеру с Wi-Fi датчики температуры, влажности, давления и освещенности. Я потратил полчаса и сделал панель визуализации этих данных.
Теперь об архитектуре
Архитектура в понимании этой статьи - это покомпонентная модель системы. Основными моментами, которые необходимо спроектировать заранее при разработке фронтенда:
1. DataFlow, или потоки данных. Когда, какие, как и как часто сервер и клиент обмениваются данными. Особенно этот вопрос важен, если фронтенд реактивен - обновляет данные без перезагрузки страницы. Обмен данными возможен:
-
Polling (опрос) сервера с помощью AJAX (http-запросов с браузера). Устаревший метод, который весьма нагружает трафиком сеть и тратит на пустые ответы ресурсы сервера (когда нет обновлений),
-
EventSource (источник событий) - подписка на уведомления с сервера. Односторонний метод, достаточно прост в использовании, но... в браузерах существуют ограничение одновременно используемых источников событий с одного сайта. В Chrome, например, вы не будете получать события из уже шестой-седьмой открытой вкладки с одним и тем же сайтом.
-
WebSockets (веб-сокеты) - наиболее популярный способ обмена данными между сервером и клиентов в обе стороны. Доставляет данные по мере появления и имеет реализацию для подавляющего большинства клиентов (современные браузеры, библиотеки для мобильных приложений).
2. Загрузка страницы. Современные Javascript-фреймворки позволяют разрабатывать SPA (Single Page Applications), но с ними есть одна проблема - в HTML от сервера обычно приходит что-то по типу
<body><app-view/></body>
Этого явно недостаточно для поисковых роботов. Проблема решается несколькими путями:
-
Isomorphic-приложения - когда HTML на клиенте и на сервере "изоморфны". Это достаточно молодая и достаточно сложная технология. Для вводной статьи достаточно упоминания :)
-
SSR (server-side rendering) - заготовка HTML на сервере. Прямо как это делает PHP :) Не есть хорошо. Например, пакет для Meteor, который позволяет проворачивать такие маневры называется "meteorhacks-ssr", что недвусмысленно намекает на то, что это не есть родной способ для Meteor. Да и зачем нагружать сервер генерацией HTML? Особенно если у вас тысячи запросов в секунду.
-
Prerender. Поисковикам можно объяснить, что текущая страница - динамическая, и её следует обрабатывать иначе. Делается это через директиву <meta name="fragment" content="!">. Встретив её в странице, поисковик добавит в запрос параметр _escaped_fragment_, которую способен перехватить сервер и отдать предварительно сгенерированную страницу (из кэша или отрендерить её заново). Пакеты prerender и prerender-node всё это умеют.
3. Визуальные компоненты и сервисы (и их различные вариации).
-
То, что вы можете переиспользовать для отображения контента. Представьте соцсеть - список комментариев может быть к записи на стене, к фото в альбоме группы, в обсуждениях... Все это может быть одной визуальной компонентой.
-
Сервисы же - это алгоритмы, которые выполняют обобщенные действия, необходимые для компонент. Например - получение и обновление данных с сервера.
Заключение
Согласно описанной архитектуре, современный фронтенд - полностью статичен. Вы даете браузеру запрос (ссылкой или кнопкой на странице например), вам не приходят заново другие HTML, CSS, JS. Все остается тем же, за исключением того, что фронтенд запрашивает и отображает (иначе) новые данные. Поэтому логично начальную статику минифицировать и просто раздавать через nginx. А ваш сервер API - делать по возможности простым, по сути "принеси-подай" данные (с проверкой доступа конечно же).
Это дает возможность использовать серверные мощности куда более рационально. Вся нагрузка идет по факту на выборку из баз данных (и эти данные часто индексированы так, чтобы это было быстро), а работа со строками на сервере практически сводится к нулю.