Search code examples
iosmobileclient-servermicroservicesconceptual

Should iOS client retry on server (microservice) failure?

I'm building a project consisting of an iOS app that communicates with microservices via HTTP for many reasons: authenticating users, saving data, retrieving data, and more.

If the client fails, the app crashes. This will be reported and fixed if possible for the following release.

Here's my question:

  1. If the server fails, it returns an error HTTP code (4XX, 5XX, etc). How should the iOS app react? Should it accept failure and notify the user? Should it re-try? How many times?

  2. If the database fails, the server returns an error message via JSON. Again, how should the iOS app react?

Does the answer depend on the technologies used?

Solution

  • It's likely to depend on the domain and the importance of a request made; e.g. a request to create a bank account transfer vs a request to post a status update won't be created equal.

    With that said, they could still technically handle the error in the same way. My 2 cents would be to ask for a retry even in the case of a server failure or database failure. This might be a little more about software development process of mobile client server applications but I believe most fixes should inherently be on the server side. This is because people may not have updated the iPad and annoying them to do an upgrade is poor user experience. Putting responsibility for fixes on the server side also helps avoiding to go through the Google or Apple approval process before it hits app stores.

    Moving forward I would suggest the following:

    • Be resilient in the mobile application and handle all errors instead of letting the application crash: use try/catch blocks to handle errors, ask the users to retry, or let them know you have reported the problem. Send a log of the bug to the server if possible.
    • QA and test thoroughly before putting it in the app store to avoid having to deploy multiple times because of bug fixes.
    • Architect your software such that fixes usually happen on the server side to minimize client-side headaches (and buggy live code). However, errors like not providing enough information in a request to send to the server should be handled on the mobile application -- but this kind of problem should be mitigated through a strict QA process.

    Hope this helps.