Getting Started with gRPC-Rust - Streaming

1. Introduzione

In questo codelab, utilizzerai gRPC-Rust per creare un client e un server che costituiscono la base di un'applicazione di mappatura delle route scritta in Rust.

Al termine del tutorial, avrai un client che si connette a un server remoto utilizzando gRPC per ottenere informazioni sulle funzionalità di una route del client, creare un riepilogo della route del client e scambiare informazioni sulla route, ad esempio aggiornamenti sul traffico, con il server e altri client.

Il servizio è definito in un file Protocol Buffers, che verrà utilizzato per generare il codice boilerplate per il client e il server in modo che possano comunicare tra loro, risparmiando tempo e fatica nell'implementazione di questa funzionalità.

Questo codice generato si occupa non solo delle complessità della comunicazione tra il server e il client, ma anche della serializzazione e deserializzazione dei dati.

Obiettivi didattici

• Come utilizzare Protocol Buffers per definire un'API di servizio.
• Come creare un client e un server basati su gRPC da una definizione di Protocol Buffers utilizzando la generazione automatica del codice.
• Comprensione della comunicazione di streaming client-server con gRPC.

Questo codelab è rivolto agli sviluppatori Rust che non hanno familiarità con gRPC o che desiderano ripassare gRPC, o a chiunque altro sia interessato alla creazione di sistemi distribuiti. Non è richiesta alcuna esperienza precedente con gRPC.

2. Prima di iniziare

Prerequisiti

Assicurati di aver installato quanto segue:

• GCC. Segui le istruzioni riportate qui.
• Git: istruzioni di installazione qui.
• Rust, versione 1.88.0. Segui le istruzioni di installazione qui.

Ottieni il codice

Per non dover ricominciare da zero, questo codelab fornisce uno scaffold del codice sorgente dell'applicazione da completare. I passaggi seguenti ti mostreranno come completare l'applicazione, incluso l'utilizzo dei plug-in del compilatore del buffer di protocollo per generare il codice gRPC boilerplate.

Innanzitutto, crea la directory di lavoro del codelab e cd in essa:

mkdir streaming-grpc-rust-getting-started && cd streaming-grpc-rust-getting-started

Scarica ed estrai il codelab:

curl -sL https://github.com/grpc-ecosystem/grpc-codelabs/archive/refs/heads/2026.tar.gz \
  | tar xvz --strip-components=4 \
  grpc-codelabs-2026/codelabs/grpc-rust-streaming/start_here

In alternativa, puoi scaricare il file .zip contenente solo la directory del codelab ed estrarlo manualmente.

Scarica file ZIP

Il codice sorgente completato è disponibile su GitHub se non vuoi digitare un'implementazione.

3. Definisci messaggi e servizi

Il primo passo consiste nel definire il servizio gRPC dell'applicazione, i relativi metodi RPC e i tipi di messaggi di richiesta e risposta utilizzando Protocol Buffers. Il servizio fornirà:

• Metodi RPC denominati ListFeatures, RecordRoute e RouteChat che il server implementa e il client chiama.
• I tipi di messaggi Point, Feature, Rectangle, RouteNote e RouteSummary, che sono strutture di dati scambiate tra il client e il server quando si chiamano i metodi sopra.

Questi metodi RPC e i relativi tipi di messaggi verranno definiti nel file proto/routeguide.proto del codice sorgente fornito.

Protocol Buffers sono comunemente noti come protobuf. Per ulteriori informazioni sulla terminologia gRPC, consulta Concetti fondamentali, architettura e ciclo di vita di gRPC.

Definisci i tipi di messaggi

Definiamo innanzitutto i messaggi che verranno utilizzati dalle nostre RPC. Nel file proto/routeguide.proto del codice sorgente, definisci innanzitutto il tipo di messaggio Point. Un Point rappresenta una coppia di coordinate di latitudine e longitudine su una mappa. Per questo codelab, utilizza numeri interi per le coordinate:

message Point {
  int32 latitude = 1;
  int32 longitude = 2;
}

I numeri 1 e 2 sono numeri ID univoci per ciascuno dei campi nella struttura message.

Definisci quindi il tipo di messaggio Feature. Un Feature utilizza un campo string per il nome o l'indirizzo postale di un elemento in una località specificata da un Point:

message Feature {
  // The name or address of the feature.
  string name = 1;

  // The point where the feature is located.
  Point location = 2;
}

