In the project my team is working we will set up two independent apps on the server-side, one is a django app and the other one is a tornado app. Both should be notified by webhooks when clients subscribe/leave a presence channel.
Will this be a problem? can we create as many webhooks to different URLs as we want to?
After asking the Pusher team (and I have to say they were very fast in giving me support) I learnt that there is not and established limit for this but they monitor it so you can't use as many as you want.
I asked if it is ok to have webhooks for 2 diferent URLS (for 2 different servers) and a total of 4 webhooks (cause we will need both channel existence and presence events webhooks) and they answered me that I won't have any problema at all with this configuration.
Related
I have a bot working on Teams and I'm able to fetch the user's Identity using the TeamsInfo. Now I want to get the same bot running on a web site (via direct line) albeit with lesser functionality and a different method of identifying the user.
I'm using TeamsActivityHandler as teams specific features (task module, messaging extensions) are being used.
As I want the flow to be different so I understand that I would need separate dialogs. I'm confused on how to approach this with activity handlers? Do I need separate activity handlers or lots of if conditions in one?
PS. I have looked for sample and articles online but didn't find anything about one bot running on multiple channels supporting different features; I can share some code if needed.
These days I am finding myself in the position of having to implement for one of my college courses a system that should act as a giant wrapper over many communications apps like Gmail , Facebook Messenger maybe even WhatsApp .To put it simply you should have a giant web interface where you can authorize Gmail , Messenger and use them at once when required. I am thinking of going with an REST API to manage the user's services authorized by OAuth2.Also I am thinking of using Node.JS and Express.js in the backend and React.js in the frontend. I found some sweet libraries in npm that should take care of interacting with the involved APIs(https://www.npmjs.com/package/node-gmail-api this one for instance), but I am also doubtful about this approach , for example I have no idea how to keep the use notified about its incoming mails or messages for example . I am in dire need of some expertise since I forgot to mention but I am quite the newbie in this field. To sum it up for once my question is how would you implement such an infrastructure ? Is it my approach viable or I am bound to hit some really hard to overcome obstacles?
As a college exercise, it would be a really fun experiment, so it definitely worth the time you want to put into it. However, once you want to add more features, the complexity will go up pretty fast.
Here are a couple of ideas you can think of:
It's pretty clear that your system can't do more things than the capabilities exposed by the APIs of communication apps (e.g. you can't have notifications in gmail if the API doesn't have this capability).
For that reason, you should carefully study the APIs and what functionalities they expose. They have public docs that you can check out: (Gmail API, Facebook Messanger API)
Some of the apps you want to communicate with may not have an official API (e.g. WhatsApp) - those kinds of details you definitely want to know from the start.
Based on the analysis of those APIs, you should lay out a list of requirements for your system, which can be extracted from all the APIs, for example: message notifications, file transfers, user profiles, etc.
In this way, you know exactly what capabilities your system should have, and you don't end up implementing a feature that is available only in 1 API out of 4.
Also, it would be a bit challenging to design your system from a user perspective, because the apps have different usage patterns - chat apps, where messages are coming in real-time, vs email, which is not real-time communication. That's just a detail anyway, the gist of your project is to play with those APIs.
Also, it may worth checking out the Gateway Aggergation Pattern, which is related to this project - you may want the user to send a message to multiple apps, by using a single request to your service.
I figured out that there's always latency of about two to three seconds when sending messages through the Bot Connector of Microsoft's Bot Framework independent of which channel type I'm using.
This means if I call the POST .../messages API method of my Bot directly (so not going through the Bot Connector) I get an answer within several dozens ms. However, if messages are routed through bot connector (e.g. when I use Direct Line communication or Telegram or any other supported channel) it always takes about two to three seconds until I get an answer.
For a possible user this would not be a good user experience so that I'm wondering whether either I'm doing someting wrong (e.g. Bot Connector settings) or whether this is a general problem and will be improved at a later pont of time.
Thanks a lot in advance.
This is a known issue. The BotFramework is still in Preview, so it has yet to be optimized. Expect to see significant performance improvements in the near future.
This question already has answers here:
In what situations would AJAX long/short polling be preferred over HTML5 WebSockets?
(4 answers)
Closed 8 years ago.
I'm a developer at enterprise social network product, and I'm working on a feature that is very similar to Facebook notifications.
We want to provide a notifications mechanism for our customers in real time.
I'm building a notifications service in node.js that my system can interact with and notify.
The biggest issue is:
should the client use pulling? I mean every few sec check the service of there are any changes?
Implement the client with websockets (socket.io) so the server knows all the available users and push them each change.
The maximum amount of users I will ever acquire is 20k
The maximum amount of active users is 5k
What do you think is best?
I like socket.io. Give it a try, it will probably get you started. But someday you will probably end up needing to dive into the details of how it works, if you're working on a serious commercial product. For example, WebSockets may get stymied by corporate firewalls, but socket.io will fall back to other methods like polling automatically.
I am making a game with Google Hangout where I need to control which participant could communicate with others.
I want to be sure that players could not change the list of participant he could see by calling a javascript function. Because from what I understand each participant could change his visibility of other participants, and I want to block that.
So I wonder if it is possible to control the visibility between participants at server-side.
Short answer: No.
Medium answer: It really depends exactly what you need, but probably not.
Much longer answer:
It sounds like you want finer grained control over both visibility and message sending/state sharing than the Hangout API allows for. The Hangout API reflects what participants can see in the actual hangout today - everyone else who is in the hangout. The shared state is shared with all other members of the hangout running the same app, and the visibility is for all users in the hangout or the same app.
If you want to restrict or limit this (for example, if people are divided into teams and you want a "team chat"), you would need to use your own server to coordinate this communication, on at least some level. Your server would either need to actually do the communication between team members, or distribute a shared secret that each team would use as a cypher for their shared state.
One possible trickier solution might be to have each team run a different app. Since each app only shares state with the same app running on another participants machine, and can list only the other members who are running the same app, this might be a valid solution in some cases.