Сейчас Гэтсби этим не занимается, но люди об этом просили. В версии 2 была проведена

@ m-allanson есть ли обсуждение / вопрос о том, как с этим справиться? Я не видел этого в указанной вами ссылке. Мне любопытно услышать разговоры о том, как справиться с этим на таком хосте, как Netlify, и с использованием CMS, например Wordpress / Drupal, которые в настоящее время требуют большого количества HTTP-запросов во время сборки.

AFAIK вы не смогли бы использовать инкрементные сборки в netlify, потому что каталоги .cache и public не сохраняются между сборками, поэтому он всегда будет выполнять чистую сборку

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

Другой вариант использования инкрементального строительства - это когда у вас очень большой сайт, который вы хотите строить по частям. Я получал "ошибку нехватки памяти" при одновременном создании ~ 5к страниц.

Мы планируем, что наш сайт станет очень большим, поэтому мы тестируем Gatsby в более крупных масштабах. Мы пробовали сделать что-то вроде этого path: './src/pages/${subPath}', где subPath - это process.argv[3] . Это прекрасно работает, когда мы размещаем части нашего сайта с помощью gatsby develop . Это также позволяет обойти проблемы с кучей памяти при использовании gatsby build для сайта размером более 5 тыс. Страниц. Чтобы это действительно было решением, это, вероятно, будет зависеть от возможности указать выходной подкаталог в общей папке: https://github.com/gatsbyjs/gatsby/pull/4756

что, если для достижения той же цели используется другой подход. Я хотел реализовать вашу идею, ребята, и посмотреть, что думают люди. Допустим, у вас есть веб-сайт на 5 тыс. Страниц. Начальные страницы будут созданы статически, но каждая страница будет иметь подкомпонент, который будет загружаться поверх статического содержимого с тем же содержимым, которое читается из статических файлов json. Таким образом, если пользователь хочет обновить одну страницу в CMS в середине дня, он может выполнить обновление, и только этот статический файл json будет регенерирован и развернут в CDN. Затем вы можете просто регенерировать весь сайт, возможно, один раз в день, как ночной процесс. Статический контент seo может быть не самым актуальным в течение дня, но я не вижу в этом большого значения. Он будет обновляться только в ночное время.

@robertschneiderman мы тоже столкнулись с проблемой памяти. Мы ближе к 1500 страницам, но безумное количество изображений (дизайнерский блог). Мы отключили исходные карты и остановили сборку от загрузки файлов изображений, но в конечном итоге пришлось отредактировать команду сборки, чтобы увеличить память, выделенную для экземпляра узла. с помощью флага --max_old_space_size .

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

Я подумываю об использовании Gatsby для создания пользовательского интерфейса для сайта с более чем 5000 элементов, большинство из которых взаимосвязаны друг с другом. Данные будут поступать из CMS, управляемой базой данных.

Преимущество использования Gatsby по сравнению со стандартным сайтом React, управляемым API, состоит в том, что я потратил бы часть времени на создание и поддержку API данных и системы управления состоянием, которая загружает удаленные данные и хранит их. (Поскольку я планирую развернуть это приложение на нескольких сайтах одинакового размера, это кажется очень ценным преимуществом.)

Обратной стороной использования Gatsby в этом случае будет тот факт, что весь сайт потребуется перестроить даже для самого незначительного обновления контента. Забыли добавить запятую? Восстановите все 5000 страниц! Кто вообще знает, сколько времени это займет? Это даже более серьезная проблема при рассмотрении опыта пользователей CMS - они привыкли видеть изменения, появляющиеся на сайте сразу после их сохранения. В случае с Гэтсби нам нужно подождать несколько минут (как минимум), прежде чем появится изменение.

Если бы существовал способ запускать сборки для подмножества страниц, это сделало бы Гэтсби четким и окончательным выбором. Однако в настоящий момент это непросто.

Кстати, я много работал над улучшением скорости для больших сборок сайтов для v2. В последней бета-версии v2 - возможно, вы сможете создать 5000 страниц за <1:30. Скоро будет больше улучшений.

Это потрясающе, @KyleAMathews! Я с нетерпением жду этого! Дайте мне знать, если вы хотите протестировать блог с большим количеством изображений

