Simplest possible solution for communication between services is to use JSON over HTTP. Though JSON has many obvious advantages - it’s human read...
For further actions, you may consider blocking this person and/or reporting abuse
Hey
I cloned your github repository & ran the test on my machine (windows) I got the results similar to what you have posted in your Readme.md file, which is in contrast to what you have posted here in the blog.
For me the http+json response was bit faster. Could you please share your views.
goos: windows
goarch: amd64
pkg: benchmark-grpc-protobuf-vs-http-json-master
BenchmarkGRPCProtobuf-4 2000 624248 ns/op 10354 B/op 201 allocs/op
BenchmarkHTTPJSON-4 5000 307458 ns/op 8809 B/op 120 allocs/op
PASS
ok benchmark-grpc-protobuf-vs-http-json-master 6.106s
As per your README.md
Results
goos: darwin
goarch: amd64
BenchmarkGRPCProtobuf-8 10000 117649 ns/op 7686 B/op 154 allocs/op
BenchmarkHTTPJSON-8 10000 105837 ns/op 8932 B/op 116 allocs/op
PASS
ok github.com/plutov/benchmark-grpc-protobuf-vs-http-json 4.340s
They are almost the same, HTTP+JSON is a bit faster and has less allocs/op.
Is the type safety really needed? Would this also be faster with MessagePack, which doesn't need pre-defined schema?
Also, how does the story look on the client? Does parsing protocol buffers outperform
JSON.parse()?Personally I prefer type-safe protocols when I use type-safe languages like Go, where you call server function (RPC) and have a struct returned with correct types, so you don't need to validate types, only values.
MessagePack is nice, it can be used without gRPC, so more flexible.
Can't answer question with
JSON.parse():)Love to suggest few tools which work well with JSON data.
jsonformatter.org/json-editor
codebeautify.org/jsonviewer
Thanks for the comparison! To me this makes a lot of sense as binary protocols are usually faster than text based protocols like JSON. However what you are comparing is really a JSON API vs a ProtoBuf API, using an HTTP server and a gRPC server, respectively.
REST on the other hand is not about the actual implementation. REST cannot be slow or fast. It requires a stateless protocol and some defined standard operations to manipulate resources. It gives you some basic principles that help you to make your API interoperable, extensible and easy to understand.
Originally, REST was more of a generalization of HTTP: ics.uci.edu/~fielding/pubs/dissert...
Agree here, let me change it in the repository and later in article here.
Go's JSON handling is notoriously slow so it's hardly surprising that protos would be faster.
Hii
You can also use onlinejsontools.org/ for json validator,beautify,minify,xml,yaml,CSV,bson,plain text,base64,tsv.
Do checkout this site!
If the point is to compare RPC performance, shouldn't it be between gRPC+protobuf and Go RPC+gob? Why is JSON+Go's http package here?
If the JSON string is very long, the format is really a mess. I usually use this online website to format .
jsonformatting.com/