Statik Pertama: Laman Jamstack Pra-Dihasilkan dengan Rendering Tanpa Pelayan sebagai sandaran

Senibina Jamstack semakin meningkat dan ia memberikan kaedah yang cekap untuk membina sebuah laman web.

Salah satu prinsip teras Jamstack adalah pra-penanaman. Ini bermakna menghasilkan satu siri sumber statik terlebih dahulu untuk membolehkan perkhidmatan pelawat dari CDN atau persekitaran hosting statik yang dioptimumkan pada kelajuan terpantas dan overhead terendah.

Tetapi jika kita pra-menghasilkan laman web terlebih dahulu, bagaimanakah kita dapat membuat mereka kelihatan lebih dinamik? Bagaimana untuk membina laman web yang memerlukan perubahan yang kerap? Bagaimana cara mengendalikan kandungan yang dihasilkan oleh pengguna?

Malah, ini adalah senario aplikasi yang ideal untuk fungsi tanpa pelayan. Jamstack dan Serverless adalah rakan kongsi terbaik, mereka saling melengkapi dengan sempurna.

Artikel ini akan meneroka corak: Di laman web yang terdiri hampir seluruh kandungan yang dihasilkan oleh pengguna, menggunakan fungsi tanpa pelayan sebagai penyelesaian sandaran untuk halaman yang telah dijana. Kami akan menggunakan teknik penghalaan URL yang optimis di mana halaman 404 adalah fungsi tanpa pelayan untuk menambah penambahan tanpa pelayan.

Kedengarannya rumit? Mungkin. Tetapi adakah ia berfungsi? Benar -benar berkesan!

Anda boleh mencuba laman web demo untuk mengetahui tentang kes penggunaan ini. Walau bagaimanapun, sila cuba selepas membaca artikel ini.

Anda kembali? Hebat, mari kita menyelam ke dalamnya.

Falsafah laman web sampel ini adalah: membolehkan anda membuat mesej hangat dan mesej galakan maya untuk dihantar kepada rakan -rakan. Anda boleh menulis mesej, menyesuaikan lollipop (atau popsicle, untuk rakan -rakan Amerika saya) dan dapatkan URL untuk berkongsi dengan penerima anda. Itu sahaja, anda telah menerangi hari mereka. Apa yang lebih baik daripada ini?

Secara tradisinya, kami akan menggunakan beberapa skrip sisi pelayan untuk memproses penyerahan borang, menambah lollipop baru (kandungan yang dihasilkan oleh pengguna kami) ke pangkalan data dan menghasilkan URL yang unik. Kami kemudian menggunakan lebih banyak logik sisi pelayan untuk menghuraikan permintaan ke halaman ini, menanyakan pangkalan data untuk mendapatkan data yang diperlukan untuk mengisi paparan halaman, memberikan templat yang sesuai, dan mengembalikannya kepada pengguna.

Ini kelihatan munasabah.

Tetapi berapa kos untuk berkembang?

Arkitek teknikal dan penyelia teknikal sering menghadapi masalah ini ketika menilai skop sesuatu projek. Mereka perlu merancang, membayar dan memperuntukkan sumber yang cukup untuk mengatasi situasi yang berjaya.

Laman web lollipop maya ini bukan hiasan biasa. Oleh kerana kita semua mahu menghantar mesej positif yang lain, laman web ini akan menjadikan saya seorang jutawan! Apabila berita menyebar, tahap lalu lintas akan melambung. Saya lebih baik mempunyai strategi yang baik untuk memastikan pelayan dapat mengendalikan beban berat. Saya mungkin menambah beberapa tier cache, beberapa pengimbang beban, dan saya akan merekabentuk pelayan pangkalan data dan pangkalan data saya supaya saya dapat berkongsi beban tanpa dibanjiri oleh keperluan untuk membuat dan menyediakan semua lollipop ini.

Tetapi ... Saya tidak tahu bagaimana melakukan perkara -perkara ini.

Dan saya tidak tahu berapa banyak kos untuk menambah infrastruktur ini dan memastikan mereka berjalan. Ini rumit.

Itulah sebabnya saya suka mempermudahkan hosting saya sebanyak mungkin dengan pra-rendering.

Menyediakan halaman statik adalah lebih mudah dan lebih murah daripada menyediakan halaman secara dinamik dari pelayan web yang memerlukan beberapa logik untuk menghasilkan pandangan untuk setiap pelawat atas permintaan.

