[0:00:01] ANNOUNCER: If you're a developer, you've probably worked with an API, or application programming interface. An API is a set of rules for how to communicate with an application or device. For example, when you build an app and want to use Stripe to handle payments, or use Slack to deliver notifications, it's APIs that make this possible. Handling communication between different applications was historically challenging, but with the growth of cloud computing and the need for smooth interoperability, APIs have become standard and are now often considered essential to make a company accessible and visible.

The growth of APIs is about to accelerate even more because of generative AI. The reason is that good APIs will be needed so AIs can write code to stitch together multiple systems. Postman is a popular application and platform for building and using APIs, and they recently released their 2023 State of the API report. Joyce Lin is the Head of Developer Relations at Postman, and she joins the show today to talk about the history of APIs, why APIs have exploded in popularity and what the future looks like.

This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[INTERVIEW]

[0:01:28] SF: Joyce, welcome to the show.

[0:01:29] JL: Hi, thank you. It's great to be here.

[0:01:31] SF: Awesome. Well, it's good to see you again. Thanks so much for being here. Let's first have you introduce yourself. Who are you? What do you do and how'd you get to where you are today?

[0:01:39] JL: Well, it's very nice to be here. My name is Joyce Lin. I work in developer relations at Postman. I think you're familiar with Postman, right, Sean?

[0:01:46] SF: Yes, of course.

[0:01:47] JL: Yeah, it's an API platform, huge developer base. I'm happy to talk about anything API related, or just general broad developer related.

[0:01:55] SF: Awesome. Yeah. We're going to take a bit of a deep dive into APIs today, a little bit of history, a little bit of some of the new API trends that are going around. I think a good place to start would be going back in time a little bit. The concept of an API has been around for a long, a long time. I think, even when I was doing some research for this, getting ahead of the types of things that we want to talk about, I was actually surprised that the whole concept of an API was actually born in the 1950s. It was a just conceptual thing. It was this idea of facilitating communication between two computers, which is essentially what you're doing with an API today.

A lot of times, I think when we think about APIs, we're thinking about either the web, or maybe cloud. If we look at primarily the focus of web APIs, something that we think of as the modern API, where did all that type of thinking and technology begin?

[0:02:48] JL: That's interesting. I was just recording another TikTok and talking about the very first modern web API. You were talking about the 1950s. It was much later than that. I'll let you guess to see if you can guess what year the first modern API was introduced. Do you have remotely any guesses?

[0:03:05] SF: I'll say, 2000.

[0:03:07] JL: Very good guess. Yes. 2000 is when the principles of REST was introduced. Before that, APIs had been around for a really long time. In my TikTok, I was like, “The first modern web API.” Somebody's, “Well, actually, RPC calls have been around for a really long time.” Indeed, they have. Programming language APIs. But when you're talking about web APIs, and specifically, you're talking about HTTP, or REST APIs, yeah, 2000. Very good guess.

[0:03:34] SF: Yeah. I remember even in the early days of my engineering, RPC was something that we would do in order to connect two different types of programming languages together. It's like, how do I make Java call a library that was written in C++, or something like that? We had very rudimentary tools available to us at that point. Obviously, we've come a long way since then.

I think everybody has a different perspective on maybe what even constitutes a web API, or something like that. That's probably where you get into these debates of like – the person's like, “Actually, this actually started 20 years ago, because this type of technology was introduced in, I don't know, 1979. It led to this and this and this and this.” It's a gray area in a lot of ways in terms of the definitive timeline for some of this stuff.

[0:04:19] JL: You're remarking that, wow, we've had APIs for a bazillion years. It's been around for so long. I'm looking at some of the dates for these really popular modern style APIs. I mean, maybe dating myself, but it doesn't seem like so long ago when we're introducing some of these newfangled technologies. Then to see the amount of adoption they've gained, I think it's happened really fast.

[0:04:42] SF: Yeah, absolutely. Going back, though, to the early days of web APIs around 2000, what were the technologies that were available to people building APIs back then?

[0:04:53] JL: Yeah. You were talking about remote procedure calls. There've been a bunch of other, I think, service-oriented architecture was big around then. Roy Fielding introduced REST principles, running on HTTP. I think that really captured the minds of a lot of people, because it was about reducing complexity, right, which was different from some of the other protocols that were going around. Then also, just it being standardized, so that any machine can talk to any machine in the world.

[0:05:22] SF: Yeah. I think REST didn't really come on my radar until much, much later than those original papers. I think it was his PhD work, or something like that, that REST came out of originally. I probably didn't actually register it until like, I don't know, the late aughts of 2009, or something like that, 2008 or something like that, when I started to consume APIs that were JSON-based and REST API-based.

Before that, a lot of the early days of what I was dealing with, and I'm sure many people that were doing engineering in the early 2000s, like XML, soap-based, these really gross interfaces to try to interact with, they were just cumbersome to try to deal with. Then you were always doing a lot of work to transpose some of those, like the object structure defined in XML into something that could be actually an object in whatever your programming language of choice was.

You mentioned the idea that one of the reasons REST caught on and was interesting was the simplicity of it. Can you maybe give a little bit of background of what some of those principles were that led to REST being something that someone saw as simple and something that was actually innovative?

[0:06:39] JL: Yeah. I mean, if you've ever seen – I wish we could do screenshots here, but if you can just put up a snapshot of what XML looks like, versus what an endpoint looks like for REST, I think you mentioned JSON. JSON was a quick follow after REST was introduced. Just even picture in your mind's eye what JSON looks like, it's machine readable, yes, but it's also very human readable. Then also, just understanding how the REST API is structured, the way the paths are formed and to access the different resources, I think is also very intuitive and human readable. I think that's part of the reason why it really took off.

It was also timing of when the Internet was starting to become a lot more popular, third-party APIs. If you need a standardized protocol that you're not just talking about within your team, or with one or two other major agencies, or companies that you're working with, if you're just talking about third-party developers, I think that's another reason why REST took off, just because of the timing.

[0:07:39] SF: Yeah. I think that also as a secondary impact thing was that the languages that made it easier to essentially work with things like JSON and also work with REST APIs, they caught on and became more popular languages, and some of the languages that were harder to map to, like a JSON structure, or to the way that the REST is set up to essentially allow you to get list, delete, these types of things. If that was cumbersome, then it was like, well, why should I continue to use this language, versus this other language that's just set up where it feels like a native thing?

[0:08:13] JL: You were alive and kicking around this time. I didn't realize that. But I had to do research. I wasn't in technology at the time. I had to do research. I worked with SOAP. I've worked with XML. CORBA. Have you worked with CORBA? Yeah. I don't know if they were perceived as complex at the time, but just in comparison, REST APIs was a lot more simple. then a lot more people were getting into the field, obviously due to demand.

[0:08:41] SF: Yeah, I mean, I think that that was what was available at the times. Even then, from my own perspective, I was a college student working with some of those early form, SOAP and WSDL files and all this stuff. It was really cool that you could make these different applications talk together, but it was also very brittle and rigid and hard to work with, which just added a lot of friction and pain to the whole thing.

I think when you have friction and pain, a lot of times, people look for ways of getting around it and circumventing it, or they just don't adopt it and they do something else instead, which becomes a barrier of essentially, scale.

[0:09:17] JL: I mean, I was thinking about that you were saying, it's like, I don't know the word, but it's like, you were talking about it being brittle and the whole concept of REST is so that any server could talk to any other server in the world. You're essentially decoupled everything, right? Then it's a lot more scalable, then you can draw a lot more – connect a lot more dots.

[0:09:34] SF: Yeah. Another fairly early type of innovation in web APIs was protobufs that you came out of Google. I worked for Google for a number of years. During my time there, everything has basically started with a proto. That's the form of every edge design work that you're doing. It seems like, my protobufs hasn't been something that's caught on the same way that something like REST has. I guess, what is the difference and value of the protobuf from your understanding and why hasn't it maybe caught on more widely?

[0:10:10] JL: Yeah. I found this out during research, but protobuf was introduced early, early on. It hasn't come across my radar until more recently when distributed systems have become a lot more popular, but I think it was 2001. Introduced the same year JSON was introduced, right? Why did protobuf went over Jason potentially? Again, in your mind's eye, picture what JSON looks like. Protobuf is a little bit more complex, a little bit more of a learning curve, and it was precisely better for reasons that shouldn't become really in demand until probably a few years later. Really complex distributed systems, microservices, a lot more of those at scale systems where efficiency, performance, all of that is a lot more important.

Then now it's becoming a little bit more popular, but even still, it has some headwinds, right? We're talking about Google inventing it, because Google has those problems, but not every startup is going to have those problems. It's like, how much tooling do you have that support HTTP, too? I'm talking about GRPC now. Yeah.

[0:11:13] SF: Yeah. I think, and this is 20 years ago at this point. The scale problems that Google was having back then, very few companies in the world, if any, were reaching that level of scale back then. They had to invent a lot of the tools and technologies that actually allow them to meet that scale and meet that demand. I guess, protobuf and GRPC and these types of technologies came along with that.

Now, if you're essentially building a startup today, that even if you had not necessarily scales of Google challenges, but you still have scale problems, a lot has happened in terms of technology innovation that's available to you today to reach the scale demands that weren't available 20 years ago. Your only solution might not be, or your optimization might not be to go to protobuff and GRPC. You might be able to stick with JSON and REST and then scale in other ways by scaling horizontally, or vertically across the public cloud with servers and so forth.

[0:12:09] JL: I'd have to look up the actual market adoption. There's a ton of interest. Any developer that hears this, I think the stat is that GRPC is seven to 10 times faster than REST. Ooh, so cool. Let me look it up. But the adoption is still in the low, I want to say, low tens of percentages. It's just like, not everyone wants to overthrow their system and implement that new technology, but it's also tough in finding people that know GRPC well, and all the systems and processes in place for it is the second question that you need to answer.

[0:12:41] SF: Yeah, when I was looking at the state of API's report from this year from Postman, I think it said that nearly 60% of respondents in 2023 had never heard of protobuf. That's a pretty big group of people who are interested enough in APIs to be responding to a survey that Postman puts out about APIs that hasn't heard of protobuf.

[0:13:02] JL: Yeah. But when they do, they are interested. But then, even still, they're not adopting it, except for maybe some POC, right?

[0:13:09] SF: Then what about GraphQL, which came out of Meta? I mean, they essentially were in a similar place where they were hitting scale issues well beyond what most companies could even imagine. They had to innovate and create something new there and it came out with GraphQL. Can you talk a little bit about essentially, the differences between GraphQL, and some of these other technologies that we've been talking about? Then what was the problem that we're trying to address with that?

[0:13:33] JL: If you compare GraphQL to let's just say, REST APIs, you're talking about with REST APIs, you're over-fetching, under-fetching, it's just part of traversing different endpoints together, what you need assembling it on the client side. GraphQL is a client's proposed way of retrieving that data. I think, if I'm not mistaken, Meta created GraphQL because of their mobile apps, right? If you can minimize the number round trips required to have somebody pleasantly scrolling on the mobile apps, then that's going to be a lot more performance. Sounds great in theory, but what a lot of public APIs ended up doing was building GraphQL wrappers around their HTTP APIs, right?

Then, you actually have a more pleasant developer experience, but you don't have any performance benefits, at least not on the tail in it. Then, I saw a bunch of larger companies build GraphQL into their data layer, just for internal tools, right? So, you can have a lot of the enhancements and benefits there, but maybe we didn't get the large scale adoption at least on the public API side.

[0:14:37] SF: Are there certain types of applications, or APIs that are better suited for GraphQL?

[0:14:42] JL: I don't know. I mean, anything that requires jumping, many jumps across many types of data.

[0:14:49] SF: Yeah. I would imagine, also, essentially, a few, the variants and the type of information that you need about object changes, then GraphQL is probably a good fit there. If some instances you only need two out of a 100 fields to describe some object versus other instances where you need 25, then you want to have – you don't want to create a unique endpoint and REST for every – to pull all those different variations versus using some learning GraphQL, where you can specify which parts of the object I want to return.

[0:15:17] JL: Well, if you do want to learn a little bit more about GraphQL and GRPC protocol shout outs, both of those summits are coming up, I think in the next, maybe this month, in the Bay Area.

[0:15:28] SF: Okay, good to know. We are in the midst of event season, so there's events going.

[0:15:32] JL: Yeah. Well, GraphQL, huge summit, and GRPC. I think there's only one or two conferences in the world dedicated to GRPC. Yeah, definitely don't miss it if you're interested.

[0:15:42] SF: No, cool. Yes. Still taking a look at the last 20 years of this history around web APIs, what were some of the other technologies that came along besides the things that we've already talked about?

[0:15:55] JL: This is like asking, what's new in tech, Joyce? In your opinion, in the last 20 years, what's new in tech? We could talk about web3, we could talk about web4, we could talk about IoT. IoT is sweeping. It's on my mind right now, because there's other protocols that are very IoT specific. Let's narrow down the query a little bit more. Or you tell me something that's interesting to you.

[0:16:17] SF: For example, OpenAPI.

[0:16:19] JL: Yeah. OpenAPI has been very popular, probably over the last, let's just say, three to five years. People are interested in this. I would say, anybody who wants interoperability with partner agencies, or partner companies, or they're operating APIs at scale are probably already using OpenAPI as a standard for their API design and development. There's a whole host of people also using OpenAPI to auto-generate things, like mock, docs, just tests. They're using it to auto generate, and so they're backing into OpenAPI, but it's an open source standard that some of the big companies came together and said, “Hey, we need more interoperability.”

We're talking about REST being a really good way to be interoperable, but it's not super opinionated. There's the principles of REST that you can implement at any way you want. Within the company, as well as when you're operating with other components, or other APIs, OpenAPI is a way to really iron out those interfaces.

