Itu bukan sesuatu yang Gatsby lakukan saat ini, tapi itu adalah sesuatu yang diminta orang. Ada pekerjaan dalam versi 2 untuk meningkatkan kinerja di situs yang lebih besar, tetapi belum ada tanggal rilis untuk itu.

@ m-allanson apakah ada diskusi / masalah tentang bagaimana menangani ini? Saya tidak melihatnya di tautan yang Anda daftarkan. Saya penasaran mendengar percakapan tentang bagaimana menangani melakukan ini pada host seperti Netlify & menggunakan CMS seperti Wordpress / Drupal yang saat ini membutuhkan banyak permintaan HTTP selama pembuatan.

AFAIK Anda tidak akan dapat menggunakan build inkremental di netlify karena direktori .cache dan public tidak disimpan di antara build, jadi itu akan selalu melakukan build yang bersih

Senang mendengarnya. Saya melemparkan banyak ide yang tidak dipikirkan dengan baik. Jadi, meskipun kami dapat menghilangkan kebutuhan akan permintaan HTTP, kami masih perlu memastikan bahwa .cache dan direktori publik dapat dirujuk oleh alat pembangunan yang menghilangkan banyak host yang menurunkan bilah untuk masuk.

Contoh penggunaan lain untuk bangunan inkremental adalah ketika Anda memiliki situs yang sangat besar yang ingin Anda bangun menjadi beberapa bagian. Saya mendapatkan "kesalahan tumpukan memori" saat membuat ~ 5k halaman sekaligus.

Kami berencana situs kami menjadi sangat besar, jadi kami menguji Gatsby pada skala yang lebih besar. Kami telah mencoba melakukan sesuatu seperti ini path: './src/pages/${subPath}', mana subPath adalah process.argv[3] . Ini berfungsi dengan baik saat kami menghosting bagian situs kami dengan gatsby develop . Ini juga menghindari masalah dengan tumpukan memori saat menggunakan gatsby build untuk situs 5k + halaman. Agar benar-benar menjadi solusi, mungkin akan bergantung pada kemampuan untuk menentukan subdirektori keluaran dalam folder publik: https://github.com/gatsbyjs/gatsby/pull/4756

bagaimana jika pendekatan lain digunakan untuk mencapai tujuan yang sama. Saya ingin menjalankan ide oleh kalian dan melihat apa yang orang pikirkan. Jadi katakanlah Anda memiliki situs web 5k halaman. Halaman awal akan dibuat secara statis tetapi setiap halaman akan memiliki sub komponen yang akan dimuat di atas konten statis dengan konten yang sama yang dibaca dari file json statis. Dengan cara ini jika pengguna ingin mengupdate satu halaman di CMS di tengah hari, mereka dapat melakukan update dan hanya file json statis itu yang akan dibuat ulang dan diterapkan ke CDN. Kemudian Anda bisa meregenerasi seluruh situs mungkin sekali sehari sebagai proses malam. Konten statis seo mungkin bukan yang terbaru sepanjang hari, tetapi saya tidak melihatnya sebagai masalah besar. Ini hanya akan diperbarui selama proses malam hari.

@robertschneiderman kami telah mengalami masalah memori juga. Kami mendekati 1500 halaman, tetapi jumlah gambar yang tidak masuk akal (blog desain). Kami telah menonaktifkan peta sumber, dan menghentikan build dari mendownload file gambar, tetapi pada akhirnya harus mengedit perintah build untuk meningkatkan memori yang dialokasikan ke instance node. melalui bendera --max_old_space_size .

Satu hal yang membuat saya khawatir tentang fitur ini adalah pembuatan skema. Jika kami tidak memiliki semua pos yang tersedia untuk gatsby untuk membuat skema, kueri kami akan memunculkan kesalahan. Akan sangat bagus jika ada cara untuk meneruskan skema ke gatsby, atau setidaknya menyediakan entitas dummy selama pembuatan untuk mendemonstrasikan berbagai bentuk yang mungkin mereka ambil.

