Conversation

jiten
@jiten
Replying to
@jiten
As mobile developers, we should follow the circuit-breaker method and see if the application can continue when an API is continuously failing. In some cases, your application may ignore a particular API's response.
1
9
jiten
@jiten
Error messages Do your APIs have well-defined and well-understood error code responses? If you rely only on HTTP status code for displaying errors, you may miss out on the 'perfect error message' for your customers.
Image
1
7
jiten
@jiten
Errors can happen at your Backend (application/input errors), the Backend may misbehave, and the API gateway or CDN may report an issue. The errors can also happen because of an inconsistent state within the application.
1
6
jiten
@jiten
Let's say your customer searched for a product on your website and your API failed to fetch results because of a database connection issue. Instead of giving zero results answer to clients, you should throw an error.
1
6
jiten
@jiten
The client can then choose to retry automatically and present customers with an error message and a retry button.
1
5
jiten
@jiten
1. When the customer sees the error message, do they know what they can do to unblock themselves (it could include calling your customer care number) 2. When your customer support team or engineers receive a screenshot of the message, can they trace and debug the error?
1
5
jiten
@jiten
I had colossal API failure %age on mobile applications reduced to less than half when we displayed the current network state (offline/online) to customers along with a retry button.
1
6
jiten
@jiten
Analytics If you already have API performance analytics for your mobile application, you are already in a good place. Google's firebase SDK automatically collects analytics around failed / timeout APIs. API performance analytics is often valuable data.
1
5
jiten
@jiten
I create custom analytics events for some APIs so that we can quickly catch failures. Custom events and alerts based on client-side analytical events become crucial in some cases - login failures, video playback failures, and purchase or checkout failures are just some examples.
1
5
jiten
@jiten
Test for failures It's okay to write code that will fail gracefully. We often test for functionality, and I want to emphasize how it's equally (if not more) essential to test for failures. It's easy to mock failure responses with different codes and delayed responses.
1
7
jiten
@jiten
Replying to
@jiten
Additionally, if your team does chaos testing, testing for mobile client behavior during backend chaos testing becomes a handy tool in your arsenal.
1
5
jiten
@jiten
Rest of the armory If your backend application is behind a CDN and your CDN supports fallback / always-on responses based on upstream application state, consider using this tool.
Image
1
3
jiten
@jiten
In past, I have generated hourly static responses for some of the popular APIs for my applications (in one case, this included a search and filter page).
1
3
jiten
@jiten
On occasions, I had also asked customers to restart the app when multiple manual retries failed. Nothing is better than resetting the state and starting with a clean slate for a buggy application. I did send a custom analytical event for all such retries and restarts.
1
5
jiten
@jiten
Remote config often comes in handy when a particular feature / API takes time to recover. When things go wrong, remote configs may not work as desired, so you should choose the default configurations carefully.
1
4
jiten
@jiten
Does your network stack consider these failure points and solutions? When you write a network stack for your next mobile application, I hope you will consider some of the problems and solutions described in this post.
Image
2
3