Closed Akilditu closed 3 years ago
In my view we have to do the first step (regular fetch on the API, if done every 5 seconds it keeps the "almost-real time" effect while being very light on the API load). The webhook could end up being a bit cumbersome to implement. When I suggested it, I had in mind the webhooks used by slack or Zapier but if we do it one ourselves without relying on a 3rd party platform, that will be a bit harder to implement. Basically we will need to create a route reay to receive post requests in the WebApps.
In my view we have to do the first step (regular fetch on the API, if done every 5 seconds it keeps the "almost-real time" effect while being very light on the API load).
Fetching every 5 seconds could be an answer yes but it requires a 24/7 on Heroku which I think is not doable based on the current plan we have (550 hours/months). An idea would be to check if app is running before fetching
oh I didn't know we had such limitations with Heroku. Well, we are not going to deploy in real conditions anytime soon right? So for demo purposes I guess it should be enough? When we will deploy we may have credits to use on Heroku.
@Akilditu I just tested that it is possible to send external requests on the pyroplatform becaue Dash is based upon a Flaks server. I guess we could create a route in the pyro-platform to receive a Post Request to signal an update has been done and that would be enough for our use case :)
This issue can be closed because #38 references the remaining task on this
Hi API team,
As a follow up to #19 and pyro-api/issues/61, the ideal way to handle live alerts would be a webhook on platform's side receiving requests from pyro-api.
I'm not sure it is 1.0, in between we could :
Here is an example of building a webhook with FastAPI. I guess this has to be a share task between platform and API, let's discuss what is our best option regarding time consumption and availabilities
cc @frgfm, @fe51, @jeanpasquier75, @florianriche