Как устроен современный фронтенд

Если вы все еще думаете, что фронтенд — это только статичные файлы js, html, css, то ошибаетесь. Сегодня расскажу, как устроена современная фронтенд-разработка, и какие фишки применяются.

SSR (server side rendering)

Начнем с базы. SSR — это то, ради чего многие разрабы выбирают Next или Nuxt вместо React и Vue, соответственно. SSR позволяет генерировать HTML перед тем, как он отправится в браузер. Но нюанс здесь в том, что внутри этого HTML уже отрисованы полученные данные с бэкенда. Причем обычно подгружаются именно те данные, которые не зависят от пользователя. Например, в Солвите список вопросов и задач можно подгрузить на серверной стороне фронтенда, а данные о самом пользователе и его решения уже в браузере.

Вы можете спросить: "что за серверная сторона фронтенда? Фронтенд - это же клиент". Не всегда)

Умная прослойка между браузером и бэкендом

Nuxt/Next и похожие фреймворки запускаются в Docker контейнере, а точнее запускается node.js, внутри которого и происходит вся магия. Покажу на примере, как нам это помогает. У нас в Солвит есть баннеры, и мы включаем их для всех пользователей обычно во время акций. И согласитесь, было бы очень тупо, если бы при заходе каждого пользователя делался новый запрос на бэкенд с просьбой дать актуальные баннеры. И тут нам предлагается решение: мы можем получать баннеры внутри node.js, которая является серверной (скрытой) стороной фронтенда, и при рендеринге страницы для пользователей мы будем идти не каждый раз в нашу апишку на FastAPI, а во внутреннее хранилище ноды, и забирать данные оттуда. То есть, грубо говоря, мы храним все данные в оперативке фронтенда (т.е. в ноде) :) Тут важный момент, что при скейлинге кэш будет разный на всех инстансах.

Кэш

Большинство подписчиков канала — бэкендеры, и при слове кэш у многих в голове всплывает лишь Redis. Но на фронте тоже можно использовать кэширование. Например, мы используем библиотеку Tanstack Query, которая позволяет кэшировать результаты запроса от апишки, и немного снижать нагрузку на бэкенд. То есть если пользователь на сайте часто переключается между разными разделами сайта, у него половина данных может лежать в кэше в браузере. Естественно, это нужно делать только для тех эндпоинтов, где данные никак не меняются со временем, иначе гарантирован плохой юзер экспириенс. Такой кэш, если что, работает на стороне браузера для конкретного пользователя.

Давайте соберем 500 огоньков , запишу эксклюзивно для подписчиков этого телеграм-канала видео-разбор устройства современного фронтенда на примере Солвита