We are trying to document our SignalR Hubs via AsyncAPI.
This is the best example so far we were able to find about SignalR and AsyncAPI:
https://github.com/neuroglia-io/AsyncApi/issues/3
When we apply this scenario to our code in a similar manner, we can create a specification, but this specification results in "Empty or invalid document" in asyncapi studio. I cannot understand why.
Another question is, AsyncApi seems to support SignalR because WebSockets is what SignalR uses, but not necessarily. (In our case, SignalR might fall back to Server Events / Long Polling depending on firewall configuration.) Does that mean that the AsycnApi UI will be useless for us when that happens? Or am I mixing things here?
Related
In database some entity is getting updated by some backend process. We want to show this updated value to the user not real-time but as fast as possible on website.
Problems we are facing with these approaches.
Polling :- As we know that there are better techniques then polling like SSE, WebSockets.
SSE :- In SSE the connection open for long time(I search on internet and found that it uses long polling). Which might cause problem when user increases.
WebSockets :- As we need only one way communication(from server to client), SSE is better then this.
Our Solution
We check database on every request of user and update the value.(It is not very good as it will depend upon user next request)
Is it good approach or is there any better way to do this or Am I missing something about SSE(misunderstood something).
Is it fine to use SignalR instead of this all?(is there any long connection issue in it or not?)
Thanks.
It's just up to your requirements what you should use.
Options:
You clients need only the update information, in the case they make a request -> Go your way
If you need a solution with different client types like (Webclient, Winformclient, Androidclient,....) and you have for example different browser types which you should support. Not all browsers support all mechanisme... SignalR was designed to choose automatically the right transport mechanisme according to the mechanisme which a clients supports --> SignalR is an option. (Read more details here: https://www.asp.net/signalr) Has also options that your connection keeps alive.
There are also alternatives like https://pusher.com/ (For short this is only a queue where you can send messages, and also subscribe for messages) But these services are only free until for example some data volume.
You can use event based communication. When ever there is a change(event) in the backend/database, server should send a message to clients.
Your app should register to respective events and refresh the UI when ever there is an update.
We used Socket IO for this usecase, in our apps and it worked well.
Here is the website https://socket.io/
JMS or messaging is really good in tying up disparate applications and form the infrastructure of many ESB and SOA architectures.
However say Application A needs an immediate response from a service on Application B e.g. Needs the provisioning details of an Order OR Needs an immediate confirmation on some update. Is Messaging the right solution for that from a performance point of view? Normally the client would connect to a MoM on a Queue - then a listener which has to be free will pick up the message and forward to the server side processor - which will process the response and send it back to a Queue or Topic and the requesting client will follow the same process and pick it up. If the message size is big the MoM will have to factor that in as well.
Makes me wonder if Http is a better solution to access such solutions instead of going via messaging route? I have seen lots of applications use MoM like AMQ or TIBCO Rvd to actually use for immediate Request/Response - but is that bad design or is it some fine tuning or setting that makes it same as Http.
It really depends on your requirements. Typically messaging services will support one or all of the following:
Guaranteed Delivery
Transactional
Persistent (i.e. messages are persisted until delivered, even if the system fails in the interrim)
An HTTP connection cannot [easilly] implement these attributes, but then again, if you don't need them, then I suppose you could make the case that "simple" HTTP would offer a simpler and more lightweight solution. (Emphasis on the "simple" because some messaging implmentations will operate over HTTP).
I don't think Request/Response implemented over messaging is, in and of itself, bad design. I mean, here's the thing.... are you implementing both sides of this process ? If not, and you already have an established messaging service that will respond to requests, all other considerations aside, that would seem to be the way to go... and bypassing that to reimplement using HTTP because of some desgin notion would need some fairly strong reasoning behind it, in my view.
But the inverse is true as well. If you an HTTP accessible resource already, and you don't have any super stringent requirements that might otherwise suggest a more robust messaging solution, I would not force one in where it's not warranted.
If you are commensing totally tabula-rasa and you must implement both sides from scratch..... then..... post another question here with some details ! :)
This is a follow-up to another question I asked, but with more precise information.
I have two fundamentally identical web pages that demo WebRTC, one using XSockets as the backend signaling layer, and one using SignalR as the backend signaling layer.
The two backends are fundamentally identical, differing only at the points where they (obviously) have different ways of sending data down to the client. Similarly, the TypeScript/JavaScript WebRTC code on the two clients is completely identical, as I've abstracted out the signaling layer.
The problem is that the XSockets site works consistently, while the SignalR site fails (mostly consistently, though not completely). Usually it fails while calling peerConnection.setLocalDescription(), but it can also fail silently; or it can (sometimes) even work.
You can see the two different pages in operation here:
XSockets site: http://xsockets.demo.alanta.com/
SignalR site: http://signalr.demo.alanta.com/
The source code for both is at https://bitbucket.org/smithkl42/xsockets.webrtc, with the XSockets version on the xsockets branch, and the SignalR version on the signalr branch.
So my question is: does anybody know of any reason why using one signal layer instead of another would make any difference to WebRTC? For instance, does one or the other send back Unicode strings instead of ANSI? Or have I misdiagnosed the problem, and the real difference is elsewhere?
Figured it out. Turns out that SignalR 1.0 RC1 has a bug in it that changes any "+" in a string into a space. So lines in the SDP that looked like this:
a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2+z
Were getting changed into this:
a=ice-pwd:qZFVvgfnSso1b8UV1SUDd2 z
But because not every SDP had a "+" in it on a critical line, sometimes it would work. Everything explained.
The bug has been reported to the good folks working on SignalR (see https://github.com/SignalR/SignalR/issues/1194), and in the meantime, a simple encodeURIComponent() and decodeURIComponent() around the strings in question fixed it.
I'm sure Wave doesn't poll the server every millisecond to find out if the other user has typed something... so how can I see what the other person is typing as they type? And without hogging the bandwidth.
Persistent HTTP, Comet
Keep your HTTP connection alive and send characters as they are typed
*Edit in 2014: also, take a look at WebSocket and HTTP/1.1 Upgrade header. Browsers started implementing this around 2010, so I'm adding this to original answer.
They probably use Web Sockets, aka server-sent events: http://www.w3.org/TR/websockets The underlying protocol can be found (as a draft) at the IETF.
Update: it doesn't seem WebSockets has any implementation yet; and a video from Google I/O (go to 11:00) talks about a long lived HTTP GET request.
Server Push in GWT
Server push is the Wait, Respond, Close, Re-Open paradigm:
Wait: When the GWT code makes a call
to your server for some data that you
don't have yet, freeze (wait)
Respond: Once the requested data is
available, respond with it
Close: Then, close the connection.
Re-Open: Once your GWT code receives the response, immediately open up a new connection to query for the next event.
See Video Google Wave: Powered by GWT around at minute 55 (near the end)
Q: How you implement the persistent Connections, the long living http connections
A: Future Plan: HTML5 Web Sockets. Longer term. That's what we use at the moment.
Q: Is there a platform or library for this we can download and play with?
A: Not sure. Don't think so
P.S.: That's what he said. To me it did not make much sense ("future plans" vs "using at the moment"). Any native english speaker might want to verify if I transcribed it correctly?
Pure speculation but could it be using the Server Side DOM events from the HTML 5 spec?
the entire reason for WebSockets is to have the browser keep a bi-directional socket open to a server so that real time communications can be used. When someone types on the other end, in a wave client, it triggers an event that is sent to the server and the server in turn looks to see who should also receive the event and pass them the event, in this case the typed letter.
WebSocket and Comet are different.
Granville
Probably comet for now websocket in the future. Because it works in Firefox 3.5 and from what I've read the websocket is only available in the nightly builds of FF... I could be wrong though... as it appears to not work in IE at all.
I spent some time reverse-engineering the Google Wave client code (shameless plug for http://antimatter15.com/misc/read/ which is a read-only public client for google wave for all public waves without need of robots or gadgets which was a lot more useful a month ago when Google didn't launch the upgrades).
Anyway, Google uses the GWT framework with certain aspects of the Google Closure library (which is actually open source and documented) and they use the goog.net.BrowserChannel library, which from the comments is also used for chat functionality within gmail.
http://closure-library.googlecode.com/svn/docs/closure_goog_net_browserchannel.js.html
I would assume that they use ajax requests. Do an XMLHttpRequest, which is asynchronous, and when the server has something to send your browser the javascript callback that was registered gets the data and does whatever with it. So basically the browser requests the next event, handles it, repeats indefinitely.
We have two client apps (a web app and an agent app) accessing methods on the same service, but with slightly different requirements. My team wants to control behaviour on the service side by passing in a ApplicationType parameter to every method - which is essentially an enum containing the name of the calling client application - which is then used as a key for a database lookup to configure the service with client-specific options.
Something about this makes me uneasy as I don't think the service should really have to be aware of which client is calling it. I'm being told that it's easier to do it this way than pass a load of options dynamically through the method call.
Is there anything wrong with the client application telling the service who they are? Or is there really no difference between passing a config key versus a set of parameterized options?
One immediate problem I can see is that if we ever opened the service to another client run by a third party, we'd have to maintain their configuration settings locally for them. At the moment we own both client apps so it's not so much of a problem.
How would you do it?
In a layered solution, you should always consider your layers as onion-like layers, and dependencies should always go inwards, never outwards.
So your GUI/App layer should depend on the businesslogic layer, the businesslogic layer should depend on the data access layer, and similar.
Unless you categorize the clients (web, win, wpf, cli), or generalize it with client profiles (which client applications can configure), I would never pass in the name of the calling application, as this would make the business logic layer aware of and dependent upon the outside layer.
What kind of differences are we talking about that would depend on the type of application? If you elaborate a bit on the differences here, perhaps someone can come up with some helpful advice on other ways to solve this.
But I would definitely look for other ways before going down your described path.
Can't you create two different services, one for each application? The two services will share a lot of code or call a single internal service with different parameterization depending on what outer service was called.
From a design perspective, this is no different than having users with different profiles. From a security perspective, I hope your applications are doing something to identify themselves, lest users of one application figure out a way to invoke the other applications logic as a hack. (Image a HR application being used by the mafia and a bank at the same time, one customer would be interesting in hacking the other customer's application on a shared application host)
In .net the design doesn't feel this way because the credentials live on the thread (i.e. when you set the IIPrincipal, that info rides on the thread-- it is communicated along with each method call, but not as a parameter.)
Maybe what you are looking for in terms of a more elegant design is an ApplicationIdentity attribute. You'd have to write a custom one, I don't know of one in the framework right now.
This is a hard topic to discuss without a solid example.
You are right for feeling that way. Sending in the client type to change behaviour is not correct. It's not a bad idea for logging... but that's about it.
Here is what I would do:
Review each method to see what needs to be different and why.
Create different methods for different usages. The method name should be self explanatory. If you ever need to break compatibility, you have more control (assuming you're not using a versioning system which would be overkill for an in-house-only service).
In some cases request parameters (flags/enum values) are more appropriate.
In some cases knowing the operating environment is more appropriate (especially for data security). The operating environment almost always sent during a login request. Something like "attended"/"secure" (agent client) vs "unattended"/"not secure" (web client). Now you must exchange a session key (HTTP cookie or an application level session id). Sessions obviously doesn't work if you need to be 100% stateless -- especially if you want to scale-out without session replication... if you have that requirement, send a structure in every request.
Think of requests like functions in your code. You wouldn't put a magic parameter that changes the behaviour of the function. You would create multiple functions that each behave differently. Whoever is using the function makes the decision which one to call.
So why is client type so wrong? Client type has no specific meaning on its own. It has many meanings and they may change over time. It's simply informational which is why it is a handy thing to log. An operating environment does have a specific meaning.
Here is a scenario to consider: What if a new client type is developed that is slightly different in a way that would break compatibility with the original request? Now you have two requests. 2 clients use Request A and 1 client uses Request B. If you pass in a client type to each request, the server is expected to work for every possible client type. Much harder to test and maintain!!