Различные среды рендеринга на стороне сервера

Рендеринг на стороне сервера — это метод загрузки и анализа элементов внешнего интерфейса и кода веб-приложений на самом размещенном сервере. Раньше браузеры не были такими продвинутыми и отображали содержимое HTML-документов только для представления пользователям статической версии веб-страницы.

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

Какие платформы поддерживают SSR для веб-разработки?

Для быстрой загрузки интерфейса необходимо доставлять в браузер важные данные и контент. И, как уже упоминалось, рендеринг на стороне сервера отлично справляется со своей задачей. Вот несколько фреймворков с включенной поддержкой SSR для разработки веб-приложений.

Реагировать
Угловой универсальный
NextJS
NuxtJS
ГэтсбиJS

Давайте поговорим обо всем этом один за другим

Мы можем создать наш проект Next.js с помощью предоставленной ему программы командной строки. Чтобы создать проект, мы просто запускаем:

npx create-next-app

or:

yarn create next-app

для создания нашего проекта.

Затем, чтобы запустить сервер разработки, мы запускаем:

npm run dev

Затем переходим на http://localhost:3000/ и наше приложение.

Теперь мы можем создать компонент в папке pages, чтобы добавить нашу страницу.

Заходим в папку pages, создаем файл hello.js и добавляем:

function Hello() {
  return <div>hello world</div>;
}
export default Hello;

to it.

Мы должны помнить об экспорте компонента, чтобы он отрисовывался.

Затем мы можем зайти на http://localhost:3000/hello и увидеть нашу страницу.

Next.js выполняет маршрутизацию автоматически по имени файла, поэтому нам не нужно об этом беспокоиться.

Страницы с динамическими маршрутами Если мы хотим создать страницы с динамическими маршрутами, мы просто помещаем их в структуру папок, и URL-адреса будут следовать той же структуре.

Например, мы можем создать папку сообщений и создать наши файлы.

Создаем 1.js в страницах/постах и пишем:

function Hello() {
  return <div>hello 1</div>
}
export default Hello
Likewise, we create 2.js in the same folder and write:
function Hello() {
  return <div>hello 2</div>
}
export default Hello

Затем, когда мы перейдем к http://localhost:3000/posts/1 и http://localhost:3000/posts/2, мы увидим hello 1 и hello 2 соответственно. Предварительный рендеринг Next.js по умолчанию выполняет предварительный рендеринг каждой страницы.

HTML для каждой страницы создается заранее. Это лучше для производительности и SEO, чем рендеринг на стороне клиента. Страницы поставляются только с JavaScript, который необходимо загрузить, чтобы они загружались быстрее.

Есть 2 формы предварительного рендеринга. Один из них — статическая генерация, а другой — рендеринг на стороне сервера. Статическая генерация означает, что HTML генерируется во время сборки и повторно используется при каждом запросе. Поскольку он повторно использует страницы, это будет самый быстрый способ рендеринга страниц, поэтому это рекомендуемый вариант. Другой вариант — рендеринг на стороне сервера, при котором HTML не отображается при каждом запросе.

Мы можем выбирать между двумя типами рендеринга. Статическая генерация с данными Мы можем генерировать страницы статически с данными. Для этого мы можем написать: pages/yesno.js

function YesNo({ data }) {
  return <p>{data.answer}</p>;
}
export async function getStaticProps() {
  const res = await fetch('https://yesno.wtf/api');
  const data = await res.json();
  return {
    props: {
      data,
    },
  };
}
export default YesNo;

Мы создали новый файл компонента с компонентом YesNo. Функция getStaticProps получает данные асинхронно из API. Затем мы возвращаем разрешенное значение, возвращая объект с данными в свойстве props. Затем мы можем получить эти данные из реквизита в компоненте YesNo. А в JSX мы отображали данные.

Далее позаботится о маршрутизации для вас.

Более быстрый рендеринг.
Поддерживает машинопись, попутный ветер, API.
Есть SEO (поисковая оптимизация)
Имеет оптимизацию изображения.

Давайте сравним Next со SvelteKit

//Next.js
npx create-next-app@latest
//SvelteKit
npm init svelte@next my-app

Маршрутизация

Маршрутизация определяет, какой URL-адрес потребуется для доступа к различным страницам веб-сайта. Все три фреймворка используют маршрутизацию на основе файлов, которая в первую очередь используется всеми метафреймворками. URL-адрес основан на имени и расположении файла для этой конкретной страницы.

