search

grpc / grpc-java

The Java gRPC implementation. HTTP/2 based RPC
https://grpc.io/docs/languages/java/
Apache License 2.0
11.35k stars 3.81k forks source link

BinderChannel: allow kotlinx.serialization as protobuf alternative #11395

Closed bubenheimer closed 1 month ago

bubenheimer commented 1 month ago

Is your feature request related to a problem?

I have a need for Android Service Binder-based communication between processes in a single app. The app is written in Kotlin and uses built-in kotlinx.serialization extensively.

Describe the solution you'd like

I would like to use kotlinx.serialization as an alternative to protobuf with BinderChannel. kotlinx.serialization can use different types of message formats; I would like to at least be able to use kotlinx.serialization JSON.

Describe alternatives you've considered

The BinderChannel proposal appears written from an assumption that grpc-java implies using protobuf as a messaging format. However, grpc-java actually supports replacing protobuf with alternative formats. Based on how the proposal is written I am assuming that it would be non-trivial for me to replace protobuf in BinderChannel in plug-and-play fashion.

I do not want to add additional complexity by adding protobuf on top of Kotlin, which already offers a preferred native serialization mechanism.

I currently hand-code Parcels for Binder-based IPC transactions, and have developed my own Binder-based transaction framework, as I find both AIDL and protobuf lacking as architectural choices for modern Android app development in Kotlin. My reasoning about protobuf is here: https://github.com/grpc/grpc-kotlin/issues/255

Additional context

My own Binder-based transaction framework aims to transparently support suspending communication around Kotlin coroutines and Kotlin flows. BinderChannel with kotlinx.serialization should not be hostile toward leveraging via Kotlin coroutines and grpc-kotlin library. Android's Binder framework is inherently hostile toward Kotlin coroutines: https://issuetracker.google.com/issues/313118132. BinderChannel should not make things worse.

ejona86 commented 1 month ago

BinderChannel doesn't depend on Protobuf. The only marshalling format it treats specially is Parcelable. BinderChannel should handle whatever marshaller you want about as well as it handled Protobuf.

Granted, we won't have generated code for your marshaller of choice, but that's a thin layer on top.

Concerning coroutine dispatch... I don't know how we'd offer that. BinderChannel isn't going to depend on Kotlin, and Binder itself does things a certain way and you have to be careful when sharing network threads with the application. The expectation is to pay the thread-based dispatch cost. (Even for a fully-async application (which is similar in spirit to coroutine dispatch), we don't recommend running on the network threads, as it can add very-hard-to-debug latency caused by CPU-heavy tasks.)

bubenheimer commented 1 month ago

@ejona86 thank you, this is very helpful to know. I will likely try this at a future time. Will create new issues for any problems I might run into.