mirror of
https://github.com/OMGeeky/tarpc.git
synced 2026-01-09 13:04:09 +01:00
7ad0e4b070
# Changes
## Client is now a trait
And `Channel<Req, Resp>` implements `Client<Req, Resp>`. Previously, `Client<Req, Resp>` was a thin wrapper around `Channel<Req, Resp>`.
This was changed to allow for mapping the request and response types. For example, you can take a `channel: Channel<Req, Resp>` and do:
```rust
channel
.with_request(|req: Req2| -> Req { ... })
.map_response(|resp: Resp| -> Resp2 { ... })
```
...which returns a type that implements `Client<Req2, Resp2>`.
### Why would you want to map request and response types?
The main benefit of this is that it enables creating different client types backed by the same channel. For example, you could run multiple clients multiplexing requests over a single `TcpStream`. I have a demo in `tarpc/examples/service_registry.rs` showing how you might do this with a bincode transport. I am considering factoring out the service registry portion of that to an actual library, because it's doing pretty cool stuff. For this PR, though, it'll just be part of the example.
## Client::new is now client::new
This is pretty minor, but necessary because async fns can't currently exist on traits. I changed `Server::new` to match this as well.
## Macro-generated Clients are generic over the backing Client.
This is a natural consequence of the above change. However, it is transparent to the user by keeping `Channel<Req, Resp>` as the default type for the `<C: Client>` type parameter. `new_stub` returns `Client<Channel<Req, Resp>>`, and other clients can be created via the `From` trait.
## example-service/ now has two binaries, one for client and one for server.
This serves as a "realistic" example of how one might set up a service. The other examples all run the client and server in the same binary, which isn't realistic in distributed systems use cases.
## `service!` trait fns take self by value.
Services are already cloned per request, so this just passes on that flexibility to the trait implementers.
# Open Questions
In the service registry example, multiple services are running on a single port, and thus multiple clients are sending requests over a single `TcpStream`. This has implications for throttling: [`max_in_flight_requests_per_connection`](https://github.com/google/tarpc/blob/master/rpc/src/server/mod.rs#L57-L60) will set a maximum for the sum of requests for all clients sharing a single connection. I think this is reasonable behavior, but users may expect this setting to act like `max_in_flight_requests_per_client`.
Fixes #103 #153 #205
91 lines
2.7 KiB
Rust
91 lines
2.7 KiB
Rust
// Copyright 2018 Google LLC
|
|
//
|
|
// Use of this source code is governed by an MIT-style
|
|
// license that can be found in the LICENSE file or at
|
|
// https://opensource.org/licenses/MIT.
|
|
|
|
extern crate itertools;
|
|
extern crate proc_macro;
|
|
extern crate proc_macro2;
|
|
extern crate quote;
|
|
extern crate syn;
|
|
|
|
use proc_macro::TokenStream;
|
|
|
|
use itertools::Itertools;
|
|
use proc_macro2::Span;
|
|
use quote::ToTokens;
|
|
use std::str::FromStr;
|
|
use syn::{parse, Ident, TraitItemType, TypePath};
|
|
|
|
#[proc_macro]
|
|
pub fn snake_to_camel(input: TokenStream) -> TokenStream {
|
|
let i = input.clone();
|
|
let mut assoc_type = parse::<TraitItemType>(input)
|
|
.unwrap_or_else(|_| panic!("Could not parse trait item from:\n{}", i));
|
|
|
|
let old_ident = convert(&mut assoc_type.ident);
|
|
|
|
for mut attr in &mut assoc_type.attrs {
|
|
if let Some(pair) = attr.path.segments.first() {
|
|
if pair.value().ident == "doc" {
|
|
attr.tts = proc_macro2::TokenStream::from_str(
|
|
&attr.tts.to_string().replace("{}", &old_ident),
|
|
)
|
|
.unwrap();
|
|
}
|
|
}
|
|
}
|
|
|
|
assoc_type.into_token_stream().into()
|
|
}
|
|
|
|
#[proc_macro]
|
|
pub fn ty_snake_to_camel(input: TokenStream) -> TokenStream {
|
|
let mut path = parse::<TypePath>(input).unwrap();
|
|
|
|
// Only capitalize the final segment
|
|
convert(&mut path.path.segments.last_mut().unwrap().into_value().ident);
|
|
|
|
path.into_token_stream().into()
|
|
}
|
|
|
|
/// Converts an ident in-place to CamelCase and returns the previous ident.
|
|
fn convert(ident: &mut Ident) -> String {
|
|
let ident_str = ident.to_string();
|
|
let mut camel_ty = String::new();
|
|
|
|
{
|
|
// Find the first non-underscore and add it capitalized.
|
|
let mut chars = ident_str.chars();
|
|
|
|
// Find the first non-underscore char, uppercase it, and append it.
|
|
// Guaranteed to succeed because all idents must have at least one non-underscore char.
|
|
camel_ty.extend(chars.find(|&c| c != '_').unwrap().to_uppercase());
|
|
|
|
// When we find an underscore, we remove it and capitalize the next char. To do this,
|
|
// we need to ensure the next char is not another underscore.
|
|
let mut chars = chars.coalesce(|c1, c2| {
|
|
if c1 == '_' && c2 == '_' {
|
|
Ok(c1)
|
|
} else {
|
|
Err((c1, c2))
|
|
}
|
|
});
|
|
|
|
while let Some(c) = chars.next() {
|
|
if c != '_' {
|
|
camel_ty.push(c);
|
|
} else if let Some(c) = chars.next() {
|
|
camel_ty.extend(c.to_uppercase());
|
|
}
|
|
}
|
|
}
|
|
|
|
// The Fut suffix is hardcoded right now; this macro isn't really meant to be general-purpose.
|
|
camel_ty.push_str("Fut");
|
|
|
|
*ident = Ident::new(&camel_ty, Span::call_site());
|
|
ident_str
|
|
}
|