Que sont l'edge computing et les fonctions edge serverless ?

L’edge computing est un modèle qui rapproche le calcul des utilisateurs ou des données ; les fonctions edge, du code serverless exécuté dans les PoP d’un CDN. Le terme général — défini de façon canonique par Shi et al. comme un calcul placé près des sources de données — couvre aussi bien l’IoT des ateliers que l’infrastructure télécom MEC. Pour les développeurs backend, il désigne quelque chose de précis : de petites fonctions déployées sur les mêmes points de présence mondiaux qu’un CDN, exécutées dans le PoP le plus proche de chaque requête — l’évolution du CDN, de la mise en cache de contenu vers l’exécution de code.

Points clés

Une fonction edge, et la couche où elle vit

// JavaScript — an edge function (web-standard APIs, runs at every POP)
// Gateway logic at the edge; the backend stays the source of truth
export default async function handler(request) {
  const url = new URL(request.url);
  const country = request.headers.get('x-user-country') ?? 'US';

  if (url.pathname === '/' && country !== 'US') {
    return Response.redirect(`${url.origin}/${country.toLowerCase()}/`, 302);
  }
  // Reject requests without credentials at the edge; full verification and data work go to the origin
  const auth = request.headers.get('Authorization');
  if (!auth) return new Response('Unauthorized', { status: 401 });

  return fetch(request); // pass through to the origin backend
}

// Flutter / Dart — Back4app Flutter SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
final query = QueryBuilder<ParseObject>(ParseObject('Post'))
  ..whereEqualTo('status', 'published')
  ..setLimit(20);
final response = await query.query();
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// iOS / Swift — Back4app Swift SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
let query = Post.query("status" == "published")
  .limit(20)
let posts = try await query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

// Android / Kotlin — Back4app Android SDK
// The three-layer picture from the client's seat:
// CDN serves static assets · edge handles gateway logic · origin owns data
val query = ParseQuery.getQuery<ParseObject>("Post")
query.whereEqualTo("status", "published")
query.limit = 20
val posts = query.find()
// This query talks to the ORIGIN backend — where the database lives.
// Moving it "to the edge" would move the round trip, not remove it.

L’onglet JavaScript est la fonction edge elle-même — Request/Response standards du web, aucun framework, interception du trafic avant l’origine. Les onglets client montrent l’autre côté de l’architecture : les données applicatives continuent d’aller au backend d’origine, parce que c’est là que vit la base de données — la phrase à laquelle tout cet article revient sans cesse.

Isolates vs. conteneurs : pourquoi l’edge démarre en millisecondes

Des milliers d’isolates partagent un seul processus de longue durée par machine — le même mécanisme qui sépare les onglets d’un navigateur — si bien que “démarrer” une fonction revient à créer un contexte, pas à démarrer un runtime. C’est cette architecture, et non des pools préchauffés, qui permet aux plateformes edge d’annoncer honnêtement des cold starts quasi nuls. L’addition se lit aux troisième et quatrième lignes : une frontière d’isolation plus faible (compensée par des mitigations soigneuses) et un runtime où une grande partie de npm ne fonctionne pas — pas de système de fichiers, pas de modules natifs, pas d’évaluation dynamique, la surface portable étant désormais standardisée sous le nom de Minimum Common API (ECMA-429).

Edge vs. origine : la répartition des charges

La partie honnête : votre base de données reste au même endroit

