3

Asking for your opinions/experience regarding this

I have a program which send payload to fcm api to push notifs. But sometimes it gets timedout at a random interval.

Someone says the server is too far from us (SE asia to US <google>). And that we should move our codes to AWS (when we already have a huge ass on premise server). Am I an idiot for being skeptical at this?

I mean i could play games on US server just fine and here we are debating about 100KB json payload that cannot be sent to a US server due to 'distance'. Dunno what the cause for timeout but it gets ridicilous now.. I dont have the patience for this

Comments
  • 4
    Can't just resend after a time and handle possible duplicates by using unique ID or something?

    If you don't know the reason for the timeouts for sure moving to AWS could be a waste of time....
  • 2
    As @N00bPancakes said, log the timeout and try sending a second request in a minute or two, if that still times out, make a manual process to trigger it.

    Can you check if the push notification was actually sent from the api side, and use that after a timeout to see if a resend is required.

    Moving to AWS because a service you use is in AWS feels overkill, just add handling for the latency of requests.
  • 0
    @N00bPancakes I have done it. Failed fcm requests will be re-sent every 1 minute.

    But still they insist to mvoe because we also use another googleapi to build a chatbot. For now i make it so that if the request fails, the chatbot will return something along the lines of "im sorry... please try again".

    It sure is annoying for the user when a timeout happens but im not buying that this is not on the network side, and to move to aws will be a waste of money.

    But hey some people believe what they want to believe. Than fixing the actual problem.
  • 0
    @DwightSchrute

    Yeah unless you KNOW the actual cause of the timeouts and can prove it... I would not make a non trivial move to address something ... just to troubleshoot.
Add Comment