Definire un servizio gRPC con buffer di protocollo
Home » IT » Blog » Definire un servizio gRPC con buffer di protocollo
* Questo post è il terzo della serie su gRPC
Il primo passo nella costruzione di un servizio gRPC è quello di creare la definizione dell'interfaccia del servizio con i metodi che sono esposti da quel servizio insieme ai parametri di ingresso e ai tipi di ritorno.
Definire un servizio gRPC con buffer di protocollo
gRPC usa i buffer di protocollo (protocol buffers o protobufs) come IDL per definire l'interfaccia del servizio. I buffer di protocollo sono un meccanismo estensibile, indipendente dal linguaggio e dalla piattaforma, per serializzare i dati strutturati. La definizione dell'interfaccia del servizio è specificata in un file proto, che non è altro che un file di testo semplice con estensione .proto. I servizi gRPC sono definiti in un formato di buffer di protocollo ordinario, con i parametri del metodo RPC e i tipi di ritorno specificati come messaggi di buffer di protocollo. Poiché la definizione del servizio è un'estensione della specifica del buffer di protocollo, uno speciale plug-in gRPC viene utilizzato per generare codice dal suo file .proto.
❝ Un file proto, che non è altro che un file di testo semplice con estensione .proto, è usato per generare codice dal suo file .proto. ❞
Nell'esempio, l'interfaccia del servizio DrinkInfo, chiamata DrinkService, è definita usando protobuf come mostrato nel seguente snippet. Il DrinkService consiste in una definizione dell'interfaccia del servizio in cui si specificano i metodi remoti (addCreate e Get), i loro parametri di ingresso e di uscita, e la definizione del tipo (o formati dei messaggi) di questi parametri.
syntax = "proto3";
message DrinkMessage {
string id = 1;
string name = 2;
string desc = 3;
}
message DrinkMessages {
repeated DrinkMessage drinks = 1;
}
message Empty {}
service DrinkService {
rpc addCreate (DrinkMessage) returns (DrinkMessage);
rpc Get (Empty) returns (DrinkMessages);
}Come potete vedere, un servizio è un insieme di metodi (ad esempio addProduct e getProduct) che possono essere invocati da remoto. Ogni metodo ha parametri di input e tipi di ritorno che definiamo come parte del servizio o che possono essere importati nella definizione del protobuf.
I parametri di input e di ritorno possono essere un tipo definito dall'utente (ad esempio i tipi DrinkMessage e DrinkMessages) o un tipo di dati standard come la stringa. Questi tipi sono strutturati come messaggi, dove ogni messaggio è un piccolo record logico di informazioni contenente una serie di coppie nome-valore. Questi campi sono coppie nome-valore con numeri di campo unici (ad esempio, string id = 1) che sono usati per identificare i loro campi nel formato binario del messaggio.
Questa definizione di servizio è usata per costruire il lato server e client di un'applicazione gRPC. Nel prossimo post vi darò maggiori dettagli sull'implementazione del server gRPC.
Vorrei cogliere l'occasione per raccomandare alcuni libri che potrebbero essere di vostro interesse:
