Build a Custom App Card from Scratch (Part 3) | Next.js Backend & Vercel Deployment

Wie Erhalten Sie externe Live Daten für Ihre benutzerdefinierte HubSpot Benutzeroberflächenerweiterung? Wir befassen uns eingehend wir erstellen ein grundlegendes Next JS Backend, das Leistungsstärke API Integrationen ermöglicht. Haben Sie das letzte Video dieser Reihe gesehen? Wir erstellen eine globale öffentliche App Karte für die Verfügbarkeit von Kontakten, die Ihnen das Rätselraten darüber erleichtert, wann ein guter Zeitpunkt ist, einen Kontakt anzurufen, indem Sie dessen aktuelle Verfügbarkeit anzeigt. Im letzten Video haben wir OOTH erfolgreich analysiert, unsere öffentliche App Karte sicher in einem Entwicklertest Konto installiert und unsere Benutzeroberflächenerweiterungskarte live im CRM System gesehen. In diesem Video erstellen wir also das grundlegende Next JS Button für unsere öffentlichen App und den API Endpunkt, der unsere Funktion zur Kontaktverfügbarkeit unterstützt. Wir erkunden die API, navigieren mit Postman durch unsere Endpunkte und stellen schließlich unsere gesamte Backend Lösung für FA Shell bereit. Hallo, ich bin Bri Developer Advocate hier bei HubSpot. Legen wir gleich los. Next JSJS ist ein Fullstack React Framework, mit dem wir robuste Webanwendungen entwickeln können. Besonders nützlich ist es für uns jedoch, da es API Routen unterstützt und so eine schnelle Entwicklung ermöglicht. Mit diesen API Routen können Sie serverseitige API Endpunkte direkt in Ihrem Next JS Projekt erstellen. Das bedeutet, dass Sie Next JS Code schreiben können, der sicher auf einem Server und nicht im Browser des Nutzers ausgeführt wird. Wichtig ist, dass für öffentliche App Karten, die mit UI Erweiterungen erstellt wurden, nicht unbedingt ein Next JSJS Backend erforderlich ist. Sie können Ihr Backend mit einer beliebigen Technologie oder einem beliebigen Service erstellen. Wichtig ist, dass das von Ihnen Ihnen gewählte Backend einen Endpunkt bereitstellt, auf den Ihre UI Erweiterung sicher zugreifen kann. Um unseren Entwicklungsprozess in diesem Tutorial zu optimieren, bietet die Verwendung von Next JS für ein Backend. Eine fantastische und einheitliche Entwicklererfahrung. Wechseln wir also zur Konsole. Im Stammverzeichnis unseres Projekts installieren wir Next JS, indem wir spätestens npx create next App ausführen. Wenn Sie diesen Befehl ausführen, wird schnell ein Gerüst für das NEX JS Projekt erstellt, das wichtige Verzeichnisse wie App für Ihre Frontend Routen und Ihre serverseitigen API Routen bereitstellt Public steht für statische Assets, Styles, für das Styling und wichtige Konfigurationsdateien wie NextConfig und Package JSON. Erstellen wir nun unsere erste API Route. Im Quellverzeichnis der App API erstellen wir also einen neuen Ordner mit dem Namen hello. Darin erstellen wir eine Datei mit dem Namen route ts. In NEX JS wird jede Datei in App API, die HTTP Methoden wie GET oder post exportiert, automatisch zu API Endpunkten. Dieser Code definiert eine einfache next jsapi Route, die auf GIT Anforderungen reagiert. Wenn jemand auf den Endpunkt API hello zugreift, wird die Funktion git ausgeführt und gibt unsere einfache hello Nachricht zurück. Nun möchten wir überprüfen, ob diese einfache API Route funktioniert. Und genau das machen wir mit postman, falls Sie noch nicht davon gehört. Postman ist eine API Plattform, die jede Phase des API Lebenszyklus vom Entwurf bis zum Testen vereinfacht. Für uns ist es ein praktisches Tool, um verschiedene Arten von HTTP Anforderungen an unsere API Endpunkte zu senden und die Antworten zu überprüfen. So können wir auch schnell überprüfen, ob unsere APIs wie erwartet funktionieren, Probleme beheben und sogar unsere Anforderungen in Sammlungen für die zukünftige Verwendung und Zusammenarbeit organisieren. Bei der Arbeit mit den APIs von HubSpot ist der HubSpot Postman Workspace eine hervorragende Ressource. Dort finden Sie Sammlungen, die Ihnen den Einstieg in die APIs von HubSpot erleichtern. Sie erkunden gängige Anwendungsfälle für HubSpot Entwickler und nutzen den neuen Flows Workspace, der das Testen und Automatisieren von mehrstufigen API Flows vereinfacht. Jetzt richten wir einen neuen Workspace für HTTP Anforderungen ein. Senden Sie die Anforderung an die Route hello auf Ihrem Entwicklungsserver. Dies ist normalerweise Localhost 3000. Achten Sie jedoch darauf, den Port zu bestätigen, auf dem Ihr Projekt derzeit ausgeführt wird. Wir können sehen, dass die Antwort nach Ausführung unserer Anfrage der Text der helloroute ist, den wir zuvor definiert haben. Wir haben also unsere einfache hello World API Route erstellt und getestet. Und das ist ein guter Anfang. Doch die wahre Kraft liegt in einer API mit aussagekräftigen, verwertbaren Daten. Sprechen wir nun über das Herzstück unserer öffentlichen App Karte, die globale Kontaktverfügbarkeits API, ihre besonderen Anforderungen und vor allem, warum wir sie so konzipiert haben. Diese API ruft unsere UI Erweiterungskarte auf, um alle benötigten intelligenten Erkenntnisse zu erhalten. Wenn Sie tiefer in den Code eintauchen und mehr darüber erfahren möchten, wie das funktioniert, besuchen Sie unbedingt den Link in der Beschreibung, um das GitHub Repository aufzurufen, in dem der gesamte Code gehostet wird. Im Kern muss unsere API drei Hauptinformationen für jeden Kontakt zurückgeben. Wir benötigen die aktuelle Ortszeit in der Zeitzone des Kontakts, seinen Verfügbarkeitsstatus, ob es gerade ein guter Zeitpunkt ist, ihn anzurufen, sowie eine Empfehlung für den besten Zeitpunkt zum Anrufen, falls es gerade kein günstiger Zeitpunkt ist, ihn anzurufen und schließlich eine Liste der anstehenden Feiertage an seinem Standort innerhalb der nächsten 30 Tage. Um diesen wichtigen Verfügbarkeitsstatus zu bestimmen, haben wir eine Reihe spezifischer Bedingungen und Prioritäten eingerichtet. Die API berücksichtigt den aktuellen Standort eines Kontakts, ob seine Ortszeit zwischen 9 Uhr und 17 Uhr von Montag bis Freitag liegt und ob es sich um einen Feiertag handelt. Diese Bedingungen ergeben daher unterschiedliche Ergebnisse in priorisierter Reihenfolge. So wird die Verfügbarkeitslogik priorisiert. Die höchste Priorität hat ein Feiertag. An nationalen Feiertagen ist der Kontakt unabhängig von der Uhrzeit nicht verfügbar. An Wochenenden sind Samstag und Sonntag sind sie nicht erreichbar. Erst dann, wenn es sich um einen Wochentag und nicht um einen Feiertag handelt, überprüfen wir, ob es sich um einen Wochentag innerhalb der Geschäftszeiten von 9 bis 17 Uhr vor Ort handelt. Oder ob es sich um eine Zeit außerhalb der Geschäftszeiten handelt, also außerhalb von 9 bis 17 Uhr unsere API zeigt bei ungünstigem Zeitpunkt mehr als nur nicht verfügbar an. Sie berechnet auf intelligente Weise das genaue Datum und die Uhrzeit für die nächstbeste Gelegenheit, sie zu erreichen und gibt diese an. Werfen wir einen Blick auf einige der Dateien und die Struktur dieser API. Zuerst haben wir Route. Dies wird unsere zentrale Befehlszentrale für unsere API sein. Hier laufen alle Teile zusammen. Sie akzeptiert den Standort eines Kontakts von HubSpot, orchestriert unsere externen APIs und speist alle diese Rohdaten in eine benutzerdefinierte Logik ein, um die Verfügbarkeit zu bestimmen. Hier IST die Eingabe und Fehlervalidierung implementiert. Essentiell für jede API. Als nächstes haben wir die abstrakte Zeitzonen API. Diese Datei umschließt unsere erste externe API, die abstrakte Zeitzone API. Dies ist eine kostenlose API, mit der wir sowohl die Zeitzoneninformationen als auch die aktuelle Ortszeit für einen bestimmten Standort in nur einem API Aufruf abrufen können. Dies vereinfacht die Dinge in unserem Backend im Vergleich zur Verkettung mehrerer Anfragen erheblich. Denken Sie daran, dass hierfür ein API Schlüssel erforderlich ist. Unten in der Beschreibung findest du den Link zu deinem Schlüssel. Sobald wir diesen API Schlüssel haben, werden wir ihn in einer Umgebungsdatei sichern. Als nächstes haben wir unsere Nagger Datums API. Wir integrieren die Naga Datums API für Feiertage. Wir haben hier auch ein wenig gefiltert. Da uns die Naga Datums API alle Feiertage des Jahres anzeigt, haben wir eine zusätzliche Logik integriert, um die Ergebnisse so zu filtern, dass uns nur die Feiertage angezeigt werden, die innerhalb der nächsten 30 Tage anstehen. Als nächstes haben wir die Dienstprogrammdatei ISO in Ländercode. Diese Datei mag klein erscheinen, aber sie löst ein sehr häufiges praktisches Problem bei unserer Integration. HubSpot gibt uns oft den vollständigen Ländernamen, aber viele externe APIs wie unsere Nagadate API erfordern einen aus zwei Buchstaben bestehenden ISO Länder Code. Dieses Dienstprogramm wurde hauptsächlich entwickelt, um diese Namen in Codes umzuwandeln und zeigt eine einfache und effektive Möglichkeit, Datentransformationen bei der Integration mit verschiedenen Systemen durchzuführen. Als nächstes haben wir unsere Kontaktverfügbarkeits Utility Datei. Hier steckt die wahre Intelligenz unserer Karte. Die Funktion zur Bestimmung des Verfügbarkeitsstatus ist hier das eigentliche Gehirn. Hier priorisieren wir die Logik, um zu erkennen, ob jemand im Büro, außerhalb der Geschäftszeiten, am Wochenende oder an einem Feiertag ist. Und der wirklich wertvolle Teil besteht darin, den nächstbesten Zeitpunkt für einen Anruf zu berechnen. Unsere API sagt Ihnen nicht nur, wann es kein guter Zeitpunkt zum Anrufen ist, sondern auch, wann ein guter ist. Sehr praktisch für unsere Nutzer. Kehren wir nun zu Postman zurück und sehen wir uns an, wie das funktioniert. Unsere Route befindet sich derzeit auf unserem lokalen Server und verwendet URL Parameter, um Stadt, Bundesland und Land von einem Kontakt abzurufen. Sehen wir uns an, wie das mit ein paar verschiedenen Standorten funktioniert. In Boston ist es derzeit etwas spät und wir können sehen, dass es nicht die beste Zeit zum Anrufen ist. Daher können wir auch sehen, dass wir die Empfehlung haben, morgen um 9 Uhr anzurufen. Außerdem können wir sehen, dass ein Feiertag vor uns liegt. Wenn wir nun an einen anderen Ort wie London wechseln, können wir sehen, dass es dort immer noch sehr früh ist und wir definitiv nicht um 4 Uhr morgens anrufen wollen. In diesem Fall erkennen wir jedoch, dass Freitag immer noch ein geeigneter Arbeitstag ist und es keinen Feiertag gibt. Daher lautet die empfehlung, heute um 9 Uhr anzurufen. Wenn wir nach Tibet in China fliegen, können wir sehen, dass es ein Wochentag ist. Wir befinden uns innerhalb der Geschäftszeiten und es ist kein Feiertag. Daher lautet die Empfehlung, sofort anzurufen. Und schließlich können wir uns Japan ansehen und sehen, dass es innerhalb der Geschäftszeiten liegt, es aber ein Samstag ist. Wir erhalten also einen Wochenendstatus und unsere Empfehlung ist, am Montagmorgen anzurufen. Unsere API sieht gut aus, aber wir möchten von überall darauf zugreifen können. Und hier kommt die Bereitstellung ins Spiel. Heute zeige ich euch, wie man ein Next JS Projekt in FA Shell bereitstellt. So erhalten wir einen produktionsreifen Endpunkt für unsere öffentliche App Karte, falls ihr noch nichts davon gehört. Fair Shell ist eine Cloud Plattform für Entwickler, die speziell für Next JS Anwendungen optimiert wurde. Sie automatisiert die Bereitstellung, bietet globale Skalierbarkeit und eine gute Entwicklererfahrung, sodass es unglaublich einfach ist, eure Webprojekte live zu schalten. Ihr könnt euch für ein kostenloses Ferse Konto registrieren, das für die Anforderungen unseres Projekts mehr als ausreichend ist. Der Registrierungsprozess ist sehr unkompliziert. Bevor wir zur Benutzeroberfläche von fashell wechseln, müssen wir einen wichtigen Befehl in unserem NEX JS Projekt ausführen. Wir führen npm build aus. Dieser Befehl kompiliert und optimiert unsere gesamte NEX JS Anwendung für die Produktion und generiert den optimierten Code und die statischen Assets, die Versell bereitstellt. In diesem Fall haben wir keine statischen Assets, aber es ist hilfreich, Linting Fehler abzufangen. Als nächstes müssen wir sicherstellen, dass unser Projekt in ein GitHub Repository übertragen wurde. Das vereinfacht die Projekteinrichtung noch weiter. Sobald Ihr Repository übertragen wurde, Wechseln wir zur Fair Shell Benutzeroberfläche und erstellen ein neues Faschelle Projekt. Möglicherweise müssen Sie Ihr GitHub Konto bei FA Shell authentifizieren, falls Sie dies noch nicht getan haben. Dadurch erhält Verzell Zugriff auf ihre GitHub Repositories. Sobald sie ihr Repository ausgewählt haben, müssen Sie sicherstellen, dass der Einstiegspunkt für Ihr Verzell Projekt korrekt ist. In diesem Tutorial haben wir mehrere verschiedene Projekte im Repository. Daher ist es wichtig, das Backend Verzeichnis Contact Availability als Einstiegspunkt für den Next JS Teil unseres Projekts festzulegen. Dann müssen wir unseren API Schlüssel als Geheimnis hinzufügen und die Bereitstellung durchführen. Damit erhalten Sie eine Live Ansicht Ihres Projekts. Die Benutzeroberfläche ist jetzt nicht die beste, da wir nichts daran geändert haben. Hier können Sie jedoch alles vom Status Ihrer Bereitstellung über die Bildprotokolle bis hin zu den Laufzeit und Beobachtbarkeitsmetriken einsehen. Für dieses Projekt verwenden wir jetzt die Live URL, die wir von der Bereitstellung erhalten haben und wechseln zurück zu Postman. Ich dupliziere den Arbeitsbereich, den ich zuvor für unsere lokale Entwicklung hatte und ich ersetze das Präfix durch unsere neue URL. Vorausgesetzt alles wurde erfolgreich bereitgestellt und konfiguriert, sollten wir dasselbe erfolgreiche Ergebnis sehen können, abgesehen von einem kleinen Zeitunterschied zur aktuellen Zeit, was derzeit der Fall ist. Das bedeutet, dass unsere öffentliche App Karte fast fertig ist. Wir haben uns mit der lokalen Entwicklung für die Einrichtung Ihrer App Karte befasst und heute das grundlegende Next JS Backend für unsere App Karte erstellt. Next JS API Routen. Wir untersuchten deren Kernkonzepte und deren Vorteile für die sichere Bereitstellung von Backend Logic für UI Erweiterungen. Unsere Kontaktverfügbarkeits IP besteht schreibt detailliert die benötigten Ausgaben und die priorisierte Logik zur Verfügbarkeitsbestimmung. Anschließend haben wir Postman verwendet, um unsere API Endpunkte zu validieren und haben sogar einen kurzen Blick auf den nützlichen HubSpot Postman Arbeitsbereich geworfen. Zuletzt wurde unser Next JS Backend via Fertil bereitgestellt, die globale API Zugänglichkeit sichergestellt und die Live Funktionalität per Postman validiert. In unserem nächsten Video werden wir unsere gesamte harte Arbeit zusammenfassen und unsere neu bereitgestellte API mithilfe von HubSpot Fetch mit der öffentlichen App Karte verbinden, abrufen und dann HubSpot UI Erweiterungen verwenden, um eine vollständige Kontaktverfügbarkeitskarte zu erstellen, die direkt in einem Kontaktdatensatz im HubSpot CRM angezeigt wird. Die Dokumentation, das GitHub Repository, den Code für dieses gesamte Projekt und vieles mehr finden Sie unter dem Link in der Beschreibung unten. Damit Sie über Videos wie dieses und andere für HubSpot Entwickler auf dem Laufenden bleiben, sollten Sie unseren YouTube Kanal abonnieren und die Benachrichtigungen aktivieren. So erfahren Sie als Erster, wenn ein neues Video veröffentlicht wird. Bis zum nächsten Mal.