I am trying to integrate our socket.io application with azure api management. But I am unable to find any solution, whether it is possible or not. Can any one help me OR give me some suggestions
UPDATE: WebSockets are now supported in APIM. Currently, only passthrough is supported which creates a one-to-one mapping of the connection between the client and APIM, and the connection between APIM and the backend websocket server. Also, do note the limitations that exist today.
Thanks #restfulhead for the bringing this up here
Unfortunately, WebSockets are not supported in Azure API Management as of today. There is a feature request on UserVoice which you could up vote to gain more traction.
Today, for WebSocket applications, you can use Azure Application Gateway which supports websockets.
On another note, Azure SignalR is also a great service for building managed, scalable, realtime websocket-powered applications but is more of an alternative to socket.io in NodeJS for C#.
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.
Assume you want to deploy 2 apps of which one provides some API to the second application.
With services I'd just bind the service (or declare it as dependency in my manifest) to my application and hence get the information regarding host, port and credentials passed to my application (e.g. via env variables in node.js). Is there a similiar mechanism for application to application "communication"?
So far my approach is to use a RabbitMQ service (or any message broker/queue) which both applications are bound to and which I then use for cross-app communication.
Thanks!
Using a message broker, as you do, is definitely a viable solution. This allows for asynchronous communication. Yet you will have to take care of authentication yourself, as opposed to app <-> service communication, where authentication/authorization is established through through cloudfoundry service binding.
Another way would be to use a service registry for this. Both apps would register with the service registry and be able to discover each other.
You could try spring cloud service registry (Eureka) or consul. As for your message broker solution, this will not generate credentials for your apps, as a cloudfoundry service binding does.
From your use case, for microservice to microservice discovery, you need Spring Cloud Services and Eureka.
I don't have much experience on nodejs. But some googling, will give you some articles. Here's one that may help you - https://www.npmjs.com/package/eureka-js-client
This article will give you an overview from Java and Spring perspective - https://spring.io/guides/gs/service-registration-and-discovery/.
I want to create an integrated sytem. My business logic will be on NodeJS.
I want to protect these resources and get paid by consumers for using my APIs as per my business logic.
What technology stack will be fine? I thought of using Amazon api gateway for hosting my APIs, and Auth0 for protecting these API calls.
How can I create a developer portal for my APIs?
Is this kind of infrastructure possible?
Yes, this is definitely possible. API Gateway currently supports some, but not all, of your requirements.
With API Gateway, you can keep your business logic in NodeJS. You can either run your own NodeJS server on EC2 or you can run your NodeJS logic in Lambda for a serverless solution.
API Gateway currently allows you to secure your API using Cognito user pools. Alternatively, you can use only API keys, which aren't a strong security mechanism, but are typically used for tracking and billing API consumers.
API Gateway supports usage reports that you can use to generate bill for customers. It doesn't currently support billing customers for you.
API Gateway does not currently support creating a developer portal for your APIs. This is a commonly requested feature and we will probably add it at some point in the future. You would have to build/host your own developer portal for now.
We've been writing services to access our on-premises databases through Azure Service Bus Relay for awhile now. That means that we've had to deploy them as WCF services. Our web site development is moving to node.js and I would like to begin deploying our API services on node as well. However, while the Azure NPM package has good support for queues/topics on Azure Service Bus, I can find no mention of the relaying capabilities. I've had a look at the code for the Azure SDK on github, but again, relay seems to be conspicuously absent.
Is it possible to use Azure Service Bus Relay with a node.js backend?
Now Azure support Node.js. You can find the infomration from here. This link is the samples for Node.js.
Right now, Relay only supports a WCF service. You can try to use Clemens Vasters' post on Port Bridge to get your scenario working. In his post, he describes creating a WCF client / service that will forward requests to a specific port.
I have a Windows Azure Mobile Service up and running, however, there is a need for that service to consume some data expose through an external SOAP service and store that information in the mobile service database.
I would like to set up a worker in the mobile service, so the calls to the external SOAP service are executed in a fixed period of time.
I've been looking for a solution to this problem, but haven't found anything yet. So any help that would get me in the right direction would be appreciated.
Unfortunately there isn't an easy way to talk to a SOAP service from your Mobile Service backend. The backend is based on Node.js, and even though there are some Node modules for talking to SOAP services, they are currently not supported in Mobile Services. We are working on a solution that will enable you to use any Node module in your service, but it is not out yet.
If you control the SOAP service and it is written using WCF, you may be able to easily add a REST endpoint to the service with just a few config changes and then consume it from your Mobile Service via plain HTTP requests by using the "request" module.