I am trying to create a chat messaging application, which has text functionality. Right now, when a user sends an SMS message from their phone to a Twilio service number, there is a Twilio webhook which redirects to an endpoint in my backend server: sending HTTP POST request.
However, since it is a chat messaging application, I need the Twilio webhook to establish a Websocket connection (upgrading over HTTP) to my backend server, so that it can send websocket events back to my client.
Is there a way to establish a websocket connection using Twilio webhooks, or even Twilio functions? I can't find any resources online to solve this issue.
I tried Twilio Webhooks, and Twilio Functions, it hasn't worked so far.
WebSockets won't help you in this situation, as the webhook timeout limit is 15 seconds. This means you either need to return a TwiML response within 15 seconds or the request will fail.
It sounds like you want to build a stateful WebSocket connection instead of the stateless API callback. To achieve a stateful session, you either need to handle the state management over multiple incoming messages on your own, or you can use a Studio Flow which comes with state management baked in.
Related
I need to add support for instant messages or reminders to my web application. I was reading that this could be accomplished with websockets.
The idea is that during the time the web app is been used, it could receive messages originated (not as a request response) from the server. For example, the server application might want to remind the user about and unpaid service.
As I understand, when the web app starts it connects to the websocket server through a standard HTTP Request call to announce itself as a client. My question is:
"If I have hundreds of clients connected at the same time, how do I call one in particular?"
Do I need to store every websocket object in an array or something so I can use it to send a message when it is required?
What would be the right approach?
Thanks.
I am looking at developing a client - server application whereby the client will send a message to the server via our API performing an action. The web api (.NET) will hand off this message to a processing queue (Amazon queue at this stage) which will perform operations on it. I would then like to send a message back to the client to indicate that the message has been processed etc.
The only way I can think of to do this is to have the processing queue which is not part of the web api send a HttpPost or HttpPut to the same API my SignalR hub is defined which will send send the messages out to the various clients.
However performance is an issue of this application so I'm hesitant to do another Http call from the backend server to the API just to then get a message sent. Is there any other way I could look at getting these messages sent?
Situation
Am trying to build a real-time chat toy app using the following technology stack
RethinkDB
Laravel 5
Ratchet
What I perceive to be the conceptual situation
The green arrows represent the real-time exchange of data.
The black arrows represent other non real-time requests and exchange of data.
My question
I was wondering if my understanding of the implementation of chat using the technology stack is correct based on the diagram?
if there are inaccuracies, what would they be?
Your interpretation seems correct, although I would not suggest using the websocket to send data to but only to distribute live data to all subscribers of a channel.
To do this, get an API(preferably) going to receive new posts/chats/users.
And use a push server to send the data received to the socket.
A push server is just an in between of the app and websocket that allows php(laravel) to access the socket easily.
Edit: to elaborate
To retry explaining this to you.
All clients listen to the WebScoket Server. This is a connection which is passive and they will only receive messages from the socket according to what topics/subscriptions they have.
When someone wants to send a message(in case of a chat application) they send it to an API to check if the right user sent it, maybe even use apikeys or other means of security.
Once the message is received in the API then the API wants to distribite it to all listening clients for that chat room/topic/subscription.
So the message is forwarded to the pushserver which is an in between of the backend (API, controllers) and the WebSocket (subscriptions, topics).
The pushserver forwards the message to the WebSocket afterwards and then the WebSocket distibutes the message to the correct listeners.
Advantages of using an API:
Security
Scalability
We are currently implementing a simple chat app that allows users to create conversations and exchange messages.
Our basic setup involves AngularJS on the front-end and SignalR hub on the back end. It works like this:
Client app opens a Websockets connection to our real-time service (based on SignalR) and subscribes to chat updates
User starts sending messages. For each new message, client app calls HTTP API to send it
The API stores the message in the database and notifies our real-time service that there is a new message
Real-time service pushes the message via Websockets to subscribed Clients
However, we noticed that opening up so many HTTP connections for each new message may not be a good idea, so we were wondering if Websockets should be used to both send and receive messages?
The new setup would look like this:
Client app opens a Websockets connection with real-time service
User starts sending messages. Client app pushes the messages to real-time service using Websockets
Real-time service picks up the message, notifies our persistence service it needs to be stored, then delivers the message to other subscribed Clients
Persistence service stores the message
Which of these options is more typical when setting up an efficient and performant chat system? Thanks!
You don't need a different http or Web API to persist message. Persist it in the hub method that is broadcasting the message. You can use async methods in the hub, create async tasks to save the message.
Using a different persistence API then calling signalr to broadcase isn't efficient, and why dublicate all the efforts?
Pusher service works as illustrated here:
Does it make sense to use it in reverse direction (and switched data channels)? My use case is as follows:
end users (actually mobile, not browser) send messages to Pusher via HTTP-based REST API
my firewalled machine is connected to Pusher via WebSockets API, subscribes channel and receives messages in realtime
This way I can work with Sandbox plan (only 1 persistent connection is used) but mobile app must contain Puser app key.
From what I understand, anyone can use this key to register subscribe same message stream via websockets. Is there a reverse mode, where receiving messages requires knowing the secret? Maybe other service would suit better?
A more secure solution would be for the mobile clients to use client events. Client events can only be triggered on private channels where the subscription to the channel has to be authenticated.The authentication requests should got to an HTTP endpoint that you control so that you can validate the subscription request.
You firewalled machine can either then have a WebSocket connection and receive the client events over that connection. Or it could receive the client events via client event WebHooks if it exposes an HTTP endpoint.