capturing all the input changes and page events in my web application with Nodejs backend application.
How the site watcher should be designed for the site?
Are there any possibilities to use effective channel in clientSide to monitor the client side actions?
Related
how to refresh local data automatically when server data changes in azure mobile app(android).Right now i m using a timer that refresh my server request but this approach is not satisfactory as my app keep on sending requests to azure.What is the best approach for doing this?I also tried to understand one of the answer in stack overflow based on Exponential Back Off Delay Based but failed to understand.Kindly just guide me on this
For communicating server-side updates to client apps, use SignalR.
Here's some guidance on using it with Azure Mobile Apps: Real-time with ASP.NET SignalR and Azure Mobile .NET Backend
We just released an update for Azure Mobile Services .NET backend which enables you to use ASP.NET SignalR for real-time, bi-directional communications with your mobile applications. SignalR will use WebSockets under the covers when it's available, and fallback to other “techniques” (i.e. HTTP hacks 😉) when it isn't. Regardless of the mode, your application code stays the same.
Best way to get notifications to Angular Client from an Azure hosted Web API
I'm creating an app where users can interact on articles. The back-end is asp.net core 2 web api. Front end is nodejs Angular universal app. I've decided to host on azure.
I need to get user notifications from server to the client. So if an user wrote a document and another user liked it, the notification will be sent to the user that wrote it, if the user is running the site.
I know I can achieve this using SignalR or Socket.io, but I was looking for something that azure provides.
Is there anything in azure that I can use, such as Event Hub, Event Grid or NServiceBus where there's already a javascript client that works on the browser, listening on Events?
hi best way notification is azure web job with azure web hook
using web job you can get notification to any devices
for more details please see
enter link description here
I'm working on a Restful Web Application. I divide frontend and backend, using Angular2 for the front, and NodeJS for the back.
I would like to use Notifications and push them to specific users.
Sample : If my user decide to subscribe, he could get a Desktop notification when I decide to send one or if my NodeJS serveur want to send a message to a user group.
I have seen a lot of differents modules for the frontend and backend, but I'm a little bit lost.
Architecturally, how should I add this service in my application?
Should I use specific node modules?
You talk about desktop notifications. I guess you want the user to receive its notifications also when the browser or app is closed. In that case you need a Service Worker. A Service Worker is a script that your browser runs in the background, to which the message is being pushed when the browser or app is closed. For a nice introduction to Service Workers, read this. Angular has a Service Workers implemented in production version since 5.0.0. Klik here to read more about it.
At the backend you need a special Node module to send the notification. For instance node-pushserver, but there are many others. This special node module connects to a messaging service whom actual send the message. You can use for instance Google's cross-platform messaging solution Firebase Cloud Messaging (FCM) (the successor of Google Cloud Messaging (GCM)). It can send to Web, iOS and Android.
At the client side you need to register the Service Worker for push notification. Then you will get an endpoint that needs to be stored at the node server side. You send a push request with this endpoint to the messaging service every time.
You can also make use of a paid push notification provider to do the job. Click here for a list of them.
Setting up a WebSocket connection (like socket.io) won't work since it can't stay connected with the Service Worker.
You can use WebSockets for pushing data from the Node.js server. Add the ws package to your server's package.json. Take a look at the BidServer.ts here: https://github.com/Farata/angular2typescript/tree/master/chapter8/http_websocket_samples/server/bids
The Angular client is here: https://github.com/Farata/angular2typescript/tree/master/chapter8/http_websocket_samples/client/app/bids
I am working on a node.js based Web application that needs to be able to push data down to the browser. The Web app will be sitting behind a load balancer.
Assuming the Web app has a POST REST API as:
/update_client
and assuming there is a third-party application calls this API to push some data to the Web app, and then the Web app pushes the data down to the browser.
Now assuming I have two servers behind the load balancer, with the Web app running. A browser client connects to server 1 to listen on the event. Then the other applications hits the /update_client API at the server 2. Now since the two activities happen on two different servers, how can server 2 notify server 1 to send the data to the connected clients?
And what if I am using auto scaling, with dynamic number of servers behind the load balancer?
You need to have some kind of shared resource behind the servers so they all know about updates. I show how to use Redis Pub / Sub for this in a blog post I wrote recently.
Server Sent Events with Node JS
I'm planning an application that has a mobile app as a front end (and perhaps a web front end also that performs a different purpose). Something like Runkeeper, or Runtastic, if you're familiar with those apps. The mobile device is the primary method of user interaction, and the web site has stats and dashboards that the users can view afterwards.
I would like the main application to reside in Windows Azure. I'm confused about how to architect the application though - should the business logic reside in a web role, or a worker role? If the main user interface is a mobile app, does it connect to the worker role to persist or retrieve data, or to a web role, or neither? I understand a typical scenario where a web role provides a user interface which can persist data directly to storage or pass data to queues or tables to be picked up by worker roles, but the presence of the mobile app throws me off.
Any help? Thanks!
Andy's answer is great, but let me add a different flavor. The only difference between a web role and a worker role is that the web role automatically has IIS turned on and configured. A good rule of thumb is that if you want IIS, use a web role. If you don't want IIS, use a worker role.
For hosting a server component for mobile apps to connect to, I think the simplest thing that would work would be a web role hosting an ASP.NET web application. Web applications can be used for services as well as web front end (HTML) web sites.
ASP.NET MVC and Web API make setting up web services really easy, and it's easy to work with non-HTML data formats, such as JSON or XML. Your mobile app could communicate with the web app using a REST JSON API, or you could use XML/SOAP if you wanted to, or whatever format you want. REST APIs with JSON as the transfer format is probably the most popular at the moment. One way to think about a web app is that it's just a way to send and recieve data from clients. If the client is a web browser, you can serve up your content as HTML pages, or if your client is a mobile app, you can serve up your data as JSON and let the client display it however it needs to. Basically, your web app can be both your web site (HTML), and your "API" for non-web-browser clients.
You can think of worker roles sort of like Windows Services. They are primarily used for doing back-end processing, and things like that. A worker role might provide some capability to host a public facing API, but you would have to manage connections, message pipelines, recycling, and all that yourself; whereas, a web role would have a web server (IIS) provided for you to manage connections, etc. If you are going to introduce things like message queues, it would make sense to have the public facing API be a web role, and the message processing component a worker role. The web app could receive the message from the client via a REST JSON API, and then pass the message off to a queue, where the worker role picks it up. Introducing queues and worker roles makes sense if you have heavy-duty server-side business logic that can be processed in the background without impacting the client.