gRPC + Image Upload

ghz 1years ago ⋅ 2064 views

Question

I want to create a simple gRPC endpoint which the user can upload his/her picture. The protocol buffer declaration is the following:

message UploadImageRequest {
    AuthToken auth = 1;
    // An enum with either JPG or PNG
    FileType image_format = 2;
    // Image file as bytes
    bytes image = 3;
}

Is this approach of uploading pictures (and recieving pictures) still ok regardless of the warning in the gRPC documentation?

And if not, is the better approach (standard) to upload pictures using the standard form and storing the image file location instead?

Answer

For large binary transfers, the standard approach is chunking. Chunking can serve two purposes:

  1. reduce the maximum amount of memory required to process each message
  2. provide a boundary for recovering partial uploads.

For your use-case #2 probably isn't very necessary.

In gRPC, a client-streaming call allows for fairly natural chunking since it has flow control, pipelining, and is easy to maintain context in the client and server code. If you care about recovery of partial uploads, then bidirectional-streaming works well since the server can be responding with acknowledgements of progress that the client can use to resume.

Chunking using individual RPCs is also possible, but has more complications. When load balancing, the backend may be required to coordinate with other backends each chunk. If you upload the chunks serially, then the latency of the network can slow upload speed as you spend most of the time waiting to receive responses from the server. You then either have to upload in parallel (but how many in parallel?) or increase the chunk size. But increasing the chunk size increases the memory required to process each chunk and increases the granularity for recovering failed uploads. Parallel upload also requires the server to handle out-of-order uploads.

#grpc