[0:17:21] SF: Then, what about, in terms of the things that were happening in industry that led to this explosion of APIs, now there's all these, essentially, there's software is eating the world, and then now we're in the world of Gen AI, but maybe somewhere in between there. APIs were eating the world to some degree. There's been this huge transformation in the last 15 years where every company in tech has become an API company to some degree. What were some of the things that led to this world where everybody was essentially building APIs?

[0:17:54] JL: Well, back when I started getting into tech, and this was many, many years after you, Sean, but there were phones, right? Mobile was becoming a big thing. Social, there was a bunch of new companies. Right when, let's see, when was the first tech boom? In the early 2000s?

[0:18:12] SF: Yeah, late 90s, early 2000s.

[0:18:14] JL: I mean, there was a huge revolution, right? When people are talking about digital transformation, one is accessibility of data, but one was being able to accommodate all of these devices, these new devices. Then cloud, even a short eight years ago, I was talking to people and they were like, “I don't know. I don't know if we can be on one of the major cloud providers, because it's not allowed at my company, but now everyone and their mother is on a major cloud.”

We've had regulatory pushes, right? GDPR in Europe saying like, you need to make this information accessible. Open banking saying, you need to make this accessible to other parties. I feel like, it's just getting faster and faster. AI, you brought up open API, right? OpenAI's way to create a new plugin is through an open API. I'm saying a lot of words there, but I mean, all large language models, when they're discovering new information, it's through API. If you do not have an API, you are invisible to LLMS.

Everything that's hitting tech is just creating more and more demand for you to have an API. If you don't have an API, I think that's where it's really troublesome for your company, or your organization, or your project.

[0:19:27] SF: Yeah. I think if we look at something like, OpenAI and essentially, how much that's become part of the zeitgeist and essentially, like my tighter Twitter feed is basically generative AI all of these days. I think a big part of that, and there's a lot of things that went into their success and why it caught fire. A big part of that is the fact that they have an easy-to-use, consumable API that then allowed all kinds of people that work in engineering to essentially build all kinds of cool, creative applications that served different types of needs leveraging AI technologies. Those became, essentially, the front end for this big movement in AI that we're seeing.

[0:20:06] JL: Yeah. I think the latest data, the API report from Postman, the one that just launched, I think just published a month or so ago, is talking about the API revenue, right? I'm seeing a shift now where people are feeling like, “I need to have an API, so that we can address the people, the partners that want something, but we're not ready to offer it yet. Here's an API so that you can build your things.” Like, holding things off and it's a layer on top of a larger system.

Some companies are launching as API-only, right? The only thing they offer is an API. Then becoming huge honking companies that are only API. Now, it's like, people are hiring API product managers. That's a new title now, where if you're at an established company, it's really hard to change your way to think about that API, because it used to be just an ad hoc last-minute thing that somebody thought about, “Oh, is this functionality available through API, too?” Now it's just, let's think about the business strategy of our API and how much money you can make off it? How much value you can add to your users.

[0:21:08] SF: Yeah. I think it also introduces new types of product challenges, where if you're a product manager building a product that has a front-end application and you change the button, or I don’t know, the menu item name from A to B, you're not breaking anyone's experiences. They can still click on B. But if you change an API endpoint from A to B, then everybody who's adopted the API, you basically broke their usage of that API. Then you have to think about breaking changes, how do you handle that, what's the deprecation cycle, all of this type of stuff that is new that people hadn't really experienced as product managers and as organizations before.

[0:21:46] JL: This is super relevant timely. We just saw that with Twitter API. We just saw that with Reddit API. Twitter, for sure, they deprecated it so quickly within 30 days. Entire organizations, like functioning companies with multiple employees had the sunset within 30 days. That's shocking that level of deprecating something that companies and partners have come to rely on.

[0:22:10] SF: Yeah, in the early days of Google Cloud, I think one of the areas that everybody really struggled with was breaking changes on their APIs. They've had to really change the way that they think about building APIs for enterprise customers and people consuming it, because you can't just go and rip out whole APIs and expect people to change in 30 days that are massive organizations that have a product roadmap that maybe is already set out for six to 12 months. That is very, very disruptive.

I think that's the mindset change when it comes to building API-first companies, or thinking about API as a product is you have to understand what is the impact of these changes on your customers and understand that the API itself is essentially the product that you're delivering.

[0:22:53] JL: Then, I mean, that's one side of things. Then the other side is like, I think I talked to Stripe. Stripe has a publicly stated policy, where they won't deprecate any endpoint. They're supporting stuff for at least a decade after it's really been not really in use internally anymore. Where is the right way to do things from a developer experience standpoint? Certainly, it's not 30 days and it's probably not super feasible for every organization to support things for decades on end indefinitely.

