Сысоева Раиса Ивановна

Сысоева Раиса Ивановна

1657885649

SSR против SSG в Next.js

Во-первых, у нас есть JavaScript. Затем у нас появились одностраничные приложения. Потом у нас... заболела голова. Это потому, что наши красивые и очень интерактивные веб-приложения стали медленными и столкнулись с рядом проблем с удобством использования, затрагивающих как поисковых роботов, так и людей. Разработчики лихорадочно искали решения. Являются ли рендеринг на стороне сервера и создание статических сайтов ответом? Чтобы выяснить это, давайте взглянем на Next.js, одну из самых популярных платформ SSR/SSG.

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

Но SSR и SSG действительно выделяются. Они имеют подлинное и практическое значение для всех, кто занимается созданием программного обеспечения — от разработчиков до дизайнеров, специалистов по UX, тестировщиков, веб-аналитиков, экспертов по SEO, копирайтеров и многих других.

Преимущества умелого использования SSR и SSG имеют большое значение во всех этих областях. Если вы еще этого не знаете, я уверен, вы поймете это к тому времени, когда я закончу.

Сегодня вы получите практическую информацию о SSR и SSG. Я также собираюсь представить фреймворк, упрощающий их использование — Next.js.

Что это за статья:

  • обзор ключевых концепций SSR и SSG и преимуществ обоих подходов,
  • введение в Next.js и его преимущества для бизнеса ,
  • практическое и простое для понимания объяснение того, как реализовать SSR и SSG с помощью Next.js ,
  • экономическое обоснование за и против использования SSR и SSG с Next.js в конкретных сценариях (за, против и альтернативы).

Чем не является эта статья:

  • углубленный технический анализ SSR и SSG на основе Next.js. 

Пока я собираюсь углубиться в код, я делаю вещи доступными для более широкой аудитории. Я действительно хочу показать, как SSR и SSG связаны с потребностями бизнеса в современной разработке программного обеспечения.

Беглый взгляд на историю — зачем нам SSR и SSG?

Чтобы более четко понять необходимость SSR и SSG, давайте совершим большой прыжок в прошлое. Дождливый и холодный полдень 4 декабря 1995 года…

Первые дни JavaScript

… Брендан Эйх как раз заканчивает работу над самой первой версией JavaScript. Он поставляется компанией Netscape как часть своего браузера Netscape Navigator.

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

Во-первых, среда Node.js предоставила возможность использовать JavaScript на сервере в качестве полноценного внутреннего языка . Затем современные веб-фреймворки и библиотеки, такие как React или Vue.js, значительно расширили возможности JavaScript с точки зрения поддержки взаимодействия с пользователем. В результате разработчики могли создать веб-страницу или приложение, которые очень похожи на родные настольные и мобильные приложения . Они работали очень быстро и практически не требовали перезагрузки в браузере. Пользователям это понравилось. Разработчикам это понравилось, и они назвали это…

… Одностраничные приложения

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

HTML-контент, отображаемый на стороне клиента, был доступен им только после того, как он был выполнен в браузере. В результате автоматические сканеры, отправленные поисковыми системами, пропустили большую часть этого. Это сделало SPA очень трудным для правильной индексации. В свою очередь, веб-сайты упустили большую часть своего органического трафика — большая проблема с точки зрения поисковой оптимизации. Как раз тогда, когда SEO действительно становилось популярным в первом десятилетии 21-го века…

 

Брендан Эйх был одним из ключевых людей на ранней стадии разработки JavaScript.

SSR против SSG — теория

SSR и SSG — это два метода, которые развились в сообществе разработчиков программного обеспечения для решения именно этой проблемы. Кто они такие?

Что такое рендеринг на стороне сервера?

С помощью SSR вы можете отображать код JavaScript на сервере и отправлять индексируемый HTML-код пользователю. Таким образом, HTML-код генерируется во время выполнения , чтобы он мог одновременно достигать поисковых систем и пользователей.

До появления Next.js такой процесс требовал много настроек и сопровождался проблемами, связанными с нагрузкой на сервер, контентом по запросу, кэшированием или даже самой архитектурой приложения. Не поймите меня неправильно — это, безусловно, выполнимо, но было бы неплохо, если бы вместо этого можно было посвятить все это время разработке бизнес-логики…

Что такое создание статического сайта?

Основное различие между SSR и SSG заключается в том, что в последнем случае ваш HTML создается не во время выполнения, а во время сборки . Такие веб-сайты работают очень быстро, поскольку HTML-контент обслуживается еще до того, как вы сделаете запрос. С другой стороны, веб-сайт необходимо перестраивать и полностью перезагружать каждый раз, когда вносятся изменения. Следовательно, веб-сайты на основе SSG гораздо менее интерактивны и нативны, чем те, которые полагаются на SSR. Это в основном статические сайты с небольшим динамическим контентом или без него.

 