Oleh kerana kami sedang mengusahakan banyak kandungan yang dihasilkan oleh pengguna, masih masuk akal untuk menggunakan pangkalan data, tetapi saya tidak akan menguruskannya sendiri. Sebaliknya, saya akan memilih salah satu daripada banyak pilihan pangkalan data yang boleh digunakan sebagai perkhidmatan. Saya akan berinteraksi dengannya melalui APInya.

Saya mungkin memilih Firebase, MongoDB, atau mana -mana lagi pangkalan data. Chris menyusun beberapa sumber ini di laman web yang hebat mengenai sumber tanpa pelayan, yang patut diterokai.

Dalam kes ini, saya memilih Fauna sebagai datastore saya. Fauna menyediakan API yang hebat untuk menyimpan dan menanyakan data. Ia adalah kedai data gaya bukan SQL, dan ia adalah apa yang saya perlukan.

Secara kritis, Fauna telah menjadikannya perniagaan lengkap untuk menyediakan perkhidmatan pangkalan data. Mereka mempunyai pengetahuan domain yang mendalam yang tidak akan saya miliki. Dengan menggunakan pembekal pangkalan data-sebagai-perkhidmatan seperti ini, saya mewarisi pasukan perkhidmatan data pakar untuk projek saya , termasuk infrastruktur ketersediaan, keupayaan dan keselamatan pematuhan yang tinggi, jurutera sokongan mahir, dan dokumentasi yang luas.

Daripada melakukannya sendiri, gunakan perkhidmatan pihak ketiga seperti itu, yang merupakan kekuatannya.

Senibina TL; DR

Apabila berurusan dengan bukti konsep, saya sering mendapati diri saya merenung beberapa aliran logik. Inilah coretan yang saya buat untuk laman web ini:

Dan beberapa penjelasan:

1. Pengguna membuat lollipop baru dengan mengisi borang HTML biasa.
2. Kandungan baru disimpan dalam pangkalan data, dan penyerahannya mencetuskan penjanaan dan penempatan tapak baru.
3. Sebaik sahaja laman web ini digunakan, Lollipop baru akan dapat diakses melalui URL yang unik. Ia akan menjadi halaman statik yang cepat dihidangkan dari CDN tanpa bergantung pada pertanyaan pangkalan data atau pelayan.
4. Tiada lollipop baru boleh diakses sebagai halaman statik sehingga penjanaan tapak selesai. Permintaan yang tidak berjaya ke halaman Lollipop akan kembali ke halaman yang secara dinamik menjana halaman Lollipop melalui API Database Query Dynamic.

Pendekatan ini mula-mula menganggap sumber statik/pra-dihasilkan dan kemudian kembali kepada rendering dinamik apabila pandangan statik tidak tersedia, yang dipanggil "statik pertama", seperti yang diterangkan oleh Markus Schork Unilever, yang saya suka pernyataan itu.

Penerangan yang lebih terperinci

Anda boleh menggali terus ke dalam kod laman web (sumber terbuka dan anda boleh meneroka seberapa banyak yang anda suka), atau kami boleh membincangkannya lagi.

Adakah anda ingin menggali lebih mendalam dan meneroka pelaksanaan contoh ini? Ok, saya akan menerangkan dengan lebih terperinci:

• Dapatkan data dari pangkalan data untuk menjana setiap halaman
• Terbitkan data ke API pangkalan data menggunakan fungsi tanpa pelayan
• Mencetuskan penjanaan semula tapak lengkap
• Membuat permintaan apabila halaman belum dijana

Menjana halaman dari pangkalan data

Kemudian, kita akan membincangkan cara menerbitkan data ke pangkalan data, tetapi pertama, mari kita anggap ada beberapa penyertaan dalam pangkalan data. Kami akan menjana laman web yang mengandungi halaman untuk setiap entri.

Penjana laman web statik sangat baik dalam hal ini. Mereka memproses data, memohon kepada templat, dan output fail HTML yang sedia untuk disajikan. Kita boleh menggunakan mana -mana penjana untuk contoh ini. Saya memilih sebelas kerana ia agak mudah dan generasi tapak pantas.

Untuk menyediakan sebelas dengan beberapa data, kami mempunyai banyak pilihan. Salah satu cara ialah menyediakan beberapa JavaScript yang mengembalikan data berstruktur. Ini bagus untuk menanyakan API pangkalan data.