[0:23:23] SF: Yeah, and that's the Microsoft problem. If you look at old versions of Windows, they basically – each version of Windows is a build on the prior version of a window and they wanted to essentially have backward compatibility with all these super old machines. Then you have Apple on the flip side where they were willing to essentially, break backwards compatibility in the spirit of innovation and creating a better experience. There's always this trade off, like you’re saying.

[0:23:48] JL: Tension. Yeah.

[0:23:48] SF: Yeah, tension, where it's essentially supporting, old systems can be a barrier of innovation, eventually lead to a lot of confusion and essentially, tech debt that you're holding on to as an organization. You also don't want to essentially, make people really angry, because you're ripping and pulling things out all the time in the spirit of innovation.

In terms of API adoption, it's certainly like a global phenomenon, but is it something that you see more popular in certain parts of the world? Are people in, for example, Europe where you have things like GDPR focused on certain aspects of pushing API standards? Or is there, essentially, cultural difference in terms of how people think about APIs?

[0:24:30] JL: That's an interesting question, and at a super high level. Let's circle in on what the true answer should be. At a super high level, APIs are used globally, or at least anywhere where there's connectivity, right? If you have data, Internet, you are consuming APIs for sure. If you have consumers that are consuming, then you're probably producing as well. There's different types of APIs that I see like, of course, say you're in an underserved area. Say, there aren't a lot of banks. I have finance on the brain right now, like microfinance, right? Microfinance does not exist for the most part in the US, but it exists in underserved countries, where there aren't brick and mortar, like banks, let's say. You see a new flavor of microfinance APIs cracking on.

As far as volume, I don't see a volume difference. I see a difference in people willing to pay for APIs, price sensitivity, but that's to be expected. Consumption and production, I don't see regional trends.

[0:25:32] SF: We talked a little bit about the, or mentioned a couple times, the state of the API report, and there's a new one that came out a couple months ago. What are some of the most popular third-party APIs that exist right now? How has that changed over time?

[0:25:47] JL: I don't know if we published this in the state of the API, but there's another list that we published that got a lot of attention. Let me see if I can find it really quick. Off the top of my head, I know Salesforce is number one. I know very popular, you already mentioned Microsoft. Microsoft has a whole suite of tools. They have a graph API that connects everything together. Notion. Notion is super popular in terms of consumer adoption, but also, wanting to hack it, right? Wanting to build automations, or little bots.

[0:26:17] SF: That must be something that's a newer one than if you look five years ago. Notion probably wasn't on that list, but Salesforce was.

[0:26:24] JL: Yeah. That's an interesting way to put it, where Salesforce probably had an accumulated developer community, whereas Notion was converts from consumer to developer. Then I think types of APIs, the communication, any messaging API is really popular, because of the things that you can build, like super easy notifications and automations.

[0:26:47] SF: Right. Yeah, things like Twilio API, for example. In the 2022 report, it said that developers are spending most of their time on APIs. With all the development that's happening in generative AI space right now, where there's a lot of innovation that's actually happening in developer workflows, like with code assistants and SDK generators, bug identifiers, documentation, all this stuff that's going on. How do you think that this might impact the time that developers are spending on APIs, if essentially, we’re able to create tools that can auto-generate some of this stuff, or do other types of – take off some of that work that a developer is normally going to be doing in terms of building and designing APIs?

[0:27:28] JL: That's an interesting stat. I think it's more than 50% of your developer time is spent on APIs. That's been the case year over year. It's actually only grown. You're thinking about productivity tools and being able to take some of that off the developer's plate. Again, that number is only growing. I think it's very similar to, you were talking about generative AI and prompt engineer becoming a new field. I think it's going to take the types of manual, repetitive, head-bashing work off of your plate. I'm not sure if it'll take overall amount of time off your plate. I think it will change what you're doing.

You'll probably, hopefully, spend less time debugging, reading through documentation. You'll have NLP prompts that then generate something and then you'll be tweaking it here and there. But you'll still be working on the APIs.

[0:28:18] SF: Yeah. I guess, it'll change the nature of the API work. Maybe you have a little bit more time to think about the design and maybe even efficiency, or scale, or these are more complex challenges that require deeper level expertise than essentially, doing the road work around debugging and maybe setting these writing tests and automating tests and integrating into a CICD pipeline and all this stuff.

[0:28:42] JL: Yeah. We've already seen some of those cool tools that you're talking about, like just auto-generating documentation, right? You're going to have the metadata, but is the metadata in a very consistent format going to be enough to enable the developer to get done what they want to get done? I mean, I brought a prompt engineer, because it's what made me think of it. Prompt engineering is super hot right now, but you still need to know how the underlying tech works to have really good prompts.

