Statisch zuerst: Vorgenerierte Jamstack-Websites mit serverlosen Rendering als Fallback

Die Jamstack -Architektur erlangt zunehmend Aufmerksamkeit und bietet eine effiziente Methode zum Erstellen einer Website.

Eines der Kernprinzipien von Jamstack ist die Vorrenderung. Dies bedeutet, im Voraus eine Reihe statischer Ressourcen zu generieren, um den Dienst von Besuchern von CDNs oder anderen optimierten statischen Hosting -Umgebungen mit schnellster Geschwindigkeit und niedrigster Overhead zu ermöglichen.

Aber wenn wir im Voraus Websites vor der Generate vorbereiten würden, wie könnten wir sie dynamischer aussehen lassen? Wie erstelle ich eine Website, die häufige Änderungen benötigt? Wie gehe ich benutzergenerierte Inhalte mit?

Tatsächlich ist dies das ideale Anwendungsszenario für serverlose Funktionen. Jamstack und Serverless sind die besten Partner, sie ergänzen sich perfekt.

In diesem Artikel wird ein Muster untersucht: In einer Website, die fast ausschließlich aus benutzergenerierten Inhalten besteht und serverlose Funktionen als Sicherungslösung für vorgenerierte Seiten verwendet. Wir werden eine optimistische URL -Routing -Technik anwenden, bei der die 404 -Seite eine serverlose Funktion ist, mit der dynamisch serverloses Rendering hinzugefügt werden kann.

Klingt kompliziert? Vielleicht. Aber funktioniert es? Absolut effektiv!

Sie können die Demo -Website ausprobieren, um diesen Anwendungsfall zu erfahren. Bitte versuchen Sie es jedoch nach dem Lesen dieses Artikels.

Du bist zurück? Großartig, lasst uns hineintauchen.

Die Philosophie dieser Beispiel -Website lautet: Lassen Sie Sie eine warme Nachricht und eine virtuelle Ermutigungsnachricht erstellen, die Sie an Freunde senden können. Sie können eine Nachricht schreiben, den Lollipop (oder Eis am Stiel, für meine amerikanischen Freunde) anpassen und eine URL mit Ihren Empfängern teilen. Das war's, du hast ihren Tag beleuchtet. Was gibt es Schöneres als das?

Traditionell würden wir einige serverseitige Skripte verwenden, um Formulareinreichungen zu verarbeiten, neue Lollipops (unseren benutzergenerierten Inhalt) zur Datenbank hinzuzufügen und eine eindeutige URL zu generieren. Anschließend verwenden wir mehr serverseitige Logik, um Anforderungen auf diese Seiten zu analysieren, die Datenbank abzufragen, um die Daten zu erhalten, die zur Fülle der Seitenansicht erforderlich sind, mit der entsprechenden Vorlage rendern und an den Benutzer zurückgeben.

Das scheint vernünftig.

Aber wie viel kostet es zu expandieren?

Technische Architekten und technische Vorgesetzte stoßen bei der Bewertung des Umfangs eines Projekts häufig auf dieses Problem. Sie müssen genug Ressourcen planen, bezahlen und zuordnen, um mit erfolgreichen Situationen fertig zu werden.

Diese virtuelle Lollipop -Website ist keine gewöhnliche Dekoration. Da wir uns alle gegenseitig positive Nachrichten senden wollen, wird mich diese Website zu einem Milliardär machen! Während sich die Nachrichten verbreiten, werden die Verkehrsniveaus steigen. Ich würde besser eine gute Strategie haben, um sicherzustellen, dass der Server schwere Lasten bewältigen kann. Ich könnte einige Cache -Ebenen hinzufügen, einige Lastbalancer, und ich würde meine Datenbank- und Datenbankserver entwerfen, damit ich die Last teilen kann, ohne von der Notwendigkeit zu erstellen und all diese Lutscher bereitzustellen.

Aber ... ich weiß nicht, wie ich diese Dinge macht.

Und ich weiß nicht, wie viel es kostet, diese Infrastrukturen hinzuzufügen und sie am Laufen zu halten. Das ist kompliziert.

Deshalb mag ich es, mein Hosting so weit wie möglich mit Vorrendern zu vereinfachen.

Die Bereitstellung von statischen Seiten ist viel einfacher und kostengünstiger als die Bereitstellung von Seiten dynamisch von einem Webserver, für das einige Logik erforderlich sind, um Ansichten für jeden Besucher auf Bedarf zu generieren.

Da wir an vielen benutzergenerierten Inhalten arbeiten, ist es immer noch sinnvoll, die Datenbank zu verwenden, aber ich werde sie selbst nicht verwalten. Stattdessen werde ich eine von vielen Datenbankoptionen auswählen, die als Dienst verwendet werden können. Ich werde durch seine API mit ihm interagieren.

