Using Protobuf instead of JSON to communicate with a front end
blog.wearewizards.io
Using Protobuf instead of JSON to communicate with a front end
1–10 of 99 posts
Re: Using Protobuf instead of JSON to communicate with a front end
#2Transit is similar but addresses the flaws described in this article
Re: Using Protobuf instead of JSON to communicate with a front end
#3I guess it only makes sense if you are already using protobuf everywhere else in your stack. Specially if you are leveraging GRPC[0] which is already profobuf over HTTP. The network tab problem could be solved by an extension, or browsers could offer the tools built-in if there were to become a trend.
Re: Using Protobuf instead of JSON to communicate with a front end
#4Transit is similar but addresses the flaws described in this article http://blog.cognitect.com/blog/2014/7/22/transit
Not sure transit is designed for the same space. E.g. there seems to be no schema, and the default JSON encoding isn't super readable either.
Protobufs can be encoded as JSON and as text, so there are some ways to address the readability I guess.
Re: Using Protobuf instead of JSON to communicate with a front end
#5At work we're using HTTP requests and now we added RabbitMQ in the last few months to deal with the fact that our frontend has to talk to our backend. After seeing this article it feels like we chose the wrong tool for the job; protobuf/thrift appear to be typed which would have saved us a lot of frustration as we've already run into multiple cases where the receiver or sender have messed up the type conversion or parsing.
Re: Using Protobuf instead of JSON to communicate with a front end
#6I guess it only makes sense if you are already using protobuf everywhere else in your stack. Specially if you are leveraging GRPC[0] which is already profobuf over HTTP. The network tab problem could be solved by an extension, or browsers could offer the tools built-in if there were to become a trend. [0] http://www.grpc.io/
Grpc doesn't work over the browser. This is stated explicitly in the FAQ.
See https://groups.google.com/forum/#!topic/grpc-io/5Ic8MKgltwY
Re: Using Protobuf instead of JSON to communicate with a front end
#7I like to use Protobuf in my server code, but then support JSON _or_ Protobuf as the encoding. So browsers can continue to use JSON, but the server gets strongly-typed Protobuf structures.
Re: Using Protobuf instead of JSON to communicate with a front end
#8I guess it only makes sense if you are already using protobuf everywhere else in your stack. Specially if you are leveraging GRPC[0] which is already profobuf over HTTP. The network tab problem could be solved by an extension, or browsers could offer the tools built-in if there were to become a trend. [0] http://www.grpc.io/
Grpc doesn't work over the browser. This is stated explicitly in the FAQ. See https://groups.google.com/forum/#!topic/grpc-io/5Ic8MKgltwY
It's rather painful that they don't seem to have any design docs up for their HTTP transport, leaving it to things like FAQ entries to explain these details. This was my first thought too- grpc does this.
Re: Using Protobuf instead of JSON to communicate with a front end
#9At work we're using HTTP requests and now we added RabbitMQ in the last few months to deal with the fact that our frontend has to talk to our backend. After seeing this article it feels like we chose the wrong tool for the job; protobuf/thrift appear to be typed which would have saved us a lot of frustration as we've already run into multiple cases where the receiver or sender have messed up the type conversion or pa…
I don't see how protobuf is mutually exclusive with RabbitMQ. RabbitMQ is a message broker and can send around byte arrays. These byte arrays can be anything, including protobuf messages.
Re: Using Protobuf instead of JSON to communicate with a front end
#10Another way to do this is to specify the protocol in protobuf but have the server translate responses and requests to and from json. The java protobuf library does that for you out of the box. This is easier to implement. I would be curious to compare performance of both approaches in different contexts.