Referenz für serverlose Funktionen
CMS Hub
- Enterprise
In diesem Artikel erfahren Sie mehr über die Dateien, die sich in einem serverlosen .functions-Ordner befinden, und die CLI-Befehle, die Sie mit serverlosen Funktionen verwenden können.
Einen umfassenden Überblick über serverlose Funktionen finden Sie in der Übersicht über serverlose Funktionen.
Bitte beachten: serverlose Funktionsdateien müssen lokal über das HubSpot-CLI hochgeladen werden.
Ihre serverless.json-Datei speichert Ihre Konfigurationseinstellungen für Funktionen in Ihrem .functions-Ordner. Diese Datei ist erforderlich, damit die serverlosen Funktionen funktionieren. Diese Datei ordnet Ihre Funktionen ihren Endpunkten zu.
| Schlüssel | Type | Description |
|---|---|---|
runtime
erforderlich
| String | Die Laufzeitumgebung. Unterstützt Node.js Version 14 ( Bitte beachten: Node.js Version 12 (
|
version
erforderlich
| String | Schema-Version der serverlose Funktion von HubSpot. (Aktuelle Version 1.0) |
endpoints
erforderlich
| Object | Endpunkte definieren die Pfade, die zugänglich gemacht werden, und ihre Zuordnung zu bestimmten JavaScript-Dateien in Ihrem Funktionsordner. |
environment
| Object | Konfigurationsvariablen, die zur Laufzeit als Umgebungsvariablen an die ausführende Funktion übergeben werden. Sie könnten dies verwenden, um eine Logik für die Verwendung einer Testversion einer API anstelle der echten Version auf der Grundlage einer Umgebungsvariablen hinzuzufügen. |
secrets
| array | Ein API-Schlüssel ist ein Geheimnis. Die Geheimnisse in der Konfigurationsdatei beziehen sich auf den Namen des Geheimnisses, nicht auf seinen Wert. Geben Sie die Geheimnisse nicht direkt in diese Datei ein, sondern verweisen Sie nur auf die Geheimnisnamen. |
Bitte beachten: Weisen Sie Ihren Geheimnissen und Umgebungsvariablen nicht denselben Namen zu. Andernfalls kommt es zu Konflikten bei der Rückgabe ihrer Werte in der Funktion.
Jeder Endpunkt kann seine eigenen Umgebungsvariablen und Geheimnisse haben. Außerhalb von Endpunkten angegebene Variablen sollten für Konfigurationseinstellungen verwendet werden, die für alle Funktionen und Endpunkte gelten.
Endpunkte haben einige eindeutige Schlüssel.
| Schlüssel | Type | Description |
|---|---|---|
method
| String or array of strings | HTTP-Methode oder -Methoden, die der Endpunkt unterstützt. Die Standardeinstellung ist GET. |
file
erforderlich
| String | Pfad zur JavaScript-Funktionsdatei mit der Implementierung für den Endpunkt. |
Serverlose Funktionen werden über einen Pfad in der Domain Ihres HubSpot CMS-Accounts bereitgestellt. Dies gilt auch für standardmäßige .hs-sites.com-Subdomains.
Sie können diese Funktionen unter der folgenden URL aufrufen:
https://{domainName}/_hcms/api/{endpoint-name/path}?portalid={hubId}.
Im Folgenden erfahren Sie mehr über die einzelnen URL-Komponenten:
| Parameter | Description |
|---|---|
domainName
| Ihr Domain-Name. |
/_hcms/api/
| Der für serverlose Funktionen reservierte Pfad. Alle Endpunkte befinden sich innerhalb dieses Pfades. |
endpoint-name/path
| Der Endpunktname oder -pfad, den Sie in der |
hubId
| Ihre Hub-ID. Wenn Sie dies in der Anfrage angeben, können Sie Ihre Funktionen in Modul- und Vorlagenvorschauen testen. |
Jede Funktion wird als Node.js-JavaScript-Datei in einem Ordner mit der Endung .functions erstellt. Zusätzlich zur Node.js-Standardbibliothek können Funktionen die request-Bibliothek nutzen, um HTTP-Anfragen an HubSpot-APIs und andere APIs zu stellen.
Eine einfache serverless-function.js-Datei sieht folgendermaßen aus:
| Parameter | Description |
|---|---|
accountId
| Die HubSpot-Account-ID, die die Funktion enthält. |
body
| body wird ausgefüllt, wenn die Anfrage als POST mit dem Inhaltstyp „application/json“ gesendet wird |
contact
| Wenn die Anfrage von einem Kontakt mit einem gesetzten Cookie stammt, ist das Kontaktobjekt mit einer Reihe von grundlegenden Kontakteigenschaften vorhanden. Diese zusätzlichen Objekte sind ebenfalls verfügbar:
|
headers
| Enthält Header, die vom Client gesendet werden, der Ihren Endpunkt erreicht. Siehe Header. |
params
| params wird mit den Werten der Abfragezeichenfolge und allen HTML-Formular-POST-Werten aufgefüllt. Diese sind als Zuordnung mit Zeichenfolgen als Schlüssel und einem Array von Zeichenfolgen für jeden Wert strukturiert. |
limits
| Gibt zurück, wie nah Sie an den Ratenbeschränkungen für serverlose Funktionen.
|
Manchmal kann es hilfreich sein, über die Header des Clients zu verfügen, der Ihren Endpunkt erreicht. Wir stellen die folgenden Header über context.headers zur Verfügung. Dies ähnelt dem Zugriff auf Informationen über context.body.
| Header | Description |
|---|---|
accept
| Teilt mit, welche Inhaltstypen, ausgedrückt als MIME-Typen, der Client versteht. Siehe MDN. |
accept-encoding
| Teilt die Inhaltskodierung mit, die der Client versteht. Siehe MDN. |
accept-language
| Teilt mit, welche menschliche Sprache und welches Gebietsschema bevorzugt wird. Siehe MDN. |
cache-control
| Enthält Richtlinien für die Zwischenspeicherung. Siehe MDN. |
connection
| Teilt mit, ob die Netzwerkverbindung offen bleibt. Siehe MDN. |
cookie
| Enthält Cookies, die der Client gesendet hat. Siehe MDN. |
host
| Übermittelt den Domain-Namen und die TCP-Portnummer eines überwachenden Servers. Siehe MDN. |
true-client-ip
| IP-Adresse des Endbenutzers. Siehe Cloudflare true-client-ip. |
upgrade-insecure-requests
| Teilt mit, dass die Clients eine verschlüsselte und authentifizierte Antwort wünschen. Siehe MDN. |
user-agent
| Vom Hersteller definierte Zeichenfolge zur Identifizierung der Anwendung, des Betriebssystems, des Anwendungsherstellers und der Version. Siehe MDN. |
x-forwarded-for
| Identifiziert die ursprüngliche IP-Adresse eines Clients durch einen Proxy oder Load Balancer. Siehe MDN. |
Sie können eine Weiterleitung von Ihrer serverlosen Funktion durchführen, indem Sie eine Antwort mit einem Standort-Header und 301-Status-Code senden.
Über Ihre serverlose Funktion können Sie dem Client (Webbrowser) mitteilen, dass er ein Cookie setzen soll.
Für Header, die mehrere Werte unterstützen, können Sie multiValueHeaders verwenden, um die Werte zu übergeben. Zum Beispiel können Sie den Browser anweisen, mehrere Cookies zu setzen.
API-Schlüssel und Authentifizierungsinformationen werden als Geheimnisse bezeichnet. Einmal hinzugefügt, sind sie über Umgebungsvariablen zugänglich (process.env.secretName). Sie können Geheimnisse zuweisen, die für bestimmte Endpunkte verfügbar sind, indem Sie den „secrets“-Schlüssel zu Ihrer serverless.json-Datei hinzufügen. Geheimnisse werden über die HubSpot-Befehlszeile mit den folgenden Befehlen verwaltet:
Geben Sie den Wert Ihres Geheimnisses nicht über die Konsolenprotokollierung oder als Antwort zurück. Dadurch würden Ihre Geheimnisse in Ihren Protokollen oder in Front-End-Seiten, die Ihre serverlose Funktion aufrufen, offengelegt.
Bei der Übermittlung von serverlosen Funktionen verwenden Sie JavaScript, um die Formulareinsendung zu verarbeiten, und verwenden Sie den "contentType" : "application/json"-Header in Ihrer Anfrage. Verwenden Sie nicht das action-Attribut <form>-Elemente.
Cross Origin Resource Sharing (CORS) ist eine Sicherheitsfunktion des Browsers. Standardmäßig schränken Browser durch JavaScript initiierte herkunftsübergreifende Anfragen ein. Dadurch wird verhindert, dass bösartiger Code, der auf einer anderen Domain läuft, Ihre Website beeinträchtigt. Dies wird als Same-Origin-Policy bezeichnet. Da das Senden und Abrufen von Daten von anderen Servern manchmal notwendig ist, kann der externe Server HTTP-Header bereitstellen, die mitteilen, welche Herkunft die Informationen von einem Browser lesen darf.
Sie sollten keine CORS-Probleme haben, wenn Sie Ihre serverlose Funktion innerhalb Ihrer von HubSpot gehosteten Seiten aufrufen. Wenn dies doch der Fall ist, vergewissern Sie sich, dass Sie das richtige Protokoll verwenden.
Erhalten Sie diesen CORS-Fehler?
"Access to fetch at [Ihre Funktions-URL] from origin [Seite, die die Anfrage stellt] has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled."
Geht Ihre Anfrage an einen anderen Ursprung als die aufrufende Seite?
- Wenn der Domain-Name anders ist, ja.
- Bei Verwendung eines anderen Protokolls (http, https), ja.
Wenn Sie ein anderes Protokoll verwenden, ändern Sie einfach das Protokoll, und das Problem ist behoben.
Sie können den Access-Control-Allow-Origin-Header von HubSpot derzeit nicht ändern.
GET-Anfragen können je nach Client auch CORS-Anfragen stellen. Bei GET-Anfragen wird nichts geschrieben, sondern nur Daten zurückgegeben.
Serverlose HubSpot-Funktionen werden derzeit mit den folgenden Paketen vorinstalliert:
- @hubspot/api-client: ^1.0.0-beta
- axios: ^0.19.2
- request: ^2.88.0
- requests: ^0.2.2
So nutzen Sie die neueste unterstützte Version eines vorinstallierten Pakets bzw. so nutzen Sie ein neu hinzugefügtes Paket:
- Klonen oder kopieren Sie Ihre Funktionsdatei.
- Ändern Sie den Endpunkt Ihrer Funktion in der
serverless.json-Datei, um auf Ihre neue Funktionsdatei zu verweisen. Sie können die alte Version bedenkenlos löschen.
Wenn Sie Pakete außerhalb des vorinstallierten Paketsatzes einbinden möchten, können Sie webpack verwenden, um Ihre Node-Module zu kombinieren und Ihre gebündelten Dateien als Funktionsdateien zu verwenden.
Serverlose Funktionen sollen schnell sein und einen engen Fokus haben. Um schnelle Aufrufe und Antworten zu ermöglichen, sind die serverlosen Funktionen von HubSpot auf Folgendes beschränkt:
- 50 Geheimnisse pro Account
- 128 MB Speicher
- Nicht mehr als 100 Endpunkte pro HubSpot-Account
- Sie müssen den Inhaltstyp
application/jsonbeim Aufrufen einer Funktion verwenden. - Protokolle der serverlose Funktionen werden 90 Tage lang gespeichert.
- 6 MB in einer AWS Lambda-Aufruf-Payload.
Ausführungslimits
- Jede Funktion hat eine maximale Ausführungszeit von 10 Sekunden.
- Jeder Account ist auf insgesamt 600 Ausführungssekunden pro Minute beschränkt.
Das bedeutet, dass jedes dieser Szenarien eintreten kann:
- 60 Funktionsausführungen, die jeweils 10 Sekunden in Anspruch nehmen.
- 6.000 Funktionsausführungen, die 100 Millisekunden dauern.
Funktionen, die diese Limits überschreiten, lösen einen Fehler aus. Ausführungsanzahl und Zeitlimits geben eine 429-Antwort zurück. Die Ausführungszeit jeder Funktion wird in den Protokollen der serverlosen Funktionen berücksichtigt.
Um diese Beschränkungen zu umgehen, werden dem Funktionskontext während der Ausführung automatisch Daten für Obergrenzen zur Verfügung gestellt. Sie können dies nutzen, um Ihre Anwendung so zu beeinflussen, dass sie innerhalb dieser Obergrenzen bleibt. Wenn Ihre Anwendung beispielsweise die Abfrage Ihres Endpunkts erfordert, können Sie mit Ihren Daten eine Variable zurückgeben, um die Häufigkeit der Abfrage zu beeinflussen. Auf diese Weise können Sie bei hohem Traffic die Abrufrate verlangsamen, um ein Überschreiten der Obergrenzen zu vermeiden, und sie dann bei geringem Traffic wieder erhöhen.
Vielen Dank, dass Sie Ihr Feedback mit uns geteilt haben.