La section que les présentations des fournisseurs omettent. Déplacer le calcul en edge ne déplace pas les données — cela transfère l’aller-retour de utilisateur → serveur à fonction → base de données, et pour les charges bavardes, c’est une régression : une fonction edge à 5 ms de l’utilisateur qui envoie cinq requêtes séquentielles à une base de données située à 150 ms passe 750 ms là où une fonction régionale colocalisée avec la base de données en passerait ~5. Ce calcul explique la discrète correction de trajectoire du secteur — certaines grandes plateformes edge recommandent désormais leurs runtimes régionaux pour la plupart des charges et ont ajouté des options pour épingler les fonctions près de la base de données, l’aveu le plus clair possible que la localité des données l’emporte sur la localité du calcul. Les remèdes partiels, par ordre de praticité : exécuter le code gourmand en données à l’origine (le tableau de répartition ci-dessus) ; regrouper en un seul aller-retour quand le code edge doit toucher aux données ; et répliquer les lectures vers l’extérieur via des caches clé-valeur en edge — trade-offs de cohérence à terme inclus. Les fonctions edge gagnent quand elles terminent leur travail en edge ; dès qu’elles doivent rappeler l’origine à chaque requête, la géographie cesse d’être de votre côté.

Quand l’edge relève de la sur-ingénierie

La plupart des applications sont un backend CRUD avec une base d’utilisateurs régionale — pour elles, un backend mono-région plus un CDN pour les ressources statiques est plus simple et souvent plus rapide de bout en bout qu’un niveau edge qui fait l’aller-retour jusqu’à la même base de données. Les fonctions edge méritent leur place quand la logique se termine en edge, pour une audience répartie dans le monde entier, sur un chemin où la latence est visible — trois conditions, toutes requises. Le modèle de coûts raconte la même histoire sous l’autre angle : les plateformes edge facturent à la requête plus les millisecondes CPU (bon marché pour une fine logique de gateway), tandis que les fonctions régionales facturent la durée réelle — y compris le temps que votre code passe à attendre la base de données à côté de laquelle il aurait dû se trouver.

Cas d’usage courants

• Barrières d’authentification — vérifiez un token de session au PoP ; les requêtes non authentifiées ne traversent jamais l’océan.
• Géo-personnalisation — langue, devise et routage de conformité décidés à quelques millisecondes de l’utilisateur.
• Répartition A/B et feature flags — attribution du cookie en edge, cohérente avant même le chargement de la page.
• Rate limiting et défense anti-bots — absorber les abus en périmètre, avec des compteurs par PoP dans un KV edge.
• L’edge computing au sens large — le sens IoT/télécom : capteurs d’usine et infrastructure 5G qui traitent localement, un sujet qui mérite son propre article, reconnu ici en une ligne.

Devriez-vous utiliser des fonctions edge ? Matrice de décision

Limites et trade-offs

• Le runtime est un sous-ensemble. Uniquement des API standards du web ; les ORM avec bindings natifs, les bibliothèques d’images et le code dépendant du système de fichiers ne fonctionnent pas — vérifiez l’arbre de dépendances avant de vous engager.
• Les plafonds CPU sont stricts. Quelques dizaines de millisecondes de calcul, c’est le budget ; les fonctions edge orientent le trafic, elles ne le traitent pas.
• L’état est ailleurs, par conception. Tout besoin stateful part vers l’origine ou vers un KV edge à cohérence à terme — aucun des deux n’est gratuit.
• Le débogage est distribué. Reproduire un bug qui ne survient que dans un PoP, sous une seule géographie, est une discipline en soi ; journaliser de manière centralisée depuis partout est la parade.
• Le balancier oscille. Les choix par défaut “edge d’abord” ont déjà été révisés une fois ; traitez l’edge comme un outil précis pour la logique de gateway, pas comme une identité d’architecture.

L’edge 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. Dans le schéma à trois couches que dessine cet article, Back4app est l’origine bien faite : la base de données et la logique métier Cloud Code vivent ensemble — la colocalisation qui rend le travail sur les données rapide — derrière un CDN qui sert fichiers et ressources statiques depuis les mêmes PoP qu’utiliserait un niveau edge. Les fonctions edge viennent ensuite s’insérer devant, comme fine logique de gateway, là où les trois conditions sont réunies : une redirection ici, une vérification de token là, avant de passer la main à une origine qui possède les données et applique les ACL à chaque requête. La leçon d’architecture qu’enseigne la section honnête — le calcul près de l’utilisateur, le travail sur les données près des données — correspond exactement à cette répartition, chaque couche faisant la part que la géographie favorise.