Poi un messaggio Rectangle che rappresenta un rettangolo di latitudine e longitudine, rappresentato da due punti diagonalmente opposti "lo" e "hi".

message Rectangle {
  // One corner of the rectangle.
  Point lo = 1;

  // The other corner of the rectangle.
  Point hi = 2;
}

Anche un messaggio RouteNote che rappresenta un messaggio inviato in un determinato punto.

message RouteNote {
  // The location from which the message is sent.
  Point location = 1;

  // The message to be sent.
  string message = 2;
}

Avremmo bisogno anche di un messaggio RouteSummary. Questo messaggio viene ricevuto in risposta a una RPC RecordRoute, illustrata nella sezione successiva. Contiene il numero di singoli punti ricevuti, il numero di funzionalità rilevate e la distanza totale percorsa come somma cumulativa della distanza tra ogni punto.

message RouteSummary {
  // The number of points received.
  int32 point_count = 1;

  // The number of known features passed while traversing the route.
  int32 feature_count = 2;

  // The distance covered in metres.
  int32 distance = 3;

  // The duration of the traversal in seconds.
  int32 elapsed_time = 4;
}

Definisci i metodi di servizio

Definiamo innanzitutto il nostro servizio e poi i nostri messaggi. Per definire un servizio, devi specificare un servizio denominato nel file .proto. Il file proto/routeguide.proto ha una struttura service denominata RouteGuide che definisce uno o più metodi forniti dal servizio dell'applicazione.

Definisci i metodi RPC all'interno della definizione del servizio, specificando i tipi di richiesta e risposta. In questa sezione del codelab, definiamo:

ListFeatures

Ottiene le Feature disponibili all'interno del Rectangle specificato. I risultati vengono trasmessi in streaming anziché restituiti contemporaneamente (ad es. in un messaggio di risposta con un campo ripetuto), poiché il rettangolo può coprire un'area estesa e contenere un numero elevato di funzionalità.

Un tipo appropriato per questa RPC è una RPC di streaming lato server: il client invia una richiesta al server e riceve uno stream per leggere una sequenza di messaggi. Il client legge dallo stream restituito finché non ci sono più messaggi. Come puoi vedere nel nostro esempio, devi specificare un metodo di streaming lato server inserendo la parola chiave stream prima del tipo di risposta.

rpc ListFeatures(Rectangle) returns (stream Feature) {}

RecordRoute

Accetta uno stream di Point su una route percorsa, restituendo un RouteSummary al termine del percorso.

In questo caso, una RPC di streaming lato client sembra appropriata: il client scrive una sequenza di messaggi e li invia al server, utilizzando di nuovo uno stream fornito. Una volta terminata la scrittura dei messaggi, il client attende che il server li legga tutti e restituisca la risposta. Devi specificare un metodo di streaming lato client inserendo la parola chiave stream prima del tipo di richiesta.

rpc RecordRoute(stream Point) returns (RouteSummary) {}

RouteChat

Accetta uno stream di RouteNote inviati durante il percorso di una route, mentre riceve altri RouteNote (ad es. da altri utenti).

Questo è esattamente il tipo di caso d'uso per lo streaming bidirezionale. Una RPC di streaming bidirezionale ha entrambi i lati che inviano una sequenza di messaggi utilizzando uno stream di lettura-scrittura. I due stream operano in modo indipendente, quindi i client e i server possono leggere e scrivere nell'ordine che preferiscono.

Ad esempio, il server potrebbe attendere di ricevere tutti i messaggi del client prima di scrivere le risposte oppure potrebbe leggere un messaggio e poi scriverne uno o una combinazione di letture e scritture.

L'ordine dei messaggi in ogni stream viene mantenuto. Devi specificare questo tipo di metodo inserendo la parola chiave stream prima della richiesta e della risposta.

rpc RouteChat(stream RouteNote) returns (stream RouteNote) {}

4. Genera il codice client e server

Ti abbiamo già fornito il codice generato dal file .proto nella directory generated/, incluse tutte le aggiunte che hai apportato sopra. Tuttavia, vorremmo dedicare un momento a spiegare come funziona la generazione del codice.

Il nostro file .proto descrive tutte le struct e le funzioni utilizzate da un client o un server. Utilizziamo uno script di build di Cargo (build.rs) insieme alla crate grpc-protobuf-build per generare automaticamente questo codice.

