What is an API application?
You’ve got a database, and you’ve got apps that need to talk to that database in a number of different ways. Adding a custom API layer takes the burden off of both your frontend and your backend to process those calls, resulting in faster runtimes, lower data processing costs, faster app development, and—ultimately—more satisfied users.
Modern digital strategies demand modern infrastructures
Limitations of three-tier architecture
Mobile device usage has exploded in recent years, and now we’re seeing the rise of wearables, the Internet of Things, and voice devices. With all of this increased activity, the traditional three-tier architecture is not ready to handle the flood of traffic users are generating. The three-tier architecture arose in the era before smartphones, when users consumed web applications on desktop computers with an always-on connection. We have built many apps that work with these types of systems, and we often encounter a number of problems:
- To support mobile devices, APIs are often bolted on to existing three-tier applications as an afterthought. The result is a user experience that is not optimized for mobile use cases.
- Mobile devices must contend with spotty connections and limited bandwidth. Three-tier applications were not designed with this in mind. They often send data payloads that are too large for mobile connections.
- User activity is much higher on mobile devices. Three-tier applications are unable to scale to meet this increase in traffic.
- Existing systems often contain data in disparate sources. This requires mobile applications to call several different services to get what they need.
- Different services could have their own authentication requirements or communication protocols. Connecting to all of these services can increase the amount of code that mobile and web developers need to write.
- Existing systems sometimes don’t contain all of the business logic necessary for mobile apps to meet their requirements. Out of necessity, the business logic lives in each separate mobile app, creating duplication of effort and increased risk of bugs.
- New devices, such as wearables and IoT, must work with a variety of different constraints, and therefore have different needs when consuming data. Existing systems usually take a one-size-fits all approach to APIs, which make it difficult to provide a great user experience.
The ultimate result of these issues is a less-than-stellar user experience. Frontend developers spend more time getting business logic correct or stitching together calls to multiple services, and less time focusing on the user experience. To address this, Forrester has published the four-tier architecture as a replacement for the traditional three-tier architecture, which introduces client, delivery, aggregation, and service tiers.
Source: Mobile Needs A Four-Tier Engagement Platform, Forrester
Strengths of a four-tier architecture
This new architecture shifts the responsibility of the user experience to the client tier, which could take place on a wide variety of devices. Instead of the server building web pages and delivering them to the client, the client now is in complete control of the user interface.
The delivery tier handles the “last-mile” of the connection by caching and optimizing content for different clients. Whereas this responsibility used to live in the application server, developers can instead leverage products like AWS CloudFront, Azure CDN, and Akamai. This tier can also handle other cross-cutting concerns, such as authentication, analytics, and rate limiting, taking them out of the application code.
The aggregation tier is an important addition to the new architecture. In the traditional three-tier architecture, most data was contained in a single database. Now, however, applications retrieve data from a variety of services, both internal and external. The application might get customer data from an internal service, and then it might consume the Google Maps API to geocode customer addresses. This new tier aggregates calls to the underlying data sources, translates data into a format more palatable for client devices, and exposes this data as single facade API. This can take several different forms: an API Gateway, a Backend for Frontend, or a mobile sync API.
The services tier represents the existing internal systems of record and external third-party services. In a four-tier architecture, these services can expose data without worrying about how it is consumed, letting the aggregation tier optimize the data for clients. A variety of enterprise architectures are possible here, from traditional service-oriented architecture to microservices.
Why do I need an API application?
There are numerous advantages to building an API application in the aggregation tier.
By having an API that is decoupled from the underlying services, the frontend developers can iterate much more rapidly. The API developers can collaborate much more closely with the frontend developers, delivering exactly the data that is needed, in the format that it is needed in. They can use consumer-driven contract testing, decreasing the risk of breaking changes. Using continuous delivery techniques, the API developers can tighten the feedback loop of getting features into production. The frontend applications can then evolve in response to changing requirements.
Data from existing services can be translated to a format better for mobile devices. An example would be translating the SOAP to JSON. This data can then be returned as paginated responses with smaller payloads. This means more efficient communication over poor connections and limited bandwidth. An API in the aggregation tier can also implement features such as mobile sync, supporting offline usage in the front end applications.
The user experience has spilled over from mere smartphones into wearables, OTT, voice devices, and IoT. Users expect to be able to seamlessly transition from one to the other. In order to support these multimodal interactions, an API must be able to remember the user’s context and reuse it between devices.
Better developer experience
An API can present a uniform, consistent experience for frontend developers. It can use the best paradigm for the situation, such as REST, GraphQL, or gRPC. It can aggregate calls to multiple services. It can transform data into formats, such as a single date format, that are consistent across all interactions. It can also implement any business logic that would otherwise need to be duplicated in all the frontend applications. By taking on these responsibilities, an API can hide the complexity of existing services. Frontend developers can devote more time to building outstanding user experiences and less time dealing with custom business logic, stitching together calls to different services, and understanding different protocols.
When there is a single API, the mobile application only needs to authenticate once, instead of once per underlying service. This functionality can also be federated to identity providers like AWS Cognito and Azure Active Directory B2C. The API can apply role-based access control to ensure only authorized users are allowed to access or modify data. It can also log every transaction that occurs, providing centralized auditing capability. The end result is better security for the organization as a whole.
An API can scale elastically in response to increases in traffic, and it can be done independently from the underlying services. Developers can write twelve-factor applications to leverage the full capabilities of the cloud.
While the aggregation tier has the freedom to change independently from the service tier, the same is true of the reverse. Services in the bottom tier can evolve without directly impacting the frontend applications. They can return data in its most appropriate format, without being concerned about how it is consumed. The enterprise can adopt a microservices architecture and the frontend applications would be none the wiser.
In order for developers to deliver an outstanding user experience, they need an outstanding experience of their own. No longer is an aggregation API a nice-to-have component that is external to the mobile and web apps. It is vital to delivering the experience that developers expect, so it is an integral part of the end user experience. In addition to building world class frontend UX on Android, iOS, and the web, WillowTree can support it by building a world class API in the aggregation tier.