grpc / grpc-dart

The Dart language implementation of gRPC.
https://pub.dev/packages/grpc
Apache License 2.0
861 stars 271 forks source link

Generate immutable classes for client #490

Closed idraper closed 3 years ago

idraper commented 3 years ago

I am trying to implement a grpc client with the flutter bloc pattern. There are plenty of resources regarding dart and grpc, so no issues there. A key part of the bloc pattern (for me at least) requires states to be immutable and I would like to make it so any response from the server is immutable. I am returning real-time data from a server that the client should not be able to modify. I understand that grpc, in general, will not support this, since immutability has language-specific issues, but I'm am wondering if it is possible in this package (eg dart specific).

Is there a way to have grpc-dart generate client classes with immutability? I found the immutable_proto package, but it hasn't been updated for over a year and I hesitate to be reliant on such a package if it is not going to be updated.

I am just getting introduced to grpc, so if I've missed something big please let me know.

mraleph commented 3 years ago

This package just relies on protobuf package (and its protoc plugin) to generate message classes. Right now these classes have mutable interfaces (though you can call freeze on individual messages to mark them read-only and get runtime errors if you try to mutate them). There are some experiments in making immutable APIs for message classes - but no concrete timeline or guarantees that this is ever going to land. There some open feature requests on the repo already (see https://github.com/dart-lang/protobuf/issues/53 ).

I am returning real-time data from a server that the client should not be able to modify.

I don't really understand this concern. What happens if client mutates this data?

I think the whole immutability is only matters if you are developing as a part of the larger team / code base. If you are developing in a small team / code base it is enough to just have a convention to simply never mutate protobuf messages, unless you have constructed them yourself.