In Cargo.toml abbiamo già aggiunto grpc-protobuf-build come dipendenza di build.

In build.rs, configuriamo grpc_protobuf_build::CodeGen per compilare proto/routeguide.proto nella directory generated/. Le righe chiave sono le seguenti:

grpc_protobuf_build::CodeGen::new()
    .include("proto")
    .input("routeguide.proto")
    .output_dir("generated")
    .compile()
    .unwrap();

Questa chiamata alla generazione del codice della crate grpc_protobuf_build, passando routeguide.proto. Abbiamo inserito questo codice in modo che venga eseguito solo quando viene passato un flag di funzionalità, in modo che venga rigenerato solo quando lo desideri. Non devi eseguirlo ora, perché abbiamo già generato il codice per te.

cargo build --bin routeguide-server --features regenerate_proto

Quando esegui cargo build, build.rs compila le definizioni del buffer di protocollo nella directory generate/, tra cui:

• Definizioni di struct per i tipi di messaggi Point e Feature.
• Un tratto di servizio Tonic che dovremo implementare per il server: route_guide_server::RouteGuide.
• Un tipo di client gRPC-Rust che utilizzeremo per chiamare il server: route_guide_client::RouteGuideClient<T>.

Per ulteriori informazioni, consulta la guida protoc-gen-rust-grpc.

A questo punto, implementeremo i metodi di servizio sul server.

5. Implementa il servizio

Nota: un'implementazione del server nativa che utilizza gRPC-Rust è attualmente in fase di sviluppo; nel frattempo, i server vengono implementati utilizzando Tonic con piena interoperabilità con i client gRPC-Rust. Ricorda: puoi implementare server e client in modo indipendente in qualsiasi lingua e sono completamente interoperabili.

Innanzitutto, vediamo come creare un server RouteGuide. La creazione del servizio RouteGuide è composta da due parti:

• Implementazione dell'interfaccia di servizio generata dalla definizione del servizio: esecuzione del "lavoro" effettivo del nostro servizio.
• Esecuzione di un server gRPC per rimanere in ascolto delle richieste dei client e inviarle all'implementazione del metodo corretto.

In src/server/server.rs, possiamo portare il codice generato nell'ambito tramite la macro include_generated_proto! di gRPC e importare il tratto RouteGuide e Point.

mod grpc_pb {
    grpc::include_generated_proto!("generated", "routeguide");
}

pub use grpc_pb::{
    route_guide_server::{RouteGuideServer, RouteGuide},
    Point, Feature, Rectangle, RouteNote, RouteSummary
};

Possiamo iniziare definendo una struct per rappresentare il nostro servizio. Per il momento, possiamo farlo su src/server/server.rs:

#[derive(Debug)]
pub struct RouteGuideService {
    features: Vec<Feature>,
}

Ora dobbiamo implementare il tratto route_guide_server::RouteGuide dal codice generato.

Implementa RouteGuide

Dobbiamo implementare l'interfaccia RouteGuide generata. Ecco come apparirebbe l'implementazione. Questo è già presente nel modello.

#[tonic::async_trait]
impl RouteGuide for RouteGuideService {
    async fn list_features(
        &self,
        request: Request<Rectangle>,
    ) -> Result<Response<ListFeaturesStream>, Status> {
        ...
    }

    async fn record_route(
        &self,
        request: Request<tonic::Streaming<Point>>,
    ) -> Result<Response<RouteSummary>, Status> {
        ...
    }

    async fn route_chat(
        &self,
        request: Request<tonic::Streaming<RouteNote>>,
    ) -> Result<Response<RouteChatStream>, Status> {
        ...
    }
}

Esaminiamo in dettaglio ogni implementazione RPC.

RPC di streaming lato server: ListFeatures

Iniziamo con ListFeatures. Si tratta di una RPC di streaming lato server (il client invierà un messaggio, il server risponderà con molti), quindi dobbiamo inviare più Feature al nostro client.

async fn list_features(
        &self,
        request: Request<Rectangle>,
    ) -> Result<Response<ListFeaturesStream>, Status> {
    println!("ListFeatures = {:?}", request);

    let (tx, rx) = mpsc::channel(4);
    let features = self.features.clone();

    tokio::spawn(async move {
        for feature in &features[..] {
            if in_range(&feature.location().to_owned(), request.get_ref()) {
                println!("  => send {feature:?}");
                tx.send(Ok(feature.clone())).await.unwrap();
            }
        }
        println!(" /// done sending");
    });

    let output_stream = ReceiverStream::new(rx);
    Ok(Response::new(Box::pin(output_stream)))
}

