This topic was also discussed in #61. Current implementation of the streaming API for both reads and writes is done via multiple RPC calls. Writes are done in chucks (resumable-writes) which is good for error handling (save-points) but at a cost of multiple RPC instead of one. Reads are also segmented (via range requests) instead one RPC for the whole content.

Things to consider:

1. some platforms may have restrictions on RPC requests (e.g. AE 10MB upstream and 32MB downstream, as well as time-to-live restrictions).
2. Current implementation of the apiary client does not expose the underlying stream and will copy its content to the caller.
3. Rate of errors and cost-benefit evaluation (if the recommended size per one RPC is small enough it might be that the option of create with content or load all is sufficient).