Основная идея SSR и SSG

SSR и SSG – основные преимущества

И SSR, и SSG имеют ряд важных преимуществ для бизнеса .

  • ЭТО

Легко индексируемые страницы дают ощутимые преимущества — больше органического трафика. Для веб-приложений, которые считают SEO стратегически важным для маркетинга и продаж, это может привести к увеличению прибыли и общей прибыли. Отчеты SEO-агентств подтверждают это — этот интернет-магазин улучшил свои продажи на 67% за счет увеличения органического трафика.

  • Производительность

Исследование UX, проведенное Google , показывает, что показатель отказов увеличивается на целых 32%, если загрузка страницы увеличивается с 1 до 3 секунд . И SSR, и SSG сокращают время загрузки по сравнению с рендерингом на стороне клиента. Это потому, что SSR собирает все данные, не дожидаясь, пока браузер сделает такой запрос. SSG идет еще дальше, собирая все данные по мере создания приложения.

  • Удобство использования

Выполняя большую часть тяжелой работы на сервере, а не в браузере, вы разгружаете клиентские браузеры и устройства. В результате SSR и SSG облегчают просмотр веб-приложения пользователям со старыми устройствами и более медленным подключением к Интернету. Это может быть особенно важно для конверсий на мобильных устройствах: целых 73 % мобильных пользователей боролись с медленной загрузкой веб-сайтов .

Я уверен, что к настоящему моменту вы уже видите преимущества SSR и SSG . Давайте узнаем, как вы можете реализовать их с помощью Next.js.

Рендеринг на стороне сервера с помощью Next.js

Страницы SSR генерируются при каждом запросе. Логика SSR выполняется только на стороне сервера. Он никогда не запускается в браузере.

Как работает SSR на основе Next.js?

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

Метод getServerSideProps вызывается в двух случаях:

  • когда пользователь запрашивает страницу напрямую,
  • или когда пользователь запрашивает страницу при переходе на стороне клиента, используя next/link или next/router .

Функция getServerSideProps всегда возвращает объект с одним из следующих свойств:

  • props — содержит все данные, необходимые для отображения страницы.
  • notFound — позволяет странице возвращать статус 404 и страницу 404.
  • redirect — позволяет перенаправить пользователя на внутренние и внешние ресурсы.

Интересно, что Next.js утверждает, что весь код, используемый в getServerSideProps , должен быть удален из пакета клиента, чтобы вы могли создавать код, связанный с сервером и клиентом. Это не всегда так. Один неправильный импорт или зависимость, и объединение не будет работать должным образом. Чем проще структура вашего приложения, тем легче добиться правильного поведения.

Пример реализации:

import { GetServerSidePropsContext, GetServerSidePropsResult } from 'next';

type Product = {
 id: string;
 title: string;
}

type SearchResultsPageProps = {
  products: Array<Product>;
}
 
const SearchResultsPage = ({ products }: SearchResultsPageProps) => (
    <div>
        {products.map((product) => (<p key={product.id}>{product.title}</p>))}
    </div>
)
 
export async function getServerSideProps({ res, query }: GetServerSidePropsContext): Promise<GetServerSidePropsResult<SearchResultsPageProps>> { 
  const category = query?.category;
  
  if (!category) {
    return {
        redirect: {
            destination: '/'
        }
    }
  }
  
  const data = await fetch(`http://external-api.com/products?category=${category}`);
  const products = await data.json();
  
  if (products.length === 0) {
    return {
      notFound: true
    }
  }
 
  return {
    props: {
      products,
    }
  }
}
 
export default ProductsPage;

Как видите, это вполне объяснимо:

  • вы можете обрабатывать параметр запроса, такой как категория
  • если параметр категории не существует, вы можете вернуть объект перенаправления. Next.js перенаправит пользователя в указанное место назначения.
  • если параметр существует, вы можете продолжить и сделать вызов внешнего API
  • если данные из внешнего API пусты, можно вернуть страницу 404
  • если у вас есть какой-либо товар, вы можете правильно отобразить свою страницу со списком продуктов

Когда использовать SSR?

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

Пример? Страница результатов поиска или веб-сайт электронной коммерции, содержащий пользовательский контент.

Плюсы ССР:

  • страница всегда содержит актуальный контент,
  • если внутри getServerSideProps возникает ошибка, Next.js автоматически покажет страницу с ошибкой.
  • у вас есть доступ к файлам cookie, заголовкам запросов и параметрам запроса URL
  • вы можете реализовать логику, связанную со страницей 404, и перенаправления на основе пользовательских запросов и данных