Come puoi vedere, riceviamo un oggetto richiesta (il Rectangle in cui il nostro client vuole trovare Features). Questa volta, dobbiamo restituire uno stream di valori. Creiamo un canale e generiamo una nuova attività asincrona in cui eseguiamo una ricerca, inviando le funzionalità che soddisfano i nostri vincoli al canale. La metà dello stream del canale viene restituita al chiamante, racchiusa in un tonic::Response.

RPC di streaming lato client: RecordRoute

Ora esaminiamo qualcosa di un po' più complicato: il metodo di streaming lato client RecordRoute, in cui riceviamo uno stream di Points dal client e restituiamo un singolo RouteSummary con informazioni sul viaggio. Riceve uno stream come input, che il server può utilizzare sia per leggere che per scrivere messaggi. Può scorrere i messaggi del client utilizzando il metodo next() e restituire la singola risposta.

async fn record_route(
        &self,
        request: Request<tonic::Streaming<Point>>,
    ) -> Result<Response<RouteSummary>, Status> {
    println!("RecordRoute");
    let mut stream = request.into_inner();
    let mut summary = RouteSummary::default();
    let mut last_point = None;
    let now = Instant::now();

    while let Some(point) = stream.next().await {
        let point = point?;
        println!("  ==> Point = {point:?}");

        // Increment the point count
        summary.set_point_count(summary.point_count() + 1);

        // Find features
        for feature in &self.features[..] {
            if feature.location().latitude() == point.latitude() {
                if feature.location().longitude() == point.longitude(){
                    summary.set_feature_count(summary.feature_count() + 1);
                }
            }
        }

        // Calculate the distance
        if let Some(ref last_point) = last_point {
            let new_dist = summary.distance() + calc_distance(last_point, &point);
            summary.set_distance(new_dist);
        }
        last_point = Some(point);
    }
    summary.set_elapsed_time(now.elapsed().as_secs() as i32);
    Ok(Response::new(summary))
}

Nel corpo del metodo, utilizziamo il metodo next() dello stream per leggere ripetutamente le richieste del client in un oggetto richiesta (in questo caso un Point) finché non ci sono più messaggi. Se questo è None, lo stream è ancora valido e può continuare a leggere.

RPC di streaming bidirezionale: RouteChat

Infine, esaminiamo la nostra RPC di streaming bidirezionale RouteChat().

async fn route_chat(
        &self,
        request: Request<tonic::Streaming<RouteNote>>,
    ) -> Result<Response<RouteChatStream>, Status> {
    println!("RouteChat");

    let mut notes: HashMap<(i32, i32), Vec<RouteNote>> = HashMap::new();
    let mut stream = request.into_inner();

    let output = async_stream::try_stream! {
        while let Some(note) = stream.next().await {
            let note = note?;
            let location = note.location();
            let key = (location.latitude(), location.longitude());
            let location_notes = notes.entry(key).or_insert(vec![]);
            location_notes.push(note);
            for note in location_notes {
                yield note.clone();
            }
        }
    };
    Ok(Response::new(Box::pin(output)))
}

Questa volta riceviamo uno stream che, come nel nostro esempio di streaming lato client, può essere utilizzato per leggere e scrivere messaggi. Tuttavia, questa volta restituiamo i valori tramite lo stream del nostro metodo mentre il client sta ancora scrivendo messaggi nel suo stream di messaggi. La sintassi per la lettura e la scrittura qui è molto simile al nostro metodo di streaming client, tranne per il fatto che il server restituisce un RouteChatStream. Sebbene ogni lato riceva sempre i messaggi dell'altro nell'ordine in cui sono stati scritti, sia il client che il server possono leggere e scrivere in qualsiasi ordine: gli stream operano in modo completamente indipendente.

Creiamo lo stream di output utilizzando try_stream!, che indica che lo stream potrebbe restituire errori.

Avvia il server

