<p>I'm working on project that includes a server in Golang and a client in Javascript, it's a game therefore they need to exchange data, do you know any good format that is network efficient ( binary protocol )?</p>
<p>I was interested into Flatbuffers from Google but there is no JS library yet :/</p>
<hr/>**评论：**<br/><br/>dgryski: <pre><p>Gzip+json. These will be implemented natively on C in the browser, but all other protocols will be in Javascript. Benchmark to determine if this isn't fast enough. </p></pre>tex0: <pre><p>Why would you want to use anything but JSON for a JavaScript client?</p>
<p>Valid JSON is a valid JavaScript object so this is executed by the Browsers JavaScript engine. I don't think there is anything more optmized than the JavaScript engine in mordern browsers.</p>
<p>But yeah, benchmark it.</p></pre>KrakatoaSpelunker: <pre><blockquote>
<p>Why would you want to use anything but JSON for a JavaScript client?</p>
</blockquote>
<p>Protobuf is faster and more efficient, which OP says he/she cares about.</p></pre>giovannibajo: <pre><p>Alas, that's not true for JS. Javascript protobuf implementation is in Javascript, while JSON parsing is down with native code. There is a big speed difference.</p></pre>KrakatoaSpelunker: <pre><blockquote>
<p>Javascript protobuf implementation is in Javascript, while JSON parsing is down with native code. There is a big speed difference.</p>
</blockquote>
<p>OP asked for network efficiency. Protobuf is going to be much faster to transfer over the wire, and that's almost certainly going to outweigh the extra cost of parsing.</p></pre>tlianza: <pre><p>Someone posted their experience here and the on-the-wire size of protobuffs versus gzipped json is surprisingly marginal: <a href="https://blog.wearewizards.io/using-protobuf-instead-of-json-to-communicate-with-a-frontend">https://blog.wearewizards.io/using-protobuf-instead-of-json-to-communicate-with-a-frontend</a></p></pre>seufert: <pre><p>But why premature optimization without even knowing? </p></pre>jerf: <pre><blockquote>
<p>that's <em>almost certainly</em> going to outweigh the extra cost of parsing.</p>
</blockquote>
<p>Profile. Profile, profile, profile. Your instinct to qualify that statement was a good start, but doesn't really go far enough. You really need a round-trip profile for the whole system.</p>
<p>I'd also suggest to the OP that if you haven't done anything much yet, you won't really know what "good enough" performance is. JSON is probably going to be pretty good.</p></pre>KrakatoaSpelunker: <pre><p>..."a good start"? OP is asking for suggestions on Reddit. I think that's about as far as any comment can be expected to go. </p></pre>egonelbre: <pre><blockquote>
<p>Why would you want to use anything but JSON for a JavaScript client?</p>
</blockquote>
<p>Medium datasets; e.g. 1GB of JSON data is quite problematic in browser - by parsing it into JS Objects you will construct millions of objects which adds GC pressure and has large overhead in object headers.</p></pre>cogman10: <pre><p>Cap'n proto is a good option. Should be pretty quick on both ends.</p></pre>dasgurks: <pre><p>JavaScript internally uses a floating point type for all numbers, which leads to extremely slow bit operations. I would therefore not consider a binary format. So realistically gzipped JSON should be the fastest option considering the client side.</p></pre>cogman10: <pre><p>Modern JavaScript engines are pretty smart. When doing int operations (bit shifts and the like) most engines will internally represent these numbers as ints and only promote to floats when a float operation happens.</p>
<p>Internally things are complex in the JavaScript world.</p></pre>captncraig: <pre><p>I've used thrift with great success.</p></pre>vbaspcppguy: <pre><p>MessagePack </p>
<p>Edit: Huh. There used to be an official JS library but not anymore. </p></pre>giovannibajo: <pre><p>I tried this, and there are many issues, the bigger one being that there is no sane way to handle the int64/uin64 in Javascript. It gets silently converted into a floating point number which then drops precision so the number... is different :)</p></pre>vbaspcppguy: <pre><p>Yeah, you likely won't find a good fix for that.</p></pre>giovannibajo: <pre><p>FWIW our workaround was to unmarshal uint64 into strings. Since they were used for ids, it kind of worked :)</p></pre>kurin: <pre><p>You can do that kinda-sorta painlessly with something like:</p>
<pre><code>type jsonInt64 int64
func (i jsonInt64) MarshalJSON() ([]byte, error) {
return []byte(`"` + strconv.FormatInt(int64(i), 10) + `"`), nil
}
func (i *jsonInt64) UnmarshalJSON(data []byte) error {
val, err := strconv.ParseInt(string(data[1:len(data)-1]), 10, 64)
if err != nil {
return err
}
*i = jsonInt64(val)
return nil
}
</code></pre></pre>cihangirsavas: <pre><p>you can just use <code>,string</code> json tag</p>
<p><a href="http://golang.org/pkg/encoding/json/#Marshal" rel="nofollow">http://golang.org/pkg/encoding/json/#Marshal</a></p>
<blockquote>
<p>The "string" option signals that a field is stored as JSON inside a JSON-encoded string. It applies only to fields of string, floating point, or integer types. This extra level of encoding is sometimes used when communicating with JavaScript programs:</p>
</blockquote>
<pre><code>Int64String int64 `json:",string"`
</code></pre></pre>kurin: <pre><p>Well or that.</p></pre>
