I'm starting a new project and I'm using qooxdoo js framework.
I'm running against a json rpc 2.0 server based on websocket communication.
I wonder if there's already a tested json rpc client for qooxdoo or should I pick any implementation like jayson.
Any considerations to take?
i think it's always better to exclude the server communication to the lowest possible layer so you are not dependent on frameworks in case of changes.
We have our communication written in plain javascript.
Regards,
Mark
Related
I am going to use SOAP based web-service for one of my project. (IONIC framework is based on AngularJS and they have written SOAP client in JavaScript)
My Question are:
Is SOAP based web-services recommended using javascript?
Will there be any performance issue ?
What type/kind of issues, i will face during development?
thanks,
Aleem
SOAP is not recommended because it's XML based.
REST is a recommended approach because it is usually based on JSON, which is a native JavaScript format.
With SOAP you will incur overhead of constant JSON / XML conversion.
Here is a comparison: http://spf13.com/post/soap-vs-rest
Is SOAP based web-services recommended using javascript?
It depends on your application you are working on. If you want security in
your application like your are build app for payment system or something then SOAP will be recommended. But you need to compromise in performance. You can also add security by using Oauth or any third party library.
Will there be any performance issue ?
Yes if you compare SOAP performance with Rest then SOAP load time is more than rest api. Because in SOAP we first load xml of service then hit exact function.
What type/kind of issues, i will face during development?
I think you can do whatever you want with SOAP.
A) Are there any resources of how to use server-side javascript without Node.js?
B) Can a java-based server communicate with a javascript-based client?
Both options are okay (I would be more happy with the B though).
My goal is a simple client-server communication, and I think, that websocket still doesn't stand on two legs.
I appreciate your answer.
Probably the best part of the REST services that they are language-agnostic. You can write serverside REST services in any language you want, then consume them from a completely different language. The most basic example (what you mentioned in option B) is combining Java and JavaScript. There are plenty of tutorials showing how to do that, maybe this one:
JAX-RS + JQuery
is the best as a starter, because it highlights the important part. Later on you may want to go for some more advanced JS library to produce production-ready code faster.
B is definitely possibly with Jersey JAX-RS and JSON encoded responses. It can automatically parse incoming JSON-formatted query (typically GET/PUT/DELETE) params or body (typically POST) parameters into POJOs and can transform returned POJOs into JSON for the response.
More than possible we do it in production with a Marionette.js and Backbone.js based front-end.
WebSocket requires a bit of custom protocol work on your part and loses caching and other client optimizations. It is s best suited to realtime message-oriented or incremental binary upload/download workloads.
I currently have a Qt-based GUI application that simply provides a graphical dashboard (guages, graphs, and such) displaying real-time data provided by another application via a TCP connection. For architectural and security reasons, I have been told that my TCP connection is no longer allowed, and that an HTTPS websocket will be my only conduit. It was suggested that I convert my app to a webapp using HTML5 and Javascript. However, I'm not a web programmer, but may consider this an opportunity to learn a new technology. I want to understand the landscape a little better before making a decision. So, I think my choices are:
Convert my app to a web app, giving me all the advantages/disadvantages of web-based apps. More work for me, as it's a new technology and I already have the Qt/TCP version working fine. If this is the suggested approach, any suggestions on a development environment/tools would be appreciated.
Convert my current Qt app to us a client HTTPS connection rather than a TCP connection. Not sure this is possible. From what I've read, this may not be possible with QtWebKit. Seems strange?
Maybe there's another choice I'm not considering?
You can also use a mixed approach, using WT library. It's c++ (and QT inspired) based.
It has a nice toolkit and supports websockets.
http://www.webtoolkit.eu/wt/examples/
Porting requires a lot of work. On Qt side there are at least two implementations of WebSockets:
QtWebSocket, Qt-based websocket server implementation and alpha-state implementation of websocket client.
WebSocket++, Boost-based websocket server and client implementation.
I just went through a similar exercise for work recently. We settled on the Google Web Toolkit (GWT) framework for doing our web apps. It's completely java-based, meaning you write (almost) everything in Java and the GWT compiler converts it to Javascript for you. We used the GWT-EventService plugin for pushing data from the server to the clients.
I wish I had know about this WT library before we started though, that looks interesting.
You can also have a look at QWebSockets, which is a pure Qt implementation of websockets, both for client and server use.
Update: this library is now an integral part of Qt
I'm working on a single page Backbone application that is going to use web sockets. The application is fairly complex, with 6 or more major areas (screens).
The syntax of web sockets seems straightforward enough and I'm wondering now about the architecture.
When using web sockets, is it most performant to take the first approach or the 2nd approach?
1: Open a single websocket for all live server communication, on any screen or area of the application, and then filter those messages on the client side?
or...
2: Open multiple websockets at a time, where each web socket represents some area of functionality in the application
(I've seen this page, but it's about the server side and I'm interested in the client side: What is the best practice for WebSocket server(s)?)
Update: server is using Jetty (a Java technology not unlike Tomcat).
I would open only one connection, easier to manage. To ease debugging you could namespace all your events with the area name. Also socket.io supports namespaces, see section "Restricting yourself to a namespace" here http://socket.io/#how-to-use.
Also if your doing lot of communications with your websocket you can turn it off with the Visibility API, example here: https://developer.mozilla.org/en-US/docs/DOM/Using_the_Page_Visibility_API
Not a direct answer to your question but, since you say you're using backbone on the client, and assuming you're using node on the server (if not, this may be a compelling argument for doing so), you may be interested in this article which discusses in some detail the sharing of model data between client and (node) server to synchronise state. Backbone, in case you weren't aware, can be installed as a module in node.
Since your application is, as you describe, fairly complex, it seems likely that you will benefit from the ability to share the same complex model directly between client and server.
I'm thinking about how limiting it is for AJAX apps to have to poll for updates, when what would be ideal is for javascript to be able to set up a real two way connection to the server. I'm wondering if there is some method of integrating javascript with a browser plugin that can make a tcp connection so that I could pass data into and out of the browser plugin.
WebSockets is designed to solve this problem.
Here is an implementation with a similar approach:
socketjs
It uses a Java Applet and bridges its API to JavaScript, interesting...
And here another one:
jSocket
This one is a wrapper of the Actionscript 3 Socket API, bridged to JavaScript...
You can use node.js framework's socket.io package which can can be installed via npm (A node package manager).
More detailed usage.
jSocket and Stream are two options that utilize Flash's built-in XML sockets, though neither appears to be production-ready. I'd lean towards using a Flash-based solution rather than Java, as browser penetration is higher and generally offers a better user experience (load times & stability).