Serverless en Swift : AWS Lambda et alternatives pour le backend

Formateur Python en ligne pour débutants

Apprenez Python facilement sans surcharge théorique. Résolvez des tâches pratiques avec vérification automatique et écrivez du code directement dans le navigateur.

Start Course

Serverless en Swift : quand le développeur mobile va dans le cloud

\n\n

Vous écrivez en Swift pour iOS, macOS ou watchOS. Votre code est beau, sécurisé et rapide. Mais tôt ou tard, une question se pose : et si on déportait la logique backend vers le même langage ? Ne pas multiplier les entités avec Python, Node.js ou Go, mais simplement écrire une fonction cloud en Swift natif ?

\n\n

Bonne nouvelle : c'est déjà une réalité. Les fonctions Serverless en Swift fonctionnent sur AWS Lambda, Google Cloud Run et même Vercel. Oui, l'écosystème n'est pas aussi mature que celui de JavaScript, mais pour les développeurs mobiles qui veulent contrôler à la fois le client et le serveur, c'est une mine d'or.

\n\n

Dans cet article, nous allons voir comment exécuter Swift dans un environnement serverless, quels sont les pièges à éviter et où trouver des modèles prêts à l'emploi. C'est parti.

\n\n

Pourquoi Swift plutôt que Python ou Node.js ?

\n\n

Soyons honnêtes : si vous avez besoin de rapidement bricoler un analyseur ou une API simple, Python ou Node.js seront plus pratiques. Mais Swift a des atouts qui pèsent lourd pour les charges de production :

\n\n

Performance — Swift se compile en code natif. Sur AWS Lambda, cela donne un gain de vitesse de 2 à 3 fois par rapport à Node.js pour des budgets mémoire identiques.
Typage et sécurité — Optionals, typage strict, absence d'objets nil. Les erreurs qui apparaîtront en Python à l'exécution seront détectées en Swift dès la compilation.
Stack unifié — si vous êtes développeur iOS, vous n'avez pas besoin d'apprendre un second langage pour le backend. Une seule base de code, mêmes structures, même logique.
Écosystème Vapor — le framework Swift le plus populaire pour le serveur, qui s'adapte parfaitement au serverless.

\n\n

Bien sûr, il y a des inconvénients : la taille du binaire (environ 15-30 Mo contre 500 Ko pour Node.js) et moins de bibliothèques prêtes à l'emploi. Mais pour les microservices et les passerelles API, ce n'est pas critique.

\n\n

Base technique : comment Swift fonctionne sur AWS Lambda

\n\n

Amazon supporte officiellement Swift via Custom Runtime. Vous n'utilisez pas le runtime intégré Node.js ou Python — vous empaquetez votre fichier exécutable dans un ZIP et le téléchargez dans Lambda.

\n\n

Voici à quoi cela ressemble au niveau de l'architecture :

\n\n

Lambda appelle votre binaire comme une commande shell.
Votre code lit l'événement depuis stdin (JSON), le traite et écrit la réponse dans stdout.
L'API Runtime (via HTTP) est utilisée pour envoyer des rapports et des erreurs.

\n\n

Cela semble compliqué ? En pratique, nous utilisons le modèle prêt à l'emploi Swift AWS Lambda Runtime d'Apple. Il prend en charge toute la routine.

\n\n

Exemple : un gestionnaire Lambda simple en Swift

\n\n

Créons une fonction qui reçoit le nom d'un utilisateur et renvoie un message de bienvenue. C'est le classique hello-world pour le serverless.

\n\n

// Importons la bibliothèque d'Apple\nimport AWSLambdaRuntime\nimport AWSLambdaEvents\n\n// Structures pour l'entrée et la sortie\nstruct GreetingRequest: Codable {\n    let name: String\n}\n\nstruct GreetingResponse: Codable {\n    let message: String\n}\n\n// Gestionnaire principal\nLambda.run { (context, request: GreetingRequest, callback: @escaping (Result<GreetingResponse, Error>) -> ()) in\n    let response = GreetingResponse(message: "Bonjour, \\(request.name)! Bienvenue dans le serverless en Swift.")\n    callback(.success(response))\n}\n

\n\n

Ce code est compilé en un binaire. Vous l'empaquetez dans un ZIP avec les bibliothèques (liaison statique) et le téléchargez dans AWS Lambda. Le Runtime trouvera lui-même le point d'entrée.

\n\n

Important : pour la production, utilisez une image Docker basée sur Amazon Linux 2, sinon vous pourriez avoir des problèmes avec glibc.

\n\n

Compilation et déploiement : plan étape par étape

\n\n

Pour ne pas perdre de temps avec des complications inutiles, utilisez l'utilitaire prêt à l'emploi aws-lambda-swift-sam. C'est une surcouche d'AWS SAM (Serverless Application Model).

\n\n