Les équipes adoptent généralement gRPC pour l'une des deux raisons.
La bonne raison est qu'elles disposent d'un ensemble croissant de services internes et souhaitent un contrat plus strict, mieux outillé que le JSON ad hoc sur HTTP. La mauvaise raison est qu'elles ont entendu dire que REST est "hérité" et souhaitent remplacer chaque API sans être claires sur le problème qu'elles cherchent à résoudre.
gRPC est excellent dans le premier cas. Il est souvent inutile dans le second.
Ce que gRPC Améliore Réellement
Pour les appels de service à service internes, gRPC vous offre quelques avantages significatifs en même temps :
- un contrat basé sur un schéma dans des fichiers
.proto
- des clients et serveurs générés
- une sérialisation binaire compacte
- des modèles de streaming intégrés
Cette combinaison réduit beaucoup de dérive d'interface entre les services.
Voici le type de contrat qui vieillit mieux qu'une forme JSON à la documentation lâche :
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
string id = 1;
}
message GetUserResponse {
string id = 1;
string email = 2;
bool active = 3;
}
Une fois que ce schéma existe, le contrat cesse de vivre dans des messages Slack et des pages wiki à moitié mises à jour.
Comment Cela Aide en Pratique
Le plus grand avantage n'est généralement pas la vitesse de sérialisation brute. C'est la discipline de l'interface.
Si cinq services doivent tous communiquer avec le même service de facturation ou d'identité, des clients générés et un schéma stable réduisent beaucoup de bris accidentels. Vous arrêtez d'écrire manuellement les types de charge utile dans chaque consommateur et commencez à traiter la frontière de service comme une véritable surface de produit.
Cela compte plus avec le temps que de réduire quelques octets sur le fil.
Où REST Gagne Encore
REST a encore de forts avantages :
- il est facile à déboguer avec des outils courants
- il fonctionne naturellement avec les navigateurs
- il se mappe clairement aux API publiques
- il s'adapte bien aux fonctionnalités de mise en cache et aux sémantiques HTTP
C'est pourquoi de nombreux systèmes finissent par avoir un modèle scindé :
- REST ou JSON HTTP à la périphérie
- gRPC à l'intérieur du maillage
C'est souvent l'architecture la plus pragmatique.
Les Compromis
gRPC n'est pas gratuit.
Vous endossez :
- la gestion de schéma protobuf
- le code généré dans la chaîne d'outils
- une inspection moins pratique que le JSON ordinaire
- plus de friction pour les clients natifs du navigateur, sauf si vous ajoutez gRPC-Web ou un autre pont
C'est acceptable quand l'environnement est contrôlé. C'est moins acceptable lorsque l'API doit être largement consommable.
Une Règle de Décision Judicieuse
Utilisez gRPC lorsque :
- les appelants sont principalement des services internes
- des contrats solides sont importants
- vous souhaitez des clients générés à travers les équipes ou les langages
Restez avec REST lorsque :
- l'API est publique
- les navigateurs sont des consommateurs de première classe
- les sémantiques HTTP et la mise en cache comptent plus que l'ergonomie RPC
Le but n'est pas de choisir un gagnant pour chaque système. Le but est d'arrêter d'utiliser un protocole par habitude.
Lectures Complémentaires