A lot of people think that prompt engineering is only a finite lifespan of being a prompt engineer before something else new is going to usurp that. Just understanding how systems work and the things, the levers that you can tweak is really going to be where it’s at. Then so, if everyone can level up, then you're still spending the same amount of time working, but you're working on stuff that hopefully, is more enjoyable.

[0:29:31] SF: How else do you think that generative AI might impact API development, or the API space?

[0:29:37] JL: I mean, like what I was saying, natural language processing, like Postman is launching into – every company is hopefully, hopefully you've already looked into it at least in thinking about how generative AI can help you do your job better. We're talking about open API being a very machine readable format to understand the guts of this service and understand the guts out of this service and being able to glue them together. Postman is taking two major trends. One is low code, and one is generative AI and smashing them together.

If we can say like, “Hmm, let's take that Twilio API and notify myself when this happens with my bank account, or something,” and just being able to imagine it and then have it happen and then being able to deploy it on a cloud somewhere, you've written what would have taken a developer X amount of hours a month ago.

[0:30:30] SF: Right. Yeah. A lot of it could be the stitching work that we tend to do as developers of stitching this API together with this API and then transposing data and presumably creating some UI to that. Essentially, we might be able to just describe what we need of like, “Hey, I want to send a message to Twilio, and then I want to send a response over to this thing. Then let's have them go through Stripe payment.” But then you need to know the landscape of essentially, the technologies that are available to you and how those workflows would go together. It doesn't take away, essentially, the knowledge that you need. It just takes away some of the rote work of, essentially, pushing and pulling data.

[0:31:06] JL: I think there's still some work to be done, because it's not like we haven't had tools that allow us to do something like that in some fashion, or another. We've had the Zapiers. We've had the ifs. If you knew about these two platforms and you were able to glue them together with a simple like, if then statement, how come more non-developers – I think those platforms are being used extensively by developers, or people that even have a little bit of knowledge, but the lay people aren't using those platforms. Why is that?

[0:31:33] SF: Yeah. I think you see the same thing with a lot of the no code types of tools that there's – back when I was a researcher, there's a lot of people that spent time trying to have, essentially, this vision that anybody would be able to program applications. There is some of that. I think, even going back 10-plus years ago, there are AI systems out there that exist to generate a website based on some non-technical description of what you need.

What ends up happening with a lot of those systems is that what they generate is maybe good as a proof of concept, or as a demo, but then the amount of work that it takes to customize it takes real engineering work to get it to something that's a real product, or even a real web page that's going to serve your business.

[0:32:18] JL: Yeah. In the short term, I mean, if it can get you that proof of concept super quick, and then you can iterate on it before passing it off to a more experienced developer, I think that's even exciting on its own.

[0:32:29] SF: Yeah, exactly. Even if you take it as the analogy of like, writing content, it's much easier to edit content than the essentially, create from scratch. I would say the same thing could apply to some forms of engineering is if you can essentially start with something, some base representation of what you need, then someone who's more experienced can come along and massage it into something that's going to work.

[0:32:50] JL: All of this is happening too fast. I cannot keep up. People are so entrepreneurial in hopping on this trend that it is, I mean, gosh, it's – I'm sure every single one of your podcasts is touches on this at some point, or another, but it's just chilling.

[0:33:06] SF: Yeah. It really reminds me of the explosion of we've already mentioned how much older and drizzled I am in my time working in industry, but it reminds me of the early days of the Internet, where there was just such an explosion of all these. Now, that was moving at a glacial speed, I think in comparison to what we're seeing in gen AI. But in terms of just every company in the world being interested, or fearing this thing, it's just, everybody is thinking about what is my AI strategy, or I don't even know what this thing is, but I know I need to be on it. Everybody's essentially consumed by this at this point.

[0:33:42] JL: Yeah. I think ChatGPT, oh, I'm going to misquote this stat, but they got to a million users in five days, as being the quickest adoption ever for any technological platform. You're comparing the growth of generative AI to the initial growth of the Internet, where it really captured the imagination of the individual users. But not everyone had a phone, not everyone had a computer, Internet service. Now, the infrastructure is all laid out there, we're already using the tools we want. Now we can just layer on generative AI into the tools that we're already using with the infrastructure that we already have built.

[0:34:19] SF: Yeah, exactly. We're set up for, essentially, this scale that – and even things like social media –

[0:34:23] JL: The singularity. Just kidding. Just kidding.

[0:34:26] SF: Even things like social media didn't exist for the spread of awareness of these things 15 years ago, like they do today. Outside of the gen AI space, are there other - what's going on in terms of API technology innovation? Is REST and JSON still leading the way out there?

[0:34:43] JL: Oh, heck, yes. I think anytime there's – I mean, it's the difference between Greenfield and Brownfield, right? Startups will be able to innovate so much faster than huge honking companies. There's too much tech debt for them to spend on a dime. Even if they were to scrap everything and immediately transition, first of all, there's no way they could do that. REST is still the top format when it comes to API communication. Well, I talked about other protocols for IoT, right? do you have a wearable on you at this point in time? Do you have a digital assistant right now?

Connected homes and all those protocols, I think, are pretty interesting. It's very different.

If you're in an enterprise IoT development team, you're going to be talking, like maybe you don't even know about REST, right? Maybe you don't even know about the types of web APIs that we're talking about. It's very, very different. Your workflow is different. Your tool chain is different.

[0:35:38] SF: I see. Yeah. I guess, the types of tools and support that you need working with those systems is going to be drastically different than like you mentioned, the tool chain that as a web developer, or web API developer would be working with.

[0:35:51] JL: Yeah. I think there's trends that I don't want to even – I mean, I will mention them just because I can't – I'm just thinking through all the different stuff that's impacting, but these are trends that have been around for 15, 20 years. I feel dumb saying it, but quality, security, developer experience, developer experience is like a little bit of a hot new term, but really, people have been talking about it for 15, 20 years. Now it's just, people are realizing the value and the detriment when they don't have a good developer experience and competitions getting tougher, because everyone has an API now.

APIs are actually a differentiator in the market now. If you're not talking about API only, like if you have an API that can, again, finance is on my brain, but A, if you have an API, A, if it talks JSON, or you can send JSON, amazing. Kudos. But again, some of these large legacy companies cannot turn on a dime.

[0:36:45] SF: Yeah, I think we're seeing that, certainly in the banking space, for example. I saw headline the other day from 2017, which was JP Morgan's declaration that the public cloud is a thing and they were going to start to move workloads to the public cloud. That was five, six years ago now. I'm sure, they probably run a hybrid infrastructure of some on-prem and some on the cloud, but it took them five-plus years to catch up to what startups were doing. That's because, just the nature of a large company, it takes a while to catch up to these innovations that happen. There's also more risk to taking big bets and essentially, adopting something that may or may not be successful.

[0:37:25] JL: That's another area that you'll see regional differences. Some countries will, I mean, I'm just thinking of France. France for a really long time didn't allow you to keep data that wasn't in France, right? Does the cloud provider you're using have a major data center in France? Great. If not, can't even consider you. Then other underserved regions might be starting from scratch. They haven't had to worry about the legacy concerns that you're mentioning, Sean. They're moving so much faster than some of these other very established regions.

[0:37:58] SF: Right. Yeah. If you're operating in Europe and you might have to navigate some challenges around GDPR, or data residency requirements, and that could, essentially, impact your speed of innovation if you don't know how to navigate those different things. In terms of API adoption success, so we've talked a little bit about some of these companies that are successful, the idea of having an API first that is using, essentially, mainstream technologies. But what are some of the things that you're seeing successful companies do when it comes to APIs that perhaps, less successful companies in the space aren't doing?

[0:38:31] JL: One thing that comes to mind is API first. Unfortunately, I've used it differently, and you just said it. I just want to clarify API first. I'm talking about API first design and development, not having an API first necessarily. That's a very ambiguous term that I just used that is being interpreted very differently by successful and less than successful organizations. That is something that if you can get that done right, that will help you scale so much faster.

I'm talking about things, like having some standardized schema, like OpenAPI, or whatever you're choosing to use to set guidelines and to allow interoperability between your services. Another one of the major trends, microservices, right? Or just being able to be composable in your organization. Then, how much consistency and interoperability do you have while maintaining consistency? Or are you just spinning up double services, which I know is a strategy for some large organizations? They don't care what you have out there. Just spin it up. If you can be quicker about it, then we have 50 of these services in our organization at this point in time.

[0:39:36] SF: You mentioned this as it's a nuance around the definition of API first. Essentially, your definition of API first is that, or, well, the definition API first, essentially, you're designing your API first, and essentially, as a ahead of the development of the API itself. Is that right?

[0:39:55] JL: Yeah. I mean, honestly, this could be a whole podcast on its own, the definition and the nuance around API first book, correct. Designing and developing your API first. Part of design is gathering feedback from stakeholders, or at least thinking about your stakeholders, right? And future proofing. I think Etsy, Etsy has a really famous example when they were building out their mobile platform. This has been a long, long time ago. They literally built a second code base, because the first time they built out their APIs, they weren't optimized for what they needed to get done to accommodate a mobile app. They literally built a second code base.

