IceRPC: RPC framework for the QUIC era

by delaconcha • 2 years ago

25 11 2 years ago

pjmlp2• 2 years ago

I guess brownie points for using .NET, it is not always that we see such kind of frameworks picking on .NET as implementation infrastructure.

reecewh• 2 years ago

ZeroC developer here. We picked .NET as our first language for two main reasons. Firstly, it is an excellent language for rapid iteration; the design and implementation of IceRPC evolved significantly throughout its development, so having a more flexible language greatly sped up the refactoring and development process. Secondly, it has mature async-await support, which is natural for an RPC.The next language we are adding support for is Rust!

pjmlp2• 2 years ago

All the best on your efforts.

real_kaipi• 2 years ago

booooo .net

where's python, where's browser javascript that's limited to HTTP1

zigzag3124• 2 years ago

Slice looks like a saner alternative to Protobuf. Proper nullability support alone is big enough reason to consider this instead of Protobuf.

I would suggest ability to also generate "builder" variant of structs, where every field is optional. That would allow cases where one service to only partially build response and another service completes it. And ability to solve issues explained here:

https://capnproto.org/faq.html#how-do-i-make-a-field-require...

DUs would also be very useful. Have you considered it?

Overall, it looks very promising. I would like to try it, but my stack's currently C# & Dart. I see Rust is already on the roadmap.

Newtons4thLaw2• 2 years ago

Hey, hi, hello, I’m the Slice guy at ZeroC, and I’m glad to see the appreciation! Honestly, a saner alternative to Protobuf is kind of what we’re going for : vP

DUs would also be very useful. Have you considered it?

Well, if DU is ‘discriminated union’ and not ‘diagnosis undetermined’, we’re literally releasing support for them tomorrow! Although we call them “enums with fields” because everyone needs their own names for things you know… But I totally agree, as someone who’s become pretty infatuated with Rust, I don’t know how I lived without them before!

I would suggest ability to also generate "builder" variant of structs, where every field is optional

One of the big departures between Protobuf and Slice is that fields in Slice are `required` by default. You can still opt-in to Protobuf-like behavior by marking your fields with a modifier like `tag(2)`, but… it’s opt-in. This would also give you a struct like you described, where you could ‘build’ it piece by piece.

I’ve read similar posts to the one you linked about how dangerous `required` can be, and I understand where they’re coming from. Required fields definitely reduce your flexibility in the future. But as someone who’s been using IDLs for a while, I personally never found myself needing it tbh. And making it opt-in goes a good way towards two of the design goals of Slice:

- It feels natural to anyone who’s programming, and in most languages (especially the cool new ones), fields are ‘required’ by default.

- It’s more explicit. Unless you mark your type nullable, it’s non-null. Unless you tag it with an id, it’s required, etc.

Have your experiences differed; Where you’re frequently removing fields from existing types? Just as an honest question from someone trying to fine-tune their language!

zigzag3124• 2 years ago

Hi! Thanks for the in-depth explanation.

I overlooked that all tagged fields are optional. Builders would only make sense, if tagged fields could be required. Also, I'm not sure if they would be possible for structs with non-tagged fields and if they would even be useful in that case. So, you can ignore that idea.

The way I see it, tagged fields give you the flexibility at the cost of a slight size/performance overhead. And they also require additional manual labor for validation.

Non-tagged fields are inflexible (changes are not backward/forward compatible), but they are simpler to work with and more performant. Changes require API versioning.

For simple types it often doesn't make sense to use tagged fields. For example, for types like GeoCoordinates(Latitude, Longitude), tagged optional fields only add unnecessary complexity, without any real benefits. Another Protobuf limitation I dislike.

Have your experiences differed; Where you’re frequently removing fields from existing types?

Not really (but I don't have much experience with large systems). I think that adding new fields is most common by far. Adding a new required field can be "dangerous" as an updated server won't be able to read old messages anymore (unless API is versioned of course).

I think that ability to have have either tagged or untagged fields in Slice is great.

we’re literally releasing support for them tomorrow! Although we call them “enums with fields”

That's great! I don't care what they are called as long as they are available :)

Regarding varints, how does your QUIC like implementation compares to something like this[0]? Any thoughts on pros and cons?

[0] https://docs.rs/vint64/latest/vint64/

IceRPC: RPC framework for the QUIC era

Related Stories