Saya sedang mempertimbangkan menggunakan Gatsby untuk membangun UI untuk situs konten dengan lebih dari 5000 item, sebagian besar dengan hubungan yang saling berhubungan satu sama lain. Data tersebut akan berasal dari CMS berbasis database.

Manfaat menggunakan Gatsby daripada situs React yang digerakkan oleh API standar adalah saya akan menghabiskan sebagian kecil waktu untuk membangun dan memelihara API data dan sistem manajemen negara yang memuat data jarak jauh dan menyimpannya. (Karena saya berencana menerapkan aplikasi ini untuk beberapa situs dengan ukuran yang sama, sepertinya ini adalah manfaat yang sangat berharga.)

Kelemahan menggunakan Gatsby dalam hal ini adalah fakta bahwa seluruh situs perlu dibangun kembali bahkan untuk pembaruan konten yang paling tidak signifikan. Lupa menambahkan koma? Bangun kembali 5000 halaman! Siapa yang tahu berapa lama waktu yang dibutuhkan? Ini bahkan lebih menjadi masalah ketika mempertimbangkan pengalaman pengguna CMS - mereka terbiasa melihat perubahan muncul di situs segera setelah mereka menyimpannya. Dengan Gatsby, kami menunggu beberapa menit (setidaknya) sebelum perubahan muncul.

Jika ada cara untuk memicu build untuk subset halaman, itu akan membuat Gatsby menjadi pilihan yang jelas dan pasti. Namun, pada saat ini, penjualannya sulit.

BTW, saya telah banyak bekerja untuk meningkatkan kecepatan untuk pembuatan situs yang lebih besar untuk v2. Pada versi beta v2 terbaru - Anda mungkin dapat membuat 5.000 halaman dalam <1:30. Akan ada lebih banyak peningkatan kecepatan.

Itu @kamnews yang luar biasa! Saya sangat menantikannya! Beri tahu saya jika Anda ingin menguji blog dengan gambar yang berat

@KAMews 5K bagus tapi kita butuh 1 juta 😉

Jika kita ingin mengkompilasi bagian dari situs secara terpisah, kita dapat mengatur flag pada build sehingga gatsby-node hanya tahu untuk menghasilkan bagian dari situs yang ditentukan. Kami kemudian dapat menambahkan kembali file statis yang dibuat sebelumnya . Ini berfungsi untuk kami selama kami menautkan ke file yang dibuat sebelumnya dengan <a href> sebagai lawan dari <Link to > .

Saya bertanya-tanya apakah kita dapat membuat <Link to> berfungsi saat menautkan ke file yang dibuat sebelumnya jika kita menggabungkan beberapa dari data.json pada waktu pembuatan. Melihatnya lebih dalam saat ini.

Saya tidak khawatir dengan waktu pembuatan tetapi lebih dengan volume file statis yang perlu saya unggah untuk pembaruan apa pun, kami meluncurkan portofolio visual besar dengan Gatsby dan situs statis yang akan diunggah berukuran lebih dari 150 MB
Kebanyakan gambar.
Ini membuat situs tidak tersedia sekitar 40 menit selama pembaruan
Ketersediaan untuk membangun kembali sebagian dari situs ini jelas merupakan fitur yang akan meningkatkan Gatsby.
Saya berencana menggunakan Gatsby untuk situs baru tetapi saya akan membagi situs menjadi bagian statis dan dinamis menggunakan CMS php tradisional untuk bagian berita.

@rbmedia Anda mungkin ingin mempertimbangkan host yang melakukan pengalihan penerapan seperti Netlify sehingga situs Anda saat ini tetap berjalan hingga versi baru Anda siap.

Terima kasih Matt, saya akan mempertimbangkannya!
Saya pernah membuat beberapa situs Berita dengan Drupal di masa lalu, pembaruan apa pun harus online dalam waktu singkat (kurang dari 2 menit). Saya ingin sekali menggunakan Gatsby di masa mendatang untuk situs semacam ini.

