Application programming interfaces are a foundational element of modern application development and service delivery.
What hasn't always been easy though is finding the right APIs to enable a given task. Among the vendors that are trying to make APIs more usable and manageable is startup RapidAPI, led by founder and CEO Iddo Gino (pictured).
APIs can be built with different web service technologies and in the past were commonly developed with SOAP or REST. However, an increasingly popular approach is to use GraphQL, to build a complex API that can deliver more information, with fewer queries.
On Jan. 22, RapidAPI announced that it is extending its API marketplace to include GraphQL.
In an interview with ITPro Today, Gino shares his views on the current state of the API market and why GraphQL is an important part of the landscape.
How did you get the idea to start RapidAPI and enter the space?
I was part of an organization called Hacking Generation Y where we were organizing hackathons around the world, mainly targeted at teenagers and students, trying to get them into software engineering and computer science in general. As part of that, we realized that if you're a developer early in your career and you want to create something in 36 hours, the only way to feasibly do that is by leveraging existing building blocks, like APIs.
So you know, developers will start using things like Sendgrid, Twilio or Stripe to create basic functionality in an application quickly. But at the same time, finding some of these APIs, or getting code snippets and examples of how to use them, was a barrier to entry, especially when we were working with more amateur developers. So, we created this repository on GitHub. Back then it was called Awesome APIs, which was just a collection of some public APIs that we thought were awesome.
That repo started getting some traction, and we got to about 5,000 stars on GitHub. We started seeing people contributing their own APIs and helping us enhance it. And we realized that we could actually start a real company behind this, and that's where we flipped into a real product.
The goal at RapidAPI remains the same: We're helping developers discover and connect to APIs more easily. Then on top of that, we added a whole layer of being able to also monitor and analyze how those API connections are performing over time, and that is what RapidAPI is today.
How do you see developers and organizations making use of application programming interfaces today?
The way we see people using APIs is really replacing a lot of what they would traditionally develop themselves. Traditionally, if you wanted to do something like payment processing, you'd have to set up a payment gateway, do a lot of coding around that, fraud protection, tokenization of the credit cards and everything. Now people are offloading a lot of that to Twilio.
In terms of the workflow or how developers are actually integrating APIs into their code, we see developers coming to RapidAPI finding the APIs they want to use, [and] copying and pasting the snippet of code in the application they are creating, usually within their IDE [integrated development environment].
We see mobile developers using Xcode or IntelliJ for Android. For people doing web development, we used to see WebStorm a lot, but lately we see more VSCode.
What challenges do developers typically face when implementing application programming interfaces?
Today, when you build an application, normally you have a few dozen APIs behind it, and all of them are runtime dependencies of the application. So, APIs are directly affecting the performance and the ability of the application to work.
So the big question when it's time to debug an application is trying to understand if something is wrong with the code or if there are the issues with the APIs.
With the RapidAPI dashboard, developers can look at all their APIs and see if there are any spikes in latency, request volumes or error rates. That information can help to identify if there is a flaw in the developer's code or if it's in an API they are using.
Where does GraphQL fit into the API landscape?
Up until now we have supported REST- and SOAP-based APIs and now the platform is adding support for GraphQL.
It's kind of been a funny journey for us because we wrote a lot of our platform about 16 months ago and back then we made the decision to actually use GraphQL ourselves. So today, when you go to RapidAPI or use any part of our products, all the communication with the back end is done through GraphQL.
In our experience, where GraphQL really shines is where you have a lot of nested or related data that you want to pull out into the UI as one packet.
For instance, if you look at our homepage on RapidAPI.com you see collections of APIs. Within each collection, we show the APIs themselves. Within an API listing, we need to show the title, the image and the username. We also show the endpoint and provide some description of what those endpoints do. So it's a lot of data.
Before GraphQL, what we needed to do is make one request to be an API endpoint that gave us the collection. Then for each collection, we needed to make another API request to get the APIs within that collection and for each API, make another API request to get the details about that API, and so on and so forth. So it's a lot of back and forth API requests.
With GraphQL, what you can do is basically say, "Bring me the collection and then within the collection, bring me the APIs, and then within the API, bring me the details." So it's kind of like a graph or relationship structure, and we're pulling all of that with one query.
