Is is must to have the client to be browser for a web server? Is this a good architecture for mobile clients to have some non browser client and get data from webservers?
I am thinking of implementing a basic browser at mobile client. Login using web methos and rest of the communication (monitoring info at every 10sec) be done using web sockets. Will this work?
Can I implement web sockets without JS?
Thanks
You can implement WebSockets outside the browser, and without any JavaScript involved. You could have i.e. a Android native Java application that talks to a server over WebSockets.
WebSockets is a protocol. The WebSockets API defined for JavaScript running in the browser is something different.
You can authenticate a WebSockets connection during the WebSockets handshake using any method available with HTTP (i.e. basic auth, digest, cram-md5, client cert.-based (TLS), and so on), since the WebSockets handshake is still like any other HTTP conversation. It is only after the handshake is completed that WS is different from HTTP.
Note, that what you likely want on the server side is not a plain old Web server, but a WebSockets server/framework.
Whether using WS to connect mobile clients is "a good architecture" is a bit vague. I would say: if you decide to have your mobile client talk to a server, and that server is under your control, and you want to leverage WS advantages like near real-time/bidirectional, then it might be good. Better than cooking your own low-level protocol.
Related
I have a backend microservice that is using MassTransit and RabbitMQ to publish some messages. I am interested in implement a solution to relay those messages to my app's front end which is written in ReactJS.
I have researched online on various tutorials, most of them show me how to use a JavaScript rabbitMQ client to subscribe/connect to the service bus. But since it is wrapped in MassTransit, and the URL is in the format of "rabbitmq://...", how do I subscribe to this messaging host using Javascript? Ideally I would like to use a WebSocket connection, research tells me that I should consider either STOMP or MQTT, is that something I need to configure in my backend MassTransit/rabbitmq service?
My backend service also have some http endpoints that I can reach using a plain http/https URL, such as https://localhost:7179/api/doSomeJob. Will this help with my intention of using a WebSocket connection to subscribe to the MassTransit service bus?
I am working with codenameone and trying to build a client to connect to a server that is using the Eventsource API to send real time updates. I have the javascript sdk but would rather use something more native to codenameone. IS there any such thing? Or does Codenameone ConnectionRequest support EventSource?
At this time we don't have builtin support EventSource mostly because there is not that much demand for it. The only Java client side library for this I could find was this one: https://github.com/aslakhellesoy/eventsource-java/blob/master/src/main/java/com/github/eventsource/client/impl/netty/EventSourceChannelHandler.java
Which is problematic as we don't support those specific API's (netty).
Most developers who need low level event based communications are using WebSockets which we support well through https://github.com/shannah/cn1-websockets/
You can also use direct TCP streams etc.
In a native app you would normally use push notification to trigger an update from the server. This works well for apps that aren't running. You can learn more about our push notification support here.
I have an angular app on a node js server. On another machine, I have an API server. My dilemma is how to communicate with the API server. The first approach is to send all my AJAX calls directly to the API server. The downside of this approach that the client will see how I send the requests to the API, including the secret key I send in the headers. This means I will have to work harder to secure my API. The other approach is to send my requests to my node js server, and then forward them to the API server. The downside of this approach, however, is increased latency, since it will require two serial HTTP requests. I would love to hear from you what you think is the best way to handle this.
Thanks.
First approach, and you "have to work harder to secure your API". I recommend JWT autthorization.
The most popular and reliable solution for this widely followed architecture style (Front End App to Backend API Server) is OAuth.
OAuth is very easy to setup and use with Angular Js.
As far as AJAX calls are concerned, if your application entails this behavior make sure your API is enable with CORS capability.
I am creating a web application using GAE/GWT. Front end GUI is a web client and the server is a RESTFUL server both running in GAE in different domains.
I am using json with padding to communicate with the server but discovered I won't be able to send a PUT/POST/DELETE request.
My application will be used to mainly used to query data (query: 85% of cases, modify data: 15%). All requests will be authenticated.
I am considering the following options.
1) For querying use JsonpRequestBuilder, for modifying create a proxy in the web client server side and hit the REST service through this proxy. Use GWT RPC to communicate to this proxy.
2) Make every request as a GET request in my REST service (including those that modify data) and use jsonp directly from web client.
I would prefer option 1) but option 2) seems less work to do.
Should 1) be my preferred option ?
Are there any problems with 2) given all my requests will be authenticated. ?
Is there any other easy approach to solve this problem ?
Regards,
Sathya
The simplest solution is to use CORS which allows you to send requests two different origins. But it is not so widely spread (check caniuse), so if you have to support IE8-9, it will not be enough for you.
In your case I would try to implement dual solution (e.g. CORS + server proxy). If browser supports CORS - send the request directly to the target server, if it doesn't - send request via proxy.
Sorry to ask but what is the advantage to have your client running on a different domain ? From what I understand your client's server will do nothing ...
If you are not the "owner" of the REST backend, maybe this backend should developp an authorization system for third party applications, like oauth2.
Then your application can talk backend to backend with a secured connection. You can use scribe to do that on your backend.
What are the usual patterns for bidirectional communication between a client and a server in a wlan environment. How is it possible for the server to push data to a mobile client over wlan after a connection has been established.
Lets say I have a webservice running on a server and the moblie cients in the wlan can use this webservice. Now the question is how can the server invoke methods at the client, or directly send data to the client. How is this handled usually?
I would apriciate some links to read about this topic.
Is this a common problem or is it not that easy to solve?
Cheers
HTTP server push (also known as HTTP streaming) is a mechanism for sending data from a web server to a web browser. HTTP server push can be achieved through several mechanisms.
More at http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term for multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins.
More at http://en.wikipedia.org/wiki/Comet_(programming)
Also there is a recent IETF draft on
Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
https://datatracker.ietf.org/doc/html/draft-loreto-http-bidirectional-01