Consider the tic-tac-toe game built with Nginx as a reverse proxy and having multiple Rails backends. Each client sets up a websocket connection with some Rails backends. If two clients playing a game are each connected to a different Rails backend, then a move sent to one backend needs to be routed to the other backend so it can be pushed on the other websocket as shown in the picture below.
In Rails what is the idiomatic way to communicate between two Rails backends?
In this situation you should setup separate WebSocket server and connect both users and Rails servers to it. This way you will be able to handle all users from one server without worrying about sharding.
In case of high traffic you could also setup several WebSocket servers and implement some kind of queue or message bus between them that will propagate new messages - for example master server that will only handle propagating messages and slave servers that will be connected to it and sent all messages received from users to it. Please note that in such configuration master server should not handle connection from users and server only for propagation of messages between slaves.
Finaly, answering your last question directly, there is usually no need to contact between Rails servers directly - as opposite to WebSocket servers they serve on request-response basis so exchanging informations via database is enough in most cases. If you really need immediate change then solutions like AMQP should help.
Related
I am developing an app that's going to have two capabilities. First of all, it has to be able to ingest a huge load of events (think millions per minute). It's also going to have a typical REST frontend/backend where I'll have the classic authentication flows, some dashboard based on an analysis of the ingested events, etc. For the REST portion of the app, I'm using Django + Postgres and React on Docker. For the event-driven backend, since Django is too slow to handle clients sending me millions of requests, I was thinking of using Kafka + a streaming database like Materialize.
However, I'm still unclear on how I would route requests to these different endpoints. Do I need to write an endpoint in something fast like Golang/Rust to send client payloads to Kafka? Or do clients communicate with Kafka directly? Is something like Nginx the right way to route these requests? I would still need to have some sort of reference to the the Postgres DB in order to verify the API Key used in the client request is valid.
be able to ingest a huge load of events (think millions per minute).
Through HTTP, or Kafka? If Kafka, then you can use Kafka Connect to directly write into the database without needing any frontend web server.
Django is too slow to handle clients sending me millions of requests
Based on your own benchmarks? Using how many instances?
Do I need to write an endpoint in something fast like Golang/Rust to send client payloads to Kafka?
Python can send producer requests to Kafka. There's nothing preventing you from using Kafka libraries in Django, although none of your question seems very specific to Kafka vs other message queues, especially when you've only referenced needing one or two databases.
If you're going to pick a different "service worker" language, you may as well write your HTTP server using those as well...
Or do clients communicate with Kafka directly?
Web clients? No, at least not without an HTTP proxy.
Is something like Nginx the right way to route these requests?
Unclear what you mean by "requests" here. Kafka requests - no, database requests - probably not, load balancing of HTTP requests - yes.
have some sort of reference to the Postgres DB in order to verify the API Key used in the client request is valid
Okay fine, use a Postgres client in your backend code.
I have an application running Laravel 6.1. There are clients which connect to it via laravel websockets and listen for events. I have an external service which sends post requests to this server which will then raise an event, and the websocket clients see it. I am in the dev stage, and it's not been deployed yet, this is what I'm currently researching. I use Docker, so there's an nginx container, a php container, and a Mysql container(in production, the containers will use RDS though)
This works fine in development, but the plan is to deploy in ECS, with Elastic Beanstalk, as it enables multiple containers per EC2 instance. I was planning on having these instances auto scale with a load balancer, so my question is how can I make the incoming events be raised and visible on all the servers? For example, the post request may hit one instance and the clients connected to that instance would see that the event was raised, but the clients connected to another instance will not see the raised event. Is this accurate? I'd imagine the events will have to be sent to some kind of "queue" which is monitored by all instances, but not sure how to implement that with Laravel or if there's a simpler faster way.
Based on the comments.
The proposed solution involves the use of sns instead of the SQS.
The reason is that sns allows delivery of messages to multiple recipients at the same time. In contrast, SQS is designed for one delivery of messages to only one recipient, unless used in fan out architecture.
I'm developing an application that has various types of Notifications. Examples of notifications:
Message Created
Listing Submitted
Listing Approved
I'd like to tie all of these up to SignalR so that any connected clients get updates in real-time.
As far as architecture goes - right now the application is entirely within a single solution hosted on an Azure Website. The triggers for each of these notification types live within this application.
When a trigger is hit, I'd like to tell signalR, "Hey, send this message to the following clients" along with a list of userIds. I'm assuming that it's possible to identify connected clients based on userId... and I'm assuming that the process of send message to clients should be executed outside of the web application, so as to not slow down the MVC app or risk losing data in a broken async call. First question - are these assumptions correct?
Assuming so, this means that I'll need something like a dedicated web/worker role to be sending messages to clients. I could pass messages from my web application directly to this process, but what happens if the process dies? The resiliency concerns lead me to believe that the proper way to pass messages would be via a queue of some sort. Second question - is this a valid train of thought?
Assuming so, this means that I can either use a good ol' Azure SQL database as a queue, but it seems like there are some specialized (and maybe cheaper) services to handle message queueing, such as this:
http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/
Third question: Should this be used as a queueing mechanism for signalR? I'm interested in using Redis for caching in the future... would Redis be better or worse than the queue service?
Final Question:
I've attempted to illustrate my proposed architecture here:
What I'm most unclear on here is how the MVC app will know when to queue, or how the SignalR processes will know when to broadcast. Should the MVC app queue blindly, without caring about connected clients? This seems to introduce a lot of wasted space on the queue, and wasted cycles in the worker roles, since a very small percentage of clients will ever be connected.
The only other approach I can think of is to somehow give the MVC app visibility into the SignalR processes to see if the client is connected... and if they are, then Enqueue. This makes me uncomfortable though because it means I have to hit that red line on the diagram for every trigger that gets hit, which - even if done async - gets me worrying about performance and reliability.
What is the recommended architecture for scalable, performant SignalR message broadcasting? Performance is top priority, followed closely by cost.
Bonus question:
What if some messages are of higher priority than others? Should two queues be used, one of which always gets checked before the other?
If you want to target some users, you'll have to come up with a mechanism, off the top of my head I can give an example, if any user hits a page, you can create a group for that page and push to all users in that group/in that page.
It's not clear to me why you need the queues. Usually users subscribe to some events when hitting a page or by some action like join a chat room, and the server pushes data using those events/functions when appropriate.
For scalability, you can run signalr in different servers, in which case you should use sql server, or service bus or redis as a backplane.
Firstly you need to create a SignalR server to which all the users can connect to. This SignalR server can be created either in the web role or worker role. If you have a huge user base then its better to create the SignalR server on a separate role.
Then wherever the trigger is hit and you want to send messages to users, you have to create a SignalR client (.NET or javascript) and then connect to SignalR server. Then you can send the message to SignalR server which in turn will broadcast to all the other users connected. After that you can disconnect the connection with SignalR server. This way you dont have to use queues to communicate with the SignalR role.
And also to send messages to specific users you can store the socket id's along with their user id's in a table (azure table storage should do) when they connect to SignalR server. Then using socket id you can send messages to specific user.
I have an existing complex website built using ASP.NET MVC, including a database backend, data layer, as well as the Web UI layer. Rebuilding this website in another language is not a feasible option.
There are some UI elements on some views (client side) which would benefit from live interactivity, involving both push and pull, so rather than implement some kind of custom long polling or websocket server in asp.net, I am looking to leverage node.js for Windows, and Socket.io.
My problem is that I need two way communication between both applications. Each user should only be able to receive data once they are authorised on the ASP.NET website, so I first need communication for this. Secondly, once certain events occur on the ASP.NET website I want to immediately push this data to the Node server, to be broadcast to specific users or groups of users. Thirdly, I would like any data sent to the node.js server to be pushed to the ASP.NET website for processing, as this is where all our business logic lies. The sole reason for adding Node.js is to have the possibility to push data directly to the client, I do not want to build any business logic into it (or as little as possible).
I would like to know what the fastest method of two-way push communication is between Node.Js and ASP.NET. The only good option I'm aware of so far is to create a special listener on a specific port on the node.js server and connect to that, but I was wondering if there's a more elegant or more efficient method? I also know that you could use a database inbetween but surely this would need to be polled and would be less efficient? Both servers will be running on the same server under a Visual Studio project.
Many thanks for any help you can provide.
I'm not an ASP.NET expert, but I think there are multiple ways you can achieve this:
1) As you said, you could make Node listen on a specific port for data and then react based on the data received (TCP)
2) You can make POST requests to Node.js (HTTP) and also send an auth-key in the process to be extra-secure. Like on 1) Node would react to the data you send.
3) Use something like Redis for pub-sub, send messages from ASP.NET (pub) and get them on the Node.js part (sub). This is even better if you want to scale your app across multiple machines etc.
The only good option I'm aware of so far is to create a special
listener on a specific port on the node.js server and connect to that,
but I was wondering if there's a more elegant or more efficient
method?
You can try to look at redis pub/sub model where ASP.NET MVC application and node.js would communicate through separate channels in order to achieve full-duplex communication. Or you can also try to use CouchDB change nofitications.
I also know that you could use a database inbetween but surely this
would need to be polled and would be less efficient?
Former techniques do not require you to poll for changes, but instead they will notify you when the changes happens or channel message arrives.
I'm writing a rails application that acts as a proxy, thus hereby referred to as the proxy. The idea is that the user should be able to manage his servers through a web UI, that's always up and running even if his servers are down.
To accomplish this, the proxy needs to keep an open connections to the servers at all times. For this I've created a background process using daemonz that accept incomming connections from servers and spawns threads that are constantly listening on the sockets.
Now I have two problems: I need to be able to send messages on these sockets from my rails controllers and I need to know which socket to use, to reach the right server. I was planning to use a ConnectionManager class to take care of this for me, but I don't know where such a class fits into rails structure and I don't know how to make the object and the sockets available to both processes.
That makes two questions:
Where does the connection manager belong?
How do I share the connection manager and the sockets between the processes?
If you only know the answer to the first question, please go ahead and answer. It's possible that I should create a separate post for my second question.
This does not seem like a useful thing to build in Rails/Ruby.
What might be more useful would be a Rails admin application that configured an existing load balancer/proxy like haproxy under the covers.
You could have a mapping of servers/ports/configuration in your Rails app and then project that into an haproxy config and restart the load balancer. A great place to start would be the haproxy-tools gem, that allows you to parse/generate an haproxy config file.
It doesn't make sense to re-write your own load balancer and Ruby/Rails is a poor technology stack even if you were going to do that.