Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom serialization #4

Open
arxdeus opened this issue Aug 4, 2024 · 4 comments
Open

custom serialization #4

arxdeus opened this issue Aug 4, 2024 · 4 comments

Comments

@arxdeus
Copy link

arxdeus commented Aug 4, 2024

hi, seems that frpc strictly bounded by databuf.rs, but what if we want to use other serialization system. like a bebop, bincode2 or smth like that?

@nurmohammed840
Copy link
Owner

The main reason is that, you need to generate encoding/decoding for client stub for that serialize format. Currently I only write for JavaScript.

Currently frpc only use subset of databuf crate, which are well defined, standardized and most importantly stable,
It will support more encoding that are both forward and backward compatible just like gRPC.

@nurmohammed840
Copy link
Owner

but what if we want to use other serialization system.

Then you need to generate client stub for that format.
code generation handle in this directory

I welcome any suggestions for improving our data standardization, Feel free to share any idea to improve current encoding strategy.

@arxdeus
Copy link
Author

arxdeus commented Nov 21, 2024

which are well defined, standardized and most importantly stable,

hi, just found that databuf doesn't useful for long-term systems/api, there's no support for deprecating/reserving fields as it done in protobuf serialization protocol, so, u can easily get messed with api versioning

i'm talking about Tag Number that describes uniqueness of fields

message Foo {
  double bar = 1; // <-- this `1` is tag number
                      
}

@nurmohammed840
Copy link
Owner

there's no support for deprecating/reserving fields as it done in protobuf serialization protocol

Yes, Currently this API is not yet supported:

#[repr(u16)]
enum Action {
    Noop = 1,
    Add { x: i32, y: i32 } = 2,
    Print(String) = 3,
}

An object can be represent using Vec<Action>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants