So I decided to mess around with GPT-3 the other day. I typed in APIs are, and here's an excerpt of what I got back:
The lack of standards makes it difficult to provide users with consistent experiences.
sighs Even artificial intelligence gets it. APIs are tough to use because they're not consistent.
That's not to say nobody has tried.
The first APIs used XML as a data transmission system, which gave it some semblance of structure. Later on we came up with REST, and that worked for a while, but it got a bit out of hand.
There are some logical issues with REST. For example, think about Stripe's API (one of my favorites). They expose the ability to retrieve both one customer as well as a list of customers. How should Stripe handle this? Should the API expose two endpoints, /customer and /customers? Should the API use two different HTTP methods? Should they use a GET parameter to tell the difference? Should it just always return a list and force the client to sort through the data if they only want one customer? Should there be something in the headers to signify what the client is asking for? There's really no ideal answer, so most API makers handle cases like this differently.
GraphQL is the latest big attempt to resolve this issue, and it does a fantastic job. Just in case you're not up to date on GraphQL, it's a standard by which we send a single endpoint a JSON-like object without values, and then the server fills in the values and returns proper JSON. You get to request whatever data you want, and only as much as you want, as opposed to a REST query where you often ask for a haiku and get served War and Peace. There's just one problem: practically nobody uses it. If you zoom out a bit and look at the whole API landscape, it seems that many of the APIs we'd actually want to use regularly don't have GraphQL endpoints. That's a real bummer, because it would drastically improve the developer experience on so many existing APIs.
My background in development
But that's not what this article is about! It's called "The Quest for a Single API", a tale of my frustration with acquiescence to the inconsistencies of the API world and my mission to find a better way. And let's be honest, if I hadn't found a better way, I wouldn't be writing this article. But as all good storytelling questors must, I'll jump back to the beginning for you:
Back in 2018, I started development on a project called Sidus, a social media app meant to work in schools and as a general education platform. I was cyberschooled, and I always felt like there needed to be something to fill that social aspect of the typical brick-and-mortar school in a virtual setting. The team I helped assemble — made up of my classmates and a faculty member or two — seemed invincible. There were two developers (including myself) and three graphic designers; things were chugging along smoothly after we worked out some kinks in our team workflow. Before long, the other dev and I ran into a speed bump though. We were trying to fetch data from datasources like an external Redis DB, an external Postgres Db, as well as interacting with the Google APIs. This started to get a bit unwieldy because we'd have the same code repeated over and over again in different functions and files, and we'd be repeatedly reaching deep into nested returned objects trying to pull a single string out of that mess. Eventually, the other developer burned out, which caused me to take on his half of the work, which meant that development stalled out while I tried to sell the product to the potential clients (spoiler alert, this didn't happen) and find new developers to help out with the project. While I was scrambling, the designers found fewer and fewer things to do, and eventually the half-baked project was left solely in my hands and without any customers.
In 2019, I decided to repurpose the app into something more Intercom-ish, which turned out as a flop as well. I was also taking webdev college courses at the time and dabbling in a lot of APIs. Between the Sidus-clone and the college coursework, my day job as a PHP developer and yet another hobby project, I was burnt out on APIs. At one point I was dreaming about a specific API problem I was facing, and then realized that I was dreaming about using the wrong API for the task. It was terrible. But that Sidus app turned me onto a new idea: what if I could build my API so that you could ask it for a specific set of type-validated data? I actually created a whole framework to do this... and then somebody told me I had reinvented GraphQL.
One of my college courses required that I build a website for a local non-profit (which ended up not wanting the free website, so that was a blow), and I needed a CMS for it. Before long, I had come across TakeShape CMS and incorporated it into the site. I found the GUI uniquely intuitive and powerful.
So now I've got the main ingredients here: a newfound passion for GraphQL and a burdening panoply of necessary APIs. That, and the solution had been dropped right in my lap in the form of TakeShape's API Mesh technology. They invented this concept where you plug all of your existing APIs (including REST and GraphQL) into a single tool, called a mesh. I like to think of it like a phone operator's switchboard, where they can plug all the lines in and create a group call so a single caller can hear all the others all at once. That's kinda what the API mesh is doing: merging all your API "callers" into a single line so that you don't have to call them all separately. Genius, right?
And there it was: my single API. Every API I wanted to use, combined into one, ready for me to build whatever crazy idea-de-jour popped into my head.
My journey into developer relations
One day — specifically March 3, 2021 — the idea-de-jour was to peruse AngelList (a job listing site for startups), find a company whose product I could really get behind, and apply to become their developer advocate. I'd make a living helping other devs learn about something that improved my life as a dev! "How wonderful that would be", I thought. And lo and behold, look what popped up on my AngelList feed:
Well, what a coincidence.
The concept that served as the destination of a multi-year quest, the culmination of my first journey as a developer, needed a mascot. The disabled "Apply" button probably spoiled the ending, but I was so excited to hear about this opportunity that I almost broke my trackpad trying to click it. Soon enough, the awesome Mark Catalano, CEO of TakeShape, reached out to me and we set up some interviews. By May, I was hired and setting up the first Jamstack Philly event.
That's my story! That's my quest for a single API to rule all the others. That's my journey into developer advocacy. That's how I got from just some 15-year-old kid in high school trying to get a handle on Stripe to some 18-year-old kid repping the next big thing in web development. And get this: the job posting is still up! So if you want to join me at TakeShape and help us get the API mesh out there into the world, check out the Careers page on our website.