Scaling API-driven development can be difficult — here’s how to nail it

Developers today think in Application Programming Interfaces, or APIs. Looking at APIs first helps you concentrate on the problem that you are looking to solve in an application, or as part of a wider service. With communication between components in an application all taking place via APIs, this approach makes it easier to adopt microservices designs and make use of multi-cloud.

However, API-driven development (ADD) is not as easy as it sounds over time. Concentrating on APIs first can make it easier to build and maintain an application, but it’s not possible to ignore the infrastructure side completely. If you want to scale up your service over time, thinking about areas like data will be essential.

So how can you make the most of ADD and consider infrastructure together? And is thinking about this from a non-functional perspective the most helpful approach?

ADDing up your approach

The best approach around ADD is to look at your approach to APIs and infrastructure at the beginning. While focusing on APIs first can help make it easier and faster to update your application over time, it does not solve the problems that can exist around infrastructure.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

[Read: Coding is not ‘fun’ — it’s technically and ethically complex]

Instead, it’s worth spending some time to consider how your APIs will interact with any back-end infrastructure service APIs, and how those services will meet any requirements for service levels. While an API in front of a database or a storage service can help you simplify the process for building a service, you do need to think about how that back-end will perform in the future.

Typically, many application components will handle some form of request around data. It may be creating an order, processing a change or providing some data back based on a request; all of these actions rely on either taking existing data from a database, or creating new data that is then inserted into an existing database. Making this simple to process as part of an API call makes it easy to grow the number of requests that can be processed.

However, that infrastructure is not as interchangeable as it may seem. Not all databases are created equal, and the same is true of public cloud service offerings too. It’s therefore worth spending time to understand how your options perform around issues like scale or availability. While the API to handle data may be the same regardless of the database you choose, different databases will perform differently and handle data in different ways.

While an API can mask the complexity of managing a database for you, that doesn’t mean that the database will go away. Instead, it’s worth spending some time on how you can make the most of this via your APIs.

New application designs call for new approaches to data

The move to ADD and microservices makes it easier to think about scale for an application. Need more horsepower to support more customer requests? Adding container nodes to handle an increasing volume of API calls, so this can support more demand. However, this is not the only potential bottleneck for performance.

For applications that are distributed — as in they are made up of multiple different components, each of which can be made up of clusters of nodes carrying out tasks — there are new approaches being developed that can make management easier over time. For example, the Kubernetes container orchestration tool makes it much easier to automate the process of creating more containers and shut them down when they are no longer needed. However, these approaches don’t deal with the issue of data.

Running a distributed database environment involves understanding how data is spread across multiple locations, and the partition tolerance, consistency and availability requirements that go into that setup. Using a distributed database alongside a fully distributed application allows you to keep your data close to your application, ensuring that latency doesn’t affect performance. Services like Apache Cassandra are specifically built for handling distributed data, making it easier to scale.

Similarly, using an API to access that database environment can mask some of the complexities that go into running that distributed environment. Even so, scaling up distributed database environments so that it can meet the needs of your application is a challenge. Understanding and planning for this in advance can make it easier to scale up your service overall.

If you do find that your existing database infrastructure is becoming a bottleneck for overall performance, then you can look at how to manage a migration behind the API. A shift from a relational database to a non-relational one, or a move from one NoSQL database to another, can require additional time and resources to be completed. However, the API can be quickly pointed from one service to another, limiting the impact on the rest of the team.

ADD and data together

Looking at your infrastructure may seem antithetical to ADD. After all, going into detail on cloud services or databases upfront can appear to be less important than looking at how to build and run the APIs that make up an application. However, issues caused by inadequate scalability or availability can quickly affect applications and they are not simple problems to solve with APIs alone.

Looking at your long-term requirements and architecture decisions upfront can therefore help you solve some issues early. By thinking about where your approaches to infrastructure and APIs overlap, you can make the best of both.