--- term: 'Cloud Code (Serverless-Funktionen)' seoTitle: 'Cloud Code und Serverless-Funktionen: FaaS, Trigger, Cold Starts' headline: 'Was ist Cloud Code (Serverless-Funktionen)?' slug: cloud-code-serverless-funktionen category: backend-compute shortDefinition: 'Cloud Code ist ein Serverless-Modell, bei dem Backend-Logik als serverseitige Funktionen läuft, ausgelöst durch Aufrufe, Datenereignisse oder Zeitpläne.' relatedTerms: - serverless-architecture - baas-vs-serverless - iaas-paas-baas-faas - webhooks contrastsWith: - edge-computing-edge-functions aboutTerms: - 'FaaS (Functions-as-a-Service)' - 'Cloud Functions' - 'Function Triggers' faq: - question: 'Was ist eine Serverless-Funktion?' answer: 'Ein kleiner, auf eine Aufgabe zugeschnittener Block serverseitigen Codes, den eine Plattform bei Bedarf als Reaktion auf ein Ereignis ausführt – einen HTTP-Aufruf, eine Datenänderung, einen Zeitplan. Bereitstellung, Skalierung und Wartung übernimmt der Anbieter. Sie deployen Logik; die Maschinerie, die sie ausführt, gehört der Plattform.' - question: 'Was ist der Unterschied zwischen FaaS und Serverless?' answer: 'FaaS – Functions-as-a-Service – ist die Compute-Hälfte von Serverless: einzelne Funktionen, die durch Ereignisse ausgelöst werden. Serverless ist das umfassendere Modell, das auch verwaltete Backend-Dienste einschließt (Datenbank, Authentifizierung, Speicher – die BaaS-Hälfte). Cloud Code ist der Punkt, an dem beide Hälften zusammenkommen: Funktionen, die mit einem verwalteten Backend laufen.' - question: 'Wie werden Serverless-Funktionen ausgelöst?' answer: 'Es gibt fünf Familien: direkte Aufrufe (ein Client oder eine API ruft die Funktion beim Namen auf), Datenbankereignisse (Code, der vor oder nach Speicher- und Löschvorgängen läuft), Auth-Ereignisse (Hooks bei Anmeldung und Registrierung), Zeitpläne (Jobs im Cron-Stil) und eingehende Webhooks externer Systeme. Eine gute Plattform bietet alle fünf als Registrierung an, nicht als Infrastruktur.' - question: 'Was ist ein Cold Start?' answer: 'Die Latenz – Hunderte Millisekunden bis Sekunden –, die entsteht, wenn eine Plattform für eine auf null skalierte Funktion erst eine frische Ausführungsumgebung initialisieren muss. Gegenmittel sind eine Mindestzahl warmer Instanzen und kleinere Bundles; Funktionen auf einem ständig laufenden Backend umgehen den Fall der Skalierung ab null vollständig.' - question: 'Warum müssen Serverless-Funktionen zustandslos sein?' answer: 'Weil jede von vielen parallelen, kurzlebigen Instanzen die nächste Anfrage bedienen kann – Daten, die zwischen Aufrufen im Speicher gehalten werden, sind ein Bug, der nur darauf wartet, zu verschwinden. Persistenter Zustand gehört in eine Datenbank oder einen Cache. In der BaaS-Variante ist die Datenbank bereits angebunden, was einen Großteil des Komforts dieses Modells ausmacht.' - question: 'Wo liegen die Grenzen von Serverless-Funktionen?' answer: 'Plattformen begrenzen Ausführungszeit (standardmäßig Sekunden, höchstens einige Minuten), Arbeitsspeicher und Payload-Größen – lang laufende Arbeit gehört in Hintergrund-Jobs, und dauerhaft hoher Durchsatz kann mehr kosten als ein ständig laufender Server. Diese Grenzen sind der Preis für die Skalierung pro Anfrage.' - question: 'Was ist der Unterschied zwischen Serverless-Funktionen und Microservices?' answer: 'Es sind verschiedene Achsen: Microservices sind eine architektonische Zerlegung, Serverless ist ein Ausführungsmodell. Eine Funktion ist feingranularer als ein Microservice, und ein Microservice lässt sich als Funktionen, Container oder Ausschnitt eines Monolithen umsetzen. Container bringen Kontrolle und langlebige Prozesse; Funktionen bringen null Betriebsaufwand und Skalierung pro Anfrage.' - question: 'Führen Serverless-Funktionen zu einem Vendor-Lock-in?' answer: 'Proprietäre Ereignisformate und Werkzeuge erzeugen auf geschlossenen Plattformen eine echte Kopplung. Das Gegengewicht ist Open Source: Funktionen, die gegen offene Runtimes geschrieben sind – darunter das quelloffene Cloud Code von Back4app, das auf jedem Node.js-Host läuft –, ziehen mit Ihrem Backend um, statt Sie an das Eventing einer einzelnen Cloud zu binden.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Serverless Architectures — Martin Fowler' url: 'https://martinfowler.com/articles/serverless.html' - name: 'CNCF Serverless Whitepaper' url: 'https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview' - name: 'Cloud Code guide' url: 'https://docs.parseplatform.org/cloudcode/guide/' - name: 'OpenFaaS — open-source functions' url: 'https://www.openfaas.com/' - name: 'Function as a service — Wikipedia' url: 'https://en.wikipedia.org/wiki/Function_as_a_service' cta: title: 'Funktionen, die bei Ihrem Backend wohnen' text: 'Back4app Cloud Code führt Ihr JavaScript direkt neben Datenbank, Authentifizierung und Dateien aus – aufrufbare Funktionen, Save-Trigger und geplante Jobs in einem Deployment, ohne Server und ohne Cold-Start-Aufschlag.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-18' translationKey: cloud-code-serverless-functions --- **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 | Frage | Antwort | | --- | --- | | Die vier Eigenschaften | Ereignisgesteuert · zustandslos · automatisch skalierend · nutzungsbasiert abgerechnet | | Die zwei Varianten | Eigenständige FaaS-Einheiten vs. Cloud Code direkt in Ihrem Backend | | Die Trigger-Familien | Aufruf per Name · Datenereignisse · Auth-Ereignisse · Zeitpläne · Webhooks | | Warum serverseitig | Clients lassen sich dekompilieren; Funktionen lassen sich nicht manipulieren | | Die ehrlichen Grenzen | Timeouts, Zustandslosigkeit und Cold Starts (wo auf null skaliert wird) | ## Eine Funktion, von überall aufgerufen Das klassische Aggregationsbeispiel – rechnen, wo die Daten liegen, und nur das Ergebnis übertragen: **JavaScript:** ```javascript // 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 // 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. ``` **Swift:** ```swift // 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. ``` **Kotlin:** ```kotlin // 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("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: | Trigger-Familie | Wird ausgelöst, wenn | Typischer Einsatz | | --- | --- | --- | | Aufrufbare Funktionen | Ein Client sie per Name mit JSON-Parametern aufruft | Geschäftslogik, Aggregationen, Aktionen | | Daten-Trigger | Vor/nach Save, Delete, Find auf einer Klasse | Validierung, Standardwerte, Kaskaden, Audit | | Auth-Trigger | Vor der Anmeldung, nach Registrierung/Abmeldung | Sperrlisten, Willkommensabläufe, Audit-Ereignisse | | Geplante Jobs | Cron-Ausdrücke | Berichte, Bereinigungen, TTL-Durchläufe, Digests | | Eingehende [Webhooks](/glossary/webhooks/) | Ein externes System ein Ereignis per POST sendet | Zahlungsbestätigungen, CI-Benachrichtigungen | ```mermaid flowchart LR accTitle: Ereignisquellen, die Serverless-Funktionen neben einem verwalteten Backend auslösen accDescr: Client-Aufrufe, Speicherereignisse der Datenbank, Authentifizierungsereignisse, Cron-Zeitpläne und externe Webhooks lösen serverseitige Funktionen aus. Diese lesen und schreiben die verwaltete Datenbank, rufen externe APIs mit serverseitig gehaltenen Secrets auf und liefern Ergebnisse zurück, während die Plattform die Ausführung automatisch skaliert. C["Client-Aufruf
per Name"] --> F["Funktion
(Ihre Logik, verwaltete Runtime)"] D["Datenereignis
vor/nach Save"] --> F A["Auth-Ereignis
Anmeldung, Registrierung"] --> F S["Zeitplan
Cron"] --> F W["Externer Webhook"] --> F F --> DB[("Verwaltete Datenbank
ACLs durchgesetzt")] F -->|"Secrets bleiben auf dem Server"| X["APIs von Drittanbietern"] ``` ## 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](/glossary/api-key-security/), 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 | | Cloud Code (BaaS-Funktionen) | Eigenständiges FaaS | Container | | --- | --- | --- | --- | | Läuft | In der Runtime Ihres Backends | Isolierte Einheiten pro Funktion | Wo immer Sie sie orchestrieren | | Kontext | Datenbank, Authentifizierung, ACLs bereits angebunden | Jeder Dienst manuell verdrahtet | Was immer Sie einbauen | | Deployment-Einheit | Eine Codebasis, ein Deployment | Pro Funktion | Pro Image | | Cold Starts | Keine – das Backend läuft bereits | Ja, bei Skalierung ab null | Nur wenn Sie auf null skalieren | | Privilegierte Operationen | Master-Key-Zugriff für Admin-Logik | IAM-Verdrahtung pro Funktion | Ihre eigene Auth-Infrastruktur | | Skalierung | Mit dem Backend | Pro Anfrage, bis auf null | Wie konfiguriert | | Passt zu | App-Backends auf einem BaaS | Sprunghafte, isolierte Ereignisarbeit | Lang laufende, zustandsbehaftete Dienste | Der Eintrag zur [Serverless-Architektur](/glossary/de/serverless-architektur/) behandelt das Modell im Ganzen, und [die Einordnung von FaaS in die Cloud-Servicemodelle](/glossary/de/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](/glossary/webhooks/)-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 | Aufgabe | Richtiger Ort | | --- | --- | | Logik, die Clients manipulieren könnten | Funktion – immer | | Sprunghafte, ereignisförmige Aufgaben | Funktion | | Lang laufende Berechnungen (Minuten und mehr) | Hintergrund-Job, keine Funktion | | Zustandsbehaftete, ständig laufende Dienste (Sockets, Queues) | Container / Plattformdienste | | Latenzkritischer Hot Path bei enormem Dauervolumen | Messen – ein ständig laufender Server kann gewinnen | | Alles, was ein Secret berührt | Funktion – das Secret wird nie ausgeliefert | ## 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](/glossary/class-level-permissions-clp/), 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.