JavaScript 的协议缓冲区?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/7074147/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-25 22:52:30  来源:igfitidea点击:

Protocol buffers for JavaScript?

javascriptgwtprotocol-buffers

提问by sgtz

Is there a way to do protocol buffers in JavaScript?

有没有办法在 JavaScript 中做协议缓冲区?

Why for .js?

为什么是 .js?

If you think about sciencey requirements for a moment, situations pop up where you might want to send a large block of data to the client. With CRUD-style it doesn't really matter so much what you use. With sciencey stuff it does matter (at least I think it does).

如果您考虑一下科学需求,就会出现您可能想要向客户端发送大量数据的情况。使用 CRUD 风格,你使用什么并不重要。对于科学的东西,它确实很重要(至少我认为它很重要)。

tradeoffs:

权衡:

  • protobuffs balances compactness, serialize and deserialize speeds well.

  • text based protocols (xml / json) have a larger message size... but with javascript I wonder which is more effective.

  • protobuffs 很好地平衡了紧凑性、序列化和反序列化速度。

  • 基于文本的协议(xml / json)具有更大的消息大小......但我想知道哪个更有效。

reference:

参考:

Additional references provided by community (see below for more context):

社区提供的其他参考资料(有关更多背景信息,请参见下文):

采纳答案by agarcian

I have been looking for protobuf for javascript. There is a project here: https://github.com/dcodeIO/ProtoBuf.js

我一直在寻找 javascript 的 protobuf。这里有一个项目:https: //github.com/dcodeIO/ProtoBuf.js

回答by Thomas Broyer

Google makes heavy use of Protocol Buffers in JS (GMail, etc.) through their Closure Library, generating JS code with a (unfortunately non-open-sourced) modified protoc(it would probably have to be portedto a protocextension before being open-sourced).

谷歌通过他们的闭包库在 JS(GMail 等)中大量使用协议缓冲区,生成带有(不幸的是非开源)修改的 JS 代码protoc(它可能必须在开源之前移植protoc扩展中) )。

Apache Wave (whose clientwebapp is built with GWT) also uses Protocol Buffers for its communications with the server, generating Java code by reflecting on the Java classes produced by protoc(this is the PST, aka protobuf-stringtemplate, subproject).
Previously, Wave was using protostuff(and I don't know why they switched to their own solution, I suspect PST is derived from what the original Google Wave was using, and protostuff was only an intermediate step during the move to open-source).

Apache Wave(其客户端web 应用程序是用 GWT 构建的)也使用协议缓冲区与服务器进行通信,通过反映由protoc(这是 PST,又名 protobuf-stringtemplate,子项目)生成的 Java 类来生成 Java 代码。
以前,Wave 使用的是protostuff(我不知道他们为什么改用自己的解决方案,我怀疑 PST 源自原始 Google Wave 使用的东西,而 protostuff 只是转向开源过程中的中间步骤) .

As a side note, I started exploring using Protocol Buffers on the browser side a while ago: http://blog.ltgt.net/exploring-using-protobuf-in-the-browser/& http://blog.ltgt.net/using-protobuf-client-side-with-gwtwith some almost-working code at http://code.google.com/p/protobuf-gwt/that you might want to resurrect.

作为一个方面说明,我开始在浏览器上侧的使用Protocol Buffers探索前段时间:http://blog.ltgt.net/exploring-using-protobuf-in-the-browser/HTTP://blog.ltgt。 net/using-protobuf-client-side-with-gwthttp://code.google.com/p/protobuf-gwt/上有一些几乎可以工作的代码,您可能想重新使用这些代码。

Finally, there's work underway to make GWT RequestFactory proxies compatible with the server-side Java classes generated by protoc(and you could use a protocextension or a similar approach to Wave's PST to generate your RequestFactory proxies). It should already be possible, provided you use builders all the way on the server-side (which is not quite how the Protocol Buffers Java API was designed).

最后,正在进行的工作是使 GWT RequestFactory 代理与由生成的服务器端 Java 类兼容protoc(并且您可以使用protocWave 的 PST的扩展或类似方法来生成您的 RequestFactory 代理)。如果您一直在服务器端使用构建器(这不是 Protocol Buffers Java API 的设计方式),它应该已经是可能的。

回答by Marc Gravell

Historically javascript made working with binary a pain, which probably in part explains a relative lack of tooling - but with javascript typed arrays it could well be a lot easier now. I kinda agree that if you haveto get the same volume of data (via some format), using less bandwidth is a plus - but before embarking on anything you'd need to check that bandwidth / processing was an actual bottleneck (and if bandwidth: have you tried gzip/deflate first).

从历史上看,javascript 使使用二进制变得很痛苦,这可能在一定程度上解释了相对缺乏工具的原因——但现在使用 javascript 类型数组可能会容易得多。我有点同意,如果您必须获得相同数量的数据(通过某种格式),使用更少的带宽是一个加分项 - 但在开始任何事情之前,您需要检查带宽/处理是否是一个实际瓶颈(如果带宽: 你有没有先试过 gzip/deflate)。

I'm a fan of protobuf - and I'd happily see stronger browser-side tooling for it, but json is so ubiquitous that you'd need a compelling reason to challenge the status-quo. Also; think "jsonp".

我是 protobuf 的粉丝——我很高兴看到更强大的浏览器端工具,但 json 无处不在,你需要一个令人信服的理由来挑战现状。还; 想想“jsonp”。