Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to just decode specific parts of a message? #1154

Closed
oliveryasuna opened this issue Jan 9, 2025 · 3 comments
Closed

Is it possible to just decode specific parts of a message? #1154

oliveryasuna opened this issue Jan 9, 2025 · 3 comments

Comments

@oliveryasuna
Copy link
Contributor

oliveryasuna commented Jan 9, 2025

Our API works by sending a serialized protobuf in the request/response body. No gRPC involved. We have a mobile app that is mainly a web view (using Capacitor). One of our endpoints has begun to return a large response (~30 MB). In turns out that iOS' WebKit has a longtime bug where, if the memory usage spikes, it can crash. So, when we attempt to deserialize the response body, the web view crashes.

We're discussing many potential solutions. One solution could be, if we could decode certain parts of a message at a time, we can avoid a large memory spike.

For example, consider the following message:

message MyResponse {
  repeated Foo foos = 1;
  repeated Bar bars = 2;
  repeated Baz bazs = 3;
}

Is there a way to just decode one-or-more fields at a time?

@stephenh
Copy link
Owner

stephenh commented Jan 9, 2025

Hi @oliveryasuna , no, not using ts-proto's MyResponse.decode methods.

However you might be able to pull this off using the lower-level @buf/protobufjs library, if you know the tags/schema/etc of the message you're wanting to read. 🤔

I.e. it has the lower-level methods like readInt / readMessage / etc. that would give the [tag, value] pairs.

Good luck!

@stephenh stephenh closed this as completed Jan 9, 2025
@oliveryasuna
Copy link
Contributor Author

Thank you.

@stephenh
Copy link
Owner

Hi @oliveryasuna sorry, I just read the first part of your message, and didn't see it the first time...

It kinda sounds like an "async" decode method would be useful for you, where instead of decode blocking, it would "do a little work", "yield to the JS engine", "do a little work", "yield to the JS engine".

Ironically this is basically what React's internals have started being able to do, is "break up" the "one big render of the DOM", into chunks of work that yield back to the browser every so often...

I think it'd be quite a big change to make a new "async decode", and have ts-proto do internal bookkeeping about how long it's blocked the browser thread...

But, just mentioning the idea in case you're sufficiently motivated to try it out :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants