Is there any way to have an Azure Function listen for events from a remote web socket and handle messages as their come over?
I have looked at the current documentation and samples but haven't found an answer.
Web sockets are not currently an event trigger that is supported by Azure Functions. Your only option would be to have another application that listened to the web socket and placed messages on a queue or hit an HTTP triggered function, but at that point the listening application might as well handle the incoming message itself.
The documentation here shows the current list of supported function triggers:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings
Related
I want to use a node script that contains an events listener function (e.g. https://portal.thirdweb.com/sdk/advanced-features/contract-events#listen-to-all-events) inside my Next.js app.
As there is no server and the serverless functions need a trigger, I'm not sure where this kind of code should live.
How can I handle this case?
Any event listening should live on it's own server/not on serverless functions. The issue is that if you want to listen for events constantly and save them somewhere/act on it, the scripts that's listening for events needs to be constantly running.
With serverless functions (which is what all Next.js API endpoints are), they're only active when they get called, which won't work for event listening.
I would suggest building a simple Express server for event listening, and then deploying it somewhere like Zeet to have it always listening.
I am looking for a solution to my problem. I have Node.js server serving my web application where user can log in. I want to handle a situation where one user A performs specific action and user B associated with this action gets real life notification. Is there a module that would help me or there is some other solution?
What you are describing is "server push" where the server proactively notifies a user on their site of some activity or event. In the web browser world these days, there are basically two underlying technology options:
webSocket (or some use socket.io, a more feature rich library built on top of webSocket)
server sent events (SSE).
For webSocket or socket.io, the basic idea is that the web page connects back to the server with a webSocket or socket.io connection. That connection stays live (unlike a typical http connection that would connect, send a request, receive a response, then close the connection). So, with that live connection, the server is free to send the client (which is the web page in a user's browser), notifications at any time. The Javascript in the web page then listens for incoming data on the connection and, based on what data it receives, then uses Javascript to update the currently displayed web page to show something to the user.
For server sent events, you open an event source on the client-side and that also creates a lasting connection to the server, but this connection is one-way only (the server can send events to the client) and it's completely built on HTTP. This is a newer technology than webSocket, but is more limited in purpose.
In both of these cases, the server has to keep track of which connection belongs to which user so when something interesting happens on the server, it can know which connection to notify of the event.
Another solution occasionally used is client-side polling. In this case, the web page just regularly sends an ajax call to the server asking if there are any new events. Anything new yet? Anything new yet? Anything new yet? While this is conceptually a bit simpler, it's typically far less efficient unless the polling intervals are spaced far apart, say 10 or 15 minutes which limits the timeliness of any notifications. This is because most polling requests (particularly when done rapidly) return no data and are just wasted cycles on your server.
If you want to notify userB, when both of you are simultaneously online during the action, then use websockets to pass message to a two-way channel to notify userB.
If you want to notify them whenever, regardless of online status, use a message queue.
I currently have a socket.io server spawned by a nodeJS web API server.
The UI runs separately and connects to the API via web socket. This is mostly used for notifications and connectivity status checks.
However the API also acts as a gateway for several micro services. One of these is responsible for computing the data necessary for the UI to render some charts. This operation is long-lasting and due to many reasons the computation will only start when a request is received.
In a nutshell, the UI sends a REST request to the API and the API currently uses gRPC to send the request to the micro service. This is bad because it locks both API and UI.
To avoid locking the socket server on the API should be be able to relay the UI request and the "computation ended" event received by the micro service, this way nothing would be locked. This could eventually lead to the gRPC server on the micro service to be removed.
Is this something achievable with socket.io?
If not is the only way for the API to spawn a secondary socket connection to the micro service for each one received by the UI?
Is this a bad idea?
I hope this is clear, thanks.
I actually ended up not using socket.io. However this can still be done with it if the API spawns a server and has the different services connected as clients, https://socket.io/docs/rooms-and-namespaces/ can be used.
This way messages can be "relayed" and even broadcasted from the server to both in case something happens.
I'm trying to setup RabbitMQ to take web application logs to a log server.
My log server will listen to one channel and store the logs that comes in.
There are several web applications that need to send info to the log server.
With many connections (users) hitting the web server, what is the best design to publish messages to RabbitMQ without locking each other? Is it a good idea to keep opening a new connection to the MQ for each web request? Is there some sort of message queue pool?
I'm using IIS for a web server.
I assume you’re leveraging the .NET framework to build your application, given that it’s hosted in IIS. If so, you can also leverage Daishi.AMQP, which has a built-in QueuePool feature. Here is a tutorial that outlines the mechanism in full.
To answer your question, you should initially establish a connection to RabbitMQ from your application server. You can then initialise a Channel (a process that executes within the context of the underlying connection) to serve each HTTP request. It is not a good idea to establish a new connection for each request.
RabbitMQ has a build in queue feature. It is well documented, have a look at the official docs: http://www.rabbitmq.com/getstarted.html
I'm working with redis to publish and subscribe messages between socket.io clients, when client connects to the server (io.sockets.on('connection', function(socket){...});) i'm creating a subscribe variable using redis.createClient() and then using the subscribe function to subscribe the client to channel.
My question is if its right to use the same subscribe variable to do a publish action? or it's important to create another instance with redis.createClient() for publishing messages so i will have 2 instances, one for publishing and one for subscribing...
Thanks
From the Redis docs:
Once the client enters the subscribed state it is not supposed to issue any other commands, except for additional SUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE and PUNSUBSCRIBE commands.
For this reason, you'll need two clients, one for subscribing and one for publishing (and potentially other commands).
By subscribe variable you mean the object that redis.createClient() returns ? If yes, from the documentation, When a client issues a SUBSCRIBE or PSUBSCRIBE, that connection is put into "pub/sub" mode. At that point, only commands that modify the subscription set are valid. so yes, you cannot publish to a client where you subscribed first, that would issue a Error: Connection in pub/sub mode, only pub/sub commands may be used error.
You do need to create one client for subscriptions (which can be modified on the fly), and one client to publish. When the subscriptions for a client are free, you have your normal state again.