Fail data sebanyak sebelas kami akan kelihatan seperti ini:

 <code>// 设置与Fauna 数据库的连接。 // 使用环境变量进行身份验证// 并访问数据库。 const faunadb = require('faunadb'); const q = faunadb.query; const client = new faunadb.Client({ secret: process.env.FAUNADB_SERVER_SECRET }); module.exports = () => { return new Promise((resolve, reject) => { // 获取最新的100,000 个条目（为了我们的示例） client.query( q.Paginate(q.Match(q.Ref("indexes/all_lollies")),{size:100000}) ).then((response) => { // 获取每个条目的所有数据const lollies = response.data; const getAllDataQuery = lollies.map((ref) => { return q.Get(ref); }); return client.query(getAllDataQuery).then((ret) => { // 将数据发送回Eleventy 以用于站点构建resolve(ret); }); }).catch((error) => { console.log("error", error); reject(error); }); }) }</code>

Saya menamakan fail ini lollies.js dan ia akan membuat semua data yang dikembalikan tersedia untuk sebelas dalam koleksi bernama Lollies.

Kami kini boleh menggunakan data itu dalam templat kami. Jika anda ingin melihat kod yang mengambil data itu dan menghasilkan halaman untuk setiap projek, anda boleh melihatnya dalam repositori kod.

Hantar dan simpan data tanpa pelayan

Apabila kami membuat halaman Lollipop baru, kami perlu menangkap kandungan pengguna ke dalam pangkalan data supaya kami dapat menggunakannya untuk mengisi halaman URL yang diberikan pada masa akan datang. Untuk melakukan ini, kami menggunakan borang HTML tradisional untuk menerbitkan data kepada pengendali bentuk yang sesuai.

Bentuknya kelihatan seperti ini (atau lihat kod penuh dalam repositori):

<code></code>

Penerima mengatakan sesuatu yang baik Pengirim tidak mempunyai pelayan web dalam skim hosting kami, jadi kami perlu merancang tempat untuk mengendalikan permintaan siaran HTTP yang dikemukakan dari borang ini. Ini adalah kes penggunaan yang sempurna untuk fungsi tanpa pelayan. Saya menggunakan fungsi Netlify untuk ini. Anda boleh menggunakan AWS Lambda, Google Cloud, atau fungsi Azure jika anda lebih suka, tetapi saya suka kesederhanaan aliran kerja Netlify Fungsi, dan fakta bahawa ia menyimpan API tanpa pelayan saya dan UI saya dalam repositori kod yang sama.

Ia adalah kebiasaan yang baik untuk mengelakkan butiran pelaksanaan backend yang bocor ke frontend. Pemisahan yang jelas membantu menjadikan perkara lebih mudah untuk transplantasi dan kemas. Semak sifat tindakan elemen borang di atas. Ia menerbitkan data ke jalan yang dipanggil /baru di laman web saya, yang tidak benar -benar membayangkan perkhidmatan yang akan berkomunikasi dengannya.

Kami boleh mengarahkannya ke mana -mana perkhidmatan yang kami suka menggunakan pengalihan. Saya menghantarnya ke fungsi tanpa pelayan yang saya akan mengkonfigurasi dalam projek ini, tetapi ia boleh disesuaikan dengan mudah untuk menghantar data di tempat lain jika kita mahu. Netlify menyediakan kami dengan enjin pengalihan yang mudah dan sangat dioptimumkan yang mengarahkan trafik kami di peringkat CDN supaya pengguna dapat mengarah ke lokasi yang tepat dengan cepat.

Peraturan redirect berikut (terletak di fail netlify.toml projek saya) proksi Permintaan untuk /baru ke fungsi tanpa pelayan yang dipanggil newlolly.js yang dihoskan oleh fungsi Netlify.

 <code># 将“new”URL 解析为函数[[redirects]] from = "/new" to = "/.netlify/functions/newLolly" status = 200</code>

Mari lihat fungsi tanpa pelayan itu:

• Simpan data baru ke dalam pangkalan data,
• Buat URL baru untuk halaman baru dan
• Pengganti semula pengguna ke halaman yang baru dibuat supaya mereka dapat melihat hasilnya.

Pertama, kita akan memerlukan pelbagai utiliti untuk menghuraikan data borang, menyambung ke pangkalan data Fauna dan membuat ID pendek dan mudah dibaca untuk Lollipop baru.

 <code>const faunadb = require('faunadb'); // 用于访问FaunaDB const shortid = require('shortid'); // 生成短唯一URL const querystring = require('querystring'); // 帮助我们解析表单数据// 首先，我们使用我们的数据库设置一个新的连接。 // 环境变量帮助我们安全地连接// 到正确的数据库。 const q = faunadb.query const client = new faunadb.Client({ secret: process.env.FAUNADB_SERVER_SECRET })</code>

