Acme Design is a full service design agency.
Carmine Di Monaco
Senior Software Engineer @ SUSE
Carmine Di Monaco
Senior Software Engineer @ SUSE
Twitter @CDimonaco
Github CDimonaco
carmine.dimonaco@computer.org
carmine.dimonaco@suse.com
Standard per serializzazione/deserializzazione di strutture dati
Language-neutral
Platform neutral
Definizione dichiarativa della struttura del messaggio
Scrivi la shape una volta,
generi automaticamente gli stubs nei vari linguaggi
Forward compatibility out of the box, i vecchi stubs possono leggere i nuovi messaggi
Formato compatto e veloce da parsare
Adatto per payload di dimensioni ridotte, da non considerare se il payload eccede diversi megabyte, dato che il protocollo assume che il messaggio possa essere letto interamente in memoria
Impossibile comparare due messaggi senza averli completamente serializzati
Messaggi non compressi
Necessita' di avere lo "schema" di un messaggio protobuf per poterlo serializzare/deserializzare correttamente
Un messaggio protobuf e' una struttura chiave valore, che segue lo schema Type-length-value
Possiamo fare guessing del messaggio senza lo schema di partenza, cercando inferire il significato del messaggio.
message Todo {
string id = 1;
string title = 2;
string description = 3;
string created_at = 4;
bool completed = 5;
}
Proto3 - Language
Tipizzato - Estensibile
Supporto ad array e mappe
Supporto enum
I field numbers non devono essere cambiati una volta in uso
per garantire la compatibilita' tra diverse versioni dello stesso messaggio
I campi da 1 a 15 e' bene riservarli per campi dei messaggi piu' importanti e frequenti, questo per massimizzare i benefici dell'encoding (da 1 - 15 1 byte per encoding, 16 - 2047 2 byte etc..)
Non riutilizzare i field numbers in caso di campi eliminati, rischio elevato di corruzione dei dati. Utilizzare la reserved list sia per i field number che per i nomi dei campi cancellati
Non cambiare il tipo di un campo, il rischio di corruzione dei dati e' pari al riutilizzo di field numbers, vi sono alcune eccezioni. Nel caso assicurarsi che il nuovo messaggio sia un SUPERSET del vecchio messaggio
Non usare la rappresentazione testuale di un messaggio per scopi diversi dal logging/debugging
https://protobuf.dev/programming-guides/dos-donts/
Usecase - Protobuf in trento-project
Messaggi protobuf scambiati usando Rabbitmq
Repository centralizzato per i .proto, generazione automatica degli stubs e delle varie librerie nei linguaggi di destinazione
https://github.com/trento-project/contracts
I messaggi sono versionati, cosi' come le librerie di destinazione
Framework RPC universale
E' possibile utilizzare protobuf
Usa HTTP2
Streaming bidirezionale
Utilizzabile anche dal browser
Adatto per applicazioni dove vi sono requisiti di bassa latenza e alta scalabilita'
Le definizioni dei service GRPC possono essere espresse in proto
service TodoService {
rpc AddTodo(AddTodoRequest) returns (AddTodoResponse);
rpc GetTodo(GetTodoRequest) returns (GetTodoResponse);
rpc ListTodos(ListTodoRequest) returns (ListTodosResponse);
}Lo streaming e' bidirezionale, sia lato client che server
Language/Platform agnostic
type TodoServiceServer interface {
AddTodo(context.Context, *AddTodoRequest) (*AddTodoResponse, error)
GetTodo(context.Context, *GetTodoRequest) (*GetTodoResponse, error)
ListTodos(context.Context, *ListTodoRequest) (*ListTodosResponse, error)
mustEmbedUnimplementedTodoServiceServer()
}
Il generato GO richiede l'implementazione di handler GRPC
Esperienza di sviluppo simile a servizi web tradizionali
Vasta scelta di librerie/middleware di terze parti
Supporto ad autenticazione
https://github.com/CDimonaco/todo-grpc-talk
Tooling necessario
Andremo ad implementare una nuova rpc, per cancellare un todo gia' creato
Partiremo dalla business logic, fino alla generazione degli stub protobuf/grpc
Sara' tutto live coding, alla fine faremo un commit con le modifiche direttamente sul repository
Grazie
@CDimonaco
carmine.dimonaco@computer.org
carmine.dimonaco@suse.com
carmine.dimonaco@gmail.com