Una volta implementato questo metodo, dobbiamo anche avviare un server gRPC in modo che i client possano effettivamente utilizzare il nostro servizio. Compila main().

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let addr = "[::1]:10000".parse().unwrap();
    println!("RouteGuideServer listening on: {addr}");
    let route_guide = RouteGuideService {
        features: load(),
    };
    let svc = RouteGuideServer::new(route_guide);
    Server::builder().add_service(svc).serve(addr).await?;
    Ok(())
}

Ecco cosa succede in main(), passo dopo passo:

1. Specifica la porta che vogliamo utilizzare per rimanere in ascolto delle richieste dei client
2. Crea un RouteGuideService con le funzionalità caricate
3. Crea un'istanza del server gRPC utilizzando RouteGuideServer::new() utilizzando il servizio che abbiamo creato.
4. Registra l'implementazione del servizio con il server gRPC.
5. Chiama serve() sul server con i dettagli della porta per eseguire un'attesa di blocco fino all'interruzione del processo.

6. Crea il client

In questa sezione, esamineremo la creazione di un client Rust per il nostro servizio RouteGuide in src/client/client.rs.

Innanzitutto, porta il codice generato nell'ambito.

mod grpc_pb {
    grpc::include_generated_proto!("generated", "routeguide");
}

use grpc_pb::route_guide_client::RouteGuideClient;
use grpc_pb::{Point, Rectangle, RouteNote};

Chiama i metodi di servizio

Ora vediamo come chiamare i metodi di servizio. In gRPC-Rust, le RPC di streaming sono asincrone e non bloccanti, utilizzando la sintassi async/await di Rust e gli stream Tokio.

RPC di streaming lato server: PrintFeatures

Nelle RPC di streaming lato server, il client invia un singolo messaggio di richiesta al server e riceve uno stream di messaggi di risposta. Ecco dove in client.rs chiamiamo il metodo di streaming lato server list_features() (che corrisponde alla dichiarazione RPC ListFeatures trovata nel nostro proto). Il server, a sua volta, invierà uno stream di messaggi Feature:

async fn print_features(client: &RouteGuideClient<Channel>) -> Result<(), Box<dyn Error>> {
    let rectangle = proto!(Rectangle {
        lo: proto!(Point {
            latitude: 400_000_000,
            longitude: -750_000_000,
        }),
        hi: proto!(Point {
            latitude: 420_000_000,
            longitude: -730_000_000,
        }),
    });

    let mut stream = client.list_features(rectangle).await;

    while let Some(feature) = stream.recv().await {
        println!(
            "FEATURE: Name = \"{}\", Lat = {}, Lon = {}",
            feature.name(),
            feature.location().latitude(),
            feature.location().longitude()
        );
    }
    let status = stream.status().await;
    assert!(status.is_ok(), "{:?}", status);
    Ok(())
}

RPC di streaming lato client: RecordRoute

Quando utilizziamo lo streaming lato client, il client aprirà uno stream al server e invierà una sequenza di messaggi. Riceverà un singolo messaggio di risposta al termine dello stream.

Qui, avviamo la chiamata con client.record_route().await, inviamo diverse coordinate Point generate una alla volta nello stream utilizzando stream.send(point).await e poi chiudiamo lo stream con stream.close_and_recv().await per ricevere il singolo messaggio RouteSummary del server.

async fn run_record_route(client: &RouteGuideClient<Channel>) -> Result<(), Box<dyn Error>> {
    let mut rng = rand::rng();
    let point_count: i32 = rng.random_range(2..100);

    let mut points = vec![];
    for _ in 0..=point_count {
        points.push(random_point(&mut rng));
    }

    println!("Traversing {} points", points.len());
    let mut stream = client.record_route().await;

    for point in &points {
        if stream.send(point).await.is_err() {
            break;
        }
    }

    match stream.close_and_recv().await {
        Ok(response) => {
            println!(
                "SUMMARY: Feature Count = {}, Distance = {}",
                response.feature_count(),
                response.distance()
            );
        }
        Err(e) => println!("something went wrong: {e:?}"),
    }
    Ok(())
}

RPC di streaming bidirezionale: RouteChat

Infine, esaminiamo la nostra RPC di streaming bidirezionale RouteChat(). Qui sia il client che il server passeranno una sequenza di messaggi avanti e indietro. Generiamo un'attività tokio per inviare continuamente messaggi al server con tx.send(note).await.is_err(). Nel frattempo, rx.recv().await rimane in ascolto dei messaggi di risposta del server e li stampa man mano che arrivano.

