[protobuf] Re: best practices for querying a resource
I think this question is more suited for gRPC, protobuf doesn't have standards about RPC endpoints. On Friday, March 18, 2022 at 3:23:35 PM UTC-7 tyty wrote: > I have a resource called Resturants. There are multiple fields and a few i > want to allow people to query specifically for (Rating and Location). > > Is it better to create multiple RPC endpoints like: > > ``` > //all resturants > QueryReseturants(QueryResturantsRequest) returns (QueryResturantsResponse) > > // all resturants with a specific rating > QueryResturantsByRating(QueryResturantsByRatingRequest) returns > (QueryResturantsByRatingResponse) > > // all resturants with a specific locatoin > QueryResturantsByLocation(QueryResturantsByLocationRequest) returns > (QueryResturantsByLocationResponse) > ``` > > OR is it better to have one query, with the specifics as fields: > > ``` > //all resturants > QueryReseturants(QueryResturantsRequest) returns (QueryResturantsResponse) > ``` > where QueryResturantsRequest contains a Rating and Location field. > Specifying neither will return all. or you can specify one or both of the > fields to narrow down the resturants returned. > > Either way works for our use case, but I'm mainly curious if this breaks > protobuf standards or something like that. > > Thanks. > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/82cc7d86-446f-4308-bea3-9f8dc58f4e30n%40googlegroups.com.
[protobuf] Re: Best practices + Large Sample
On Thursday, January 24, 2013 12:48:14 AM UTC+8, smartnerd wrote: > > Hello gents, > > I;m looking for a source of inspiration where protobuf is used with the > following features : > > - large amount of files/definitions (e.g. 100-200), the more the better > - sharing definitions within several sub-projects/domains > - usage of extension > - RPC style > Protobuf's usage in Google meets all the above criterions. As the documentation has pointed out, there are more than 10K .proto files in Google code tree and many of them are used in RPC systems. > > I know the definition of the protobuf, but would be great to see something > "large" to get an > idea where "travel" can lead. Simply a large blueprint.. What exactly do you want to know about protobuf? Whether it can be fit into a large system? > > Thank you. > > Cheers, > jj > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[protobuf] Re: Best practices for proto file organization in large projects
we are using protobuf in a very large system, and we simply put all proto files in one directory like "./public/rpc" and it works very well! On Jun 19, 10:49 am, Justin Muncaster wrote: > Hello, > > I've been using protocol buffers for a while, and I love the library, > however I find that when using them in large projects I generally have to > fight with the compiler to get protoc to play nicely with my build > system. My projects are organized as follows: > > common/foo/foo.h > common/foo/foo.cpp > common/foo/foo.proto > ... > common/bar/bar.h > common/bar/bar.cpp > common/bar/bar.proto > > where bar.proto contains > import "common/foo/foo.proto" > > ... and elsewhere... > app1/baz.proto > ... > app1/fud.proto > > and baz.proto and fud.proto contain > "import common/bar/bar.proto" > > I'm currently changing our build system to be cmake based and I'm again > finding myself fighting with the build system to get the .proto to be > automatically generated in a way where they build correctly. This leads me > to believe that I am doing something wrong or at least not organizing files > in a way that is expected. In light of that, > > How do you organize your proto files when you have many in common > libraries? Do all .proto files live in one folder? Should one avoid "import > a/b/c/d/f.proto"? Do you have any recommendations for how one ought one > setup the cmake build system to work with proto files that are organized as > they are above? Any general recommendations? > > Thanks, > > Justin -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Best practices - Sharing definitions between projects
Hi I want to do achive something similiar. Did you have any luck with this? If so what path did you choose? - Kostya -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/PZoNsVcWllIJ. To post to this group, send email to protobuf@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Best Practices
On Thu, Oct 7, 2010 at 5:29 AM, users wrote:
> Thank you Kenton and Jason for the advice. I have a couple more
> questions as I move forward with PB implementations.
>
> In the documentation it states that PBs don't make good first class
> citizens in an OO domain model and the suggestion is of course to wrap
> the PB. Through some other posts it is quite evident that you do not
> want people subclassing or using 'extends' in Java on PBs. However,
> in process of looking at wrapping classes it is quite clear the
> Message and Builder interfaces will be common across every PB I
> create, but for each PB there will be a uniqe set of setters, getters,
> and has functions for my protocol member fields. Am I going to get
> into trouble creating the following type of abstract class using
> generics:
>
>
> public abstract class MyAbstractMessage extends GeneratedMessage.Builder> {
>
>
>protected T message;
>protected B builder;
>
>
>// This is implemented here only to work around an apparent bug in
> the
>// Java compiler and/or build system. See bug #1898463. The mere
> presence
>// of this dummy clone() implementation makes it go away.
>@Override
>public B clone() {
> throw new UnsupportedOperationException(
> "This is supposed to be overridden by subclasses.");
>}
>/**
> * see {...@link GeneratedMessage#newBuilderForType()}...@link
> MessageLite#newBuilderForType()}
> * @param obj
> * @return
> */
>@SuppressWarnings("unchecked")
>public final B newBuilder() {
>return (B) message.newBuilderForType();
>}
>
>/**
> * see {...@link GeneratedMessage.Builder#build()} {...@link
> MessageLite.Builder#build()}
> * @return
> */
>@SuppressWarnings("unchecked")
>public final T build() {
>message = (T) builder.build();
>builder = null;
>return message;
>}
>
>// ... wrap all the Message and Builder interface methods ...
>
> }
>
> Then for each PB I create I would wrap them in an implementation of
> this abstract class and add my additional setters and getters, hide
> what I want about builder creation or message object creation and
> implement interfaces as necessary.
>
> Is this approach heading down a path that will create chaos in my life
> going forward as migrate numerous protocols to the PB implementation?
If you have incredibly complex protos this could be cumbersome to maintain.
But if the API you want to expose users is more than just the setters and
getters that are provided by the generated code, it's the way to go.
> One final question, I have realized enumeration changes may be
> particular difficult to adapt to with compatibility issues. Can you
> point to any strategies here?
>
The advice to avoid required is especially true for enums: if you send a
value that's unknown to the recipient, and the field is required, the client
will fail to parse the entire message (unless it is using the Partial
variants). Otherwise, it's ok that it gets "dropped" (it's just stored in
the unknown fields) since presumably the client has no idea how to handle
that enumeration value anyway.
>
> Thank you for all the input and advice!
>
> On Sep 21, 3:38 pm, Kenton Varda wrote:
> > On Wed, Sep 15, 2010 at 6:03 AM, users wrote:
> > > I am implementing PB to provide an external interface and API to a
> > > developing system. I know the interface will change and the extension/
> > > backwards compatibility is a major benefit. When designing the .proto
> > > files should I, for pure flexibility, make everything optional or
> > > repeated fields? If I do this I can then write separate Validate
> > > functions for each implementation revision. I can see an opportunity
> > > to automate the validate function creation with the code generating
> > > capabilities. This will remove the burden of "required is forever"
> > > but will it impact performance or have other negative effects that I
> > > can not see? Is this a good practice for flexible implementations or
> > > are there better patterns?
> >
> > This is exactly what I usually recommend to people, and do in my own
> code.
> > There are no significant performance effects (if anything, performance
> will
> > be better because there are fewer checks to perform when parsing). But
> as
> > Jason says, opinions vary.
> >
> >
> >
> >
> >
> > > Thanks
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Protocol Buffers" group.
> > > To post to this group, send email to proto...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > protobuf+unsubscr...@googlegroups.com
>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.- Hide quoted text -
> >
> > - Show quoted text -
>
> --
> You received thi
[protobuf] Re: Best Practices
Thank you Kenton and Jason for the advice. I have a couple more
questions as I move forward with PB implementations.
In the documentation it states that PBs don't make good first class
citizens in an OO domain model and the suggestion is of course to wrap
the PB. Through some other posts it is quite evident that you do not
want people subclassing or using 'extends' in Java on PBs. However,
in process of looking at wrapping classes it is quite clear the
Message and Builder interfaces will be common across every PB I
create, but for each PB there will be a uniqe set of setters, getters,
and has functions for my protocol member fields. Am I going to get
into trouble creating the following type of abstract class using
generics:
public abstract class MyAbstractMessage> {
protected T message;
protected B builder;
// This is implemented here only to work around an apparent bug in
the
// Java compiler and/or build system. See bug #1898463. The mere
presence
// of this dummy clone() implementation makes it go away.
@Override
public B clone() {
throw new UnsupportedOperationException(
"This is supposed to be overridden by subclasses.");
}
/**
* see {...@link GeneratedMessage#newBuilderForType()}...@link
MessageLite#newBuilderForType()}
* @param obj
* @return
*/
@SuppressWarnings("unchecked")
public final B newBuilder() {
return (B) message.newBuilderForType();
}
/**
* see {...@link GeneratedMessage.Builder#build()} {...@link
MessageLite.Builder#build()}
* @return
*/
@SuppressWarnings("unchecked")
public final T build() {
message = (T) builder.build();
builder = null;
return message;
}
// ... wrap all the Message and Builder interface methods ...
}
Then for each PB I create I would wrap them in an implementation of
this abstract class and add my additional setters and getters, hide
what I want about builder creation or message object creation and
implement interfaces as necessary.
Is this approach heading down a path that will create chaos in my life
going forward as migrate numerous protocols to the PB implementation?
One final question, I have realized enumeration changes may be
particular difficult to adapt to with compatibility issues. Can you
point to any strategies here?
Thank you for all the input and advice!
On Sep 21, 3:38 pm, Kenton Varda wrote:
> On Wed, Sep 15, 2010 at 6:03 AM, users wrote:
> > I am implementing PB to provide an external interface and API to a
> > developing system. I know the interface will change and the extension/
> > backwards compatibility is a major benefit. When designing the .proto
> > files should I, for pure flexibility, make everything optional or
> > repeated fields? If I do this I can then write separate Validate
> > functions for each implementation revision. I can see an opportunity
> > to automate the validate function creation with the code generating
> > capabilities. This will remove the burden of "required is forever"
> > but will it impact performance or have other negative effects that I
> > can not see? Is this a good practice for flexible implementations or
> > are there better patterns?
>
> This is exactly what I usually recommend to people, and do in my own code.
> There are no significant performance effects (if anything, performance will
> be better because there are fewer checks to perform when parsing). But as
> Jason says, opinions vary.
>
>
>
>
>
> > Thanks
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Protocol Buffers" group.
> > To post to this group, send email to proto...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > protobuf+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
