Was ist Cloud Code (Serverless-Funktionen)?

Cloud Code ist ein Serverless-Modell, bei dem Backend-Logik als serverseitige Funktionen läuft, ausgelöst durch Aufrufe, Datenereignisse oder Zeitpläne. Vorab zwei Klarstellungen, denn die Begriffsfamilie ist unübersichtlich. Erstens bedeutet „Serverless“, dass die Server nicht Ihr Problem sind – es gibt sie, unsichtbar und für Sie skaliert. Zweitens gibt es Funktionen in zwei Architekturen: eigenständiges FaaS, bei dem jede Funktion eine isolierte Einheit ist, die mit externen Diensten verdrahtet wird, und die BaaS-Variante, nach der dieser Artikel benannt ist – Funktionen, die in Ihr Backend deployt werden und sich die Umgebung mit der Datenbank, der Authentifizierung und den Dateien teilen, auf denen sie arbeiten.

Das Wichtigste im Überblick

Eine Funktion, von überall aufgerufen

Das klassische Aggregationsbeispiel – rechnen, wo die Daten liegen, und nur das Ergebnis übertragen:

// JavaScript / Node.js — Back4app JS SDK
// Calling a Cloud Code function: server-side logic, one line from the client
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
// The aggregation ran NEXT TO the database — only the answer crossed the wire

// The function itself (cloud/main.js — deployed to your backend, not the app):
// Parse.Cloud.define('averageStars', async (req) => {
//   const q = new Parse.Query('Review').equalTo('movie', req.params.movie);
//   const reviews = await q.find({ useMasterKey: true });
//   return reviews.reduce((s, r) => s + r.get('stars'), 0) / reviews.length;
// });

// Flutter / Dart — Back4app Flutter SDK
// Calling a Cloud Code function: server-side logic, one line from the client
final response = await ParseCloudFunction('averageStars')
    .execute(parameters: {'movie': 'Arrival'});
final avg = response.result;
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

// iOS / Swift — Back4app Swift SDK
// Calling a Cloud Code function: server-side logic, one line from the client
let avg: Double = try await Cloud.run(name: "averageStars",
                                      parameters: ["movie": "Arrival"])
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

// Android / Kotlin — Back4app Android SDK
// Calling a Cloud Code function: server-side logic, one line from the client
val params = mapOf("movie" to "Arrival")
val avg = ParseCloud.callFunction<Double>("averageStars", params)
// The aggregation ran NEXT TO the database — only the answer crossed the wire
// The function lives in cloud/main.js on your backend — update it anytime;
// every client gets the new logic instantly, no app-store release required.

Wer tausend Bewertungen auf dem Smartphone mittelt, muss tausend Bewertungen herunterladen; die Funktionsvariante überträgt eine einzige Zahl. Dieses Bandbreitenargument lässt sich zum gesamten Plädoyer für serverseitige Logik verallgemeinern, das weiter unten folgt.

Die Trigger-Taxonomie

Viele Erklärtexte handeln Trigger in einem Satz ab; die Struktur verdient eine Tabelle:

Warum Logik auf den Server gehört

Vier Argumente, die in den meisten Erklärtexten fehlen. Vertrauen Sie nicht dem Client: Apps werden dekompiliert und Anfragen gefälscht; Preisberechnungen, Berechtigungsprüfungen und Spielstände, die auf dem Gerät berechnet werden, sind Vorschläge – dieselbe Logik in einer Funktion ist verbindlich. Ein beforeSave-Trigger validiert jeden Schreibvorgang, egal welcher Client ihn gesendet hat. Secrets bleiben zu Hause: API-Schlüssel von Drittanbietern liegen in der Umgebung der Funktion, niemals in einem Bundle, das jeder entpacken kann – die Disziplin beim Umgang mit API-Schlüsseln, strukturell verankert. Aktualisieren ohne Release: Änderungen an der Serverlogik erreichen sofort alle Nutzer, ohne App-Store-Review zwischen dem Fix und der behobenen App. Rechnen, wo die Daten liegen: Aggregation, Aufbereitung von Suchergebnissen und Fan-out laufen Mikrosekunden von der Datenbank entfernt statt über ein Mobilfunknetz.

Cloud Code vs. eigenständiges FaaS vs. Container

Der Eintrag zur Serverless-Architektur behandelt das Modell im Ganzen, und die Einordnung von FaaS in die Cloud-Servicemodelle hat einen eigenen Artikel. Entscheidend ist hier die Zeile Kontext: Cloud-Code-Funktionen sind von Geburt an verbunden – dasselbe SDK, dieselbe Session-Semantik, ACLs, die bei ihren Abfragen durchgesetzt werden –, während eigenständiges FaaS jedes Projekt mit Verdrahtungsarbeit beginnt.

Cold Starts und Zustandslosigkeit, ohne Beschönigung

Zwei Eigenschaften folgen aus der Skalierung pro Anfrage, und beide verdienen eine klare Aussage. Cold Starts treten auf, wenn eine auf null skalierte Funktion vor der Ausführung erst eine Umgebung initialisieren muss – auf typischen Plattformen Hunderte Millisekunden bis Sekunden. Abhilfe schaffen eine Mindestzahl warmer Instanzen und schlanke Bundles; bei Funktionen auf einem ständig laufenden Backend fallen sie architekturbedingt weg. Das ist ein echter Unterschied zwischen den beiden Varianten, kein Werbeversprechen. Zustandslosigkeit heißt: Per Vertrag überlebt nichts im Arbeitsspeicher zwischen zwei Aufrufen. Zähler, Caches und Sessions, die in einer Funktion gehalten werden, sind Bugs mit Zeitzünder. Zustand gehört in die Datenbank – und der unauffällige Vorteil der BaaS-Variante ist, dass die Datenbank nur eine Codezeile entfernt ist, statt ein Dienst zu sein, den Sie erst auswählen, anbinden und absichern müssen.

Typische Anwendungsfälle

• Validierung und Geschäftsregeln – beforeSave-Prüfungen, die Invarianten für jeden Client unverhandelbar machen.
• Aggregationen und Berichte – rechnen, wo die Daten liegen; Antworten zurückgeben, keine Datensätze.
• Integration von Drittanbietern – Zahlungen, E-Mail und KI-APIs, aufgerufen mit serverseitig gehaltenen Secrets.
• Webhook-Empfänger und -Sender – Funktionen als HTTP-Schnittstelle von Ereignisintegrationen.
• Geplante Wartung – Digests, Bereinigungen und Durchläufe per Cron, ohne eigene Worker-Flotte.

Sollte es eine Funktion sein? Entscheidungsmatrix

Grenzen und Trade-offs

• Timeouts sind Verträge. Funktionen sind auf Sekunden bis Minuten begrenzt; Arbeit, die diese Grenze überschreiten könnte, braucht eine Job-Queue, keine Hoffnung.
• Zustandslosigkeit ist strikt. Alles im Arbeitsspeicher ist flüchtig; Designs, die das vergessen, bestehen die Tests und scheitern beim Scale-out.
• Wildwuchs ist das typische Scheitern. Fünfzig kleine Funktionen ohne gemeinsame Module und Benennungsdisziplin werden zu einem verteilten Monolithen mit schlechteren Werkzeugen.
• Debugging ist naturgemäß remote. Logs und Traces ersetzen Breakpoints; Plattformen mit guten Log-Oberflächen zahlen sich hier aus.
• Bei Dauerlast kippt die Kostenrechnung. Nutzungsbasierte Abrechnung ist bei sprunghafter Last unschlagbar und wird bei konstant hohem Durchsatz von ständig laufenden Servern geschlagen – rechnen Sie mit Ihrer Lastkurve, nicht mit dem Werbeprospekt.

Cloud Code mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Cloud Code ist hier die BaaS-Variante in ihrer ursprünglichen Form: JavaScript, das in Ihr Back4app-Backend deployt wird – Parse.Cloud.define für aufrufbare Funktionen wie im Beispiel der Code-Tabs, beforeSave/afterSave-Trigger für Datenregeln, Auth-Hooks und geplante Jobs, alles in einer Codebasis und einem Deployment. Die Funktionen laufen mit angebundenem Kontext: dasselbe SDK, das Ihre Clients verwenden, ACLs und Class-Level Permissions, die bei Abfragen durchgesetzt werden, Master-Key-Zugriff, wenn Admin-Logik sie berechtigterweise umgehen muss, und Secrets in der serverseitigen Konfiguration. Da das Backend ständig läuft, tritt der Cold Start bei Skalierung ab null nie auf – und da die Plattform Open Source ist, lassen sich die Funktionen auf jeden Host portieren, auf dem sie läuft. Das ist die praktische Antwort auf die Lock-in-Frage.