I'm developing an on-site WinRT application and would like to send push notifications when a new update is available (since it's an on-site app, the installation process requires a custom loader rather than the Windows Store app).
However, I'm trying to wrap my head around how such a system should ideally function.
I could obviously create a service which returns the latest version number and the app would periodically poll the service for that info. It would be easy to implement, but it seems like a very ugly approach (the need to send constant requests for the latest version doesn't seem like an elegant one).
I have the power of Azure at my disposal. Obviously a Notification Hub would be the preferred way. HOWEVER, I have no intention of getting a Windows Store account purely to develop a "private" on-site application. So using the Notification Hub is a no-go.
I've thought about using topics. This WOULD work, but every client would probably need to be added as a subscriber. While technically possible, the administrative overhead could be a major issue. I also thought about creating the subscribers dynamically by the WinRT application itself. However the SDK (Azure Messaging Managed) for handling this is too old and always throws an error (invalid date format, which apparently was changed at some point) when creating subscribers. The only "current" package from MS seems to be for the full .NET framework, not the limited WinRT counterpart.
I'm looking for ways around this problem. Either a newer, proper SDK (which can handle listing and creating subscriptions as well as receiving topic), or perhaps a completely different approach to the problem.
Note - I don't need any code just yet. Pseudocode or simply a description on how the communication would work should suffice.
For a limited scale deployment, Service Bus Topics may quite well be a feasible choice. Or you may want to take a look at IoT Hub as an alternative push notification channel.
The new Service Bus client SDK for .NET Standard lives this repo, but we do not build binaries as of yet: https://github.com/Azure/azure-service-bus-dotnet
Related
According to https://firebase.flutter.dev/docs/messaging/usage/
onBackgroundMessage(...) is running on its own isolate.
How do I pass data from that isolate (which automatically spawns and runs a top level function) to the main app without using persistent storage (sqlite/files) which isn't supported on the web platform?
Flutter Web does not support isolates. You are likely looking in the wrong documentation tab. Still, what you are looking for may just not be supported yet.
Web requires you to register a JavaScript Service Worker which runs in the background.
Unfortunately we haven't yet been able to establish a proper way of communicating with the Service Worker and Flutter applications. Right now, all web background code must be executed in the JavaScript Service Worker file.
EDIT:
In order to share data between WebWorkers and the app, you can try using the awesome Drift library (formerly Moor).
https://pub.dev/packages/drift
https://drift.simonbinder.eu/web/
You can offload the database to a background thread by using Web Workers. Drift also supports shared workers, which allows you to seamlessly synchronize query-streams and updates across multiple tabs!
You should be able to communicate with the background database web worker and save your data. If correctly setup, this will in turn update your frontend.
Maybe checkout this example: https://github.com/simolus3/moor/tree/develop/extras/web_worker_example
I am hoping this is not too off topic for a post here.
I have an asp.net webAPI service, which provides a number of routes to get near realtime data (ie within say 10 seconds), which required the client application to poll for changes.
I am investigating on which technology would be best to add an "opt in" push notification service, which just pushes "thin" payloads to tell the client application it is now time to call the existing REST route for an update. This way, the push payload is small, and does not contain any security sensitive data (it still gets this using the existing REST security infrastructure)
Cloud based messaging
Previously, I have been told that, for a Mobile application, I should use something like Firebase cloud messaging, or some other messaging service, however this does not seem like the right solution for "subscription based notifications" I am talking about here. I can certainly see this would be useful, if the client is on either iOS or Android device, and wanted messages/notifications/alarms (etc), which could also work when the application is not running, but this does not seem like the right thing to use of these notifications of changed data (which may be happening all the time, sometimes every 5 seconds). Also, I do not want to only target these mobile devices, but also, for example either a web or desktop application, which may also use the same REST service
Other technologies
I have seen mention of Web sockets, or, in the case of asp.net, the option to use SignalR (which will wrap the web sockets, with fallback). SignalR looks good, but my worry is the availability of client libraries for non web / Windows applications (eg iOS, Android). I am also looking at Rest Hooks. These look interesting, but I can't quite see what the actual "push mechanism" is; it almost looks like they need to POST to the subscriber using HTTP, which means the subscriber has to also act as a "server endpoint".
Just after any thoughts / best practices on this, or what others have used?
In particular, (the verification or otherwise), that for this use case, using cloud based messaging is not the right thing to use due to the frequency of these push notifications (ie something where my server gets to the application via another 3rd party service which pushes to the device/application)
Thanks in advance for any suggestions!
Signalr is an option
There are some libraries which you can use in iOS and android. I suggest you to read once https://visualstudiomagazine.com/articles/2013/11/01/how-to-use-signalr-in-ios-and-android-apps.aspx (its a bit older, but on the point)
Android Client: See How to use signalr in Android
Some alternatives :
Pusher (https://pusher.com/)
Android Client: https://pusher.com/docs/android_quick_start
iOS Client: https://pusher.com/docs/ios_quick_start
Socket.IO (https://socket.io/)
Details iOS Client: https://socket.io/blog/socket-io-on-ios/
Details Andriod Client: https://github.com/socketio/socket.io-client-java
To discuss:
Why you will only send a thin payload whith signalr? I see no benefit for that.
Why "using cloud based messaging is not the right thing"? I do not understand your arguments but I do not know how your application looks like.
We currently designing a mobile app and the client has requested we have the ability to work offline and sync data when online again. I'm looking at using realm as it seems to make having an offline state really easy, however I'm a bit confused about where any server side logic would live. Am I right in that realm isn't really designed to have server side logic? You are just persisting data to the cloud when the cloud is available but you aren't actually in charge of building an API with and logic behind it?
Edit.
Reading further maybe Azure offline data sync is a better option because you can write the server side code? Am I correct in this decision that if I want server side code I can't use realm?
Thansk Michael
Realm Mobile Platform is designed for offline data access since it uses the full power of Realm Mobile Database as the client data store. However, that doesn't mean you are limited to only client-side interactions. We offer a Node.js SDK in the Professional and Enterprise editions where you can work with the same copy of Realm data from the mobile clients in a Linux environment.
The Node.js SDK offers the ability to open any Realm, query or perform write transactions on the server which will push data out to the client(s). In addition, it has event-handling capabilities, where you can register callbacks to perform logic in response to data changes performed on client devices.
To make it easier to get started with the event-handling functionality, we launched Realm Functions which allows you to create Javascript functions through the Realm Object Server dashboard, which will then run in response to data changes. Underneath the hood this uses the Node.js SDK to power it.
The sum total of all of this is that you should be able to build any server-side business logic that you need. By using Realm's sync as the transport layer, your mobile development can focus on the application logic versus networking and data transformation. Likewise, your server has an exact copy of the data to perform logic as well. Both sides operate independently, so offline changes will always sync back up!
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I have been given access to a real time data feed which provides location information, and I would like to build a website around this, but I am a little unsure on what architecture to use to achieve my needs.
Unfortunately the feed I have access to will only allow a single connection per IP address, therefore building a website that talks directly to the feed is out - as each user would generate a new request, which would be rejected. It would also be desirable to perform some pre-processing on the data, so I guess I will need some kind of back end which retrieves the data, processes it, then makes it available to a website.
From a front end connection perspective, web services sounds like it may work, but would this also create multiple connections to the feed for each user? I would also like the back end connection to be persistent, so that data is retrieved and processed even when the site is not being visited, I believe IIS will recycle web services and websites when they are idle?
I would like to keep the design fairly flexible - in future I will be adding some mobile clients, so the API needs to support remote connections.
The simple solution would have been to log all the processed data to a database, which could then be picked up by the website, but this loses the real-time aspect of the data. Ideally I would be looking to push the data to the website every time the data changes or now data is received.
What is the best way of achieving this, and what technologies are there out there that may assist here? Comet architecture sounds close to what I need, but that would require building a back end that can handle multiple web based queries at once, which seems like quite a task.
Ideally I would be looking for a C# / ASP.NET based solution with Javascript client side, although I guess this question is more based on architecture and concepts than technological implementations of these.
Thanks in advance for all advice!
Realtime Data Consumer
The simplest solution would seem to be having one component that is dedicated to reading the realtime feed. It could then publish the received data on to a queue (or multiple queues) for consumption by other components within your architecture.
This component (A) would be a standalone process, maybe a service.
Queue consumers
The queue(s) can be read by:
a component (B) dedicated to persisting data for future retrieval or querying. If the amount of data is large you could add more components that read from the persistence queue.
a component (C) that publishes the data directly to any connected subscribers. It could also do some processing, but if you are looking at doing large amounts of processing you may need multiple components that perform this task.
Realtime web technology components (D)
If you are using a .NET stack then it seems like SignalR is getting the most traction. You could also look at XSockets (there are more options in my realtime web tech guide. Just search for '.NET'.
You'll want to use signalR to manage subscriptions and then to publish messages to registered client (PubSub - this SO post seems relevant, maybe you can ask for a bit more info).
You could also look at offloading the PubSub component to a hosted service such as Pusher, who I work for. This will handle managing subscriptions and component C would just need to publish data to an appropriate channel. There are other options all listed in the realtime web tech guide.
All these components come with a JavaScript library.
Summary
Components:
A - .NET service - that publishes info to queue(s)
Queues - MSMQ, NServiceBus etc.
B - Could also be a simple .NET service that reads a queue.
C - this really depends on D since some realtime web technologies will be able to directly integrate. But it could also just be a simple .NET service that reads a queue.
D - Realtime web technology that offers a simple way of routing information to subscribers (PubSub).
If you provide any more info I'll update my answer.
A good solution to this would be something like http://rubyeventmachine.com/ or http://nodejs.org/ . It's not asp.net, but it can easily solve the issue of distributing real time data to other users. Since user connections, subscriptions and broadcasting to channels are built in to each, that will make coding the rest super simple. Your clients would just connect over standard tcp.
If you needed clients to poll for updates then you would need a que system to store info for the next request. That could be a simple array, or a more complicated que system depending on your requirements and number of users.
There may be solutions for .net that I am not aware of that do the same thing, but those are the 2 I know of.