API series - DataStax: The rise of the data services API
This is a guest post for the Computer Weekly Developer Network written by Jeff Carpenter in his capacity as engineering coach at DataStax.
DataStax is the company behind a ‘highly available’ cloud-native NoSQL data platform built on Apache Cassandra, which is a free and open source, distributed, wide column store, NoSQL database management system.
Carpenter writes as follows…
If you ask developers about what they like best about their jobs, they will say that they most enjoy the days when they can focus on coding. Solving problems. Building cool applications.
It’s doubtful you’ll hear them mention managing databases, or dealing with the other operational tasks that infrastructure components like databases require, such as backups.
The rise of DevOps was supposed to make it easier to collaborate across development and operations. However, many teams took this as an opportunity to build out tools and automate approaches based on the infrastructure that developers wanted to use. They had more choice over how things would work. Over time, this led to a ‘you built it, you run it’ mentality. Rather than freeing up developers to work on what they wanted, they ended up with more responsibility.
What does this have to do with APIs?
If you ask developers, they want to remove any impediment that stops them from developing. Data services provide an ideal opportunity to facilitate that advancement, delivering access to data through APIs instead of databases and the management overhead they require.
What does ‘APIs for data’ mean?
DataStax’s Carpenter: If you ask developers, they want to remove any impediment that stops them from developing. Data services provide an ideal opportunity to facilitate that advancement.
Adopting data services requires some shift(s) in mentality, including handing over management of any service to a third party. However, in this age of cloud and as-a-Service applications, that is something that many developers are comfortable with.
Using APIs for data access reduces the level of ongoing maintenance that developers need to perform.
For example, you can eliminate the tasks associated with installing and upgrading drivers, or relying on unsupported drivers in order to make your applications work. In addition, data services also remove the burden of maintaining your own data access or abstraction layer. Using APIs rather than direct connections like Object-Relational Mapping (ORM) removes a significant source of complexity required to just get things working as your team wants.
Another big benefit of using APIs to interact with data is that your team can use the style of API that they are most familiar with, such as REST, gRPC, or document-based.
This reduces the learning curve to get started with managing data and keeps you focused on developing the core business logic of your applications.
Data services can work together
What does this move to using APIs mean over time?
Beyond making it easier for developers to access data using their preferred APIs, this should open up more opportunities to use data in the ways that developers want.
For example, GraphQL makes it easy to request data from multiple tables in one call.
GraphQL reduces ‘overfetching’ and ‘underfetching’ common with other APIs by allowing you to retrieve the specific fields required by your application. In fact, because GraphQL can query not just multiple databases but multiple data stores, GraphQL opens up the possibility of federating data from multiple sources.
This creates new ways to interact with data and innovate within applications without increasing the management headache for developers.