[0:40:28] SF: Yeah, and I'm sure a lot of companies face that issue. Essentially, moved into mobile, because mobile wasn't reality, essentially, before at some intel, like years later, after they already built established APIs within the organization.

[0:40:41] JL: If you're building out today, you might not be able to see the next mobile, but you should be able to consider all of the stakeholders that are in your immediate, as well as short term.

[0:40:52] SF: As we start to wrap up, is there anything else you'd like to share?

[0:40:55] JL: I know this isn't about you, Sean, but I am curious to hear your perspective. I didn't realize you've been around alive and kicking for so long in the world of tech. I don't mean that in a bad way, but what is your perspective? Because I work with REST and the main players of APIs day in and day out, but I've only been in for the last, let's say decade. What have you noticed?

[0:41:18] SF: I mean, I think we touched on a lot of these things. I think the big trend is – and you see the same thing. My day job is around privacy and security. I think the big thing that you see that leads to adoption there is, essentially, simplicity and things working by default, secure by default. If you make it easy for people to do the right thing, then they tend to do it. Otherwise, they try to circumvent it, essentially, and figure out like, “How can I deliver on this feature, or whatever thing I'm responsible for?”

I think you're going to see the same thing in APIs. I think that's why things like REST, JSON, and then the combination of those tools, plus things, like other innovations that came along, like Node, or other programming languages that make it really easy to interface with those technologies, we just see such an explosion in adoption from those.

I think, now the big difference that I see in companies, regardless of the type of company that you're building in the technology space, a lot of times, you're starting with essentially, thinking about my product as an API. What is essentially the API interface that we're building to solve this problem, or this challenge? That didn't exist 20 years ago when I starting my career. You were thinking about what is really the UI of the thing that you're building, rather than essentially, a way of someone taking your problem and plugging into different spaces.

You weren’t thinking about abstracting at that level and making it something that people can plug in and into other software to allow them to innovate, you were just thinking about like, how do I solve this specific problem delivering this shrink draft piece of software? I think that's been the big changes. It's almost like a platform way of thinking about product innovation and product creation that didn't exist 20 years ago.

[0:42:58] JL: Yeah. I would say, maybe 12, 15 years ago, I can't remember when user experience became a buzzword, right? User experience became really important for the consumer experience. I think developer experience is becoming that important for developers. When we're talking about APIs, it really – if you're listening to this right now and you're like, “Oh, how important could DX actually be?” Go try out your product. Go try out your API. Just kick the tires fresh from scratch. It makes a huge difference. Then do the same thing for your competitor, because I've heard so many companies nowadays being compared to, like this company, but with better DX. Whole companies are being formed based on, you have a really good idea there, but you don't know how to do the user experience.

[0:43:44] SF: Yeah. I think in the world of user experience, companies like Box, one of their innovations was, they basically took consumer grade user experience and they applied it to businesses. They were one of the first companies that realized, sure, consumers care about user experience, but so does the business user, the enterprise customer they're selling to. That was one of their big innovations that led to a lot of adoption. I think now, finally, enterprises are also recognizing that developer experience is something that also can dramatically impact adoption.

There's research around this, but most people, essentially, believe that people can go from nothing to Hello World, or whatever that equivalent is, time to 200, or whatever you want to call it in less at 15 minutes. In studies, almost every API product fails to get somebody through from zero to Hello World, or to time to 200 in 15 minutes. Almost every product fails that. The best companies in the world are able to do that in five minutes under. That's the competitive landscape that you're looking at when it comes to APIs.

I always say that when you have an API product, your competitor isn't necessarily when it comes to developer experience, isn't necessarily whoever is your direct competitor when it comes to sales. When you're talking developer experience, your competitor is companies like a Twilio, or Stripe, basically the companies that set the bar for the best-in-class developer experience, that's who you're competing against, because the developers that are adopting your technology are going to be comparing you to whatever that best experience is.

It's just like, if you do lines, whatever your company is, your line competitor is Disney, because no one does lines better than Disney. That's the way your thing is. It's essentially not a direct competitor. It's an experience competitor.

[0:45:26] JL: Yeah. People like you and me, we probably check out a lot of different tech occasionally here and there. Some of the folks, you're talking about boxes business users, they might try to build an integration a few times a year, maybe? The amount of suffering is just magnitudes greater and that much more important for just losing somebody immediately.

[0:45:47] SF: Absolutely. Well, Joyce, thanks so much for being here. This was really, really fun. I guess, I'll see you in a few weeks in Croatia at the Shift Conference.

[0:45:55] JL: Yeah, sounds good. Look forward to seeing you then.

[0:45:56] SF: All right. Cheers. Thanks.

[0:45:58] JL: All right. Bye.

[END]