Mobile apps: Third-party integration strategy
Mobile applications interact with different services, share and aggregate data, unify the functionalities, etc to give a unified experience to the user. Mobile apps are both producers and consumers of data, depending on the type of the application. Businesses across the globe interact with partners, vendors and leverage modern technologies to provide more value adds to the customer, apart from the core products that they offer and support to the customer. It leads to lots of third-party integrations. And at the same time, share data securely with the third party. Product discovery workshops would reveal all the possible integrations that the mobile app may have.
Things to consider in an integration strategy with 3rd party -
A) Better UX — A smooth user experience that transitions from one flow to another without being noticed by the user
B) Latency — In a multi-party integration situation, insist on the agreed SLA for latency. In general, 1 sec or less for any service is good
C) Retry options — How to handle errors by providing a smoother user experience? Work with the 3rd party on the retry and notify techniques
D) Security — Every 3rd party will have different security standards in place. At least stick to the top 10 mobile OWASP standard
E) Support — The user does not know how many 3rd party integrations are involved in the app. As a user, it’s a single product. Work with 3rd parties on providing the unified support experience
Let us see some of the common integration patterns used in the mobile application development
1) All third-party integration via the pass-through cloud (Traditional client-server model)
1 — Mobile app requests the information to the backend system
2 — The backend system calls the 3rd party systems
3 — The 3rd party system returns the data to our backend
4 — If needed, the compute instance stores the returned information to our database. This step is optional
5 — Our backend system returns the requested information to the mobile app
When to use it?
It is the most commonly used approach. Use this when all of the requests and responses have to be vetted in our backend before being handed over to the 3rd party for processing. The solution can be used for both synchronous and asynchronous approaches.
Pros –
- Security-first approach
- Easy implementation
- No new learning curve needed
Cons –
- Single point of failure
- High latency as it has to go through multiple layers
2) Direct third party integration from mobile (Call back handled by mobile (C2S2C))
What happens in this approach? -
1 — Mobile app directly calls the 3rd party systems
2 — Third-party system replies to the mobile app
3 — If needed, the mobile can sync with our backend for persistence storage. This step is optional
When to use it?
The mobile app should work synchronously. Use it when there is a need for very low latency like M2M applications. If IT is all about mobile apps development, then it is wiser to choose this model.
Pros –
- UX first approach
- Very less latency
Cons –
- Lack of security because of direct association of API keys in the mobile app
- Needs more attention to handle retry mechanisms
- Chances of missing the response back from the third party systems because of the state of the mobile app
3) Direct third party integration from mobile (Call back handled by the server (C2S2S))
What happens in this approach? -
1 — Mobile app directly calls the 3rd party systems
2 — Third-party system replies to our backend system
3 — Mobile app requests our backend system on a needed basis
4 — Our backend system returns the requested information to the mobile app
When to use it?
The mobile app should work asynchronously. Use it when the mobile app has to just notify the third party systems and need not worry about the outcome of the third party systems.
Pros –
- High persistence and availability first approach
- Highly reliable
- Highly secure
Cons –
- Need to pay more attention to the security involved in the S2S callback
- More network calls and high latency
4) Combination of both 2 and 3 (C2S2C and C2S2S)
What happens in this approach? -
1 — Mobile app directly calls the 3rd party systems
2A — Third-party system replies to the mobile app
2B — If needed, the mobile can sync with our backend for persistence storage. This step is optional
3A — Third-party system replies to our backend system
3B — Mobile app requests our backend system on a needed basis. Our backend system returns the requested information to the mobile app
When to use it?
The solution uses a combination of both synchronous and asynchronous approaches. When both high UX and highly reliable solutions are the requirements, then choose this model. If IT already has a well-sophisticated backend system that can handle the S2S calls, it is not a big operational overhead to implement this.
Pros –
- Best in class approach by taking the best of all the above approaches
- A highly available, scalable, persistent, and resilient solution
Cons –
- Less cost-effective
- More operational overhead
What are the modern tools available to implement the discussed strategies?
1) Traditional cloud — Build a container-based microservices orchestration and deploy them as needed. This would be the most preferred choice because of the cloud-agnostic nature of the solution.
2) Serverless cloud — Quick to build and deploy with less maintenance and operation overhead expenses. There is a potential risk of cloud vendor lock. However, using a microservices pattern can alleviate issues during migration to a new cloud vendor.
3) SDKs — It is the modern way of building mobile applications. Rapid Application Development (RAD) is the key here. The mobile apps simply integrate the SDKs, and everything else is taken care of seamlessly. There is a higher risk of vendor lock-in with very minimal or near-zero customization options.
Share your thoughts on the mobile application integration strategies.
Happy learning!
Originally published at http://shankarkumarasamy.blog on July 26, 2021.
