Serverless Functions als Proxys

Das erste Mal, als Cloud-Funktionen / Serverless Functions für mich Sinn ergaben, war, als ich Auth0s (jetzt eingestelltes) Webtask sah und ausprobierte. Es war eine kleine CodePen-ähnliche IDE, aber man sah nicht wirklich etwas außer Code und Logs. Der Punkt war, kleine Stücke Node zu schreiben, wenn man die Funktions-URL aufrief (das ist buchstäblich genau das, was eine Serverless Function ist). Es speicherte sogar Ihre Secrets für Sie, was bedeutet, dass Sie die Serverless Function als Proxy verwenden konnten. Sie rufen die Funktion auf, die Funktion ruft die API unter Verwendung Ihrer nicht offengelegten API-Schlüssel-Secrets auf, die API gibt Daten zurück, die Funktion gibt dann Daten zurück, und diese Daten sind für die Client-Seite verfügbar, mit der Sie arbeiten können. Der gesamte Sinn war 1) Sie können Daten von einer ansonsten völlig statischen Website abgreifen, und 2) Ihre API-Schlüssel sind geschützt. Genial.

Ich vermisse Webtask immer noch, aber ich bin sicher, dass es heutzutage bessere und ausgefallenere Dinge gibt. Ich habe keinen festen Griff auf die gesamte Landschaft. Selbst AWS hat einen Online-Editor für Lambdas (ein " Lambda " ist die standardsetzende Implementierung von AWS für das, was eine Serverless Function ist), aber die direkte Nutzung der AWS-Konsole für irgendetwas ist normalerweise nicht... sehr gut. Functions in AWS Amplify sind wahrscheinlich die bessere Wahl dort.

Meine Vermutung ist, dass die richtige moderne Art, diese Dinge zu bauen, Dinge sind wie...

• Nutzen Sie das Framework von Serverless.com, um Ihre Serverless Functions zu erstellen/testen/bereitstellen
• Nutzen Sie Netlify Functions + Netlify Dev
• Nutzen Sie die Serverless Functions von Vercel oder den /pages/api Kram von Next.js mit jedem Node-Host, wie Heroku

Aber es gibt allerlei andere Tools, die ziemlich modern erscheinen, zu denen ich einfach nicht so gut Auskunft geben kann, die aber gut zu sein scheinen

• Begin.com
• SLAppForge
• Die neumodische Next-Gen-Server-Side-JavaScript-Sprache Deno kommt ins Deployment als Service.

Aber was mich an all das denken lässt und auch in die Kategorie der Dinge fällt, mit denen ich keine persönlichen Erfahrungen habe, ist Pipedream. Ich habe davon von Raymond gehört, der eine ähnliche Geschichte wie meine hat

Eines der ersten Dinge, das mich an Serverless faszinierte, und ehrlich gesagt ist es nicht wirklich neuartig, ist die Möglichkeit, Proxys zu anderen APIs zu bauen. Stellen Sie sich zum Beispiel eine coole API vor, die eine Authentifizierung irgendeiner Art erfordert, wie einen API-Schlüssel. Wenn Sie dies in clientseitigem JavaScript verwenden, kann jeder Ihren Code einsehen und Ihren Schlüssel erhalten. Bessere Dienste lassen Sie einen Schlüssel auf eine Domain beschränken, aber wenn Sie diese Option nicht haben, besteht die einfache Verwendung von Serverless darin, Ihnen einfach einen Endpunkt zu geben, der den Aufruf an die API mit Ihrem Schlüssel vornimmt.

Raymond Camden, „Using Pipedream to Proxy Other APIs“

Pipedream sieht ziemlich schick aus

Es ist nicht nur eine webbasierte IDE zum Erstellen von Funktionen, sondern ich kann sie auf verschiedene Arten auslösen – natürlich eine URL, aber auch über CRON oder Dinge wie per E-Mail oder RSS. Nett. Schauen Sie sich auch all die anderen Optionen an. Slack? GitHub? Twitter? Es ist in gewisser Weise so, wie Zapier aussieht, nur dass Zapier komplett No-Code ist (glaube ich). Pipedream macht Code zu einem First-Class-Citizen.

Und es verwaltet Geheimnisse über kontoebene Umgebungsvariablen.

Daher ist es perfekt, um als Serverless-Proxy zu fungieren. Lesen Sie Raymonds Beitrag für die tatsächliche Implementierung und Codebeispiele.