gRPC en Swift : quand et pourquoi c'est vraiment nécessaire

gRPC en Swift : quand ce n'est pas seulement tendance, mais nécessaire

Imaginez : vous développez une application iOS pour gérer une maison intelligente. Les commandes sont envoyées chaque seconde, un délai de 100 ms est déjà une catastrophe. Ou vous créez un service de streaming où vidéo, audio et télémétrie circulent simultanément. REST commence alors à « ralentir » et à rester à l'écart. Faites connaissance avec — gRPC en Swift.

Mais soyons honnêtes : gRPC n'est pas une solution miracle. Parfois, un simple JSON sur HTTP/1.1 fonctionne mieux. Dans cet article, nous analyserons quand gRPC sur iOS est justifié, quand il vaut mieux garder REST, et à quoi cela ressemble dans du code Swift réel.

Je ne vais pas noyer le poisson. Seulement de la pratique, des exemples et des scénarios concrets. C'est parti.

Qu'est-ce que gRPC (très brièvement, pour ceux qui ont raté le coche)

gRPC est un framework RPC de Google qui utilise Protocol Buffers (protobuf) pour la sérialisation des données et HTTP/2 pour le transport. Il prend en charge :

\n
• Les appels unaires (comme un REST classique)
\n
• Le streaming côté serveur
\n
• Le streaming côté client
\n
• Le streaming bidirectionnel
\n

Sur Swift, il existe une bibliothèque officielle grpc-swift (Swift Package Manager) qui permet au client et au serveur de fonctionner en Swift. Oui, vous pouvez écrire un serveur en Swift avec gRPC — ce n'est pas une blague.

Quand gRPC en Swift est votre meilleur ami

1. Charge élevée et faible latence

Si votre application envoie des centaines de requêtes par seconde (par exemple, trading, gaming, IoT), gRPC l'emporte grâce à :

\n
• HTTP/2 — multiplexage, compression des en-têtes
\n
• Protocole binaire — protobuf est plus rapide à analyser que JSON
\n
• Connexions persistantes — pas besoin d'ouvrir une poignée de main TCP à chaque fois
\n

Exemple concret : une application de surveillance de serveurs. Chaque seconde, 1000 métriques arrivent. Avec REST — 1000 connexions TCP, avec gRPC — une seule connexion longue durée. La différence de charge sur la batterie est considérable.

2. Streaming de données

REST avec son « requête-réponse » ne sait pas diffuser en continu. Mais gRPC le peut. Si vous avez besoin de :

\n
• Recevoir des mises à jour de taux de change en temps réel
\n
• Diffuser de l'audio/vidéo en continu
\n
• Recevoir des logs du serveur au fur et à mesure
\n

Alors gRPC est votre choix. Voici à quoi ressemble le streaming côté serveur en Swift :

// Définition dans .proto\nservice StreamService {\n    rpc SubscribeToUpdates(Empty) returns (stream Update) {}\n}\n\n// Client en Swift\nlet client = StreamServiceAsyncClient(channel: channel)\nlet updates = client.subscribeToUpdates(Empty())\n\nfor try await update in updates {\n    print("Mise à jour reçue : \\(update.message)")\n}

Remarquez : for try await — c'est Swift Concurrency. gRPC-Swift fonctionne parfaitement avec cela.

3. Microservices en Swift (oui, ça existe)

Vous pouvez écrire tout le backend en Swift (Vapor, Hummingbird) et utiliser gRPC pour la communication interne entre microservices. Avantages :

\n
• Code de modèles partagé (protobuf génère des structures Swift)
\n
• Typage strict
\n
• Prise en charge intégrée des timeouts, des tentatives, de l'équilibrage de charge
\n

// Serveur en Swift\nfinal class GreeterProvider: GreeterAsyncProvider {\n    func sayHello(request: HelloRequest, context: GRPCAsyncServerCallContext) async throws -> HelloReply {\n        return HelloReply.with { $0.message = "Bonjour, \\(request.name)!" }\n    }\n}

Ce code est un serveur gRPC complet qui peut être exécuté sur n'importe quel serveur Linux/macOS.

4. Quand vous avez un système de contrat strict

Les fichiers Protobuf sont une source unique de vérité. Vous décrivez l'API dans un fichier .proto, générez le code pour Swift, Go, Python — et tout le monde parle le même langage. Plus de « oh, ici le champ est optionnel, mais là non ».

Pour les grandes équipes, c'est une bouée de sauvetage