async fn run_route_chat(client: &RouteGuideClient<Channel>) -> Result<(), Box<dyn Error>> {
    let (mut tx, mut rx) = client.route_chat().await;

    let start = time::Instant::now();
    tokio::spawn(async move {
        let mut interval = time::interval(Duration::from_millis(50));
        for _ in 0..10 {
            let time = interval.tick().await;
            let elapsed = time.duration_since(start);
            let note = proto!(RouteNote {
                location: proto!(Point {
                    latitude: 409146138 + elapsed.as_millis() as i32,
                    longitude: -746188906,
                }),
                message: format!("at {elapsed:?}"),
            });
            if tx.send(note).await.is_err() {
                return;
            }
        }
        tx.close();
    });

    while let Some(note) = rx.recv().await {
        println!(
            "Note: Latitude = {}, Longitude = {}, Message = \"{}\"",
            note.location().latitude(),
            note.location().longitude(),
            note.message()
        );
    }
    let status = rx.status().await;
    assert!(status.is_ok(), "{:?}", status);
    Ok(())
}

Sebbene ogni lato riceva sempre i messaggi dell'altro nell'ordine in cui sono stati scritti, sia il client che il server possono leggere e scrivere in qualsiasi ordine: gli stream operano in modo completamente indipendente.

Crea e passa il client

Per chiamare i metodi di servizio, dobbiamo prima creare un canale per comunicare con il server. Per farlo, creiamo prima un endpoint, ci connettiamo a quell'endpoint e passiamo il canale creato quando ci siamo connessi a RouteGuideClient::new() come segue:

// Create channel to connect to server
let channel = Channel::builder(
    "dns:///[::1]:10000",
    Arc::new(LocalChannelCredentials::new()),
)
.build();

// Create a new client
let client = RouteGuideClient::new(channel);

Con questo client creato, possiamo chiamare i metodi che abbiamo scritto sopra, passandogli il client. Aggiungiamo tutto questo codice a main(), che utilizza il runtime asincrono Tokio. Ecco il codice completo:

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Create channel to connect to server
    let channel = Channel::builder(
        "dns:///[::1]:10000",
        Arc::new(LocalChannelCredentials::new()),
    )
    .build();

    // Create a new client
    let client = RouteGuideClient::new(channel);

    println!("\n*** SERVER STREAMING ***");
    print_features(&client).await?;

    println!("\n*** CLIENT STREAMING ***");
    run_record_route(&client).await?;

    println!("\n*** BIDIRECTIONAL STREAMING ***");
    run_route_chat(&client).await?;

    Ok(())
}

7. Prova

Per eseguire il client e il server, verifica innanzitutto che entrambi i target binari siano definiti in Cargo.toml:

[[bin]]
name = "routeguide-server"
path = "src/server/server.rs"

[[bin]]
name = "routeguide-client"
path = "src/client/client.rs"

Quindi, esegui i seguenti comandi dalla nostra directory di lavoro:

1. Esegui il server in un terminale:

cargo run --bin routeguide-server

2. Esegui il client da un altro terminale:

cargo run --bin routeguide-client

L'output dovrebbe essere simile al seguente:

*** SERVER STREAMING ***
FEATURE: Name = "Patriots Path, Mendham, NJ 07945, USA", Lat = 407838351, Lon = -746143763
FEATURE: Name = "101 New Jersey 10, Whippany, NJ 07981, USA", Lat = 408122808, Lon = -743999179
FEATURE: Name = "U.S. 6, Shohola, PA 18458, USA", Lat = 413628156, Lon = -749015468
...
*** CLIENT STREAMING ***
Traversing 86 points
SUMMARY: Feature Count = 0, Distance = 803709356

*** BIDIRECTIONAL STREAMING ***
Note: Latitude = 409146138, Longitude = -746188906, Message = "at 112.45µs"
Note: Latitude = 409146139, Longitude = -746188906, Message = "at 1.00011245s"
Note: Latitude = 409146140, Longitude = -746188906, Message = "at 2.00011245s"

8. Passaggi successivi

• Esplora il repository ufficiale di gRPC-Rust.
• Scopri di più sull'architettura gRPC in Concetti fondamentali.
• Visualizza la documentazione di gRPC-Rust su gRPC.io.

9. Hanno collaborato alla stesura di questo codelab

• Cathy Zhao
• Arvind Bright
• Nathaniel Ford