I think this is an interesting library, but I had a couple of concerns about the API, particularly regarding streaming requests. First, I noticed that in your server streaming example, the response messages appear to be coalesced into an array before being returned to the user, which seems to negate two major advantages that would lead someone to use streaming responses in the first place: providing the ability to handle responses as they are generated by the server, and avoiding the need to keep all responses in memory simultaneously. For example, one use of streaming responses could be for video streaming, where each response is a small chunk of video data. Holding all of the data until the end of the call would essentially turn a video stream into a video download.
I also noticed that the bidirectional streaming section had this caveat: "In order to keep track of the messages sent and to be able to callback all the requests, the server implementation needs to answer with the same id received". This makes it sound like your API only supports bidirectional streams with a 1-to-1 mapping of requests to responses, which would be a major restriction of general bidirectional streaming semantics. Does that mean that your bidirectional streaming API requires request and response messages to contain an integer id field, and that that id field is only used to store the message sequence number within a single stream?