Qu'est-ce que Cloud Code (fonctions serverless) ?

Cloud Code est un modèle serverless où la logique backend s’exécute en fonctions côté serveur, déclenchées par appels, événements de données ou cron. Deux clarifications d’entrée de jeu, parce que cette famille de termes vit dans la confusion. Premièrement, “serverless” signifie que les serveurs sont le problème de quelqu’un d’autre — ils existent, invisibles, mis à l’échelle pour vous. Deuxièmement, les fonctions existent en deux architectures : le FaaS autonome, où chaque fonction est une unité isolée câblée à des services externes, et la variante BaaS qui donne son nom à cet article — des fonctions déployées dans votre backend, partageant leur environnement avec la base de données, l’authentification et les fichiers sur lesquels elles agissent.

Points clés

Une fonction, appelée de partout

L’exemple classique de l’agrégation — calculer à côté des données, n’expédier que la réponse :

// 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.

Faire la moyenne de mille avis sur le téléphone, c’est télécharger mille avis ; la version en fonction ne déplace qu’un seul nombre. Cet argument de bande passante se généralise en l’argumentaire complet pour la logique côté serveur, juste en dessous.

La taxonomie des triggers

Les explications superficielles listent les triggers en une phrase ; la structure mérite une table :

Pourquoi la logique appartient au serveur

Quatre arguments, presque toujours absents des explications habituelles. Ne faites pas confiance au client : les apps se décompilent et les requêtes se falsifient ; les calculs de prix, vérifications de permissions et scores de jeu calculés sur l’appareil sont des suggestions, tandis que la même logique dans une fonction fait loi — un trigger beforeSave valide chaque écriture, quel que soit le client qui l’a envoyée. Les secrets restent à la maison : les clés d’API tierces vivent dans l’environnement de la fonction, jamais dans un bundle que n’importe qui peut déballer — la discipline des clés d’API rendue structurelle. Mettez à jour sans release : les changements de logique serveur se déploient instantanément chez tous les utilisateurs, sans cycle de revue d’app store entre le correctif et le corrigé. Calculez près des données : l’agrégation, le façonnage des recherches et le fan-out s’exécutent à quelques microsecondes de la base de données, pas à l’autre bout d’un réseau mobile.

Cloud Code vs. FaaS autonome vs. conteneurs

L’article architecture serverless couvre le modèle dans son ensemble et la place du FaaS dans l’échelle des services a son propre article ; la ligne qui compte ici est contexte : les fonctions Cloud Code naissent connectées — même SDK, même sémantique de session, ACL appliquées à leurs requêtes — là où le FaaS autonome commence chaque projet par la plomberie.

Cold starts et statelessness, sans détour

Deux propriétés découlent de la mise à l’échelle par requête, et toutes deux méritent d’être dites clairement. Les cold starts surviennent quand une fonction descendue à zéro doit initialiser un environnement avant de s’exécuter — de quelques centaines de millisecondes à plusieurs secondes sur les plateformes typiques, atténués par des instances chaudes minimales et des bundles légers, et architecturalement absents pour les fonctions hébergées sur un backend toujours actif, ce qui est une différence réelle entre les deux saveurs, pas une vantardise de fournisseur. La statelessness signifie que, par contrat, rien en mémoire ne survit entre les invocations : compteurs, caches et sessions conservés dans une fonction sont des bugs à retardement. L’état va dans la base de données — et l’avantage discret de la variante BaaS est que la base de données est à une ligne de code, pas derrière un service qu’il faut d’abord choisir, connecter et sécuriser.

Cas d’usage courants

• Validation et règles métier — des portes beforeSave qui rendent les invariants non négociables sur tous les clients.
• Agrégations et rapports — calculez à côté des données ; renvoyez des réponses, pas des datasets.
• Intégrations tierces — paiements, e-mail, API d’IA appelées avec des secrets conservés côté serveur.
• Récepteurs et émetteurs de webhooks — les fonctions comme visages HTTP des intégrations événementielles.
• Maintenance planifiée — digests, nettoyages et purges sur cron, sans flotte de workers à opérer.

Devriez-vous en faire une fonction ? Matrice de décision

Limites et trade-offs

• Les timeouts sont des contrats. Les fonctions sont plafonnées de quelques secondes à quelques minutes ; le travail qui pourrait dépasser le plafond exige une file de jobs, pas de l’espoir.
• La statelessness est stricte. Tout ce qui est en mémoire est éphémère ; les conceptions qui l’oublient passent les tests et échouent sous scale-out.
• La prolifération est le mode de défaillance. Cinquante petites fonctions sans modules partagés ni discipline de nommage deviennent un monolithe distribué avec un pire outillage.
• Le débogage est distant par nature. Logs et traces remplacent les points d’arrêt ; les plateformes dotées de bonnes surfaces de logs montrent ici tout leur intérêt.
• Le coût s’inverse sous charge soutenue. Le paiement à l’usage est imbattable pour le travail en pics mais peut être battu par des serveurs toujours actifs à débit élevé constant — chiffrez la courbe, pas la brochure.

Cloud Code sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Ici, Cloud Code est la saveur BaaS dans sa forme originale : du JavaScript déployé dans votre backend Back4app — Parse.Cloud.define pour les fonctions invocables comme celle des onglets de code, des triggers beforeSave/afterSave pour les règles de données, des hooks d’auth et des jobs planifiés, le tout dans un codebase et un déploiement. Les fonctions s’exécutent avec le contexte attaché : le même SDK que vos clients, les ACL et permissions au niveau des classes appliquées aux requêtes, l’accès master key disponible quand la logique d’administration doit légitimement les contourner, et les secrets dans la configuration côté serveur. Comme le backend tourne en permanence, le cold start du redémarrage depuis zéro ne s’applique tout simplement pas — et comme la plateforme est open-source, les fonctions sont portables vers n’importe quel hôte qui l’exécute, ce qui est la réponse pratique à la question du lock-in.