Required config params for Go module returning large payload

Hey guys, could I get some clarification on what the required config params are to handle a go module that returns quite a large payload? We’ve replicated a php api we used as a go module - the module fetches a list of images, resizes them, and returns them to our unity client as base64 encoding strings. When the list is small, everything works fine, but when we have the required amount of images for the operation - around 2 or 30 images, the rpc call fails. in the nakam log it looks like the rpc completed, but the client receives a null error, so I’m guessing this is related to exceeding a default config. Any help very appreciated thanks.

@oscargoldman What size in KBs of data do you send in the RPC response?

Chris, somewhere in the range of 3000-6000 Kb. Maybe a little higher sometimes. typically 100kb per image depending on the resolution and quality settings we resize to. Our current php api returns the data all as one http response, so we’re replicating that functionality in go and nakama.

sorry that was 20 - 30 images, i can’t seem to edit the original post to fix this.

@novabyte I checked on the gRPC plugin and it looks like the max message size has been set to 4mb, and it’s advised to not increase this over significant performance loss. So looks like if we continue to use this module for this purpose we’ll have to page and make multiple calls.

I think the limit you’re hitting is the default max message size the Go GRPC client accepts as a response from a GRPC server. You’re right, the default is 4 MB but it’s fine to increase in this case I believe. It’s an internal server call between GRPC Gateway and GRPC server and it won’t affect small payloads as it’s just a ‘limit’ value rather than an outright buffer allocation.

This means we can support large responses with no degradation in small response performance, but it might be best to break up the calls anyway to get the best experience on user end devices. This will be in the next release of Nakama. Thanks for the help tracking this down!