Минусы ССР:

  • страница заметно медленнее, чем статически сгенерированная, потому что некоторая логика должна выполняться при каждом запросе (например, вызов API).
  • страница, отображаемая на стороне сервера, может кэшироваться в CDN только путем установки заголовка cache-control (требуется дополнительная настройка).
  • метрика Time to First Byte (TTFB — время, необходимое серверу для доставки первого байта информации на страницу) будет выше, чем на статически сгенерированной странице

На ССГ!

Генерация статического сайта с помощью Next.js

Страницы на основе SSG генерируются во время сборки. Вы можете повторно использовать (и перезагружать) всю страницу по каждому запросу.

Как работает SSG на основе Next.js?

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

  • если содержимое страницы зависит от внешних данных , используйте только метод getStaticProps ,
  • если пути к страницам зависят от внешних данных — используйте метод getStaticPaths в дополнение к getStaticProps .

Метод getStaticProps всегда выполняется на сервере (а не на стороне клиента). Он собирает данные страницы для заданного пути. Метод вызывается в одном из трех случаев:

  • во время следующей сборки,
  • в фоновом режиме, когда вы используете revalidate,
  • по запросу в фоновом режиме при использовании нестабильного_ревалидате.

Я собираюсь рассмотреть два последних случая в разделе «Пошаговая статическая регенерация».

Метод getStaticProps всегда возвращает объект с одним из следующих свойств:

  • props — содержит все данные, необходимые для рендеринга страницы,
  • notFound — позволяет странице возвращать статус 404 и страницу 404,
  • редирект — позволяет перенаправить пользователя на внутренние и внешние ресурсы,
  • revalidate — время (в секундах), необходимое для регенерации страницы.

Что действительно важно, метод getStaticProps не имеет доступа к входящим запросам. Если вам нужен доступ к запросу, рассмотрите возможность использования некоторого промежуточного программного обеспечения, кроме getStaticProps, или рассмотрите вместо этого SSR. В режиме разработки getStaticProps вызывается при каждом запросе для лучшего взаимодействия с разработчиком.

Метод getStaticPaths будет выполняться только во время производственной сборки. Он не будет вызываться во время выполнения. Метод необходимо использовать вместе с getStaticProps . Его нельзя использовать с getServerSideProps .

Метод getStaticPaths всегда возвращает объект с любым из следующих свойств:

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

Next.js предоставил статическую регенерацию по запросу в версии 12.1. Это означает, что вы можете вручную очистить статический кеш для ‌страницы, если ее содержимое было обновлено во внешнем источнике (например, CMS или базе данных). Эта функция дает вам возможность всегда доставлять актуальные данные без задержек и при этом сохранять статическую генерацию для данной страницы.

Пример реализации:

import { GetStaticPathsResult, GetStaticPropsResult, GetStaticPropsContext } from 'next';

type Post = {
 id: string;
 title: string;
}

type PostPageProps = {
  post: Post;
}
 
const PostPage = ({ post }: PostPageProps) => {
  return (
    <p>{post.title}</p>
  )
}
 
export async function getStaticPaths(): Promise<GetStaticPathsResult> {
  const data = await fetch('http://external-api.com/posts');
  const posts = await data.json();
  
  return {
    paths: posts.map(post => ({
      params: { id: post.id }
    })),
    fallback: false,
  }
}
 
export async function getStaticProps({ params }: GetStaticPropsContext<{ id?: string }>): Promise<GetStaticPropsResult<PostPageProps>> {
  const data = await fetch(`http://external-api.com/posts/${params.id}`);
  const post = await data.json();
 
  return {
    props: {
      post,
    },
  }
}
 
export default PostPage;

Пример выше реализует второй из двух ранее упомянутых сценариев — когда пути зависят от внешних данных:

  • вы реализуете метод getStaticPaths для получения списка сообщений в блоге на основе ответа от внешнего API,
  • метод getStaticPaths возвращает массив путей, которые будут предварительно отображены во время сборки,
  • резервный вариант: false , возвращаемый getStaticPaths , означает, что приложение будет отображать страницу 404 для любой страницы, не указанной в путях,
  • с помощью метода getStaticProps вы извлекаете данные для одного сообщения и возвращаете данные в качестве свойств страницы компоненту страницы.

Когда использовать ССГ?

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

Плюсы ССГ:

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

Минусы ССГ:

  • из-за отсутствия доступа к входящим запросам вы не можете читать заголовки запросов, файлы cookie или параметры запроса URL,
  • ваш контент не может быть изменен между развертываниями сайта (без ISR).

Как видите, и у SSR, и у SSG есть свои плюсы и минусы. Вот почему вы также должны рассмотреть альтернативные решения.

Альтернативы SSR и SSG

