我有一个单页面应用程序,当前使用ajax和REST与服务器通信.我主要使用promises和deferred来构造代码,并使用pubsub代理在组件之间进行通信.通常,代码的结构遵循Zakas’ suggestions for scalable application architecture.
为了性能和易于开发,我想将至少一些与服务器的交互移动到websockets中.我计划更改为使用websockets的一些特定交互是：
>聊天功能
>对长时间运行任务的反馈
>更新当前查看对象的属性(例如某人POST到REST端点,该端点对应于我当前正在呈现的对象)
我的问题是：
>什么是其他快速获胜(即特定用例的websockets>> ajax)我应该注意什么？
> design patterns最有助于构建websocket代码？
>是否应该保留RESTful ajax调用的某些交互,或者是否有强大的情况可以使用100％的websockets？
谢谢.
编辑
赫拉是我提交之后发现的一些相关问题.这些问题与我的问题的最后部分密切相关(100％的websockets是否有意义).
> What is the disadvantage of using websocket/socket.io where ajax will do?
> websocket api to replace rest api?
> Why use AJAX when WebSockets is available?
> With websockets, is there a place for AJAX?
解决方法:
正如我所看到的,能够通过单一(基于WebSocket)协议同时执行PubSub和RPC,具有协同作用,技术和概念上的优势.事实上,我们一直在开发并使用这样的协议：WAMP.
这是一个why one protocol的FAQ条目,以及一个blog post,它讲述了一个真实的战争故事,即将传统的Ajax迁移到基于WebSocket的完整解决方案,该解决方案在WAMP,Autobahn和Crossbar.io上运行.
披露：我是WAMP,Autobahn和Crossbar.io的原作者,并为Tavendo工作.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
