I am implementing webhooks with my payment solution (stripe), and I set up basic webhook server responses.
So, upon various events, such as updating a subscription, a server request is sent to a specific endpoint (/webhooks), and a 200 response is fired.
Now, I would like to listen to this server with my saga, but I'm not sure how to do that. The idea is I have a redux-saga event channel listening, and such an async request as updating a subscription status, would trigger a new saga. If for instance, the user updated his subscription status from paid to unpaid, his new status could reflect immediately in the UI.
Implementing this is not an issue when the event is triggered by the user. However, stripe allows me (as an admin) to trigger such events from Stripe's dashboard. If let's say I update one user's subscription status from Stripe's dashboard (because there is a bug with the UI for example), that will send a request to the webhooks endpoint on my server, but I'm not sure how to "intercept" it on the front-end, in order to then do what's needed for that user.
Do you have any suggestion ? I read about service workers, about pub/sub services. But I'm not sure they are the right way to do what i'm trying to do.
You'd need to implement either websockets or long polling from your frontend to your backend that looks for the updated response/data in your backend.
Related
Our company now uses ms teams. Whenever an incomming or outgoing call is made the name of the company or customer is not displayed in teams. So I need to display details to that call in a custom app. Therefore I wanted to use the callRecord subscription.
But in order to get the subscription working with my app, I need to have an API that gets all the subscription calls and provides the data via websockets to my app, right?
Isn't it possible that the app gets the subscriptions?
Today Microsoft graph change notifications only support delivering the change notifications gtuys webhooks/http post.
If you want those change notifications to be delivered to your front end application via Web sockets, you need to build your own backend solution to receive the change notifications via http post and relay it via Web sockets. Additionally you can request the feature on uservoice
I would like to access the messages in the Twitter via the API in real time. A cursory search showed that it is possible to periodically send API-request to Twitter. In general, this is possible. 15 requests in 15 minutes is enough.
But I'm wondering, are there other ways to get information faster?
For example, is it possible to subscribe to notifications and receive a request from Twitter at a certain address?
Are you asking if Twitter has webhooks? The answer is yes
Review Securing Webhooks documention taking special note of the
Challenge Response Check (CRC) requirements.
Create a web app with an endpoint to use as your webhook to receive
events (e.g. https://example.com/webhook/twitter).
Make sure your webhook supports POST requests for incoming events and
GET requests for the CRC.
Register your webhook URL with your app using POST
account_activity/webhooks.
Use the returned webhook_id to add user subscriptions with POST
account_activity/webhooks/:webhook_id/subscriptions.
I have read about the outbound webhook and Event api. And i am able to install a bot to a team using slack button. outbound webhook dosent fit in my scenario i think.
So how can i can get all events(specially whenever this bot receive a msg) using the event api to my webhook.?
Any direction or right way to solve this problem ..?
Outgoing Webhook and Event API are two completely unrelated functions. So you can not get event notifications through an outgoing webhook.
To get event notification your Slack App need to
request the correct oath scopes
subscribe to the events you want to get in the Slack App config
have a script ready to receive the event requests from Slack
Your script will then be called every time the subscribed event occurs.
For all details please have a look at the excellent official documentation about the Event API.
The scenario is - A twilio web client 'Mr TWC' and A customer 'Mr 123'.
Now I need to respond 'Mr 123' based on 'Mr TWC' in online on a web browser OR offline/not on a web browser.
Thanks In Advance
Twilio developer evangelist here.
I'm afraid there's no way to check the status of Twilio Client users via the REST API.
There used to be presence events available on the Client, but this was deprecated in version 1.3. So, I recommend you keep track of whether your users are online yourself. You could do so by maintaining a list of online users in something like redis on your server. Every time a user successfully authenticates and starts listening for incoming calls with Client, send an Ajax request to your backend to add their username to the list. Then, when they go offline, or close the browser you can send another request to remove their name from the list.
Let me know if that helps at all.
I have a video transcoding API and a CMS application which consumes it.
Workflow is as follows:
CMS sends a GET request to to the API to get a of list video files to transcode and it gets the answer in JSON format.
CMS user selects which file to be transcoded and clicks on the "Transcode" button.
As user click on the link, a POST request goes to API and API creates necessary Progresses internally and responds with initial status of the progresses in JSON format.
After creating Progresses at the API, I make GET ajax requests to API asking about the current process status periodically. Because it's a requirement for me to show user current status of the transcoding processes (like percentage..).
Additionally, I have some other resources that I should inform CMS about the current status.
At this time, I'm making an ajax call to API once in 5 seconds.
Here is the question:
Is this the best way to do it all?
Is there a way to create full-duplex communication between an API and a Rails app?
I tried pusher and push notifications but seems like they're only for front-end communication? Is this true?
I had heard about websocket but I couldn't find a good resource to fully understand it.
What is the approved way of Rails community to do what I ask for?
Thank you
To clarify: you need more than just server -> client communication because you need to inform the user/browser and also other components in the CMS about progress.
Note: not sure what technology the API is written in so I'll assume Ruby
Based on this Faye may be a very good solution. Both the web browser and the CMS server can be Faye clients and can subscribe to updates from the API. The API can publish updates to a channel appropriately named based on the video file that is being transcoded.
Browser <-> API Faye server communication will be over WebSocket or fallback transport.
CMS <-> API Faye server comms can be over the same transport types or they can use an Engine such as redis.
CMS sends a GET request to to the API to get a of list video files to transcode and it gets the answer in JSON format.
CMS user selects which file to be transcoded and clicks on the "Transcode" button.
As user click on the link, a POST request goes to API and API creates necessary Progresses internally and responds with initial status of the progresses in JSON format and the channel for progress updates.
After creating Progresses at the API, the client subscribes to the updates channel. As progress changes the API will publish the update progress to the channel and the client will receive the updates.
The CMS somehow needs to know the progress channel too. It could do this by having an channel that it always subscribes to. The API can then publish all transcoding information on that channel e.g. video-transcoding. When it sees a new transcoding has started it can subscribe to the channel for specific video transcoding updates.
It may be that bi-directional communication isn't 100% necessary. It seems like the API needs to push updates to the CMS and to the client. If that's the case EventSource/Server-Sent Events may be an option. And if you don't want the CMS to have a persistent connection to the API and would rather have updates pushed to it via HTTP you could add WebHook support to the API; on progression it makes an HTTP request to the CMS to inform it of progress.