После всего сказанного и сделанного можно подумать, что SSR и SSG исчерпывают все возможности переноса вашей рабочей нагрузки на сервер. Но разработчики действительно не могут ничего с собой поделать, но постоянно вводят новшества. Введите инкрементную статическую регенерацию!

Инкрементная статическая регенерация — что это такое?

Инкрементная статическая регенерация — одна из самых мощных функций Next.js. Это позволяет вам использовать статическую генерацию таким образом, чтобы вам не приходилось перестраивать всю страницу при каждой перезагрузке.

Инкрементная статическая регенерация является расширением статической генерации. Он предлагает дополнительное свойство, возвращаемое getStaticProps . Это свойство называется revalidate и считается в секундах. Свойство revalidate сообщает вам, как часто Next.js должен регенерировать статический HTML для данной страницы. Регенерация запускается по запросу пользователя, а не каждые «X» секунд. Это свойство должно быть настроено в зависимости от характера данных, которые вы хотите отображать на данной странице, таких как сообщения в блогах, продукты, данные, связанные с пользователями, маркетинговый контент.

ISR улучшает масштабируемость веб-приложений. Вы можете статически генерировать сотни самых популярных или последних сообщений во время сборки и включать ISR для остальных статей. Как только пользователь делает запрос на страницу, не указанную в getStaticPaths , Next.js выполнит серверную визуализацию страницы для этого пользователя и статически сгенерирует страницу в фоновом режиме. Следующий пользователь получит статически сгенерированный контент. Это сократит время сборки, сохранив все преимущества SSG для каждого поста в блоге. Представьте, сколько времени может занять сборка, если вы хотите предварительно отрендерить более 10 000 сообщений во время сборки!

Пример реализации:

import { GetStaticPathsResult, GetStaticPropsResult, GetStaticPropsContext } from 'next';

type Post = {
 id: string;
 title: string;
}

type PostPageProps = {
  post: Post;
}
 
const PostPage = ({ post }: PostPageProps) => {
  return (
    <p>{post.title}</p>
  )
}
 
export async function getStaticPaths(): Promise<GetStaticPathsResult> {
  const data = await fetch('http://external-api.com/posts');
  const posts = await data.json();
  
  return {
    paths: posts.map(post => ({
      params: { id: post.id }
    })),
    fallback: 'blocking'
  }
}
 
export async function getStaticProps({ params }: GetStaticPropsContext<{ id?: string }>): Promise<GetStaticPropsResult<PostPageProps>> {
  const data = await fetch(`http://external-api.com/posts/${params.id}`));
  const post = await data.json();
 
  return {
    props: {
      post,
    },
    revalidate: 10, // In seconds
  }
}
 
export default PostPage;

Как это работает?

Вы получаете список сообщений для предварительного рендеринга в getStaticPaths так же, как и для SSG. Разница в том, что для резервного значения установлено значение blocking . Это означает, что когда пользователь посещает страницу, которая еще не сгенерирована статически, Next.js вернет контент после того, как для этой конкретной страницы будет выполнен серверный рендеринг. SSG будет выполняться в фоновом режиме для следующих пользователей.

В getStaticProps есть новое свойство, которому поручено возвращать объект, который называется revalidate . Он считается в секундах, поэтому Next.js будет предварительно отображать страницу при поступлении запроса, но не чаще одного раза в 10 секунд. Когда страница посещается только один раз в день, повторная проверка запускается один раз в день.

Когда вы можете рассмотреть ISR?

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

CSR или рендеринг на стороне клиента

Другой альтернативой является рендеринг на стороне клиента, основанный на выборке данных на стороне клиента. В отличие от работы с API рендеринга на стороне сервера, выборка данных может выполняться на уровне страницы или компонента. 

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

Когда вы можете рассмотреть вопрос о корпоративной социальной ответственности?

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

Когда вы решите использовать SSR или SSG, всегда ли следует реализовывать их с помощью Next.js?

Почему Next.js для SSR и SSG?

Next.js — это мощное решение, которое предлагает множество различных подходов к отображению ваших страниц. Поскольку он охватывает так много методов, вы можете легко настроить его в соответствии со своими требованиями. Вы можете использовать разные стратегии рендеринга или даже комбинировать их вместе.

Как понять, какой подход лучше? Вот несколько полезных вопросов, которые стоит задать себе:

  • Вам нужно как отличное SEO, так и производительность? SSG - это путь .
  • Вам нужно SEO и возможность часто обновлять свои данные? Используйте ССР .
  • Вам нужны часто обновляемые данные, но SEO и производительность не являются приоритетом? КСО — это разумный выбор .
  • У вас есть тысячи страниц, которые требуют частого обновления контента? ISR заслуживает внимания .

Существует несколько комбинаций описанных выше сценариев. Поиск наилучшего баланса требует тщательного анализа вашего проекта.

