What is the best way to build a server-side architecture in Erlang (Cowboy) for WebSocket communication with mobile clients?

Question

Erlang

Good afternoon.
There is a need for a high-performance WebSocket server that maintains a connection with a mobile client and supplies it with some data at the request of the client.
Cowboy on Erlang was chosen as such a server (options?).
The client makes a request for some data. The data is collected for some time (5..30 sec) and then sent to the client.
What is the best way to build a server-side architecture with Erlang capabilities?
Cowboy receives a request from a mobile client and:
1. Puts it in a queue for processing (a database table, for example). Some worker picks up a task from the queue, collects data and updates the task in the queue.
The data is then sent to the client.
2. Doing without a worker, Cowboy creates a thread on demand and does the work of the worker himself to collect the necessary data, which takes a certain time, and then gives the data to the client.
What do you think?

Answer 1

Those. is your client communicating with Cowboy using one of the protocols (Websocket, http, long-pooling ) ?
In fact, you gave the same way --- to transfer control to someone.
Only in the first case you have a limited number of workers in the pool, and in the second case you have an unlimited number.
And what prevents to process the request directly in the handler?
The handler can also receive any messages, and generate any messages i.e. you can implement any logic, the same as what you implement on get_server or by hand loop() -> receive ... end.

Answer 2

You can use faye. faye.jcoglan.com
For it, there are ready-made client libraries for mobile phones, for example, here https://github.com/m1entus/MZFayeClient, I also saw it for android.
I use it in the ipad application, the flight is normal.

Answer 3

If you have a very large load (or a very large load is planned), and one server cannot cope, then the option with separate workers will be more flexible. (You can even make workers in different languages.)
If you have one server doing everything, then it's better to use only Erlang itself - it perfectly keeps a hanging passive connection. As soon as the data appears (they will be returned by the callback), they will immediately go to the client, but while the data is being prepared, the resources for maintaining the connection are practically not spent.
Plus, about multiple servers - Erlang itself can work on multiple servers, so the second option looks preferable. But the first one is more flexible. More flexibility for further development of the service.
Hm. I re-read your question. The worker is only for data processing. And Erlang will keep the connection anyway. It turns out that in the first option, the profit will be if non-Erlang is used as a worker, which will (much) faster process this specific task (if your task is difficult to process on Erlang itself).

Answer 4

Creating a high-performance WebSocket Erlang relay comes with the following list of tasks that the architect will need to solve:
1. Message formatting: JSON, BERT, MessagePack
2. XHR Fallback in the absence of websockets
3. Providing subscriptions between WebSocket processes via PubSub for chat
4. Providing client PING and providing reconnects
5. Advanced support for UTF-8 text and binary format
The cowboy web server does not provide any of this list. For 2) there is a bullet library, but it will not suit everyone, users will have to modify it if they want a stateful WebSocket connection. This means that cowboy is a low-level web server, and to implement these vital mechanisms, you will have to use higher-level libraries, web frameworks that take care of all this application-level routine.