REX | gRPC

gRPC est un framework gratuit et open-source permettant aux utilisateurs définir les REQUÊTES et les RÉPONSES pour du RPC (Remote Procedure Calls).

Il a été développé par Google et maintenu par la CNCF (Cloud Native Computation Foundation) au même titre que Docker, et Kubernetes.

gRPC est un framework moderne, de faible latence conseillé pour ses performances, et son effet catalyseur dans une architecture micro-service.

Il utilise le protocole HTTP/2 pour le transport, est language-independant, supporte le streaming, et facilite l’intégration de l’authentification, le load balancing, le logging, et le monitoring.

Protocole RPC

RPC signifie Remote Procedure Calls que l’on pourrait traduire par appel de fonction à distance.

En effet, dans le code côté Client, cela revient à appeler une fonction directement sur le Serveur.

1
2
3
4
5
6
7
8
9

    // SERVER SIDE (any language)
    def CreateUser(user) {
        ...
    }
        
    // CLIENT SIDE (any language)
    ...
    server.CreateUser(user)
    ...

    Par contre, derrière nous aurons bien un échange sur le réseau entre le Client et le Serveur.

Dans cet exemple, nous voyons bien l’interaction entre 1 serveur et 2 clients, développés dans des languages différents.

Génération de code

Pour pouvoir supporter tous les languages, nous allons donc générer un SDK côté client et serveur.

gRPC propose un language et format de sérialisation pour définir le contrat d’API : Protocol Buffers.

Un fichier .proto fonctionne pour plus de 12 languages de programmation, et permet d’utiliser gRPC et de scaler jusqu’à plusieurs millions de RPC à la seconde.

L’avantage de la génération de code est :

• Support de (presque) tous les languages
• Documentation gratuite
• Design de l’API en amont (modèles de données, fonctionnalités)
• Moins de code à maintenir
• Gain de temps
• Très facile de brancher un nouveau micro-service (quelque soit le language)
• Permet de se concentrer sur le code fonctionnel du micro-service

Protocol Buffers vs JSON

• Protocol Buffers sérialise les messages sous un format binaire compact
• JSON est sous forme de texte human-readable
• Protocol Buffers est plus léger que JSON, ce qui réduit l’usage de la bande passante
• Protocol Buffers requiert moins de puissance pour être parsée, ce qui le rend plus performant pour les appareils mobiles

Types d’API dans gRPC

Il y a 4 types d’API dans gRPC :

• Unary: C’est le fonctionnement traditionnel avec une requête et une réponse (comme REST)
• Streaming Server: Le serveur répond au client en streaming (chunks de données, live feed, notifications)
• Streaming Client: Le client requête le serveur en streaming (chunks de données, backpressure)
• Bi Directional Streaming: Le client requête le client en streaming et le serveur répond au client en streaming (chat, long running connections, )

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

service GreetService {
    // Unary
    rpc Greet(GreetRequest) returns (GreetResponse) {};

    // Streaming Server
    rpc GreetManyTimes(GreetManyTimesRequest) returns (stream GreetManyTimesResponse) {};

    // Streaming Client
    rpc LongGreet(stream LongGreetRequest) returns (LongGreetResponse) {};

    // Bi Directional Streaming
    rpc GreetEveryone(stream GreetEveryoneRequest) return (steam GreetEveryoneResponse) {};
}

Scalabilité

• Les serveurs gRPC sont asynchrones par défaut.
• Les clients gRPC peuvent être synchrones (bloquant) ou asynchrones en fonction du besoin.
• Les clients gRPC peuvent effectuer du client-side load balancing (horizontal scaling).
• gRPC permet de scale à plusieurs millions de RPCs par secondes

Sécurité

gRPC intègre le protocole SSL/TLS ainsi qu’un système d’authentification (token-based) avec Google (uniquement pour se connecter à des services de Google).

gRPC vs REST

Concernant le Benchmark, gRPC serait 25 fois plus rapide que REST

Conclusion

L’argument de l’utilisation du protocole HTTP/2 suffit à lui seul à justifier le choix de gRPC.

Durant mes années de développement d’API REST, j’ai perdu énormément de temps en discussions d’équipe sur des sujets sans valeur ajoutée autour du nommage des routes par exemple.

Le framework gRPC permet réellement de réduire la charge de travail dans le développement d’API, et gère toute la partie mécanique pour nous.

Nous pouvons ainsi nous concentrer sur les vrais questions telles que les modèles de données, les fonctionnalités, le métier.