Другая причина выбора Next.js проста и в то же время очень важна — Next.js чрезвычайно популярен . У него более 83 000 звезд на Github (больше, чем у любых других альтернатив) и большое сообщество. Кроме того, компания Vercel работает в фоновом режиме, обеспечивая непрерывную разработку и поддержку платформы Next.js. В совокупности вы получаете стабильную, яркую среду, которая никуда не денется.

Конечно, как и у любого другого фреймворка, у Next.js есть свои недостатки. Например, не так просто обмениваться статическим содержимым между несколькими экземплярами Next.js в производственной среде с помощью Docker. Тем не менее, гибкость Next.js позволяет относительно легко находить решения в случае изменения требований в проекте. Скорее всего, вам не нужно будет переходить на другое решение или платформу, чтобы добиться цели.

Альтернативы Next.js

Гэтсби

Gatsby — это быстрый и гибкий фреймворк и генератор статических сайтов, который делает создание сайтов с помощью любой CMS или API очень приятным. Gatsby используется для создания веб-сайтов, которые генерируют статический HTML во время сборки. Впоследствии код можно хранить в CDN и распространять среди всех ваших пользователей по всему миру. Gatsby сочетает в себе лучшие элементы React и GraphQL, поэтому это настоящее удовольствие для разработчиков. Начиная с версии 4, Gatsby поддерживает SSR, что делает фреймворк еще более мощным. Более 52 000 звезд GitHub — свидетельство популярности Гэтсби.

Ремикс

Remix — это веб-фреймворк с полным стеком, который позволяет вам сосредоточиться на пользовательском интерфейсе. Он обеспечивает быстрый и удобный пользовательский интерфейс. 

В Remix есть только два режима рендеринга — вы можете использовать SSR во время выполнения и CSR во время выполнения. Remix использует React для создания пользовательских интерфейсов. Он содержит вложенные маршруты, что означает, что вы можете запускать несколько маршрутов в одном представлении без каких-либо состояний загрузки. Ремикс стал популярным в последние несколько месяцев. Сообщество быстро растет. У него более 14 000 звезд GitHub .

Гексо

Hexo — это инструмент на базе Node.js, который относится к категории SSG. Это быстро, просто и мощно. Он продается в первую очередь как фреймворк для блогов. Он анализирует ваши сообщения с помощью Markdown или другого механизма рендеринга, создавая статические файлы за считанные секунды. У него более 34 000 звезд на GitHub .

Что принесет будущее?

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

Компоненты сервера React

React 18 представляет компоненты React Server. На первый взгляд это звучит не так захватывающе, но становится лучше! Начнем с документов.

Короче говоря, серверные компоненты и их логика будут выполняться только на сервере. Они не будут подвергаться процессу гидратации. В результате вы получите свежесгенерированные статические фрагменты HTML. Естественно, серверные компоненты могут содержать дочерние компоненты клиента. Эти компоненты могут быть полностью интерактивными и отображаться в браузере.

Чтобы понять практические последствия, давайте снова обратимся к документации.

Несмотря на альфа-версию, серверные компоненты уже поддерживают некоторые API Next.js, включая next/link , next/image и next/document . Они также имеют доступ к маршрутизатору. Он вводится в компонент свойством маршрутизатора .

Компоненты сервера не имеют состояния, поэтому вы не можете использовать React Hooks как useContext , useState , useReducer или useEffect внутри этих компонентов. Кроме того, пока не поддерживаются такие функции, как i18n (интернационализация) или next/head .

На мой взгляд, серверные компоненты потенциально могут изменить способ использования фреймворка Next.js. Они могли бы заменить традиционные SSR. Их преимущества включают отправку меньшего количества JavaScript в браузер (меньше килобайт для загрузки) и ограничение процесса гидратации клиентскими компонентами. Оба должны улучшить взаимодействие с пользователем за счет повышения веб-производительности, особенно метрик « Время до первого байта» и « Задержка первого ввода ».

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

SSR/SSG для улучшения и обеспечения безопасности вашего приложения в будущем

Вот и все! Конечно, о SSR и SSG можно сказать гораздо больше. Тем не менее, это должно дать вам четкое представление о том, как это работает, чтобы сделать ваше приложение и ваш бизнес более эффективными. Ты знаешь что:

  • SSR и SSG — это методы, которые органично развились, чтобы реагировать на реальные проблемы, с которыми сталкиваются компании, связанные с производительностью, удобством использования и видимостью своего контента.
  • SSR улучшает все эти показатели без ущерба для вашего веб-приложения.
  • SSG предлагает еще больше с точки зрения улучшения метрик, но во многих сценариях это нецелесообразно — необходимость перестраивать ваш веб-сайт каждый раз, когда меняются данные, ограничивает его варианты использования страницами, которые не включают большой обмен данными с клиентом.
  • Next.js предлагает решение некоторых проблем SSG с помощью Incremental Static Regeneration . Конечно, у этого решения есть свои плюсы и минусы. К последним относятся проблемы с кешированием и отладкой.