Ich kann Firebase, MongoDB oder eine andere Anzahl von Datenbanken wählen. Chris hat einige dieser Ressourcen auf einer großartigen Website über serverlose Ressourcen zusammengestellt, was es wert ist, erkunden zu werden.

In diesem Fall wähle ich Fauna als meinen Datenspeicher. Fauna bietet eine großartige API zum Speichern und Abfragen von Daten. Es ist ein Datenspeicher im Nicht-SQL-Stil und genau das, was ich brauche.

Entscheidend ist, dass Fauna es zu einem kompletten Geschäft gemacht hat, Datenbankdienste bereitzustellen. Sie haben tiefes Domänenwissen, das ich niemals haben werde. Durch die Verwendung eines solchen Datenbank-AS-A-Service-Anbieters habe ich ein Expert Data Services-Team für mein Projekt geerbt , einschließlich Infrastruktur mit hoher Verfügbarkeit, Kapazitäts- und Compliance-Sicherheit, qualifizierte Support-Ingenieure und umfangreiche Dokumentation.

Verwenden Sie einen solchen Drittanbieter-Service, der seine Stärken sind, anstatt es selbst zu tun.

Architektur tl; dr

Wenn ich mich mit Proof of Concept zu befassen habe, bin ich oft ein paar logische Flüsse. Hier ist das Doodle, den ich für diese Website gemacht habe:

Und einige Erklärungen:

1. Benutzer erstellen einen neuen Lollipop, indem sie ein normales HTML -Formular ausfüllen.
2. Neue Inhalte werden in der Datenbank gespeichert, und ihre Einreichung löst die Erzeugung und Bereitstellung neuer Site aus.
3. Sobald die Website bereitgestellt ist, ist der neue Lollipop über eine eindeutige URL zugänglich. Es wird eine statische Seite sein, die schnell vom CDN serviert wird, ohne sich auf Datenbankabfragen oder Server zu verlassen.
4. Als statische Seite ist kein neuer Lollipop zugänglich, bis die Site -Generierung abgeschlossen ist. Eine erfolglose Anfrage an der Lollipop -Seite fällt auf eine Seite zurück, auf der die Lollipop -Seite über die dynamische Abfrage -Datenbank -API dynamisch generiert wird.

Dieser Ansatz setzt zuerst statische/vorgenerierte Ressourcen an und fällt dann wieder auf das dynamische Rendering zurück, wenn die statische Sichtweise nicht verfügbar ist, was als "statisch zuerst" bezeichnet wird, wie von Unilevers Markus Schork beschrieben, den ich mag, die Aussage.

Detaillierte Beschreibung

Sie können direkt in den Code der Website graben (es ist Open Source und Sie können so viel untersuchen, wie Sie möchten), oder wir können ihn weiter diskutieren.

Möchten Sie tiefer graben und die Implementierung dieses Beispiels untersuchen? Ok, ich werde ausführlicher erklären:

• Holen Sie sich Daten aus der Datenbank, um jede Seite zu generieren
• Veröffentlichen Sie Daten mit serverlosen Funktionen an Datenbank -API
• Eine vollständige Website -Regeneration auslösen
• Auf Anfrage auf Nachfrage rendern, wenn keine Seiten generiert wurden

Generieren Sie Seiten aus der Datenbank

Später werden wir diskutieren, wie Daten in der Datenbank veröffentlicht werden, aber zunächst nehmen wir an, dass es bereits einige Einträge in der Datenbank gibt. Wir werden eine Website generieren, die die Seiten für jeden Eintrag enthält.

Statische Website -Generatoren sind sehr gut darin. Sie verarbeiten die Daten, wenden sie auf die Vorlage an und geben HTML -Dateien aus, die bereit sind, bereit zu sein. Wir können jeden Generator für dieses Beispiel verwenden. Ich habe ELEDY gewählt, weil es relativ einfach ist und die Site -Generation schnell ist.

Um einige Daten zu bieten, haben wir viele Optionen. Eine Möglichkeit besteht darin, ein JavaScript bereitzustellen, das strukturierte Daten zurückgibt. Dies eignet sich hervorragend für die Abfrage von Datenbank -APIs.

Unsere leichte Datendatei sieht folgendermaßen aus:

 <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>

Ich habe diese Datei lollies.js benannt und alle Daten, die sie für ELEDY in einer Sammlung namens Lollies zurückgeben.

Wir können diese Daten jetzt in unseren Vorlagen verwenden. Wenn Sie den Code anzeigen möchten, der diese Daten nimmt und eine Seite für jedes Projekt generiert, können Sie ihn im Code -Repository anzeigen.

