Meet Tina Huang: she’s the co-founder and CTO of Transposit, an API composition platform that makes it easy to build and deploy API-dependent applications. Having worked at tech giants Apple, Google, and Twitter, Tina has always been passionate about developer experience.

My dream job coming out of college was to work on an application framework, which I was lucky enough to experience at Apple. At Apple, we would run user studies against internal customers of our new APIs to make sure we provided a maximally flexible interface.

That desire to bring usability to APIs and developer experience has stuck with me throughout my career and I’m fortunate to have the opportunity with Transposit to spend all day thinking about APIs and developer experience.

Tina at the Austin API Summit

We’re extremely pleased to announce that Tina will be speaking at our 2019 Austin API Summit. When asked what she’d be covering, Tina explained how building and maintaining API-dependent applications can be troublesome, and how a composition platform can solve that.

We’ve all seen the power APIs can provide, but building applications on top of them can still take more time and skill than we’d really like. And not just building the first version of the application, but maintaining these applications as APIs change and evolve can create lots of unplanned work. So whether you are talking to external SaaS APIs or have a microservices architecture with lots of internal APIs, we need to simplify the model for composing all these APIs.

At Transposit we’ve been working on such a platform for the last 2 years, and I’m going to share the need for organizations to build or incorporate some sort of compositional platform in their stack to speed up development.

APIs Moving Forward

As with all of our speaker interviews, we wanted to get Tina’s take on how the API industry is developing. To kick things off, we wanted to get a feel for what design styles and principles Tina is most looking forward to in 2019. GraphQL was the obvious example, but Tina says that it’s just one example of the shift towards systemizing the development, rollout, and usage of APIs.

GraphQL is the easy answer, but that’s just one example of the trend towards machine-focused API design. Let’s look back at ancient computer history: it used to be that assembly instructions were targeted at a human audience. Every line of code that used to be written by hand, is now often generated code: from higher level languages, protocol descriptors, or even just the IDE helping us out.

APIs are moving in that same direction. We need to embrace standardization and describability as layers of compilation, encapsulation, and composition now wrap the APIs we consume. We’re heading to an era where docs just need to describe what APIs do, not how to use them. Yes, GraphQL is aligned with that, but the proliferation of Swagger and OpenAPI are even stronger indicators.

As far as cloud architecture is concerned, Tina believes that APIs are only getting more important for cloud-consuming enterprises:

The enterprises I’ve talked to look on in awe at what AWS has built with their API-first strategy and aspire to replicate that structure.

The serverless paradigm should be a guiding principle for how enterprises think about applications that compose APIs or the glue that binds APIs together to the shape of an app.

We were also curious to know how API technology could stay relevant in new and upcoming fields like IoT and artificial intelligence. With regard to IoT in particular, Tina believes that making APIs more usable will be crucial:

I think IoT has brought a whole new class of developers into the market. Developers who aren’t interested in building complex distributed systems, but are really interested in integrating various devices with existing services. So platforms that lower the barrier to entry for these developers will be key.

Finally, we asked for Tina’s thoughts on the API economy overall. A decade from now, Tina thinks integration will be the rule, not the exception.

20 years ago everything you cared about was in a relational database. 10 years ago an “integration” application was an esoteric backwater. With the proliferation of APIs and the fragmentation of services, it’s common to see applications talking to 5–10 APIs.

10 years from now the term “integration” will be anachronistic — every application of any interest will be an integration application. The number of APIs that exist and the demand to see more data reflected in the applications and services we build are both on escape velocity.

API Best Practices

Moving on to some API tips and tricks, we quizzed Tina on how we could build APIs with better developer experiences and better security measures.

For developer experience, Tina believes that documentation should be secondary to an intuitive, self-explanatory product:

The easy answer is docs, but that’s also the wrong answer: the best documentation is the documentation you don’t have to read. Developers love interfaces that let them engage and experiment interactively, that self-describe without needing to flip to the docs. Great APIs anticipate interaction, and have errors that guide the developer without leaving them guessing at the problem.

As for API security, Tina relates her passion for API composition solutions to an overarching need for layered design. It’s these layers, especially gateways, which make developers’ lives easier and improve security concurrently:

Our world of APIs has become tightly coupled, but loosely governed: changes in one API, service or application can have unexpected consequences on the downstream consumer whose dependency is invisible. This problem is even more acute when it comes to security lapses (and a strategy to never have a security problem is not a strategy). When an application is breached, we scurry around to find the impacted systems. When a system of record is breached, we scurry around to discover the impacted applications and users.

API strategies will need to include gateways or composition layers that add value and speed for developers while building a more secure and audit-able infrastructure.

Meet Tina in Austin!

That just about brings our interview with Tina to a close! But first, let’s get to know her favorite “useless” API…

My favorite has to be the dog API that fetches images of random dogs. I liked it so much I based our Transposit quickstart off of it, making it super for anyone to brighten their slack days with a random dog pic.

If you’d like to meet Tina in-person, you’ll be glad to know that she’d like to meet you too! Tina is looking forward to meeting fellow API-kin at the Austin API Summit, and we can only hope you’ll be there!

These are my people. I think about APIs morning, noon, and night. I have for my whole career. It takes an API nerd to appreciate an API nerd.