@KyleAMathews 5K - это хорошо, но нам нужен 1M 😉

Если мы хотим скомпилировать части сайта по отдельности, мы можем установить флаги при сборке, чтобы gatsby-node знал только, чтобы сгенерировать указанные части сайта. Затем мы могли бы снова добавить ранее созданные статические файлы. Это работает для нас, пока мы связываемся с ранее сгенерированными файлами с базовым <a href> а не с <Link to > .

Мне интересно, можем ли мы заставить <Link to> работать при связывании с ранее созданными файлами, если мы объединим некоторые из предыдущих data.json во время сборки. На данный момент мы рассмотрим это подробнее.

Я не беспокоюсь о времени сборки, но больше об объеме статических файлов, которые мне нужно загрузить для любого обновления, мы запустили большое визуальное портфолио с Gatsby, и статический сайт для загрузки составляет более 150 МБ
В основном изображения.
Это делает сайт недоступным около 40 минут во время обновления.
Возможность перестроить часть сайта, безусловно, поможет Гэтсби.
Я планирую использовать Gatsby для нового сайта, но я разделю сайт на статическую и динамическую части, используя традиционную php CMS для новостной части.

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

Спасибо, Мэтт, я учту!
Раньше я создавал несколько новостных сайтов с помощью Drupal, любое обновление должно было быть доступно в течение короткого промежутка времени (менее 2 минут). Я хотел бы использовать Gatsby в будущем для таких сайтов.

Есть новости по этому поводу? Мы планируем создать сайт примерно на 100 тыс. Страниц, и дополнительные сборки будут отличными.