Ada berita tentang masalah ini? Kami merencanakan situs dengan sekitar 100 ribu halaman dan peningkatan bertahap akan sangat mengagumkan.

jadikan jalur lain sebagai folder halaman statis default, bukan '/ publik'.
Setelah menjalankan gatsby build, salin ../public/* ke jalur default.

Hai!

Masalah ini telah menjadi sunyi. Diam seram. 👻

Kami mendapatkan banyak masalah, jadi saat ini kami menutup masalah setelah 30 hari tidak aktif. Sudah setidaknya 20 hari sejak pembaruan terakhir di sini.

Jika kami melewatkan masalah ini atau jika Anda ingin tetap membukanya, balas di sini. Anda juga dapat menambahkan label "tidak basi" agar masalah ini tetap terbuka!

Terima kasih telah menjadi bagian dari komunitas Gatsby! 💪💜

Saya masih tidak berpikir ini diperbaiki / didukung di Gatsby. Ada berita @ TeamGatsby?

ini adalah masalah yang sudah berlangsung lama karena sangat sulit untuk diperbaiki tanpa terlalu memikirkannya. @Moocar memiliki masalah yang terbuka untuk setidaknya membawa kami selangkah ke arah yang benar.

Apakah Gatsby saat ini melacak node GraphQL mana yang diambil pada halaman tertentu? Jika demikian, tampaknya layak untuk menambahkan pembangunan kembali bertahap berdasarkan perubahan pada data. Itu setengah dari pekerjaan, bukan?

Bagian lain dari pekerjaan adalah menyediakan plugin sumber dengan cache dan mendorong pengembang plugin untuk hanya mengambil data yang diubah jika memungkinkan. Dalam banyak kasus, ini sepele.

@coreyward Ya, Gatsby melacak setiap node yang dikembalikan untuk sebuah kueri (melalui page-dependency-resolver.js ). Inilah yang menggerakkan kemampuan gatsby develop untuk hanya menjalankan kembali kueri untuk data yang diubah. Kami saat ini tidak menyimpan informasi itu ke disk jadi belum digunakan untuk gatsby build tapi itu jelas rencananya.

Saya tahu bahwa bagi tim kami, ini akan menjadi keputusan go / no-go untuk tidak menggunakan Gatsby untuk pembangunan kembali situs andalan kami tahun 2019. Saya benar-benar berharap ini bisa dirilis atau setidaknya berada di cakrawala saat kita mulai membangun. Kami mendukung ratusan penulis web yang mengedit berbagai bagian situs sepanjang hari kerja. Ketika mereka menekan simpan, mereka sangat mengharapkan konten diperbarui. Tidak jarang mereka kembali hanya untuk memperbaiki koma atau mengubah tanggal posting.

@mattbloomfield kami memiliki lebih banyak pelanggan yang tertarik dengan ini jadi kami menempatkan ini pada daftar prioritas.

kami mengimplementasikan gatsby dengan backend drupal 8 menggunakan plugin gatsby-source-graphql, dan kinerja sejauh ini tidak menjadi masalah, dengan ~ 4000 halaman dibuat dalam <30 detik. kami menarik semua data dalam gatsby-node sebagai lawan menjalankan ribuan StaticQuerys, dan melewati pemrosesan gambar untuk saat ini.

``
sukses menjalankan kueri graphql - 3.088 s - 4008/4008 1311.56 kueri / detik
sukses menulis data halaman - 0,070 s
sukses menulis data pengalihan - 0,001 s
sukses Membangun manifes dan ikon terkait - 0,117 d
sukses diPostBootstrap - 0,127 dtk

Info bootstrap selesai - 15.751 dtk

sukses Membangun produksi bundel JavaScript dan CSS - 3.361 d
sukses Membangun HTML statis untuk halaman - 6.906 s - 4006/4006 609.25 halaman / detik
info Selesai membangun dalam 26,047 dtk

Saat ini saya mengevaluasi menggunakan Gatsby untuk mempercepat situs Rails 3.x lama yang dihosting Heroku yang lambat seperti molase. Ini memiliki sekitar 1 juta halaman sehingga build inkremental adalah satu-satunya cara kerjanya. Sebagian besar halaman tidak berubah sehingga membuatnya statis terasa seperti kemenangan besar, tetapi halaman baru terus ditambahkan dan beberapa halaman lama diedit. Pengguna berharap untuk melihat perubahan dalam beberapa detik. Harapan saya adalah menambahkan kode yang cukup ke aplikasi Rails untuk menjadikannya server API JSON, dan menghasilkan frontend baru dengan Gatsby, dengan aset statis yang dihosting di suatu tempat seperti Netlify atau S3.

Saya berpikir saya akan dapat melakukan sesuatu seperti menjalankan Gatsby build tambahan melalui pekerja antrian pekerjaan. Server API Rails tahu kapan halaman diperbarui, sehingga akan membuat 'tugas halaman pembaruan' menggunakan page_id (kunci di postgres DB), dan pekerja akan meneruskannya ke Gatsby dengan var ENV dengan sesuatu seperti PAGE_ID=1235 gatsby build . Saya akan menggunakan var ENV itu di dalam createPages () untuk mencari apa yang dibutuhkan untuk satu halaman itu dan membangunnya. File keluaran yang dihasilkan akan ditransfer ke host statis (saya berharap ada pengait untuk itu). Jika tidak ada var PAGE_ID yang disetel, itu akan membuat semua halaman seperti biasa.

Jika halaman dihapus, Rails API akan membuat pekerjaan yang menghapus aset langsung dari host statis, atau mungkin ada sesuatu yang diperlukan dari Gatsby jadi saya masih akan menjalankannya dengan variabel ENV yang berbeda. (Saya pikir saya membutuhkan jalur halaman minimal).

Apakah saya menggonggong pohon yang salah dengan berpikir bahwa Gatsby kompatibel dengan proyek semacam ini? Terima kasih atas bantuannya.

Kami memiliki versi alfa. Ini belum membangun bertahap tapi setidaknya jalan ke depan.
Anda dapat menggunakannya dengan menginstal npm install --save gatsby@per-page-manifest

Info lebih lanjut:
https://github.com/gatsbyjs/gatsby/pull/13004

@mpoisot untuk saat ini per bangunan halaman belum berfungsi. Saya tidak yakin jangka waktu apa yang Anda lihat untuk proyek ini. Jika kuerinya ringan, gatsby mungkin cocok untuk situs Anda bahkan tanpa build tambahan.

cc @KyleAMews @Moocar untuk memberikan penjelasan yang lebih baik tentang ini.

Mem-ping ini, karena sudah beberapa bulan sejak pembaruan terakhir dan tampaknya menjadi tempat tindakan. Saya melihat bahwa penguraian halaman-data.json telah masuk, dan saya telah menggunakannya.

Apakah ada persyaratan dan tugas yang lebih konkret untuk mendorong hal ini ke depan? Saya mengerti bahwa ini masalah besar, tetapi selalu membantu jika dipecah menjadi masalah kecil yang dapat menunjukkan kemajuan dan daya tarik.

@wardpeet @Moocar Saya tidak yakin siapa orang / daftar yang paling tepat untuk melakukan ping tentang ini, tetapi saya melihat Anda berdua sebagai yang terakhir aktif dari proyek di sini. Adakah pembaruan untuk tujuan utama tiket ini?

Berbincang - @KyleAMews tentang incremental build dan cara pengirimannya https://twitter.com/dominicfallows/status/1169152367964643328?s=19

Berbincang - @KyleAMews tentang incremental build dan cara pengirimannya https://twitter.com/dominicfallows/status/1169152367964643328?s=19

TLDR;

@KyleAMews mengonfirmasi bahwa Gatsby sedang mengerjakan fitur build inkremental yang dihosting Gastsby Cloud.

Versi "Gatsby Enterprise" yang dihosting sendiri / di tempat, dengan build tambahan, dimungkinkan, tetapi mereka belum mengerjakannya ....

Dominic Fallows - 4 Sep - Sebagian besar vendor yang kami pilih menawarkan opsi swakelola / di lokasi, seperti yang dilakukan Gatsby OSS. Kami dengan senang hati membayarnya, seperti yang kami lakukan pada solusi Gatsby Enterprise Cloud lokal dari Anda.

Kyle Mathews - 4 Sep - ya pasti - kami memiliki jalur yang cukup jelas untuk mendukung versi onprem dari apa yang kami lakukan - semuanya adalah Kubernetes jadi seharusnya mungkin - tetapi onprem menambahkan banyak overhead ketika kami awalnya hanya bekerja tentang pengiriman sesuatu yang berhasil 😅

Dominic Fallows - 4 Sep - Nah, itu berita bagus untuk didengar! Maaf jika saya melewatkan yang dibahas di tempat lain, tetapi peta jalan onprem itu akan sangat berguna untuk bisnis dan pengembang untuk dilihat.

Kyle Mathews - 4 Sep - Itu cukup jauh sekarang sehingga saya tidak bisa memberikan garis waktu. Jelas bukan tahun ini dan juga tidak ingin berjanji tahun depan. Tergantung pada seberapa cepat kami dapat meningkatkan pendapatan dan tim teknik kami

Sayang sekali karena memblokir menggunakan Gatsby sebagai alat untuk penerbit tempat kami berbicara tentang jutaan halaman kanonis dan yang sama atau halaman pengindeksan.

Tidakkah masuk akal untuk "mengeluarkan" kasus penggunaan tersebut sebagai proyek terpisah menggunakan konsep / inti yang sama?

Buat atau hancurkan fitur untuk keputusan tahun 2020. Tampaknya menjadi tempat yang baik untuk menginvestasikan semua uang VC itu 😀

Gatsby melakukan banyak hal dengan benar, tetapi waktu pembuatan yang lama membuatnya benar-benar tidak dapat digunakan dalam proyek yang lebih besar: / Kami membahas perpindahan dari kerangka kerja minggu ini hanya karena itu.
Tolong percepat pembangunan!

Setuju dengan yang di atas! Gatsby dapat menjadi solusi blogging yang cepat dan mudah atau mengimplementasikan build tambahan / lebih cepat dan siap untuk perusahaan.

Tepat sekali; menabrak ini berulang kali pada proyek yang lebih besar. Tanpa build tambahan, Gatsby bukanlah pilihan.

Build inkremental di Gatsby Cloud memperbaiki masalah ini. Anda dapat mendaftar untuk beta pribadi di sini https://www.gatsbyjs.com/builds-beta/

Tidak ada tentang itu yang tampaknya menyarankan itu mendukung build tambahan - hanya saja ia memiliki "waktu pembuatan tercepat untuk situs Gatsby".

Saya khawatir tentang implikasi bahwa build inkremental hanya akan tersedia pada layanan Gatsby yang dihosting daripada tersedia untuk digunakan secara mandiri.

Saya mengerti maksud Anda @dwightwatson tidak ada di situs web yang mengatakan itu "tambahan". Di Gatsby Days London, mereka mendemonstrasikan bangunan dan itu jelas merupakan bangunan tambahan. Tidak yakin bagaimana itu dilakukan dan apakah itu akan menjadi bagian dari paket Gatsby atau apakah itu hanya akan menjadi layanan yang mereka sediakan.

Bagaimanapun juga, investor harus mendapatkan uang mereka kembali. 🙄

mencoba membangun situs web yang sangat besar 140k + halaman

gatsby build agak bagus… tetapi melakukan penerapan itu menyakitkan (zeit.co)

Tidak yakin bagaimana cara menambahkan label ke ini, tapi saya menganggap ini masih menjadi masalah.

@gomflo adakah cara saya dapat membangun situs Anda? Mungkin ada beberapa buah gantung rendah yang harus diselesaikan untuk meningkatkan waktu pembangunan :) Tidak ada janji.

Tidak ada tentang itu yang tampaknya menyarankan itu mendukung build tambahan - hanya saja ia memiliki "waktu pembuatan tercepat untuk situs Gatsby".

Saya khawatir tentang implikasi bahwa build inkremental hanya akan tersedia pada layanan Gatsby yang dihosting daripada tersedia untuk digunakan secara mandiri.

ulang ini ^: Jika repo gatsby saya ada di gitlab dan bukan github, apakah saya dapat menggunakan fitur gatsby cloud / build?

Saya mungkin telah menyebutkannya sebelumnya, tetapi menyangkut masalah / fitur asli. Untuk penerbit, Gatsby akan masuk akal jika kami dapat memicu satu-satunya pembuatan halaman baru dan mungkin memperbarui ke indeks. Hampir tidak ada penerbit yang peduli tentang memperbarui halaman kanonis lama.

Jadi, apakah kami akan memiliki pembaruan parsial yang berdiri sendiri atau tidak ada peluang? Mungkin ada cara lain untuk memperbarui hanya beberapa halaman dan tidak membangun kembali keseluruhan proyek?

Hanya ingin memperbarui bahwa tim saya akan segera menerbitkan PR ke dalam repo Gatsby yang menurut kami memungkinkan pembuatan tambahan. Kami hanya meluangkan waktu untuk menulis PR yang baik dan memperketat kodenya, tetapi saya akan memperbarui di sini ketika kami selesai (dalam minggu depan atau lebih).

Hanya ingin memperbarui bahwa tim saya akan segera menerbitkan PR ke dalam repo Gatsby yang menurut kami memungkinkan pembuatan tambahan. Kami hanya meluangkan waktu untuk menulis PR yang baik dan memperketat kodenya, tetapi saya akan memperbarui di sini ketika kami selesai (dalam minggu depan atau lebih).

Berikut PR https://github.com/gatsbyjs/gatsby/pull/20785

Pembaruan lebih lanjut untuk PR: https://github.com/gatsbyjs/gatsby/pull/20785#issuecomment -579355927

PR baru, dengan fokus pada perubahan data tambahan https://github.com/gatsbyjs/gatsby/pull/21523

Dengan # 21523 yang digabungkan dan Build Inkremental tersedia di Gatsby Cloud, saya yakin masalah ini telah teratasi. Itu tidak mendukung semua alur kerja, tetapi saya akan menutup ini untuk saat ini dan mungkin lebih baik untuk membuka masalah baru di masa depan untuk usaha di masa depan jika perlu.

Haruskah itu benar-benar ditutup? Pengoptimalan hanya itu - pengoptimalan. Itu bukanlah build yang benar-benar inkremental. Selain itu, apa pun yang tersedia melalui Gatsby Cloud tidak tersedia melalui penggunaan paket publik. Untuk maksud khusus dari tiket ini, tidak ada yang diselesaikan.

Haruskah itu benar-benar ditutup?

Berdasarkan https://github.com/gatsbyjs/gatsby/issues/5496#issuecomment -641005662, menurut saya masalah ini tidak harus ditutup, dan saya tidak mengerti mengapa label not stale dihapus .

Adakah orang di sini yang mencoba, atau mengetahui apakah mungkin, untuk mengubah konfigurasi webpack GatsbyJS untuk secara bersamaan menghasilkan baik pratinjau pengembangan maupun versi build produksi dengan "gatsby develop"? (Kemungkinan menghasilkan "build tambahan" dengan biaya server pengembangan yang dijalankan selamanya.)