Senden und speichern Sie Daten ohne Server

Wenn wir eine neue Lollipop -Seite erstellen, müssen wir den Benutzerinhalt in der Datenbank erfassen, damit wir sie in Zukunft die Seite der angegebenen URL füllen können. Dazu verwenden wir herkömmliche HTML -Formulare, um Daten an den entsprechenden Formularhandler zu veröffentlichen.

Das Formular sieht so aus (oder sehen Sie den vollständigen Code im Repository):

<code></code>

Die Empfänger sagen etwas Gutes, dass der Absender keinen Webserver in unserem Hosting -Schema hat. Daher müssen wir einen Ort entwerfen, an dem HTTP -Posting -Anfragen aus diesem Formular übermittelt wurden. Dies ist der perfekte Anwendungsfall für serverlose Funktionen. Ich verwende dafür Netlify -Funktionen. Sie können AWS Lambda, Google Cloud oder Azure -Funktionen verwenden, wenn Sie es vorziehen, aber ich mag die Einfachheit des Netlify -Funktions -Workflows und die Tatsache, dass meine serverlose API und meine Benutzeroberfläche im selben Code -Repository behalten.

Es ist eine gute Angewohnheit zu vermeiden, dass die Details zur Implementierung von Backend -Implementierungen an die Frontend ausgelöst werden. Klare Trennung erleichtert die Transplantation und Aufmerksamkeit. Schauen Sie sich die Aktionseigenschaften des obigen Formularelements an. Es veröffentlicht die Daten auf einem Pfad namens /neu auf meiner Website, wodurch nicht wirklich darauf hinweist, mit welchem ​​Service sie kommunizieren wird.

Wir können es an jeden Service weiterleiten, den wir gerne um Weiterleitungen verwenden. Ich sende es an die serverlose Funktion, die ich in diesem Projekt konfigurieren werde, aber es kann einfach so angepasst werden, dass Daten an einen anderen Ort gesendet werden, wenn wir möchten. Netlify bietet uns eine einfache und stark optimierte Umleitungsiegin, die unseren Datenverkehr auf CDN -Ebene leitet, damit die Benutzer sehr schnell an den richtigen Standort wechseln können.

Die folgende Umleitungsregel (befindet sich in der Datei netlify.toml meines Projekts) stellt die Anforderung für /neu in eine serverlose Funktion namens Newlolly.js, die von Netlify -Funktionen gehostet wird.

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

Schauen wir uns diese serverlose Funktion an:

• Neue Daten in die Datenbank speichern,
• Erstellen Sie eine neue URL für die neue Seite und
• Umleiten Sie Benutzer auf die neu erstellte Seite, damit sie die Ergebnisse sehen können.

Erstens benötigen wir verschiedene Dienstprogramme, um Formulardaten zu analysieren, eine Verbindung zur Fauna-Datenbank herzustellen und eine kurze, leicht zu lesende ID für den neuen Lollipop zu erstellen.

 <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>

Jetzt werden wir der Anfrage einen Code hinzufügen, um serverlose Funktionen zu verarbeiten. Die Handler -Funktion analysiert die Anfrage, um die erforderlichen Daten aus der Formulareingabe abzurufen, dann eine eindeutige ID für den neuen Lollipop zu generieren und sie dann als neuen Datensatz in die Datenbank zu erstellen.

 <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>

Lassen Sie uns unseren Fortschritt überprüfen. In der Datenbank können wir neue Lollipop -Seiten erstellen. Wir haben auch einen automatischen Build, der eine Seite für jede unserer Lutscher generiert.

Um sicherzustellen, dass für jeden Lutscher eine vollständige Reihe von vorgenerierten Seiten vorhanden ist, sollten wir den Wiederaufbau jedes Mal auslösen, wenn ein neuer Eintrag erfolgreich in die Datenbank hinzugefügt wird. Dies ist sehr einfach. Dank unseres statischen Website -Generators wurde unser Build automatisiert. Wir brauchen nur einen Weg, um es auszulösen. Mit Netlify können wir eine beliebige Anzahl von Build -Hooks definieren. Sie sind Webhooks und wenn sie HTTP -Postanfragen erhalten, werden sie unsere Website wieder aufbauen und bereitstellen. Dies ist eine, die ich in der Site Management Console von Netlify erstellt habe:

Um die Website zu regenerieren, einschließlich der Seiten jedes in der Datenbank aufgezeichneten Lollipops, können wir eine HTTP -Postanforderung in diesem Build -Hook unmittelbar nach dem Speichern der neuen Daten in der Datenbank ausstellen.

Hier ist der Code, der dies tut:

 <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>

Sie können es im vollständigen Code sehen, der dem erfolgreichen Handler für die Datenbankeinführung hinzugefügt wurde.