сделайте другой путь как папку статической страницы по умолчанию, а не '/ public'.
После запуска gatsby build скопируйте ../public/* в путь по умолчанию.

Привет!

Этот вопрос утих. Жуткая тишина. 👻

У нас много проблем, поэтому в настоящее время мы закрываем их после 30 дней бездействия. Прошло как минимум 20 дней с момента последнего обновления здесь.

Если мы пропустили эту проблему или вы хотите оставить ее открытой, ответьте здесь. Вы также можете добавить ярлык «не устаревший», чтобы эта проблема оставалась открытой!

Спасибо, что стали частью сообщества Гэтсби! 💪💜

Я до сих пор не думаю, что это исправлено / поддерживается в Gatsby. Есть новости @ TeamGatsby?

это давняя проблема, потому что ее действительно трудно исправить, не задумываясь над ней. У @Moocar есть открытая проблема, по крайней мере, чтобы сделать нам шаг в правильном направлении.

Отслеживает ли Gatsby в настоящее время, какие узлы GraphQL извлекаются на данной странице? Если это так, было бы целесообразно добавить инкрементные перестройки на основе изменений данных. Это половина работы, не так ли?

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

@coreyward Да, Гэтсби отслеживает каждый узел, возвращаемый по запросу (через page-dependency-resolver.js ). Это то, что дает возможность gatsby develop повторно запускать запросы только для измененных данных. В настоящее время мы не сохраняем эту информацию на диск, поэтому она еще не используется для gatsby build но это определенно план.

Я знаю, что для нашей команды это будет решение "идти / не идти" против использования Gatsby для перестройки нашего флагманского сайта в 2019 году. Я очень надеюсь, что он будет выпущен или, по крайней мере, появится на горизонте, когда мы начнем строить. Мы поддерживаем сотни веб-авторов, редактирующих различные части сайта в течение рабочего дня. Когда они нажимают «Сохранить», они в значительной степени ожидают, что контент будет обновлен. Они нередко возвращаются назад, чтобы исправить запятую или изменить дату в сообщении.

@mattbloomfield, у нас больше клиентов, заинтересованных в этом, поэтому мы

мы реализуем gatsby с бэкэндом drupal 8 с использованием плагина gatsby-source-graphql, и пока производительность не является проблемой, ~ 4000 страниц построены менее чем за 30 секунд. мы извлекаем все данные в gatsby-node, а не запускаем тысячи StaticQuerys и пока не обрабатываем изображения.

``
Успешный запуск запросов graphql - 3,088 с - 4008/4008 1311,56 запросов в секунду
успешная запись данных страницы - 0,070 с
успешная запись данных перенаправления - 0,001 с
Успех сборки манифеста и связанных значков - 0,117 с
успех onPostBootstrap - 0,127 с

info bootstrap завершен - 15.751 с

Успех Создание производственных пакетов JavaScript и CSS - 3,361 с
успех Создание статического HTML для страниц - 6,906 с - 4006/4006 609,25 страниц в секунду
info Завершено строительство за 26.047 сек.

В настоящее время я оцениваю использование Gatsby для ускорения работы старого сайта Rails 3.x, размещенного на Heroku, который работает медленно, как патока. В нем около 1 миллиона страниц, поэтому инкрементные сборки - единственный способ, которым он будет работать. Большинство страниц не меняются, поэтому сделать их статичными кажется огромной победой, но постоянно добавляются новые страницы, а некоторые старые редактируются. Пользователи ожидают увидеть изменения в течение нескольких секунд. Я надеялся добавить достаточно кода в приложение Rails, чтобы сделать его сервером JSON API, и сгенерировать новый интерфейс с помощью Gatsby со статическими активами, размещенными где-то вроде Netlify или S3.

Я думал, что смогу сделать что-то вроде запуска инкрементной сборки Gatsby через работника очереди заданий. Сервер Rails API знает, когда страница обновляется, поэтому он создаст «задание обновления страницы», используя page_id (ключ в базе данных postgres), и рабочий передаст это Gatsby с помощью переменной ENV с чем-то вроде PAGE_ID=1235 gatsby build . Я бы использовал эту переменную ENV в createPages (), чтобы найти то, что нужно для этой страницы, и построить ее. Результирующий выходной файл (ы) будет передан на статический хост (я надеюсь, что для этого есть хук сборки). Если не задана переменная PAGE_ID, все страницы будут построены как обычно.

Если страница будет удалена, Rails API создаст задание, которое либо удаляет ресурсы непосредственно со статического хоста, либо, возможно, что-то нужно от Gatsby, поэтому я все равно запустил бы это с другой переменной ENV. (Я думаю, мне нужен как минимум путь к странице).

Я лаю не на то дерево, думая, что Гэтсби совместим с такого рода проектами? Спасибо за любую помощь.

У нас есть альфа-версия. Это еще не инкрементальные сборки, но, по крайней мере, путь вперед.
вы можете использовать его, установив npm install --save gatsby@per-page-manifest

Больше информации:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot на данный момент постраничное построение еще не работает. Я не уверен, в какие сроки вы рассчитываете для этого проекта. Если запросов мало, gatsby может подойти для вашего сайта даже без дополнительных сборок.

cc @KyleAMathews @Moocar, чтобы лучше объяснить это.

Пингуем это, так как с момента последнего обновления прошло несколько месяцев, и, похоже, это место действия. Я вижу, что произошла поломка page-data.json, и я ее использую.

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

@wardpeet @Moocar Я не уверен, кто является наиболее подходящим человеком / списком, чтобы пинговать по этому поводу, но я вижу, что вы оба являетесь последними активистами этого проекта. Есть ли обновления относительно основной цели этого билета?

Хорошая беседа с @KyleAMathews о дополнительных сборках и способах их доставки https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Хорошая беседа с @KyleAMathews о дополнительных сборках и способах их доставки https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TL; DR;

@KyleAMathews подтвердил, что Gatsby работает над функциями инкрементной сборки, размещенными в Gastsby Cloud.

Самостоятельная / локальная версия "Gatsby Enterprise" с инкрементными сборками возможна, но они еще не работают над этим ....

Доминик Фаллоуз - 4 сентября - Большинство выбранных нами поставщиков предлагают вариант с самоуправлением или локально, как это делает Gatsby OSS. Мы с радостью платим за это, как и за локальное решение Gatsby Enterprise Cloud от вас.

Кайл Мэтьюз - 4 сентября - да, конечно - у нас есть довольно четкий путь для поддержки onprem-версий того, что мы делаем - это все Kubernetes, так что это должно быть возможно - но onprem добавляет много накладных расходов, когда мы изначально просто работаем о доставке того, что работает 😅

Доминик Фэллоуз - 4 сентября - Отличные новости! Извините, если я пропустил то, что обсуждалось в другом месте, но эта дорожная карта onprem будет очень полезна как для предприятий, так и для разработчиков.

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

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

Разве не имеет смысла «выбросить» такой вариант использования как отдельный проект с использованием тех же концепций / ядра?

Функция "Сделай или сломай" для решений 2020 года. Кажется, хорошее место для инвестирования всех этих венчурных денег 😀

Гэтсби многое делает правильно, но длительное время сборки делает его абсолютно непригодным для использования в более крупных проектах: / На этой неделе мы обсуждали уход от фреймворка только по этой причине.
Пожалуйста, сделайте сборку быстрее!

Согласен с вышеизложенным! Gatsby либо занимает нишу в быстром и простом решении для ведения блогов, либо внедряет инкрементные / более быстрые сборки и становится готовым для предприятий.

Абсолютно правильно; сталкиваясь с этим снова и снова в более крупных проектах. Без инкрементальных сборок Гэтсби не вариант.

Дополнительные сборки Gatsby Cloud устраняют эти проблемы. Вы можете подписаться на частную бета-версию здесь https://www.gatsbyjs.com/builds-beta/

Ничто в этом, похоже, не предполагает, что он поддерживает инкрементные сборки, просто он имеет «самое быстрое время сборки для сайтов Gatsby».

Я был бы обеспокоен тем, что инкрементные сборки будут доступны только для размещенной службы Gatsby, а не для автономного использования.

Я понимаю, что вы имеете в виду, @dwightwatson , на веб-сайте нет ничего, что говорило бы, что это "инкрементный". На Gatsby Days London демонстрировали сборки, и это определенно были инкрементальные сборки. Не уверен, как это делается, и будет ли он частью пакета Gatsby или это будет просто услуга, которую они предоставляют.

Инвесторам нужно как-то вернуть свои деньги. 🙄

пытаюсь создать очень большой сайт 140k + страниц

gatsby build в некоторой степени хорош ... но развертывание его болезненно (zeit.co)

Не знаю, как добавить к этому метку, но я считаю это проблемой.

@gomflo есть ли способ создать ваш сайт? Могут быть некоторые низко висящие фрукты, которые нужно решить, чтобы улучшить время сборки :) Никаких обещаний.

Ничто в этом, похоже, не предполагает, что он поддерживает инкрементные сборки, просто он имеет «самое быстрое время сборки для сайтов Gatsby».

Я был бы обеспокоен тем, что инкрементные сборки будут доступны только для размещенной службы Gatsby, а не для автономного использования.

re this ^: Если мое репозиторий gatsby находится в gitlab, а не на github, смогу ли я использовать функции gatsby cloud / build?

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

Так будет ли у нас отдельное частичное обновление или никаких шансов? Может быть, есть другой способ обновить только несколько страниц и не перестраивать весь проект?

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

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

Вот PR https://github.com/gatsbyjs/gatsby/pull/20785

Дальнейшее обновление PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

Новый PR с упором на постепенное изменение данных https://github.com/gatsbyjs/gatsby/pull/21523

Я считаю, что с объединением # 21523 и добавочными сборками в Gatsby Cloud эта проблема решена. Он не поддерживает все рабочие процессы, но я собираюсь закрыть его сейчас, и, возможно, будет лучше открыть новый выпуск в будущем для будущих усилий, если это будет необходимо.

Стоит ли его действительно закрывать? Оптимизация была всего лишь оптимизацией. Это не были действительно инкрементальные сборки. Вдобавок ко всему, все, что доступно через Gatsby Cloud, недоступно через общедоступный пакет. Для конкретного намерения этого тикета ничего не решено.

Стоит ли его действительно закрывать?

Исходя из https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662, я не думаю, что эта проблема должна оставаться закрытой, и я не понимаю, почему метка not stale была удалена .

Кто-нибудь здесь пробовал или знает, возможно ли настроить конфигурацию веб-пакета GatsbyJS для одновременного создания как предварительной версии для разработки, так и производственной версии сборки с помощью «gatsby develop»? (Возможны «инкрементные сборки» с затратами на вечно работающий сервер разработки.)