I am trying to understand how single page apps spa's work.
My understanding of a spa is that you load the data on start-up and you use ajax calls for save etc, and the whole idea is that your models cache data on the client so you have a rich snappy experience in your browser.
I am confused as to how the client stays in sync with the server changes.
E.G. If I have multiple users logged into my spa and they are all making changes, how does my client know that another user has updated a persons details if it is using cached data?
My guess is that something similar needs to happen server side to update the client on a change. Does this exist or am I misunderstanding something?
Any help or pointers to additional info would be much appreciated.
Thank you in advance.
For server to client communication you can use SignalR.
SignalR allows you to create a hub on the server which you can then tell to update the clients.
It works with a fallback mechanism, it tries to use the following techniques and falls back onto the next one if it's not available in the browser:
Web Sockets
server sent events
forever frame
long polling
Link for fallbacks: http://www.asp.net/signalr/overview/introduction/transports-and-fallbacks
Link for signalR: http://signalr.net/
Related
I just confused to distinguish between app server and web server.
as far as i know , web server handles user request , fetch from database and renders back to user and so on .
Now my question is what does a app server do in a web-application??
why it is useful to use app server along with web server ??
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.
An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.
Hope this is clear now!
I am looking to make an web application that allows to PUT ,GET etc from the client to the server. That is easy. However, if a certain event occurs on the serverside I would like to send information to the client. My clients will be mobile devices. I decided to use asp.net webapi. How should I handle sending information to the client. Should I use tcp sockets? What if the event occurs, and I need to send a json to the client, however the client has the application in suspended state. Can I buffer the messages and send it at the next socket connection?
Any insight would be greatly appreciated.
Thanks
Have you thought of trying WebSockets?. Since they are HTTP, you will not have much problems with things like firewalls. While its original intent was to be used in browsers, there seems to be libraries floating around for objective-c though I have not used any of them my self. One such library http://corner.squareup.com/2012/02/socketrocket-websockets.html
First I want to describe the scenario:
Let's say I have an admin page where multiple different things are displayed.
The things displayed are sent by client devices (SignalR between admin <-> clients).
Clients can see what other clients send.
They can like this stuff.
Likes have an effect to the order of items on the admin side.
Everything that is send across SignalR has to be saved in the database (can be done async) for the simple reason when somebody refreshes the site (initial page load).
Admin side
At first I wanted to do my own polling with a 5s interval (ASP.NET Web API).
But that's not real time and that's not what I call good performance (the db is queried every time).
Now my problem is to make sure that the received items via SignalR from the clients are in sync with the database.
And also the order has to match. So I have to replicate a little of the business logic concerning the likes/votes in JavaScript and on and on.
This seems prone to errors.
What are your thoughts on this?
I have made a lib that fits very good when you want to catch events fired in backend and forward them to clients. Please see my answer here
How to use a Singleton Signalr client within an MVC application
Refreshing List of news using SignalR
I am working on a project where we have a very slim server (Linux, Nginx, Sqlite), but our web application shall not show any signs of shortcomings (should contain charts, dashboards, nice looking controls) – so I need the client to do all the heavy work.
I assume that BreezeJS would be good in this case, because it manages data on the client, in a way that reduces workload on the server. The server only sends the data to the client and at some point gets data back that has to be saved to the database. All caching and other stuff is managed on the client.
I assume AngularJS would also be good in this case, because it is a client-side MVC-framework, again reducing workload on the server. It also works seamlessly together with BreezeJS.
I assume Wijmo would also be good in this case, because it provides nice looking controls and also works seamlessly together with BreezeJS and AngularJS.
Are my assumptions right? Any comments?
My only concerns are how I get BreezeJS to “talk” with the Linux-server (Nginx, Sqlite). Are there any samples regarding this? Is anyone working on something similar?
We will be releasing a NodeJS/Express/Mongo example within the next few weeks that should show how to communicate with an arbitrary non-.NET backend. (also see the current 'Edmunds' example in the Breeze zip). But we don't have anything yet that explicity shows Breeze working with a Linux backend. Please vote for this here: Breeze User Voice
I have an existing complex website built using ASP.NET MVC, including a database backend, data layer, as well as the Web UI layer. Rebuilding this website in another language is not a feasible option.
There are some UI elements on some views (client side) which would benefit from live interactivity, involving both push and pull, so rather than implement some kind of custom long polling or websocket server in asp.net, I am looking to leverage node.js for Windows, and Socket.io.
My problem is that I need two way communication between both applications. Each user should only be able to receive data once they are authorised on the ASP.NET website, so I first need communication for this. Secondly, once certain events occur on the ASP.NET website I want to immediately push this data to the Node server, to be broadcast to specific users or groups of users. Thirdly, I would like any data sent to the node.js server to be pushed to the ASP.NET website for processing, as this is where all our business logic lies. The sole reason for adding Node.js is to have the possibility to push data directly to the client, I do not want to build any business logic into it (or as little as possible).
I would like to know what the fastest method of two-way push communication is between Node.Js and ASP.NET. The only good option I'm aware of so far is to create a special listener on a specific port on the node.js server and connect to that, but I was wondering if there's a more elegant or more efficient method? I also know that you could use a database inbetween but surely this would need to be polled and would be less efficient? Both servers will be running on the same server under a Visual Studio project.
Many thanks for any help you can provide.
I'm not an ASP.NET expert, but I think there are multiple ways you can achieve this:
1) As you said, you could make Node listen on a specific port for data and then react based on the data received (TCP)
2) You can make POST requests to Node.js (HTTP) and also send an auth-key in the process to be extra-secure. Like on 1) Node would react to the data you send.
3) Use something like Redis for pub-sub, send messages from ASP.NET (pub) and get them on the Node.js part (sub). This is even better if you want to scale your app across multiple machines etc.
The only good option I'm aware of so far is to create a special
listener on a specific port on the node.js server and connect to that,
but I was wondering if there's a more elegant or more efficient
method?
You can try to look at redis pub/sub model where ASP.NET MVC application and node.js would communicate through separate channels in order to achieve full-duplex communication. Or you can also try to use CouchDB change nofitications.
I also know that you could use a database inbetween but surely this
would need to be polled and would be less efficient?
Former techniques do not require you to poll for changes, but instead they will notify you when the changes happens or channel message arrives.