I want to create a nodejs Azure Service Bus client to read from a topic, and I want my client to automatically register its subscription.
So #azure/service-bus allows to work with SB normally, yet does not allow to create a subscription. azure-sb does allow to create one and also operate on the bus.
Do I need to install both in my nodejs app? Both seem official package from Microsoft, however, I wonder what is the intended usage for both and intended future (will one replace the other?)
To put things simply, azure-sb is the old SDK for managing Service Bus while #azure/service-bus is the new one.
There are a few differences in the two packages:
Protocol: azure-sb is a wrapper over Service Bus REST API (HTTP protocol) while #azure/service-bus makes use of AMQP protocol to communicate with Service Bus.
Features: azure-sb enables you to work with entities (Queues, Topics and Subscriptions) by allowing them to perform CRUD operations on them. These features were removed from #azure/service-bus as Microsoft is moving these CRUD operations under control plane by enforcing RBAC on these operations. For performing these operations, you will need to use #azure/arm-servicebus. #azure/service-bus package is more geared towards sending and receiving messages. It also supports Websockets in case you need that.
Do I need to install both in my nodejs app? Both seem official package
from Microsoft, however, I wonder what is the intended usage for both
and intended future (will one replace the other?)
Considering your requirement, my answer is yes. You would need both of these packages. I'm not sure if that will cause any problems. In our project, we ended up implementing REST API directly (instead of using azure-sb package) for CRUD operations on entities and used #azure/service-bus for working with messages.
Regarding #azure/service-bus will eventually replace azure-sb package, I will be purely speculating but I don't think that will happen anytime soon. For this, Service Bus team will have to remove the REST API first which seems highly unlikely however Microsoft is pushing hard for RBAC at entities level so I would recommend that you use #azure/arm-servicebus along with #azure/service-bus if you're starting new.
Related
I want implement the claim-check workflow with Azure Service Bus:
claim check
Is it possible to do that using node.js?
I just found only .net examples and I cant see anything in #azure/service-bus node package that seems to refer to claim check.
Anyone that had the same problem?
A claim check pattern can be implemented using any language as long as there's support to hook into the pipeline. For a long time, this pattern was not easy not possible to implement with .NET either as the previous .NET SDK did not provide a way to hook into the sending/receiving. The new .NET SDK had that consideration from the beginning. Almost. Once it was implemented, claim-check pattern implementation was a no brainer.
If you're looking to implement a claim check pattern as a plugin, it would need to have a pipeline concept support in the Node.js SDK.. You can raise an issue for the Service Bus library to request it or contribute yourself.
Another alternative is to abstract sending and receiving operations with your custom implementation that would use some kind of storage for the payloads.
I am new to the Azure Bot Framework and I am trying to do something that I think is quite simple.
I have a Node application that a few times a day needs to send notifications to various skype groups. I have been using skype-http for a while, but it is unreliable and not officially supported by Microsoft. So, I am looking to rebuild the notification system using azure services.
It seems like I should be creating an Azure Bot Function, but the Bot Functions use the V3 API, which is deprecated.
It looks like Web App Bots are now the recommended option to create bots, but they seem to be solving a slightly different problem. But going this route, it looks like I still need to set up an Azure Function as well as storage. So, it seems vastly more complex than my current implementation.
My question is: Should I be using a Bot Function, a Web App Bot, or something else entirely to send notifications to multiple chat groups?
EDIT: To be clear, I am looking for an officially supported solution. skype-http regularly breaks for us due to API changes, and the other node-based skype libraries are similarly brittle.
Or, please let me know if there is no Microsoft-supported solution, then at least I know I will be stuck using private APIs.
You should look at Azure Functions as your platform, instead. Azure Functions would allow you to make the API calls you need. Additionally, you can set it to run via a trigger (timer or http request).
Instead of skype-http, check out sky-web-plus (https://www.npmjs.com/package/sky-web-plus). It's basically a port of several other packages already out there, but is getting regular love from its developer (so, hopefully stable and up-to-date) and appears to do what you need. As the developer is active, you can reach out to him/her with any specific questions.
Azure Bot Framework would not be a good fit for this purpose, alone.
Hope of help!
The documentation of Service Fabric recommends service remoting, ICommunicationClient or WcfCommunicationClient to realize the communication between the micro services.
The ServiceBus, which I always used for inter-service communication, is not even mentioned. Why?
I think you misinterpreted the docs. It does not recommend any protocol or service (the word is not even present on the page). What it does do is list the built-in communication options and appropriate situations of when to use them.
There is nothing that prevent you from using service bus for inter service communications. In fact, if you google around you will find some projects like this one
The ability to plug in any desired service or protocol is one of the great things about SF, but they leave the implementation to you.
There are many approaches to do service to service communication, if they had to document all of then, they would spend more time writing the possible approaches than doing the actual communication.
They probably decided for the one with closest relation to the platform, but they could write about any possible, it is just a matter o preference.
I could name a few from many just to have an idea:
Http
Remoting
WCF
Service Bus
Event Hub
AMQP
MQTT
gRPC + protobuf
TCP
UDP
Pipes
And many more, Imagine if they had to document all of then.
The communication is flexible enough to let you implement using any communication mechanism.
Regarding the ones you mentioned,
I always opt for HTTP for being platform agnostic and widely implemented on most platforms, does not matter if is .Net, Java, NodeJs, Windows or Linux, they all talk the same language, the others are very tight to the .Net and Windows platform and force every other solution to be also tighten or adapted to then. And also there is the fact of some being synchronous and other asynchronous like Service bus.
Then, when performance is an issue, I evaluate the other options.
We're planning on implementing a server-side notification mechanism that pushes out to iOS and Android via ANH. We will have no code footprint on our mobile clients, short of a call to our server API for "registration". In this way our approach is looking similar to this MSDN discussion.
I also see the alternate, more bare-bones, approach noted on MSDN.
Is it fair to conclude that the two approaches will have similar performance on the 'send' side?
It appears the main difference is this:
The former approach has already done the work of integrating with the Task and Async mechanism, presenting a callable C# mechanism that has taken on more of the RESTful API layer,
The DirectBatch/Send API is just that -- the raw RESTful API for you to use as you see fit.
For operations that are available as both REST API and SDK, you shouldn't see any significant difference in performance on the client side because the SDK is just a wrapper around the REST APIs. There are SDKs for both iOS and Android and it's recommended to use those so that you don't have to re-write the wrapper.
Direct Send is only available in .NET SDK at the moment and for other platforms as REST API, so you'd have to implement your own wrapper in case you're using something other than .NET for the operation. You can use the sample to help you in the process.
In terms of performance it depends on what you mean by that.
Direct send will most likely be delivered to customers a bit faster because ANH service doesn't have to do any registrations in the process, it just delivers notifications with your parameters. But it has it's limitations in terms of number of handles you can provide and also you need to manage handles yourself.
If you only mean performance on the client side, then there should be no difference as all calls are asynchronous. And if you take advantage of tags, then you can do really tricky sends in one server call and let ANH figure out the details behind it.
But without knowing your scenario and requirements there's no way to give a proper recommendation.
Is there an easy way to manage offline data with a web app, and synchronize with a server when there is a connection? I have been looking at Meteor, CouchDB and the likes, but still not sure what would be the least painfull way.
I could of course implement it myself with sockets or something similar, but if something is already made for the purpose, I don't see a reason to do it again.
I'm planning to work with Node as the server.
Thanks
You're talking about two things; 1) How to store/persist data if/when offline (storage mechanism), and 2) How to synchronize with a server when online (communication mechanism). The answer to 1 is some kind of local storage, and there any several ways of doing that (localstorage, websql, filesystem APIs etc) depending on your platform. The answer to 2 really depend on how urgent your synchronization needs are, but in general you can use HTTP itself with periodic (long-) polling, websockets and similar.
On top of both storage and communication mechanisms there are numerous libraries that make the job simpler, like Meteor (communication) and CouchDB (storage), but also many many more. There are even libraries that take care of the actual synchronization mechanism (with possible conflict resolution as well), but this very much depends on your actual application.
Updated: This framework looks promising, but I haven't tested it myself:
http://blog.nateps.com/announcing-racer-experimental-realtime-model
You might want to look at cloud services as well. These are best if you are developing a new application as they push you more to a serverless model, and of course you have to be happy using a service.
Simperium (simperium) is an interesting cloud service - the only one I can find today that does syncing (unlike Firebase and Spire.io who are similar in other respects), and for iOS it includes offline storage, while for JavaScript clients you'd need to cover the local storage yourself using HTML5 features. Backbone.js seems to have some support for this, and Simperium can integrate with Backbone, using a similar API style.
For non-cloud services, Derbyjs (derbyjs) is an open source project that includes Racer, a data synchronization library (mentioned by the earlier answer) - both are under rapid development and not yet complete, but look interesting if your timescales allow, and don't require a cloud service. There is a comparison of Derbyjs to Meteor that is useful - although it's written by the Derbyjs developers it's not too biased.
I also looked at CouchDB, which has some interesting built-in replication features, but I didn't like its use of indexes that are updated lazily when a query needs them (or by a batch process), and I wasn't happy with exposing the server DB directly to clients to enable replication/sync. Generally I think it's best to decouple the client side local storage from the server side DB, and of course for a web app it would be hard to use CouchDB on the client.