API series - Tigris Data: Developers love APIs & data, but do they love data APIs?
This is a guest post for the Computer Weekly Developer Network’s API series written in full by Ovais Tariq in role as CEO of Tigris Data — Tigris is an open source developer data platform for all the data needs of an application without any of the infrastructure management.
Tariq writes as follows…
For developers, APIs can help them build applications quickly and effectively.
If you need to implement a payment service, you could implement payment infrastructure and processes and have to implement security… or, you could integrate Stripe through a single API.
If you want to add more communications channels, you could implement your own email or SMS gateway to manage messages… or, you could use Twilio with an API.
Developers like this approach because it means they can concentrate on what they love doing – solving problems and writing code to meet business goals – and hand over other services to other companies and their developer teams. This fits in with the modern application development method for using microservices and connecting components using APIs.
The data created by applications should be handled the same way. Rather than running your own infrastructure, use a service instead.
Design patterns affect app data
So then, rather than building and running databases for each microservices component, why not use a Database-as-a-Service (DBaaS) or API instead?
Hang on for a moment though, it is not as simple as it sounds.
Developers today like working with microservices to build their applications. While this makes it easier to plug together application components using APIs, each component will have its own database component running alongside, such as a database or a search system. Each of those instances will need tending, management and improvement over time, which eats into developer time.
Replacing database infrastructure with DBaaS takes on some of the heavy lifting, but it will still mean some infrastructure management.
Tigris Data’s Tariq: Looking ‘data’ as a concept is not specific enough.
Similarly, you may think about using different databases within your application for specific use cases, each of which would need its own instance and API too. Using a data service API removes some of that management component, as developers can use that API to interact with data as they want.
However, there is more to this in reality.
Consolidating APIs & data
Just looking at ‘data’ as a concept is not specific enough. In your application, you may want to offer search capabilities, or plug in other data services like event streaming. Each of these can have its own API.
If you add more APIs to cover more use cases, you still end up with a management headache to contend with.
Rather than having to manage databases, now you end up having to learn multiple APIs and how to integrate them while still having to deal with other overheads, such as query tuning and optimizations. Abstracting the database access through an API alone isn’t a solution.
What we need instead is a consolidated and cohesive approach.
API-led approach around data infrastructure
Just like with Stripe and Twilio, consolidating services down to a single API offers more benefits for developers compared to running multiple APIs at the same time. This greatly reduces the management overhead that developers should be concerned with.
It also puts the emphasis on how developers can build applications that work with data, rather than working at data.
Moving to an API-led approach around data infrastructure will help your team to be more productive and prevent the visible sprawl and management overhead that comes up alongside applications built with a modern microservices architecture.
However, you should keep that single API mantra in mind – it should keep your mind focused and free up time, rather than shift the burden.