Ниже вы увидите несколько примеров того, как различные файлы сопоставляются с URL-адресами, включая пример с параметрами URL-адреса, которые определяют часть URL-адреса как переменную, которую вы можете получить.

Next.js

/ → pages/index.js
/hello → pages/hello/index.js or pages/hello.js
/use_param/:id → pages/use_param/[id].js

SvelteKit

/ → src/routes/index.svelte
/hello → src/routes/hello/index.svelte or src/routes/hello.svelte
/use_param/:id → src/routes/use_param/[id].svelte

Загрузка данных на стороне сервера

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

Во всех трех фреймворках на каждой странице есть функция, которую мы можем определить, которая будет запускаться с сервера перед отправкой страницы в браузер пользователя.

Next.js Аналогично, в Next.js вы можете экспортировать функцию с именем getServerSideProps. Затем возвращаемое значение может определять свойства компонента страницы:

export const getServerSideProps = async ({ params, query }) => {
  // get a param from the url
  const id = params.id;
  // getting data from the url query string
  const limit = query.limit;
  return { props: { id, limit } };
};
export default function SomePage() {
  let { id, limit } = useLoaderData();
  return (
    <div>
      <h1>The params is: {id}</h1>
      <h1>The limit url query is: {limit}</h1>
    </div>
  );
}

SvelteKit

В SvelteKit вы определяете функцию загрузки в отдельном блоке скрипта. Как и в предыдущих примерах, вы можете обрабатывать любые вызовы API и подготовку данных, а затем возвращать данные для использования в качестве реквизита компоненту страницы:

<script context="module">
        // Load function to define data
        export function load({ page }) {
   // get params from url
   const id = page.params.id
   // get data from url query
   const limit = page.query.get("limit")
                return {
                        props: {
                                id,
            limit
                        }
                };
        }
</script>
<script>
   // normal client side javascript block
        export let id;
   export let limit
</script>
<div>
   <h1>The params is: {id}</h1>
   <h1>The limit url query is: {limit}</h1>
</div>

Предварительный рендеринг страниц как генераторов статических сайтов

Предварительный рендеринг страниц в виде генераторов статических сайтов, вероятно, является самым большим отклонением в наборах функций. На момент написания Remix не поддерживал предварительный рендеринг страниц, в то время как Next.js и SvelteKit поддерживают, что означает, что вы также можете использовать их в качестве генераторов статических сайтов.

Next.js Если вы предпочитаете, чтобы ваша страница была предварительно обработана, просто экспортируйте getStaticProps вместо getServerSideProps. В противном случае мы будем наблюдать ту же картину, что и раньше.

SvelteKit Если вы хотите, чтобы страница предварительно отображалась в блоге скрипта модуля, просто установите следующий код:

экспорт константы prerender = true; Приведенный выше код сообщает SvelteKit о необходимости предварительного рендеринга страницы вместо ее рендеринга при каждом запросе.

API-маршрутизация

Хотя мы можем обрабатывать логику на стороне сервера с помощью загрузчика, getServerSideProps или функции загрузки, ключи API и другие данные не должны быть в этом коде. Вам по-прежнему могут понадобиться выделенные URL-адреса API с кодом, который виден только и выполняется на стороне сервера.

Next.js Если вы создаете маршрут, который экспортирует функцию маршрута, как в Express.js, в папку pages/api, он будет обрабатываться аналогично маршруту API:

export default function handler(req, res) {
  res.status(200).json({ id: req.params.id });
}

SvelteKit

Если у вас есть файл JavaScript или TypeScript вместо файла Svelte, экспортируйте функцию, и она будет рассматриваться как маршрут API. Имя функции будет определять, на какой метод она является ответом:

export async function get({ params }) {
  return {
    body: { id: params.id },
  };
}

Стайлинг

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

Next.js Вы также можете использовать компонент шлема для добавления тегов ссылок, но вы также можете использовать стилизованные компоненты, JSS, Emotion, Sass или любую другую абстракцию CSS, а также просто импортировать стандартные таблицы стилей CSS.

SvelteKit Svelte, как и Vue, использует однофайловые компоненты, поэтому CSS находится в файле компонентов.

Заключение

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

Различные среды рендеринга на стороне сервера

Какие платформы поддерживают SSR для веб-разработки?

Давайте поговорим обо всем этом один за другим

Давайте сравним Next со SvelteKit

Маршрутизация

Загрузка данных на стороне сервера

SvelteKit

Предварительный рендеринг страниц как генераторов статических сайтов

API-маршрутизация

Стайлинг

Заключение

Рекомендации

Вопросы по теме