Hii, Im trying to find resources to setup networki...

# ktor

[Chirag Redij]

Hii, Im trying to find resources to setup networking using protobuf with KTOR client but a non KTOR server, in a multi platform environment (android & ios). What are your ideas on this and if is there a complete setup I use.

[Bruce Hamilton]

I think gRPC plugin on the client side would support it now. @Alexander Sysoev thoughts?

[Chirag Redij]

But isnt it JVM based??

[Bruce Hamilton]

looks like it's JVM and native atm

[Chirag Redij]

Hii, I just found some info on Wire by Square. Their documentation is a little hazy tho. It seems to be KMP compatible

[Chrimaeon]

You know that ContentNegotiation with Kotlin serialization has a ProtoBuf implementation?

https://ktor.io/docs/client-serialization.html#add_protobuf_dependency

[Bruce Hamilton]

I probably should've remembered that one my bad 😅

[Alexander Sysoev]

gRPC is jvm + native: https://kotlin.github.io/kotlinx-rpc/grpc-client.html
It doesn't use Ktor client though

[Chirag Redij]

But we dont have a KTOR Server. So im not sure if that will be compatible

[Chirag Redij]

@Alexander Sysoev we dont have a rpc compatible server. We were exploring options to just change the encoding/decoding for the apis and have more flexibility. Maybe use json during development/debugging and use protobuf in prod

[Alexander Sysoev]

Then you indeed can just use what Christian suggested. Server doesn't need to be Ktor, just read the same encoding

[Chirag Redij]

Yes, Im just searching for documentation which covers the proto version configuration and the order for messages. Just like end to end stuff

[Chirag Redij]

From what I have researched so far, using Wire by Square should help me encode & decode requests/responses by writing proto files. Then using ktor with Protobuf content negotiation so get raw bytes as responses and then decode it

[Chirag Redij]

Wait I can also use Ktors Proto numbers to do that

[curioustechizen]

I use Wire by square for serializing/de-serializing protobufs in a mobile app (Android + iOS). It works great.

Currently I'm only using it for BLE communication (so the receiving side is not a Ktor server). I do have plans for this in the future; and when that time comes, I'm likely to use Wire with Ktor as well.

I do have another Java/JAXRS server - that's the one place where I think I will not use Wire.

[Chirag Redij]

Why not KTOR content negotiation plugin??

[curioustechizen]

I assume the Ktor content negotiation plugin is using kotlinx-serialization protobuf under the hood. If my assumption is correct then,
• ktx serialization's protobuf support is experimental
• ktx serialization uses proto2 semantics while I use proto3 for my protobuf definitions
https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/formats.md#protobuf-experimental

[curioustechizen]

Additionally, if I'm using Wire anyway in a KMP project, I might as well use the same module that uses Wire as a dependency for my server Ktor project. This is in KMP's spirit of sharing code between client and server (so in this case 3 platforms - Android, iOS and server). This especially makes sense for protobufs since the same definitions are shared between server and client.

[curioustechizen]

Finally, there's a mismatch between the way ktx-serialization's protobuf integration works compared to Wire's. In Wire, you define the .proto schemas and it generates classes. I've not used ktx-serialization with Protobuf but from my limited understanding, it requires you to declare a class for each message.

I'm not claiming that Wire's approach is better - there are pros and cons of each approach and there are trade-offs. I'm just saying that if I'm using one approach on the client, it just makes sense to use the same on the server.

[Chirag Redij]

🧐Yes, even Im not sure which proto version ktx-serialization proto plugin uses. Compatibility was my only concern for using it. Apart from that KTOR CN approach is very simple, you can set proto numbers / index for fields in your data classes. And it also supports other definition options (optionables, etc). With Wire I assume we would have to manually serialise/deserialise for each request