I'm looking at creating a bot for Slack that can be installed across multiple different Slack communities. Slack offers a Real Time Messaging (RTM) API that creates a web socket per community to manage. Are there any best practices in Ruby for connecting to multiple web sockets concurrently? Is this something EventMachine or Celluloid should be used for or do clients exist that allow connecting into multiple bots? Thanks!
Here's a detailed post on "Writing a Slack Bot Service in Ruby": http://code.dblock.org/2015/11/14/writing-a-slack-bot-service-for-multiple-teams.html
You should use EventMachine or Celluloid. Either will work. A lot of the ground work has been done for you with a fully running sample in https://github.com/dblock/slack-bot-server.
Update: A more complete example can be found https://github.com/dblock/slack-gamebot which is the service that powers http://playplay.io, a Ping Pong, Chess and Pool Slack bot.
Related
I am surprised that I need third-party services such as Pusher or Redis to have a bidirectional communication from my server to my clients through WebSockets.
What are the advantages of Pusher over Redis or simply a socker.io server aside from nginx? I see many disadvantages:
Rely on a third-party service
Pricy above 200k messages a day
Cannot work on LAN without Internet
From my understanding, they are only two possible solutions with Laravel:
Laravel Echo + Redis
Pusher
Laravel Websockets
Pusher Php Server
Is there a third alternative?
There is a clone of pusher server available on laravel, have you checked it?
https://beyondco.de/docs/laravel-websockets/getting-started/introduction
You can use this on LAN.
This runs a php-socket server on some port
like 5000
Just use Laravel Echo or Pusher SDK for mobile apps and
connect it to your server on 5000 port.
You don't have to pay anyone, it runs clone of pusher server on your
server.
The benefits of using a third party solution are different per use case and per person. However, broadly speaking there are a couple of benefits that haven't been mentioned here that are worth highlighting:
Hosted solutions do not require you to implement your own infrastructure to manage the websocket connections. This means you don't need to worry about the uptime, security, provisioning or maintenance of the infrastructure, this is done for you.
Hosted solutions scale seamlessly. As your app user base grows and your connections grow, you no longer need to provision more infrastructure and load balance/route connections.
Hosted solutions such as Pusher have dedicated support teams to help during implementation/troubleshooting.
Hosted solutions often have round the clock server monitoring, ensuring the platform is available 24/7 without the need for you to respond to server alarms in the early hours.
A lot has been said about build vs buy over the years, and there are many resources that discuss the merits of both (in fact Pusher has a resource for this). Ultimately this is not a decision that can be made for you, you will need to assess your application requirements and then look at what best fits your use case.
Sorry if this is a silly question. Has anyone managed to get the twilio stream to websocket working with SignalR (https://www.twilio.com/docs/voice/twiml/stream).
I have been trying for a while now and although I can see its hitting the server I never see it hit any of the methods.
Any help would be greatly appreciated
Thanks
Steve
I am just taking a look at Twilio Streams now that they've announced bidirectional support, I noticed that the docs indicate you have to utilize WebSockets. SignalR uses WebSockets but isn't just WebSockets. It's summed up succinctly in Jim Mc̮̑̑̑͒G's blog post How to save an audio file from Twilio Media streams to Azure storage
"SignalR is terrific, but it solves a different problem. SignalR can be thought of as a wrapper of several technologies - of which WebSockets represent a major component. It primarily serves the purpose of connecting web-browser clients to a back-end service. Other problems it solves include the maintenance of robust connections and the use of fallback techniques to enable browsers that don’t natively support WebSockets, to still benefit from real-time connections.
For Twilio Media Streams, we need to use WebSocket connections in a server-to-server configuration. SignalR isn’t the right tool for that job."
For some security reasons that I can't have a public accessible server to receive data from slack.
So, this is what I'm planning to do:
Inbound message from slack: using RTM API
Outbound message to slack: using RTM API or Web API
Questions:
Any better alternatives?
Any restrictions? (AFAIK, buttons and drop downs can't work)
If Web API reach rate limit, can I use incoming webhook as a backup plan?
RTM only approach
Yes, that would work. With only the RTM API you are limited to:
receiving and responding to messages
Other RTM events.
You can't use any interactive functionality like:
Interactive components (buttons, menus, datepickers)
Dialogs
Rate limit on message posting
Using the webhook as "backup" to circumvent the rate limit is not an option, since the rate limit of posting max 1 message per second applies to all form of message posting.
From the documentation:
In general, apps may post no more than one message per second per
channel, whether a message is posted via chat.postMessage, an incoming
webhook, or one of the many other ways to send messages in to Slack.
Alternatives
You did not give any details about the reasons why your app can't expose an endpoint to the public Internet. But you might want to consider using a VPN tunnel like ngrok.
Yes! Socket Mode
There is a new alternative from slack, Socket Mode, which doesn't require a publicly accessible server.
Note: this is only for private apps.
With Socket Mode you have an API token and your server uses it to communicate with Slack's servers and create a two way socket connection. This means your Slack Bot's code can run on a machine behind a firewall and not require any inbound ports to be opened.
Slack message delivery requires an acknowledgement once you get the message, or else they may retry to deliver it.
Limitations
Socket Mode has two main limitations:
Apps using Socket Mode are not currently allowed in the public Slack App Directory.
Socket Mode is only available for apps using new, granular permissions. If you created your app on or after December of 2019, good news: your app already uses the new permissions. Otherwise, you may have to migrate your classic Slack app to use granular permissions before turning on Socket Mode.
I'm working on a simple slack bot which is supposed to ask simple questions (yes/no) and based on answers perform some actions. AFAIU I should be using interactive messages for this. The problem is that it's supposed that slack will then call some external URL with the result, but for security reasons, I can't expose any service externally.
I was hoping I can just receive some event (using Events API) from Slack that user choose one of the options and simply read it directly using API. Unfortunately I can't find anything like that.
Is possible to use interactive messages without exposing external service to the world?
Yes. If you build a bot with the Real Time Messaging API you do not need to expose an endpoint to the public Internet.
With the RTM API you open a connection to Slack (which can be from behind a firewall) and maintain that connection. There is no call-back from Slack.
However, the RTM API will only enable you to create a chat bot that can react to events and message posts. The interactive message features like buttons and drop-down menus still require you to provide an endpoint.
When taking a look at the Pusher Servcer and their Client / Server API I am having some problems trying to figure out how Pusher will help me allow bi-directional communication between devices / apps.
I am having multiple smaller devices / apps in the field that should return their status to a server or another client, which acts as a dashboard to browse all those devices and monitor status, etc.
In my understanding this can be done using traditional WebSockets and a cloud-server in between which manages all connections between those clients - something I though Pusher would be.
But after reading through the docs I can't really see a concept of bi-directional data communication. Here's why:
To push data to the clients I have to use one of Pushers Server Libraries
To receive that Data I have to use one of Pusher Client Libraries
This concept however does not fit into what I need. I want to:
Broadcast to Clients.
Clients can send Data directly to Clients (Server acting as Gateway / Routing).
Clients can send Data to Server.
Server can send / response to unique Client.
When reading about Pusher, they state: "Bi-Directional Communication" which I currently cannot see. So how to implement that advertised Bi-Directional Communication?
Pusher does PubSub only. Using this, you can simulate bi-directional communication: Both sides of the conversation each need to have a topic dedicated to the conversation, and you then publish to this.
This is not ideal. For something which is probably closer to what you seem to want, take a look at WAMP (Web Application Messaging Protocol), which has more than just PubSub. There is a list of implementations at http://wamp-proto.org/implementations. For a router I would recommend Crossbar.io (http://crossbar.io), which has the most documentation to help you get started. Full disclosure: I am involved both with WAMP and Crossbar.io - but it's all open source and may just be what you need.