Pros of dedicated API services for cross-platform mobile apps
One API can rule them all -- but developers shouldn't be surprised if problems occur. Delve into the pros and cons of dedicated API services for cross-platform apps.
Developers that use one API for cross-platform mobile apps should consider a beneficial alternative: dedicated API services.
It's common to use one API to deploy platform-specific mobile applications for Apple iOS, Google Android and even the web. This straightforward approach may work on medium-scale projects or on projects where all the clients have the same requirements, but it can also result in bottlenecks.
Challenges of a single API for cross-platform mobile apps
Cross-platform mobile apps often use the back-end server's API to communicate. This API abstracts out all the implementation details and exposes the back-end server's functionality in the most convenient way. However, the teams that build different cross-platform mobile apps usually have different experiences, capacity and preferences -- and each platform can have different requirements.
For example, companies often have mobile apps act as active business agents and web clients act as operations controls and dashboards. The difference in requirements is reflected in features that different platforms need from the back end, which can result in different constraints on the back-end server's API.
The back end that exposes two API services: one for mobile clients and one for web clients
As a mobile app development project grows in complexity and clients' requirements diverge, it will be increasingly difficult for a single API to accommodate conflicting requirements and constraints. Developers may make changes for one client that can unintentionally break another one. Plus, back-end servers can block the developer teams that build platform-specific mobile apps from accessing them.
Benefits of dedicated API services
It's important for developers to tailor the API service to the specific requirements of the platform. To do that, developers must decouple the API from other existing API services. Developers can expose a set of related functionalities to the back end, an approach known as dedicated API services.
With dedicated API services for each platform, developers can change the back-end API independently. Dedicated API services can also enable developers to break interdependencies between teams and products.
It's important for developers to tailor the API service to the specific requirements of the platform.
Let's say that developers are creating an application for couriers that will make deliveries and capture recipients' signatures on their smartphones. In addition, it will enable office employees to control overall business operations from their web browsers. The requirements of mobile clients are different from the requirements of web clients.
Developers that try to satisfy all of these requirements with a single back-end API will likely get a bloated and incomprehensible API with lots of duplication. As the mobile and web clients' requirements diverge with the project's increase in size and complexity, the coupling between mobile and web clients through the API can become a bottleneck.
Developers that have separate API services for mobile and web client apps, however, can develop each of them independently. This can eliminate the time wasted on figuring out which portions of the combined API are relevant, and the application won't break due to adaptations made for other clients.
How to implement dedicated API services for cross-platform mobile apps
It takes more planning and attention to maintain multiple API services. Developers, for example, need to version each API service separately. Developers must also invest more time in the initial setup of the API services. Many organizations implement microservices, however, so the addition of a couple of services is less of an undertaking.
The bitter pill to swallow for many organizations is that the deployment of multiple API services might require organizational changes. The central question becomes who owns each individual API service? Should back-end server professionals be responsible for all of them or should client-side developer teams take ownership of their dedicated API services?
Organizations can designate all API services to back-end developers that build and maintain servers and databases. If the organization has a rigid IT structure with clear boundaries between different teams, this approach is the simplest.
Alternatively, client teams can take full ownership of their respective API services. This will allow them to be more independent and will reduce the communication overhead with back-end teams. However, this approach either requires organizations to staff back-end developers on client teams or client-side developers to learn back-end development.
There is a middle ground, however. Ownership over API services can remain in the back end, but the organization can designate developers that maintain these services to client teams like freelance consultants. This approach requires less organizational change, but still allows the client teams to be independent. It can also result in a transfer of knowledge and improved collaboration.