Если у вас есть опыт разработки программного обеспечения в качестве разработчика или бизнесмена, вы определенно понимаете, что не существует универсальных решений. Чем сложнее и инновационнее ваше приложение, тем больше правды в нем содержится. То же самое касается SSR и SSG.

Ссылка: https://tsh.io/blog/ssr-vs-ssg-in-nextjs/

#nextjs #реакция #javascript

What is GEEK

Buddha Community

SSR против SSG в Next.js
JavaScript Daily

JavaScript Daily

1632537859

NBB: Ad-hoc CLJS Scripting on Node.js

Nbb

Not babashka. Node.js babashka!?

Ad-hoc CLJS scripting on Node.js.

Status

Experimental. Please report issues here.

Goals and features

Nbb's main goal is to make it easy to get started with ad hoc CLJS scripting on Node.js.

Additional goals and features are:

  • Fast startup without relying on a custom version of Node.js.
  • Small artifact (current size is around 1.2MB).
  • First class macros.
  • Support building small TUI apps using Reagent.
  • Complement babashka with libraries from the Node.js ecosystem.

Requirements

Nbb requires Node.js v12 or newer.

How does this tool work?

CLJS code is evaluated through SCI, the same interpreter that powers babashka. Because SCI works with advanced compilation, the bundle size, especially when combined with other dependencies, is smaller than what you get with self-hosted CLJS. That makes startup faster. The trade-off is that execution is less performant and that only a subset of CLJS is available (e.g. no deftype, yet).

Usage

Install nbb from NPM:

$ npm install nbb -g

Omit -g for a local install.

Try out an expression:

$ nbb -e '(+ 1 2 3)'
6

And then install some other NPM libraries to use in the script. E.g.:

$ npm install csv-parse shelljs zx

Create a script which uses the NPM libraries:

(ns script
  (:require ["csv-parse/lib/sync$default" :as csv-parse]
            ["fs" :as fs]
            ["path" :as path]
            ["shelljs$default" :as sh]
            ["term-size$default" :as term-size]
            ["zx$default" :as zx]
            ["zx$fs" :as zxfs]
            [nbb.core :refer [*file*]]))

(prn (path/resolve "."))

(prn (term-size))

(println (count (str (fs/readFileSync *file*))))

(prn (sh/ls "."))

(prn (csv-parse "foo,bar"))

(prn (zxfs/existsSync *file*))

