I am new to MVVM , and i wanted to understand ,
if you have a model in the back end, say a c# library which is getting data from the database or any other service. how would the Model notify the viewmodel.
i understand in the MVVM INotifyprovier does that for WPF (just read it somewhere), but how about Web app based scenario, does Viewmodel in java-script always have to ping Model to identify if there is a change in the model and then propagate to UI.
I am assuming that the viewmodel would always have to send Ajax request to a asmx or api with a set interval of 10 minutes or so (just an example).
is that how it works end to end. any example will be great.
Because one of the properties is, automatic UI refresh, so I am assuming that fresh data needs to be asked from server at regular intervals. A lot of examples i see on the web is only interacting between ViewModel and View, but hardly i see any thing with Model, ViewModel and View all combined together.
I could think that if one uses SignalR which sends a ping from Server to the client, then the Viewmodel could be updated and hence the View.
But if every time you need to ask a fresh set of data from Sever, so what's with the hype of Knockout, Jquery has been doing that for a while, except the Declarative binding stuff, in the knockout library.
Appreciate if somebody could correct me.
Thanks
It is up to your client application to fetch new data since server doesn't have any concept of observables. There is also a useful mapping plugin that could automatically map your javascript data from the server into an observable. That way when you fetch data you don't have to re-map your data.
However, it is possible to notify client of changes from server. One way is to make server push changes to the client is via HTML5 WebSockets. SignalR is a good library candidate for that task. It that would open a WebSockets connections so server can notify client of changes. And you would use Service Broker SqlDependency to trigger event notifications on updates. An example could be found here.
Good luck!
Also here is a really good video to watch about knockoutjs that would give you understanding of the framework.
Related
I am working on an application in Angular JS 1.5 version.
When i submit a form, based on the input parameters passed, a query is made to the middle layer and data is sent back to the application.
The response received would have around million records. I need to display this data in the form of Graphs on the front-end Using Angular C3 js library.
Can some one please guide me how and where this data received should be stored.
Thanks in advance.
AngularJS is a client-side MVVM pattern. The data coming from your middle layer would be loaded into the viewmodel which will be databound to the view.
If you aren't worried about support for older browser, then localStorage or sessionStorage will probably be your best bet. Most modern browsers will support around 5MB, so you can determine if that's enough. Then in your angular app, you can load the data from the storage into the viewModel or a custom angular factory/service in angular.run() or the controllers themselves.
But unless you have a very very good reason to actually store 1 million+ records to a browser storage, you should just retrieve it your API when you need it.
On a side note, you will probably want to look the memory usage of your angular app. Especially with a lot of data held in memory, things like .watch() and ng-repeat can make your application performance suffer.
I've read a few StackOverflow posts related to this subject but I can't find anything specifically helps me in my scenario.
We have multiple monitoring instances within our network, monitoring different environments (Nagios, Icinga, more...). Currently I have a poller script written in PHP which runs every minute via cron, it asks the instance to return all of its problems in JSON, the script then interprets this and pushes it in to a MySQL database.
There is then an 'overview' page which simply reads the database and does some formatting. There's a bit of AJAX involved, every X seconds (currently use 30) it checks for changes (PHP script call) and if there are changes it requests them via AJAX and updates the page.
There's a few other little bits too (click a problem, another AJAX request goes off to fetch problem details to display in a modal etc).
I've always been a PHP/MySQL dev, so the above methodology seemed logical to me and was quick/easy to write, and it works 'ok'. However, the problems are: database constantly being polled by many users, mesh of javascript on the front end doing half the logic and PHP on the back doing the other half.
Would this use case benefit from switching to NodeJS? I've done a bit of Node.JS before but nothing like this. Can I subscribe to MySQL updates? Or trigger them when a 'data fetcher' pushes data in to the database? I've always been a bit confused as I use PHP to create data and javascript to 'draw' the page, is there still a split of NodeJS doing logic and front end javascript creating all the elements, or does NodeJS do all of this now? Sorry for the lack of knowledge in this area...
This is definitely an area where Node could offer improvements.
The short version: with websockets in the front-end and regular sockets or an API on the back-end you can eliminate the polling for new data across the board.
The long version:
Front-end:
You can remove all need for polling scripts by implementing websockets. That way, as soon as new data arrives on the server, you can broadcast it to all connected clients. I would advise Socket.io or the Primus websocket wrapper. Both are very easy to implement and incredibly powerful for what you want to achieve.
All data processing logic should happen on the server. The data is then sent to the client and should be rendered on the existing page, and that is basically the only logic the client should contain. There are some frameworks that do all of this for you (e.g. Sails) but I don't have experience with any of those frameworks, since they require you to write your entire app according to their rules, which I personally don't like (but I know a lot of developers do).
If you want to render the data in the client without a huge framework, I highly recommend the lightweight but incredibly useful Transparency rendering library. Using this, you can format a Javascript object on the server using Node, JSONify it, send it to the client, and then all the client would have to do is de-JSONify it and call Transparency's .render.
Back-end:
This one depends on how much control you have over the behaviour of the instances you need to check. I assume you have some control, since you can get all their data in a nice JSON format. So, there are multiple options.
You can keep polling every so often. This is the easiest solution since it requires no change to the external services. The Javascript setInterval function is very useful here. Depending on how you connect with the instances, you might be able to use a module like Request to do the actual request, so that takes out a bunch more of the heavy lifting.
The benefit of implementing the polling in your Node app as well, is that you will receive the data in your Node app and that way you can immediately broadcast it to the clients, even before inserting it into a database. This will greatly reduce the number of queries on your database.
An alternative to polling would be to set up a simple Express-based API where the applications can post their 'problems', as you call them. This way your application will get notified the moment a problem occurs, and combined with the websockets connection to the client this would result in practically real-time updates.
To be more redundant, you would have a polling timer alongside the API, so that you can check the instances in case there's something wrong that causes them to not send over any more data.
An alternative to the more high-level API would be to just use direct socket communication, which is basically the same approach only using a different set of functions.
Lastly, you could also keep the PHP-based polling script. This would be the most efficient solution since you wouldn't go and replace everything. Then from the Node app that's connected to the clients with websockets, you could set an interval to query the database every so often and broadcast the updates. This will still greatly reduce the number of queries, since no matter how many clients are connected there will only be one query, the response of which then gets sent to all connected clients.
I hope my post has give you some ideas of how you could implement your application using Node. Keep in mind though that I am just one developer, this is how I would approach building your application in Node. There will definitely be others who have different opinions.
I'm a Meteor newbie. I came across the Meteor Streams package which allows for "Real Time messaging for Meteor". Here's what it can do:
Meteor Stream is a distributed EventEmitter across meteor. It can be managed with filters and has a good security model (Inherited from existing meteor security model). You can create as many as streams you want, and it is independent from mongo.
With Meteor Streams, you can communicate between
client to clients
server to clients
client to server
server to servers
There's an example of it being used in a realtime blackboard where users can draw together. Being a Meteor newbie, out of ignorance, I ask, what is the difference between using something like this and just updating a session ie Session.set, Session.get. As I've seen session being used, two browsers can be open and updated with the same information with Session.set. So in an environment where two people are drawing, why can't it just be done using Session setting vs Meteor collections or Streams? what is it I'm not understanding about Session setting? I believe I'm probably wrong thinking session setting could be used instead, I just would like to know why. It will help me to understand Sessions in Meteor and the Meteor Streams package.
A Session variable is a quick variable created so you can reactively change stuff in templates.
E.g you have this in your template:
<template name="hello">
{{message}}
</template>
With it a template helper
Template.hello.message = function() { return Session.get("message") }
If you do something like Session.set("message", "Hi there"), the html will say Hi there. The idea is that you can easily change your HTML using this. Its a type of one way data binding.
A Meteor stream helps you communicate between the browser and server (or other combinations between servers and clients) so you can send messages to and fro, but it wont help you change the HTML.
Likewise the Session wont help you communicate between the browser and server, it can help change HTML when you have a result in your events or pass data reactively between your javascript code and the html that the user sees.
With the blackboard example, you can share the data the other users have drawn, but it wont help you draw onto your blackboard. (In the case of blackboard you could use streams because you're updating a canvas with javascript, so you don't need a session). You cant use Session on its own (or dont need to since its a canvas) - but you need Meteor streams to communicate to the other users.
You could use stuff like JQuery to update your html too! Using a Session is by far the easiest though, because you can use it all over and only have to update one thing for all the rest to change.
Basically, I have created a NODEJS app that uses Jade as its templating engine, along with Express and a MySQL database.
I am looking to create a new page which allows user to share a portion of text, and then a div underneath it named "Wall" will update dynamically with the new status.
Basically, it would ideally be similar to Facebook where something is typed, shared and then the page updates below dynamically. I'm also looking to have the wall page update when a new post have been shared from a users friend. All updates shared by the users would be sent to a database.
I have conducted a lot of searches but seem unable to gather a right answer.
I have narrowed it down to the use of either of the following: JQuery, Ajax, PHP.
Since the site I am building is built in JS - what is my best option?
I'm pretty new to all of this, but I assume when a user clicks share it calls a JS file which then stores the update in the database. But how do I get my "Wall" to refresh upon new content?
Any help greatly appreciated.
You've posed a conceptual question. So I'll do my best to explain some of the conceptual options you can choose to further explore and do your own research on how to best implement it with your project.
You have two paths to go here.
You can have your own wall update (do a refresh / re-render on the UI side) upon a successful AJAX write to your database, this would be something you implement in your AJAX callback function - basically the JS function that gets executed after your write request (submitting the new post) to the database returns successful.
A whole other branch of options you could explore, is implement either of the following options to basically "listen" in for changes server-side, and have the re-rendering react as the callback you use:
Polling - basically issue a request every X number of
seconds to check if there have been updates, or change of state on
server-side.
WebSockets - checkout Socket.io. Through this you can "push" messages from the server-side to your clients. As a note, WebSockets are not universally supported in every browser and from past experience I've found WebSocket protocols even differ by browser versions. So if you need universal support, I'd go with a polling method.
Good luck on your project, hope this helps!
Use...
setTimeout(function(){
/* update wall here */
}, 1000)
to poll your "Wall" backend and updated the content.
I'm programming a browser application (html5+websockets+css3+js preferred) that enables users to concurrently access (read, write) attributes of the same object. To create a real-time experience I'd like to use optimistic synchronization. I read about Timewarp and Trailing State algorithms and I wonder if there is a javascript library, which already implements these or similar algorithms.
I found this question, but unfortunately it was not answered yet. XSTM only supports pessimistic synchronization as it seems.
Do you have any idea for me?
I am working on a realtime HTML5 web browser application now too. Maybe my choice of weaponry could inspire you...who knows, so I am using:
Frontend:
KnockoutJS -it takes care of displaying data which I send to every connected client in JSON(view models), you can easily subscribe to changes in the client data and push the changes back to server, though I am having problems displaying pages with knockoutjs on mobile browsers
on serverside I run custom made server based on Fleck
Since JSON is my favourite data format, I ditched SQL databases in favour of [RavenDB][2], which stores data almost exactly as they are sent via websocket protocol and also it is pretty quick