Sekarang, kami akan menambah beberapa kod kepada permintaan untuk mengendalikan fungsi tanpa pelayan. Fungsi pengendali akan menghuraikan permintaan untuk mendapatkan data yang diperlukan dari penyerahan borang, kemudian menghasilkan ID unik untuk lollipop baru, dan kemudian membuatnya ke dalam pangkalan data sebagai rekod baru.

 <code>// 处理对无服务器函数的请求exports.handler = (event, context, callback) => { // 获取表单数据const data = querystring.parse(event.body); // 添加一个唯一的路径ID。并记下它- 我们稍后会将用户发送到它const uniquePath = shortid.generate(); data.lollyPath = uniquePath; // 组装准备发送到数据库的数据const lolly = { data: data }; // 在fauna db 中创建棒棒糖条目client.query(q.Create(q.Ref('classes/lollies'), lolly)) .then((response) => { // 成功！将用户重定向到此新棒棒糖页面的唯一URL return callback(null, { statusCode: 302, headers: { Location: `/lolly/${uniquePath}`, } }); }).catch((error) => { console.log('error', error); // 错误！返回带有statusCode 400 的错误return callback(null, { statusCode: 400, body: JSON.stringify(error) }); }); }</code>

Mari kita periksa kemajuan kita. Kami mempunyai cara untuk membuat halaman Lollipop baru dalam pangkalan data. Kami juga mempunyai binaan automatik yang menghasilkan halaman untuk setiap lollipop kami.

Untuk memastikan bahawa terdapat satu set lengkap halaman yang telah dijana untuk setiap lollipop, kita harus mencetuskan membina semula setiap kali entri baru berjaya ditambah ke pangkalan data. Ini sangat mudah dilakukan. Terima kasih kepada penjana laman web statik kami, binaan kami telah automatik. Kami hanya memerlukan satu cara untuk mencetuskannya. Dengan Netlify, kita boleh menentukan bilangan cangkuk membina. Mereka adalah webhooks dan jika mereka menerima permintaan pos HTTP, mereka akan membina semula dan menggunakan laman web kami. Ini adalah yang saya buat dalam konsol pengurusan tapak Netlify:

Untuk menjana semula laman web ini, termasuk halaman setiap lollipop yang direkodkan dalam pangkalan data, kami boleh mengeluarkan permintaan pos HTTP ke cangkuk membina ini dengan segera selepas menyimpan data baru ke pangkalan data.

Inilah kod yang melakukan ini:

 <code>const axios = require('axios'); // 简化发出HTTP POST 请求// 触发新的构建以永久冻结此棒棒糖axios.post('https://api.netlify.com/build_hooks/5d46fa20da4a1b70XXXXXXXXX') .then(function (response) { // 在无服务器函数的日志中报告console.log(response); }) .catch(function (error) { // 描述无服务器函数日志中的任何错误console.log(error); });</code>

Anda dapat melihatnya dalam kod penuh, yang telah ditambah kepada pengendali yang berjaya untuk penyisipan pangkalan data.

Ini semua baik jika kita sanggup menunggu binaan dan penempatan selesai sebelum kita berkongsi URL lollipop baru dengan penerima. Tetapi kami tidak sabar dan kami segera ingin berkongsi apabila kami mendapat URL baru untuk lollipop yang baru saja kami buat.

Malangnya, jika kami mengakses URL sebelum tapak melengkapkan penjanaan semula untuk memasukkan halaman baru, kami akan mendapat 404. Tetapi ia adalah keseronokan untuk mengambil kesempatan daripada 404 ini.

Routing URL Optimis dan senario back-up tanpa pelayan

Menggunakan penghalaan 404 adat, kami mempunyai pilihan untuk menghantar setiap permintaan gagal ke halaman Lollipop ke halaman yang boleh terus mencari data lollipop dalam pangkalan data. Kita boleh melakukan ini dalam klien JavaScript jika kita mahu, tetapi cara yang lebih baik adalah secara dinamik menghasilkan halaman yang sedia untuk dilihat dari fungsi tanpa pelayan.

Kaedahnya adalah seperti berikut:

Pertama, kita perlu memberitahu semua permintaan yang ingin mengakses halaman Lollipop (permintaan ini kembali kosong) untuk pergi ke fungsi tanpa pelayan kami. Kami melakukan ini dengan menambahkan peraturan lain ke konfigurasi redirect Netlify:

 <code># 未找到的棒棒糖应该直接代理到API [[redirects]] from = "/lolly/*" to = "/.netlify/functions/showLolly?id=:splat" status = 302</code>