(zx/$ #js ["ls"])

Call the script:

$ nbb script.cljs
"/private/tmp/test-script"
#js {:columns 216, :rows 47}
510
#js ["node_modules" "package-lock.json" "package.json" "script.cljs"]
#js [#js ["foo" "bar"]]
true
$ ls
node_modules
package-lock.json
package.json
script.cljs

Macros

Nbb has first class support for macros: you can define them right inside your .cljs file, like you are used to from JVM Clojure. Consider the plet macro to make working with promises more palatable:

(defmacro plet
  [bindings & body]
  (let [binding-pairs (reverse (partition 2 bindings))
        body (cons 'do body)]
    (reduce (fn [body [sym expr]]
              (let [expr (list '.resolve 'js/Promise expr)]
                (list '.then expr (list 'clojure.core/fn (vector sym)
                                        body))))
            body
            binding-pairs)))

Using this macro we can look async code more like sync code. Consider this puppeteer example:

(-> (.launch puppeteer)
      (.then (fn [browser]
               (-> (.newPage browser)
                   (.then (fn [page]
                            (-> (.goto page "https://clojure.org")
                                (.then #(.screenshot page #js{:path "screenshot.png"}))
                                (.catch #(js/console.log %))
                                (.then #(.close browser)))))))))

Using plet this becomes:

(plet [browser (.launch puppeteer)
       page (.newPage browser)
       _ (.goto page "https://clojure.org")
       _ (-> (.screenshot page #js{:path "screenshot.png"})
             (.catch #(js/console.log %)))]
      (.close browser))

See the puppeteer example for the full code.

Since v0.0.36, nbb includes promesa which is a library to deal with promises. The above plet macro is similar to promesa.core/let.

Startup time

$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)'   0.17s  user 0.02s system 109% cpu 0.168 total

The baseline startup time for a script is about 170ms seconds on my laptop. When invoked via npx this adds another 300ms or so, so for faster startup, either use a globally installed nbb or use $(npm bin)/nbb script.cljs to bypass npx.

Dependencies

NPM dependencies

Nbb does not depend on any NPM dependencies. All NPM libraries loaded by a script are resolved relative to that script. When using the Reagent module, React is resolved in the same way as any other NPM library.

Classpath

To load .cljs files from local paths or dependencies, you can use the --classpath argument. The current dir is added to the classpath automatically. So if there is a file foo/bar.cljs relative to your current dir, then you can load it via (:require [foo.bar :as fb]). Note that nbb uses the same naming conventions for namespaces and directories as other Clojure tools: foo-bar in the namespace name becomes foo_bar in the directory name.

To load dependencies from the Clojure ecosystem, you can use the Clojure CLI or babashka to download them and produce a classpath:

$ classpath="$(clojure -A:nbb -Spath -Sdeps '{:aliases {:nbb {:replace-deps {com.github.seancorfield/honeysql {:git/tag "v2.0.0-rc5" :git/sha "01c3a55"}}}}}')"

and then feed it to the --classpath argument:

$ nbb --classpath "$classpath" -e "(require '[honey.sql :as sql]) (sql/format {:select :foo :from :bar :where [:= :baz 2]})"
["SELECT foo FROM bar WHERE baz = ?" 2]

Currently nbb only reads from directories, not jar files, so you are encouraged to use git libs. Support for .jar files will be added later.

Current file

The name of the file that is currently being executed is available via nbb.core/*file* or on the metadata of vars:

(ns foo
  (:require [nbb.core :refer [*file*]]))

(prn *file*) ;; "/private/tmp/foo.cljs"

(defn f [])
(prn (:file (meta #'f))) ;; "/private/tmp/foo.cljs"

Reagent

Nbb includes reagent.core which will be lazily loaded when required. You can use this together with ink to create a TUI application:

$ npm install ink

ink-demo.cljs:

(ns ink-demo
  (:require ["ink" :refer [render Text]]
            [reagent.core :as r]))

(defonce state (r/atom 0))

(doseq [n (range 1 11)]
  (js/setTimeout #(swap! state inc) (* n 500)))

(defn hello []
  [:> Text {:color "green"} "Hello, world! " @state])

(render (r/as-element [hello]))

Promesa

Working with callbacks and promises can become tedious. Since nbb v0.0.36 the promesa.core namespace is included with the let and do! macros. An example:

(ns prom
  (:require [promesa.core :as p]))

(defn sleep [ms]
  (js/Promise.
   (fn [resolve _]
     (js/setTimeout resolve ms))))

(defn do-stuff
  []
  (p/do!
   (println "Doing stuff which takes a while")
   (sleep 1000)
   1))

(p/let [a (do-stuff)
        b (inc a)
        c (do-stuff)
        d (+ b c)]
  (prn d))

$ nbb prom.cljs
Doing stuff which takes a while
Doing stuff which takes a while
3

Also see API docs.

Js-interop

Since nbb v0.0.75 applied-science/js-interop is available:

(ns example
  (:require [applied-science.js-interop :as j]))

(def o (j/lit {:a 1 :b 2 :c {:d 1}}))

(prn (j/select-keys o [:a :b])) ;; #js {:a 1, :b 2}
(prn (j/get-in o [:c :d])) ;; 1

Most of this library is supported in nbb, except the following:

  • destructuring using :syms
  • property access using .-x notation. In nbb, you must use keywords.

See the example of what is currently supported.

Examples

See the examples directory for small examples.

Also check out these projects built with nbb:

API

See API documentation.

Migrating to shadow-cljs

See this gist on how to convert an nbb script or project to shadow-cljs.

Build

Prequisites:

  • babashka >= 0.4.0
  • Clojure CLI >= 1.10.3.933
  • Node.js 16.5.0 (lower version may work, but this is the one I used to build)

To build:

  • Clone and cd into this repo
  • bb release

Run bb tasks for more project-related tasks.

Download Details:
Author: borkdude
Download Link: Download The Source Code
Official Website: https://github.com/borkdude/nbb 
License: EPL-1.0

#node #javascript

Eva Murphy

Eva Murphy

1625674200

Google analytics Setup with Next JS, React JS using Router Events - 14

In this video, we are going to implement Google Analytics to our Next JS application. Tracking page views of an application is very important.

Google analytics will allow us to track analytics information.

Frontend: https://github.com/amitavroy/video-reviews
API: https://github.com/amitavdevzone/video-review-api
App link: https://video-reviews.vercel.app

You can find me on:
Twitter: https://twitter.com/amitavroy7​
Discord: https://discord.gg/Em4nuvQk

#next js #js #react js #react #next #google analytics

Landen Brown

Landen Brown

1625985180

Client & SSR Authentication with Next.js in Less than 7 Minutes from Scratch

In this video we’ll start from scratch to build out authentication in a brand new Next.js project to implement client, server, and API route authentication using AWS Amplify and Amazon Cognito.a

#next #next.js #ssr

Eva Murphy

Eva Murphy

1625751960

Laravel API and React Next JS frontend development - 28

In this video, I wanted to touch upon the functionality of adding Chapters inside a Course. The idea was to not think much and start the development and pick up things as they come.

There are places where I get stuck and trying to find answers to it up doing what every developer does - Google and get help. I hope this will help you understand the flow and also how developers debug while doing development.

App url: https://video-reviews.vercel.app
Github code links below:
Next JS App: https://github.com/amitavroy/video-reviews
Laravel API: https://github.com/amitavdevzone/video-review-api

You can find me on:
Twitter: https://twitter.com/amitavroy7​
Discord: https://discord.gg/Em4nuvQk

#next js #api #react next js #next #frontend #development

joe biden

1615787193

Kонвертер MBOX в PST - Бесплатный MBOX в PST для конвертации файла MBOX в файл PST

Descargue el MBOX al convertidor PST y convierta los archivos MBOX al formato PST. Con esta aplicación, los archivos se convierten a gran velocidad sin ningún problema. Para conocer la aplicación el usuario puede instalar la versión demo de esta aplicación y así conocer la aplicación y su funcionamiento. Con una alta velocidad de compatibilidad, la aplicación convierte todos los archivos MBOX en formato PST.

Conozca el funcionamiento de la aplicación.

Esta aplicación avanzada funciona en un orden específico para convertir los archivos MBOX a formato PST. Por lo tanto, a continuación se muestran algunos de los puntos que hablan sobre la aplicación y ver si la aplicación cumple con todas las expectativas del usuario.

  • Los usuarios pueden convertir archivos MBOX a granel y sin problemas.
  • Con la ubicación especificada por el usuario, los datos se convierten rápidamente.
  • La aplicación proporciona una conversión directa.
  • De forma avanzada, se realiza el proceso de conversión.
  • La aplicación proporciona una conversión rápida con solo un clic.
  • La aplicación funciona en cualquier aplicación de Windows, incluidos XP o Vista.
  • Cualquier archivo MBOX de correo electrónico se convierte en este convertidor inteligente.
  • La aplicación guarda el archivo localmente.

Por lo tanto, la aplicación ofrece estas funciones avanzadas que permiten que el software funcione de manera avanzada.

¿Cómo convertir archivos MBOX a PST?

Los usuarios pueden convertir el archivo en unos pocos pasos sin asistencia técnica. Siga estos pasos para convertir su archivo MBOX al formato PST de Outlook:

Paso 1: descargue el convertidor MBOX a PST
Paso 2- Inicie el convertidor
Paso 3- Seleccione los archivos MBOX que desea convertir
Paso 4- Ahora, elija el tipo que desea exportar los archivos.
Paso 5- Elija la ubicación donde desea guardar el archivo
Paso 6- Finalmente, haga clic derecho en el botón “Convertir ahora”.

Estos pasos pueden ser realizados por cualquier usuario novato.

Algunos de los atributos de este convertidor inteligente

Analicemos las funciones inteligentes de este convertidor que se indican a continuación:

  1. Convierta cualquier archivo MBOX

Esta herramienta convierte archivos MBOX de cualquier tipo desde Thunderbird a Apple Mail. Este es un convertidor avanzado.

  1. Conversión masiva de archivos MBOX

Los usuarios pueden convertir cualquier cantidad de archivos de datos sin ningún obstáculo. No importa cuál sea el tamaño del archivo MBOX, la conversión procede.

  1. Solo se convierten los archivos seleccionados

Los archivos que selecciona el usuario se convierten de archivos MBOX al formato PST de Outlook. Los resultados convertidos son los deseados por los usuarios.

  1. Ubicación personalizada

El usuario puede guardar el archivo en cualquier ubicación donde el usuario quiera guardarlo. En una ubicación adecuada, se guardan los datos convertidos.

  1. Buena compatibilidad

El usuario proporciona una interfaz fácil de usar que ayuda al usuario a convertir los archivos sin problemas y sin ningún obstáculo.

  1. Excelente precisión

El resultado proporcionado por la aplicación es 100% exacto. La calidad del resultado sigue siendo impecable.

Conclusión

La aplicación da todos los resultados adecuados después de la conversión. Con una alta velocidad de compatibilidad, la tarea de conversión es procesada por la aplicación sin ningún error. Descargue la versión de demostración gratuita del convertidor MBOX a PST para ver si funciona.

Más información:- https://www.datavare.com/ru/конвертер-mbox-в-pst.html

#конвертер mbox в pst #mbox в импортер pst #преобразование mbox в pst #mbox в экспортер pst #конвертировать mbox в pst #импортировать mbox в pst