Dies ist alles gut, wenn wir bereit sind, auf den Build und die Bereitstellung zu warten, bevor wir die URL des neuen Lollipops mit dem Empfänger teilen. Aber wir sind nicht geduldig und wir möchten es sofort teilen, wenn wir eine neue URL für den gerade erstellten Lutscher erhalten.

Wenn wir vor dem Abschluss der Website auf die URL zugreifen, um die neue Seite zu enthalten, erhalten wir leider eine 404. Es ist jedoch eine Freude, diese 404 zu nutzen.

Optimistische URL-Routing und serverlose Sicherungsszenarien

Mit einem benutzerdefinierten 404 -Routing haben wir die Option, jede fehlgeschlagene Anforderung an die Lollipop -Seite an eine Seite zu senden, auf der Lollipop -Daten in der Datenbank direkt nachschlagen können. Wir können dies in Client -JavaScript tun, wenn wir möchten, aber ein besserer Weg ist es, eine Seite, die bereit ist, aus der serverlosen Funktion zu sehen, dynamisch zu generieren.

Die Methode lautet wie folgt:

Zunächst müssen wir alle Anfragen mitteilen, die auf die Lollipop -Seite zugreifen möchten (diese Anfragen kehren leer zurück), um stattdessen zu unserer serverlosen Funktion zu gehen. Wir tun dies, indem wir der Netlify -Umleitung eine weitere Regel hinzufügen:

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

Diese Regel wird nur angewendet, wenn die Anfrage für die Lollipop -Seite keine statische Seite zum Servieren findet. Es schafft eine temporäre Umleitung (HTTP 302) zu unserer serverlosen Funktion, die so aussieht:

 <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>

Wenn eine Anfrage für eine andere Seite (nicht im / lolly / Pfad der Website) einen 404 zurückgibt, senden wir diese Anfrage nicht an unsere serverlose Funktion, um nach Lollipops zu überprüfen. Wir können Benutzer direkt an die 404 -Seite senden. Unsere Netlify.TOML -Konfiguration ermöglicht es uns, eine beliebige Anzahl von 404 Routing -Ebenen zu definieren, indem wir der Datei mehr Fallback -Regeln hinzufügen. Die erste erfolgreiche Übereinstimmung in der Datei wird übernommen.

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

Wir sind fertig! Wir haben jetzt eine "statische" Site, die versucht, Inhalte dynamisch mit serverlosen Funktionen zu rendern, wenn die URL nicht mit einer statischen Datei generiert wurde.

Sehr schnell!

Unterstützt größere Maßstäbe

Die Technik, einen Build auszulösen, um jedes Mal, wenn ein neuer Eintrag erstellt wird, zu regenerieren, ist möglicherweise nicht immer die beste. Während die Automatisierung von Builds bedeutet, dass die Einschichtung von Websites sehr einfach ist, möchten wir vielleicht anfangen, Dinge einzuschränken und zu optimieren, wenn wir anfangen, sehr beliebt zu werden. (Es ist nur eine Frage der Zeit, oder?)

Es spielt keine Rolle. Hier sind einige Dinge zu berücksichtigen, wenn wir viele Seiten erstellen und häufiger Inhalte in der Datenbank hinzufügen:

• Anstatt für jeden neuen Eintrag einen Wiederaufbau auszulösen, können wir die Website in einen geplanten Job umstellen. Vielleicht kann dies stündlich oder einmal am Tag passieren.
• Wenn wir einmal am Tag gebaut wurden, können wir uns entscheiden, Seiten nur für neue Lutscher zu generieren, die am vergangenen Tag eingereicht wurden, und die Seiten, die jeden Tag für die zukünftige Verwendung generiert werden, zwischenstrahlen. Diese Logik im Build hilft uns dabei, eine große Anzahl von Lutscherseiten zu unterstützen, ohne den Build zu lang zu machen. Aber ich werde hier nicht über In-Build-Cache sprechen. Wenn Sie neugierig sind, können Sie im Netlify Community Forum fragen.

Durch die Kombination statischer vorgenerierter Ressourcen mit serverlosen Backup-Lösungen, die dynamisches Rendering bieten, können wir eine überraschend breite Palette von Anwendungsfällen erfüllen. Sie vermeiden gleichzeitig die Notwendigkeit, eine große Anzahl dynamischer Infrastruktur zu konfigurieren und zu verwalten.

Welche anderen Anwendungsfälle können Sie diesen "statischen ersten" Ansatz verwenden, um sich zu treffen?

Das obige ist der detaillierte Inhalt vonStatisch zuerst: Vorgenerierte Jamstack-Websites mit serverlosen Rendering als Fallback. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!