Peraturan ini hanya digunakan jika permintaan untuk halaman Lollipop tidak menemui halaman statik yang sedia untuk disampaikan. Ia mewujudkan redirect sementara (HTTP 302) ke fungsi tanpa pelayan kami, yang kelihatan seperti ini:

 <code>const faunadb = require('faunadb'); // 用于访问FaunaDB const pageTemplate = require('./lollyTemplate.js'); // JS 模板文字// 设置和授权Fauna DB 客户端const q = faunadb.query; const client = new faunadb.Client({ secret: process.env.FAUNADB_SERVER_SECRET }); exports.handler = (event, context, callback) => { // 从请求中获取棒棒糖ID const path = event.queryStringParameters.id.replace("/", ""); // 在DB 中查找棒棒糖数据client.query( q.Get(q.Match(q.Index("lolly_by_path"), path)) ).then((response) => { // 如果找到，则返回视图return callback(null, { statusCode: 200, body: pageTemplate(response.data) }); }).catch((error) => { // 未找到或发生错误，将悲伤的用户发送到通用错误页面console.log('Error:', error); return callback(null, { body: JSON.stringify(error), statusCode: 301, headers: { Location: `/melted/index.html`, } }); }); }</code>

Jika permintaan untuk mana -mana halaman lain (tidak di dalam / lolly / laluan tapak) mengembalikan 404, kami tidak akan menghantar permintaan itu ke fungsi tanpa pelayan kami untuk memeriksa lollipops. Kami boleh menghantar pengguna terus ke halaman 404. Konfigurasi Netlify.toml kami membolehkan kami menentukan bilangan 404 tahap penghalaan dengan menambahkan lebih banyak peraturan sandaran ke fail. Perlawanan pertama yang berjaya dalam fail akan diterima pakai.

 <code># 未找到的棒棒糖应该直接代理到API [[redirects]] from = "/lolly/*" to = "/.netlify/functions/showLolly?id=:splat" status = 302 # 真正的404 可以直接转到这里： [[redirects]] from = "/*" to = "/melted/index.html" status = 404</code>

Kami sudah selesai! Kami kini mempunyai laman "statik pertama" yang akan cuba menjadikan kandungan secara dinamik menggunakan fungsi tanpa pelayan jika URL belum dijana dengan fail statik.

Sangat pantas!

Menyokong skala yang lebih besar

Teknik mencetuskan binaan untuk menjana semula halaman lollipop setiap kali entri baru dicipta mungkin tidak selalu menjadi yang terbaik. Walaupun automasi binaan bermakna penempatan semula laman web sangat mudah, kita mungkin mahu mula mengehadkan dan mengoptimumkan perkara apabila kita mula menjadi sangat popular. (Ini hanya masalah masa, bukan?)

Tidak menjadi masalah. Berikut adalah beberapa perkara yang perlu dipertimbangkan ketika kami membuat banyak halaman dan menambah kandungan lebih kerap dalam pangkalan data:

• Daripada mencetuskan pembinaan semula untuk setiap entri baru, kami dapat membina semula tapak tersebut menjadi pekerjaan yang dijadualkan. Mungkin ini boleh berlaku setiap jam atau sekali sehari.
• Jika dibina sekali sehari, kami boleh membuat keputusan untuk menjana halaman hanya untuk lollipop baru yang dikemukakan pada hari lalu dan cache halaman yang dihasilkan setiap hari untuk kegunaan masa depan. Logik ini dalam binaan akan membantu kami menyokong sejumlah besar halaman lollipop tanpa membuat binaan terlalu lama. Tetapi saya tidak akan bercakap mengenai cache di sini. Jika anda ingin tahu, anda boleh bertanya di Forum Komuniti Netlify.

Dengan menggabungkan sumber pra-dihasilkan statik dengan penyelesaian back-up tanpa pelayan yang menyediakan rendering dinamik, kami dapat memenuhi pelbagai kes penggunaan yang sangat luas-sambil mengelakkan keperluan untuk mengkonfigurasi dan mengekalkan sejumlah besar infrastruktur dinamik.

Apakah kes penggunaan lain yang boleh anda gunakan pendekatan "statik pertama" ini untuk bertemu?

Atas ialah kandungan terperinci Statik Pertama: Laman Jamstack Pra-Dihasilkan dengan Rendering Tanpa Pelayan sebagai sandaran. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!